前言这里基于whoami示范服务，部署3个实例，分别一一验证各种类型的K8S Service服务范畴。大致逐一从下面列表逐一验证每种类型的Service访问方式：Service Name域名解析结果等CLUSTER-IPEXTERNAL-IP一些设定如下：测试环境K8S版本号为v1.27.3K8S集群Node节点IP地址段范围：10.0.1.0/24K8S集群自动生成Pod网段为10.43.0.0/24本书所列代码皆可拷贝直接粘贴到终端界面直接运行首先，部署whoami服务先部署包含3个实例的whoami：# cat << 'EOF' | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: whoami labels: app: whoami spec: replicas: 3 selector: matchLabels: app: whoami template: metadata: labels: app: whoami spec: containers: - name: whoami image: containous/whoami por ...继续阅读 (56)

业务需要将默认的K8S存储服务修改NFS，这里记录一下操作记录。列出当前StorageClass：kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE local-path (default) rancher.io/local-path Delete WaitForFirstConsumer false 17d nfs cluster.local/nfs-nfs-subdir-external-provisioner Delete Immediate true 6d14h首先，将默认的名称为local-path修改为false：kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclas ...继续阅读 (117)

前言参与开源不是为了证明什么，而是为了更好的配合工作。开源和工作在绝大部分时间，都是可以和谐共处，互相促进，Win-WIn双赢。本文内容记录了为apisix项目提交的一次pull request提交 （访问地址：https://github.com/apache/apisix/pull/3615）完整过程，提交内容为一个独立的服务发现模块，本文目的是为团队的其他同学参与社区项目分享的行为提供一个简单可遵循、可操作模型。概括来讲，简要操作流程如下：首先，确定需要开源的部分其次，在项目社区中分享我们的看法和后续行为等然后，准备提交内容接着，提交pull request，接受社区审核，反复调整修改后续，关注社区的走向，持续改进下面为每一步具体操作的流水账。提前预警，图多费流量，慎入 :))首先，我们有一个Consul KV服务发现组件作为Nginx用户，我们实际场景使用Nginx Upsync模块，结合Consul KV作为服务注册和发现形式。我们基于Apisix构建HTTP API服务网关，没有发现现成的Consul KV形式服务发现模块，既然实际业务需要，我们需要把它按照接口规范开发出来，以适应我们自己的实际场景。当服务发现模块功能开发出来后，也是仅仅能满足基本需求，还不够完善，但这时改进的思路并不是非常清楚，既然开源社区也有类似的需求，那我们可以考虑分享开源出去，接收整个社区的考验 ...继续阅读 (44)

零、前言线上运行的 APISIX 为 1.5 版本，而社区已经发布了 Apisix 2.2，是时候需要升级到最新版了，能够享受最版本带来的大量的BugFix，性能增强，以及新增特性的支持等~从Apisix 1.5升级到Apisix 2.2过程中，不是一帆风顺的，中间踩了不少坑，所谓前车之鉴后事之师，这里给大家简单梳理一下我们团队所在具体业务环境下，升级过程中踩的若干坑，以及一些需要避免的若干注意事项等。下文所说原先版本，皆指Apisix 1.5，新版则是Apisix 2.2版本。一、已有服务发现机制无法正常工作针对上游Upstream没有使用服务发现的路由来讲，本次升级没有遇到什么问题。公司内部线上业务大都基于Consul KV方式实现服务注册和服务发现，因此我们自行实现了一个consul_kv.lua模块实现服务发现流程。这在Apisix 1.5下面一切工作正常。但在Apisix 2.2下面，就无法直接工作了，原因如下：服务发现配置指令变了上游对象包含服务发现时需增加字段discovery_type进行索引2.1 服务发现配置指令变了原先运行中仅支持一种服务发现机制，需要配置在apisix层级下面：apisix: ...... discover: consul_kv ......新版需要直接在config*.yaml文件中顶层层级下进行配置，可支持多种不同 ...继续阅读 (46)

前言最近一段时间，要为一个手机终端APP程序从零开始设计一整套HTTP API，因为面向的用户很固定，一个新的移动端APP。目前还是项目初期，自然要求一切快速、从简，实用性为主。下面将逐一论述我们是如何设计HTTP API，虽然相对大部分人而言，没有什么新意，但对我来说很新鲜的。避免忘却，趁着空闲尽快记录下来。技术堆栈的选择PHP嘛？团队内也没几个人熟悉。Java？好几年没有碰过了，那么复杂的解决方案，再加上团队内也没什么人会 ……团队使用过Lua，基于OpenResty构建过TCP、HTTP网关等，对Lua + Nginx组合非常熟悉，能够快速的应用在线上环境。再说Lua语法小巧、简单，一个新手半天就可以基本熟悉，马上开工。看来，Nginx + Lua是目前最为适合我们的了。HTTP API，需要充分利用HTTP具体操作语义，来应对具体的业务操作方法。基于此，没有闭门造车，我们选择了http://lor.sumory.com/这么一个小巧的框架，用于辅助HTTP API的开发开发。嗯，OpenResty + Lua + Lor，就构成了我们简单技术堆栈。HTTP API简要设计HTTP API路径和语义每一具体业务逻辑，直接在URL Path中体现出来。我们要的是简单快速，数据结构之间的连接关系，尽可能的去淡化。eg：/resource/video/I ...继续阅读 (42)

前言在Tsung笔记之压测端资源限制篇中说到单一IP地址的服务器最多能够向外发送64K个连接，这个已算是极限了。但现在我还想继续深入一下，如何突破这个限制呢 ？如何突破限制这部分就是要从多个方面去讨论如何如何突破限制单个IP的限制。0. Tsung支持TCP情况在Tsung 1.6.0 中支持的TCP属性有限，全部特性如下：protocol_options(#proto_opts{tcp_rcv_size = Rcv, tcp_snd_size = Snd, tcp_reuseaddr = Reuseaddr}) -> [binary, {active, once}, {reuseaddr, Reuseaddr}, {recbuf, Rcv}, {sndbuf, Snd}, {keepalive, true} %% FIXME: should be an option ].比如可以配置地址重用：<option name="tcp_reuseaddr" value="true" />1. 增加IP地址这是最为现实、最为方便的办法，向运维的同事多申请若干个IP地址就好。在不考虑其它因素前提下，一个IP地址可 ...继续阅读 (44)

前言总是说细节、理论，会让人不胜其烦。我们使用Tsung来一次100万用户压测的吧，或许能够引起好多人的兴趣 :))下面，我根据在公司分享的PPT《分布式百万用户压测你的业务》，贴出其中的关键部分，说明进行一次100W(即1M)用户压测的执行步骤。如何做分布式百万用户的压测 ？假定面向小白用户，因此才有了下面可执行的10个步骤用于开展分布式百万用户。看着步骤很多，一旦熟悉并掌握之后，中间可以省却若干。1. 阅读Tsung文档建议大家在使用Tsung之前，花费一点时间阅读完整个用户手册，虽然是英文的，阅读起来也不复杂。读完之后，我们也就知道如何做测试了，遇到的大部分问题，也能够在里面找到答案。官网：http://tsung.erlang-projects.org/在线手册：http://tsung.readthedocs.io/en/latest/index.html2 确定压测目标要对线上系统压测100万用户，为了尽可能降低线上服务器负载压力，这里设置每秒产生500个用户，将在60分钟内产生完毕要压测的服务器所填写网络访问地址可以根据需要填写多个3. 计算所需要从机数量Tsung为主从模型，我们启动了主节点之后，主节点会按需启动从节点设定所用服务器可用内存大于3G，并且都只有一个IP地址一台从机可用模拟6万用户，需要17台从机若资源充足，可以少用几台服务器，配置多 ...继续阅读 (55)

前言Tsung对具体协议、通道的支持，一般以插件形式提供接口，接口不是很复杂，插件也很容易编写，支持协议多，也就不足为怪了。下面首先梳理一下当前Tsung 1.6.0所有内置插件，然后为一个名称为Qmsg的私有二进制协议编写插件, 运行Qmsg服务器端程序，执行压力测试，最后查看测试报告。已支持插件梳理Tsung 1.6.0支持的协议很多，简单梳理一下：压测的协议首先需要支持xml形式配置，配置内容需要tsung_config_protocolname模块解析存放在tsung_controller目录下其次是tsung client端也要插件ts_protocolname模块支持数据操作存放在tsung目录下同时在tsung项目examples目录下也给出了已支持协议配置简单示范xml文件已经支持协议简单说明：amqp，Advanced Message Queuing Protocol缩写，只要支持高级消息队列协议的应用，都可以用来做压测，比如RabbitMQ，ActiveMQ等http，基本协议，构建于HTTP协议之上的，还有类似于BOSH，WebDav等上层业务协议jabber，也称之为XMPP，支持的相当丰富，除了TCP/SSl，还可以通过Websocekt进行传递raw，针对原始类型消息，不做编解码处理，直接在TCP / UDP / SSL等传输层中传递，这个对部分私有协 ...继续阅读 (85)

前言压力测试和监控分不开，监控能够记录压测过程中状态，方便问题跟踪、定位。本篇我们将讨论对压测客户端tsung client的监控，以及对被压测服务器的资源占用监控等。同时，也涉及到Tsung运行时的实时诊断方式，这也是对Tsung一些运行时状态的主动监控。压测客户端的监控压测端（指的是tsung client）会收集每一个具体模拟终端用户（即ts_client模块）行为数据，发送给主节点（tsung_controller），供后面统计分析使用。ts_client模块调用ts_mon，而ts_mon又直接调用ts_mon_cache，有些绕，不直观（逻辑层面可忽略掉ts_mon）count为计数器，sum表示各项累加值，sample和sample_counter计算一次统计项的平均值&标准差tsung.dump文件一般不会创建&写入，除非你在tsung.xml文件中指定需要dump属性为true，压测数据量大时这个会影响性能match.log仅仅针对HTTP请求，默认不会写入，除非在HTTP压测指定<http url="/" method="GET" version="1.1"/> <match do=’log’ when=’match’ name=’http_match_20 ...继续阅读 (57)

前言前面说到设计一个小型的C/S类型远程终端套件以替换SSH，并且已经应用到线上。这个问题，其实不是Tsung自身的问题，是外部连接依赖问题。Tsung在启动分布式压测时，主节点tsung_controller要连接的从机必须要填写主机名，主机名没有内网DNS服务器支持解析的情况下(我所经历互联网公司很少有提供支持的)，只好费劲在/etc/hosts文件中填写主机名称和IP地址的映射关系，颇为麻烦，尤其是要添加一批新的压测从机或从机变动频率较大时。那么如何解决这些问题呢，让tsung在复杂的机房内网环境下，完全基于IP进行直连，这将是本文所讨论的内容。预备知识完全限定域名完全限定域名，缩写为FQDN (fully qualified domain name)，赛门铁克给出的中文定义：一种用于指定计算机在域层次结构中确切位置的明确域名。一台特定计算机或主机的完整 Internet 域名。FQDN 包括两部分：主机名和域名。例如 mycomputer.mydomain.com。一种包含主机名和域名（包括顶级域）的 URL。例如，www.symantec.com 是完全限定域名。其中 www 是主机，symantec 是二级域，.com 是顶级域。FQDN 总是以主机名开始且以顶级域名结束，因此www.sesa.symantec.com也是一个 FQDN。若机器主机名为内网域名形式，并且 ...继续阅读 (68)

前言Erlang天生支持分布式环境，Tsung框架的分布式压测受益于此，简单轻松操控子节点生死存亡、派发任务等不费吹灰之力。Tsung启动分布式压测时，主节点tsung_controller默认情况下需要通过SSH通道连接到远程机器上启动从节点，那么问题便来了，一般互联网公司基于跳板/堡垒机/网关授权方式访问机房服务器，那么SSH机制失效，并且被明令禁止。SSH不通，Tsung主机启动不了从机，分布式更无从谈起。那么如何解决这个问题呢，让tsung在复杂的机房网络环境设定下更加如鱼得水，将是本文所讨论的内容。RSH：Remote ShellRSH，remote shell缩写，维基百科上英文解释：https://en.wikipedia.org/wiki/Remote_Shell。作为一个终端工具，Linux界鸟哥曾经写过RSH客户端和服务器端搭建教程。在CentOS下安装也简单：yum install rshErlang借助于rsh命令行工具通过SSH通道连接到从节点启动Tsung应用，下面可以看到rsh工具本身失去了原本的含义，类似于exec命令功效。比如Erlang主节点（假设这个服务器名称为node_master，并且已经在/etc/hosts文件建立了IP地址映射）在启动时指定rsh的可选方式为SSH：erl -rsh ssh -sname foo -setcookie ...继续阅读 (62)

前言这里汇集一下影响tsung client创建用户数的各项因素。因为Tsung是IO密集型的应用，CPU占用一般不大，为了尽可能的生成更多的用户，需要考虑内存相关事宜。IP & 端口的影响系统端口限制Linux系统端口为short类型表示，数值上限为65535。假设分配压测业务可用端口范围为1024 - 65535，再加上一台服务器上可能还运行着其它对内或对外连接的服务，真正可用端口也就是65000左右（实际上为了便于计算可假定为50000）。即在一台机器上一个IP，可用同时对外建立65000网络连接。若是N个可用IP，理论上 65000*N，实际上还需要满足：充足内存支持tcp接收/发送缓冲区不要设置太大，tsung默认分配32K（可以修改成16K，一般够用了）一个粗略估算一个连接占用80K内存，那么10万用户，将占用约8G内存为多IP的压测端分配适合的权重，以便承担更多的终端连接另外还需要考虑端口的快速回收等，可以这样做：sysctl -w net.ipv4.tcp_syncookies=1 sysctl -w net.ipv4.tcp_tw_reuse=1 sysctl -w net.ipv4.tcp_tw_recycle=1 sysctl -w net.ipv4.tcp_fin_timeout=30 sysctl -w net.ipv4.ip_local_port ...继续阅读 (55)

前言接着上文，tsung一旦启动，主从节点之间需要协调分配资源，完成分布式压测任务。如何启动Tsung压测从机Erlang SDK提供了从机启动方式：slave:start(Host, Node, Opts)启动从机需要借助于免登陆形式远程终端，比如SSH（后续会讨论SSH存在不足，以及全新的替代品），需要自行配置。<client host="client_100" maxusers="60000" weight="1"> <ip value="10.10.10.100"/> </client>host属性对应value为从机主机名称：client_100Node节点名称由tsung_controller组装，类似于tsung10@client_100Opts表示相关参数一个物理机器，可以存在多个tsung从机实例一个tsung从机实例对应一个tsung client简单翻译一下：slave:start(client_100, 'tsung10@client_100', Opts)从机需要关闭时，就很简单了：slave:stop(Node)当然若主机中途挂掉，从机也会自动自杀掉自身。启动tsung client方式Tsung主机启动从机成功，从机和主机就可以E ...继续阅读 (83)

前言本篇讲解Tsung大致功能组成、结构，以及主从模型，以便总体上掌握。总体组成tsung_controller和tsung这两个模块，负责分布式压测的核心功能。代码组成从代码层次梳理一下tsung项目功能组成结构，便于一目了然，方便直接索引。主从模型一览设定环境为分布式环境下Tsung集群，下面简单梳理一下主、从节点启动流程。流程大致说明：主节点（tsung_controller）通过SSH或其它远程终端（后面会讲到操作更为轻量的完全替代SSH方式）连接到从服务器启动tsung从节点运行时环境主节点RPC批量启动tsung client进程主节点为每一个从节点启动会话监控，控制会话速度，开启ts_client模拟终端从节点请求主节点具体业务进程，获取会话指令以及会话具体内容从节点建立到目标压测服务器的SOCKET网络连接，开始会话主节点可以通过SSH/其它终端方式连接到目标压测服务器，启动从节点，然后收集数据（可选，具体细节，后续文字会讲到）这种模型下：全局严格控制模拟终端用户生成总量和生成速度主节点动态管理从节点生命周期，从生到死，并且掌握着所有会话细节，全局掌控从节点很轻，所有需要的会话指令，都必须请求主节点获得主从之间交互流程下面一张图简单说明了主从之间核心模块交互流程，虽然粗略，核心点也算是涉及到了。后面会对具体协议部分有更为详细论述。一次压测回话（ts_clie ...继续阅读 (67)

前言有测试驱动的开发模式，目的在于确保业务层面功能是准确的，每一次新增、修改等动作确保都不会影响到现有功能。功能开发完成了，需要部署到线上，系统能够承载多大的用户量呢，这时候就需要借助于性能压测，也称之为压力测试，界定系统能够承载具体容量上限，从容应对业务的运营需要，扩容或缩容，心中有底。工欲善其事，必先利其器。掌握一种压测工具，并切实应用到实践环境中，并以此不断迭代，压力测试驱动推动所开发后端应用处理性能逐渐完善。目前成熟的支持支持TCP、HTTP等连接通道的压测工具不少，以前接触过Apache JMeter，后面又接触过Tsung，因为在实际环境下使用比较多，支持丰富的业务场景定义，并且可扩展性强，因此Tsung强力推荐之。为什么要选择Tsung基于Erlang，并发处理性能好，可以模拟足够多海量用户，只要你有足够多的机器受益于Erlang，天然支持分布式，很欢快的运行在一个集群中支持协议众多 WebDAV/WebScoket/MQTT/MySQL/PGSQL/Shell/AQMP/JABBER/XMPP/LDAP 等传输通道支持 TCP/UDP/SSL，更底层支持IPv4/IPv6支持单机绑定多个IP：无论是虚拟IP，还是物理网卡绑定IP，可以突破单机端口65535的限制，扩展尽可能多的网络连接出口地址支持监控被压测的服务器，通过Erlang Agent/SNMP/Munin ...继续阅读 (69)

零。前言TCP自从1974年被发明出来之后，历经30多年发展，目前成为最重要的互联网基础协议。有线网络环境下，TCP表现的如虎添翼，但在移动互联网和物联网环境下，稍微表现得略有不足。移动互联网突出特性不稳定：信号不稳定，网络连接不稳定。虽然目前发展到4G，手机网络带宽有所增强，但因其流动特性，信号也不是那么稳定：坐长途公交车，或搭乘城铁时，或周边上网密集时等环境，现实环境很复杂。以下讨论基于Linux服务器环境，假定环境为移动互联网环境。记录我目前所知TCP的一些不足，有所偏差，请给与指正。一。三次握手在确定传递数据之前需要三次握手，显然有些多余，业界提出了TCP Fast Open (TFO)扩展机制，两次握手之后就可以发送正常业务数据了。但这需要客户端和服务器端内核层面都支持才行： Linux内核3.6客户端，3.7支持服务器端。进阶阅读：TCP Fast Open: expediting web services二。慢启动一次的HTTP请求，应用层发送较大HTML页面的数据，需要经过若干个往返循环时间(Round-Trip Time)之后，拥塞窗口才能够扩展到最大适合数值，中间过程颇为冗余。这个参数直接关系着系统吞吐量，吞吐量大了，系统延迟小了。但设置成多大，需要根据业务进行抉择。3.0内核之前初始化拥塞窗口(initcwnd)大小为3。一个已建立连接初始传输数据时可传递3个 ...继续阅读 (303)

零。前言TCP是无感知的虚拟连接，中间断开两端不会立刻得到通知。一般在使用长连接的环境下，需要心跳保活机制可以勉强感知其存活。业务层面有心跳机制，TCP协议也提供了心跳保活机制。一。TCP Keepalive解读长连接的环境下，人们一般使用业务层面或上层应用层协议（诸如MQTT，SOCKET.IO等）里面定义和使用。一旦有热数据需要传递，若此时连接已经被中介设备断开，应用程序没有及时感知的话，那么就会导致在一个无效的数据链路层面发送业务数据，结果就是发送失败。无论是因为客户端意外断电、死机、崩溃、重启，还是中间路由网络无故断开、NAT超时等，服务器端要做到快速感知失败，减少无效链接操作。1. 交互过程2. 协议解读下面协议解读，基于RFC1122#TCP Keep-Alives。TCP Keepalive虽不是标准规范，但操作系统一旦实现，默认情况下须为关闭，可以被上层应用开启和关闭。TCP Keepalive必须在没有任何数据（包括ACK包）接收之后的周期内才会被发送，允许配置，默认值不能够小于2个小时不包含数据的ACK段在被TCP发送时没有可靠性保证，意即一旦发送，不确保一定发送成功。系统实现不能对任何特定探针包作死连接对待规范建议keepalive保活包不应该包含数据，但也可以包含1个无意义的字节，比如0x0。SEG.SEQ = SND.NXT-1，即TCP保活探测报文序列号 ...继续阅读 (69)

零。前言这里讲的移动APP主要指的是安卓平台，大部分情况也适用于IOS等移动平台，可能重点嘛会在后半部分呢。一。嵌入多SDK存在的隐患但凡一个常用的APP都会嵌入至少一个SDK，不同来源或同一来源，有广告SDK，有推送SDK，有性能汇报SDK，有用户跟踪SDK，有统计流量SDK等，有支付SDK等等。虽然带来了功能的复用和解耦，便于纵向扩展，但可能会存在：一个SDK可以看做一个后台Service，多个SDK多个Service存在（粗略上计算）运行缓慢的问题，多个SDK或多功能的模块（若不按需加载的话）会导致运行缓慢，符合木桶理论，最慢的那个拖慢了总体步伐每一个SDK都有自己核心诉求，各自为政，实现方式各异。总体架构是否合适，带来了隐形的兼容成本彼此协调运作兼容性问题，一旦出现某个隐含BUG，会不会导致连锁反应CPU、内存、网络等资源竞争问题，想协调都很难网络资源各自为政，无法共享，更不用提连接复用若是同一来源的SDK，当问题发生的时候还能够有所协作稍作调整，虽然这也是比较理想的情况。外部的SDK可能问题反馈和BUG修正，时效性就不太好说了。解耦虽然带来了功能的扩展性，带随之带来了资源利用方面的重复和浪费，愈多的SDK嵌入越有可能导致总体运行缓慢，需要谨慎使用。二。APP后台Service数量很多一般安卓手机会提供后台进程的查看，一般APP会启动多个后台服务，比如爱奇艺APP就很变态， ...继续阅读 (106)

零。前言这里整理了一下错误和安全相关部分简单记录。一。HTTP/2错误1. 错误定义HTTP/2定义了两种类型错误：导致整个连接不可使用的错误为连接错误(connection error)单独出现在单个连接上的错误为流错误(stream error)2. 错误代码错误代码，32位正整数表示错误原因，RST_STREAM和GOAWAY帧中包含。未知或不支持的错误代码可以选择忽略，或作为INTERNAL_ERROR错误对待都可以。3. 连接错误处理一般来讲连接错误很严重，会导致处理进程无法进行下去，或影响到整个连接的状态。终端一旦遇上连接错误，需第一时间在最后一个可用流上发送包含错误原因GOAWAY帧过去，然后关闭连接GOAWAY有可能不被对端成功接收到，若成功接收可获得连接被终止的原因终端可在任何时间终止连接，也可以把流错误作为连接错误对待。但都应该在关闭连接之前发送一个GOAWAY帧告知对方4. 流错误一般来讲具体流上的流错误不会影响到其它流的处理。终端检测到流错误，需要发送一个RST_STREAM帧，其包含了操作到错误流标识符RST_STREAM应当是发送错误流最后一个帧，内含错误原因。发送方在发送之后，需要准备接收对端将要或即将发送过来的帧数据，处理方式就是忽略之，除非是可以修改连接状态帧一般来讲，终端不应该发送多个RST_STREAM帧，但若在一个往返时间之后已关闭的流上能够 ...继续阅读 (54)

前言无论是HTTP/1.*还是HTTP/2，HTTP的基本语义是不变的，比如方法语义（GET/PUST/PUT/DELETE），状态码（200/404/500等），Range Request，Cacheing，Authentication、URL路径。以前纯文本形式作为传输的载体，HTTP/2带来了与之不同的二进制传输语法语义。下面为HTTP/2消息交换方便笔记。请求/响应流程一个典型的HTTP消息包含请求/响应，组成如下：以响应为例，零或多个HEADERS帧（每一个HEADERS帧可能跟着>=0个CONTINUATION帧，以补充单个HEADERS容量不够的情况）包含状态码为1xx的报文头响应或者一个HEADERS帧包含了完整的报文头（一般情况下）零个或多个DATA数据帧包含了具体的消息负载内容一个HEADERS帧，后面跟随零个或多个包含有报尾（trailer-part）的CONTINUATION帧，作为可选项注意事项：一个HEADERS帧携带有END_STREAM标志，后面可跟随有CONTINUATION帧用以补充剩余的包头块来自于其它流的类型帧是不能够出现在HEADERS帧和CONTINUATION帧中间DATA数据帧不支持分块传输编码（chunked transfer encoding）报尾字段（Trailing header field）当出现在报头块中时，可以终止当前流 ...继续阅读 (51)

零。前言客户端和服务器端一旦握手协商成功接建立连接，端点之间可以基于HTTP/2协议传递交换帧数据了。一。帧通用格式下图为HTTP/2帧通用格式：帧头+负载的比特位通用结构：+-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+ ...继续阅读 (52)

零。前言本部分将讲解HTTP/2协议中对流的定义和使用，其实就是在说HTTP/2是若何做到多路复用的。一。流和多路复用的关系1. 流的概念流（Stream），服务器和客户端在HTTP/2连接内用于交换帧数据的独立双向序列，逻辑上可看做一个较为完整的交互处理单元，即表达一次完整的资源请求-响应数据交换流程；一个业务处理单元，在一个流内进行处理完毕，这个流生命周期完结。特点如下：一个HTTP/2连接可同时保持多个打开的流，任一端点交换帧流可被客户端或服务器单独或共享创建和使用流可被任一端关闭在流内发送和接收数据都要按照顺序流的标识符自然数表示，1~2^31-1区间，有创建流的终端分配流与流之间逻辑上是并行、独立存在2. 多路复用流的概念提出是为了实现多路复用，在单个连接上实现同时进行多个业务单元数据的传输。逻辑图如下：实际传输可能是这样的：只看到帧(Frame)，没有流（Stream）嘛。需要抽象化一些，就好理解了：每一个帧可看做是一个学生，流可以认为是组（流标识符为帧的属性值），一个班级（一个连接）内学生被分为若干个小组，每一个小组分配不同的具体任务。HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个小组任务都需要建立一个班级，多个小组任务多个班级，1:1比例HTTP/1.1 Pipeling解决方式为，若干个小组任务排队串行化单线程处理，后面小组任务等待前面小组任务完 ...继续阅读 (115)

前言HTTP/2协议在TCP连接之初进行协商通信，只有协商成功，才会涉及到后续的请求-响应等具体的业务型数据交换。HTTP版本标识符h2，基于TLS之上构建的HTTP/2，作为ALPN的标识符，两个字节表示，0x68, 0x32，即httpsh2c，直接在TCP之上构建的HTTP/2，缺乏安全保证，即http在HTTP/2 RFC文档出现之前，以上版本字段需要添加上草案版本号，类似于h2-11,h2c-17HTTP/2 请求过程针对直接建立在标准TCP之上HTTP2，在未知服务器是否提供HTTP/2支持之前，可以依赖现有HTTP/1.1进行试探。HTTP版本的请求内容客户端发起请求，只有请求报头：GET/ HTTP/1.1Host:server. example. comConnection:Upgrade, HTTP2-SettingsUpgrade:h2c HTTP2-Settings:2SETTINGS payload>服务器若不支持HTTP/2，直接按照HTTP/1.1响应即可HTTP/1.1200OK Content-Length:243Content-Type:text/html . . .服务器支持HTTP/2，通知客户端一起切换到HTTP/2协议下吧HTTP/1. 1101Switching ProtocolsConnection:UpgradeUpgrade:h2 ...继续阅读 (53)

前言本系列基于HTTP/2第17个草案文档，地址就是：https://tools.ietf.org/html/draft-ietf-httpbis-http2-17。HTTP/2规范已经通过发布批准，下面等待分配具体的RFC号码，不会有所较大的变动了。本笔记不是直接翻译，记录成笔记方便以后学习。HTTP/1.1的问题一张图可以很较为全面的概括了HTTP/1.*存在缺陷：前端一般采用： - CSS Spriting，小图合并成大图，CSS进行分割成小图显示 - Inlining，使用DataURL方式内嵌Base64编码格式图片 - JS Concatenation，多个JS文件合并成一个，缺陷是一旦有文件修改，需要重新合并 - Sharding，将资源/服务部署到多个机器上，均摊/分享请求压力HTTP/1.*没有充分利用TCP特性，再加上同一个站点打开多个连接等，导致网络资源利用率不高。HTTP/2改进点与HTTP/1相比，主要区别包括：HTTP/2采用二进制格式而非文本格式高效紧凑传输解析更少错误倾向，没有了所谓的空白行、大写、换行符、空连接等HTTP/2是完全多路复用的，而非有序并阻塞的HTTP/1.1默认情况下单个请求单个连接HTTP/1.1流水线化pipelining方式导致较大/较慢的响应阻塞后续任务HTTP/1.1无法解决线头阻塞的问题多路复用可以有效避免线头阻塞，多个 ...继续阅读 (57)

前言因为能力有限，还是有很多东西（SO_REUSEADDR和SO_REUSEPORT的区别等）没有能够在一篇文字中表达清楚，作为补遗，也方便以后自己回过头来复习。SO_REUSADDR VS SO_REUSEPORT两者不是一码事，没有可比性。有时也会被其搞晕，自己总结的不好，推荐StackOverflow的Socket options SO_REUSEADDR and SO_REUSEPORT, how do they differ?资料，总结的很全面。简单来说：设置了SO_REUSADDR的应用可以避免TCP 的 TIME_WAIT 状态 时间过长无法复用端口，尤其表现在应用程序关闭-重启交替的瞬间SO_REUSEPORT更强大，隶属于同一个用户（防止端口劫持）的多个进程/线程共享一个端口，同时在内核层面替上层应用做数据包进程/线程的处理均衡若有困惑，推荐两者都设置，不会有冲突。Netty多线程使用SO_REUSEPORT上一篇讲到SO_REUSEPORT，多个程绑定同一个端口，可以根据需要控制进程的数量。这里讲讲基于Netty 4.0.25+Epoll navtie transport在单个进程内多个线程绑定同一个端口的情况，也是比较实用的。TCP服务器，同一个进程多线程绑定同一个端口这是一个PING-PONG示范应用：publicvoidrun()throwsExcepti ...继续阅读 (223)

前言本篇用于记录学习SO_REUSEPORT的笔记和心得，末尾还会提供一个bindp小工具也能为已有的程序享受这个新的特性。当前Linux网络应用程序问题运行在Linux系统上网络应用程序，为了利用多核的优势，一般使用以下比较典型的多进程/多线程服务器模型：单线程listen/accept，多个工作线程接收任务分发，虽CPU的工作负载不再是问题，但会存在：单线程listener，在处理高速率海量连接时，一样会成为瓶颈CPU缓存行丢失套接字结构(socket structure)现象严重所有工作线程都accept()在同一个服务器套接字上呢，一样存在问题：多线程访问server socket锁竞争严重高负载下，线程之间处理不均衡，有时高达3:1不均衡比例导致CPU缓存行跳跃(cache line bouncing)在繁忙CPU上存在较大延迟上面模型虽然可以做到线程和CPU核绑定，但都会存在：单一listener工作线程在高速的连接接入处理时会成为瓶颈缓存行跳跃很难做到CPU之间的负载均衡随着核数的扩展，性能并没有随着提升比如HTTP CPS(Connection Per Second)吞吐量并没有随着CPU核数增加呈现线性增长：Linux kernel 3.9带来了SO_REUSEPORT特性，可以解决以上大部分问题。SO_REUSEPORT解决了什么问题linux man文档中一段 ...继续阅读 (489)

前言前面啰啰嗦嗦的几篇文字，各个方面介绍了Fastsocket，盲人摸象一般，能力有限，还得继续深入学习不是。这不，到了该小结收尾的时候了。缘起，内核已经成为瓶颈使用Linux作为服务器，在请求量很小的时候，是不用担心其性能。但在海量的数据请求下，Linux内核在TCP/IP网络处理方面，已经成为瓶颈。比如新浪在某台HAProxy服务器上取样，90%的CPU时间被内核占用，应用程序只能够分配到较少的CPU时钟周期的资源。经过Haproxy系统详尽分析后，发现大部分CPU资源消耗在kernel里，并且在多核平台下，kernel在网络协议栈处理过程中存在着大量同步开销。同时在多核上进行测试，HTTP CPS(Connection Per Second)吞吐量并没有随着CPU核数增加呈现线性增长：内核3.9之前的Linux TCP调用kernel 3.9之前的tcp socket实现bind系统调用会将socket和port进行绑定，并加入全局tcp_hashinfo的bhash链表中所有bind调用都会查询这个bhash链表，如果port被占用，内核会导致bind失败listen则是根据用户设置的队列大小预先为tcp连接分配内存空间一个应用在同一个port上只能listen一次，那么也就只有一个队列来保存已经建立的连接nginx在listen之后会fork处多个worker，每个wor ...继续阅读 (306)

前言前面分析Fastsocket慢慢凑成了几篇烂文字，要把一件事情坚持做下来，有时味同爵蜡，但既然选择了，也得硬着头皮做下去。闲话少说，文归正文。本文接自上篇内核模块篇，继续记录学习Fastsocket内核的笔记内容。Fastsocket建立在SO_REUSEPORT支持基础上Linux kernel 3.9包含TCP/UDP支持多进程、多线程绑定同一个IP和端口的特性，即SO_REUSEPORT；在内核层面同时也让线程/进程之间各自独享SOCKET，避免CPU核之间以锁资源争夺accept queue的调用。在fastsocket/kernel/net/sock.h定义sock_common结构时，可以看到其身影：unsignedcharskc_reuse:4;unsignedcharskc_reuseport:4;在多个socket.h文件中（比如fastsocket/kernel/include/asm/socket.h），定义了SO_REUSESORT的变量值：#define SO_REUSEPORT15在fastsocket/kernel/net/core/sock.c的sock_setsockopt和sock_getsockopt函数中，都有SO_REUSEPORT的身影：sock_setsockopt函数中：caseSO_REUSEADDR:sk->sk_reuse ...继续阅读 (260)

前言本篇学习Fastsocket内核模块fastsocket.so，作为用户态libfsocket.so的内核态的支持，处理ioctl传递到/dev/fastsocket的数据，非常核心和基础。嗯，还是先翻译，随后挟带些点评进来。模块介绍Fastsocket内核模块 (fastsocket.ko) 提供若干特性，并各自具有开启和关闭等丰富选项可配置。VFS 优化CentOS 6.5带来的内核锁竞争处处可见，导致无论如何优化TCP/IP网络堆栈都不能够带来很好的性能扩展。比较严重锁竞争例子，inode_lock和dcache_lock，针对套接字文件系统sockfs而言，并不是必须。fastsocket通过在VFS初始化结构时提供fastpath快速路径用以解决此项问题，已经向代号为香草（vanilla）的内核提交了两处修改：a209dfc vfs: dont chain pipe/anon/socketonsuperblock s_inodeslist4b93688 fs: improve scalabilityofpseudo filesystems此项修改没有提供选项可供配置，因此所有fastsocket创建的套接字sockets都会强制经由fastpath传输。内核模块参数enable_listen_spawnfastsocket为每个CPU创建了一个本地socket监听表（ ...继续阅读 (100)

前言本篇为fastsocket的动态链接库学习笔记，对应源码目录为 fastsocket/library，先翻译README.md文件内容，后面添加上个人学习心得。介绍动态链接库libfsocket.so，为已有应用程序提供加速服务，具有可维护性和兼容性。可维护性：Fastsocket优化在于重新实现套接字的系统调用从而达到Linux内核网络堆栈效率的提高。而应用程序是不用修改这些系统调用，借助于Fastsocket就可以达到加速的目的。Fastsocket在内核模块提供了一个新的ioctl接口，供上层应用程序调用。兼容性：若让应用程序必须修改其代码以适应新的系统调用接口，在现实世界中这很麻烦也不可行。借助于libfsocket拦截系统调用并提供新的接口进行替换系统调用，同时Fastsocket提供了与BSD socket完全兼容的调用接口，这使得应用程序在无需更改任何代码的情况下，可直接使用Fastsocket，获得网络加速的效果。编译很简单，进入目录之后，执行make命令编译即可：cdfastsocket/librarymake最后在当前目录下生成libfsocket.so文件。用法很简单的说，借助于LD_PRELOAD加载libfsocket.so，启动应用程序，以nginx为例：LD_PRELOAD=/your_path/fastsocket/library/libfsoc ...继续阅读 (69)