TCP 延迟分析

Posted on by 11 Comments

本文是对《延迟增加了多少？》一文的答案和分析。

总延迟应该是 900ms 左右。

Ping 的延迟指的是 RTT, Round Trip Time. 即一个包发过去，对方发一个包回来，总延迟是 200ms。一种误解是认为 ping 测得的延迟是 200ms，所以一个请求发过去是 200ms，响应发回来是 200ms，总延迟是 400ms。如果仔细想一想的话，我们在发送端测量延迟的时候，没有办法只测量一个包从发送端达到接收端的延迟。除非是让接收端在回复的时候记录收到包的时间？但是发送端和接收端的时钟可能不一致，如果精确测量的话，协议上就要依赖不同的机器时钟对齐。直接让总时间除以 2？这也意义不大，因为包去和回的路线不一定一样，延迟也不一定是一半一半。所以我们在讨论延迟的时候，都是默认 RTT。

TCP 握手的延迟是 1 个 RTT，即 200ms。这里也有很多人会有一个误解，就是认为「TCP 是三次握手，所以握手带来的延迟是 1.5 RTT」。这个误解是因为教科书的 TCP 序列图太迷惑了，看起来像是握手需要发送 3 个包，之后才能发送数据。实际上，在握手阶段，第三个包 ACK 发出之后，发送端直接开始发送数据。即，客户端发送 SYN 建立握手，收到 SYN+ACK，消耗了 1 个 RTT；发送端随即发送 ACK，然后直接进入数据发送阶段，开始发送数据。所以握手阶段第三个 ACK 包是不会带来延迟的。

很多教材的 TCP 握手序列图是这样
但其实应该是这样，在第三个 ACK 发送之后直接开始发送数据

上文题目提到，请求的大小是 16KiB，这里经常出现的误解是：「一个 Frame 的 MTU 是 1500bytes，减去 20 bytes IP header 和 20 bytes TCP header，一个包携带的实际数据是 1460 bytes，所以 16KiB 请求传输完成是 16KiB/1460 bytes 个 RTT。」这也是被教科书常用的序列图迷惑了，TCP 传输中，发送端并不是发送一个包，等待 ACK，发送下一个包……而是直接传输很多包，接收端可以直接用一个 ACK 去 ACK 多个包。发送端是「一组包一组包地发送」，而不是「一个包一个包地发送」。

错误的序列图：每一个数据都等待 ACK
实际上一直发送数据，直到达到 rwnd 或者 cwnd 的瓶颈

那么一下子可以发送多少个包呢？发送端可以一下子把 16KiB 的数据都发送完吗？这里涉及到 TCP 的拥塞控制了。为了避免过载接收端和中间链路上的路由器等设备，TCP 发送端发送出去但是未确认的数据会保持在接收端窗口 (rwnd)和拥塞控制窗口之内 (cwnd)。接收端的窗口一般不是瓶颈，所以这里忽略不讨论。cwnd 在 Linux 的初始值是 10，即 TCP 连接建立之后，会一下子发送 10 个 MSS 的数据，即 1460 bytes * 10 大约是 14.6KiB 的数据。然后会等待接收端发送回来 ACK，再开始下一轮数据的发送，并且逐渐增大 cwnd。对于响应，同理，这时候服务 B 的服务器变成了发送端，也是需要发送两轮数据。更详细的解释可以阅读这篇：《TCP 拥塞控制对数据延迟的影响》。

最后，来到了四次挥手。这里的误解是 TCP 断开连接 4 次挥手需要花费 2 个 RTT。实际上，断开连接的过程是不产生耗时的，因为在 TCP 断开连接之前，应用的请求已经发送完成，响应也已经收到，kernel 已经将收到的数据送给了用户态，用户态的程序已经继续运行了。即使应用调用 close(), 也是直接返回，kernel 再慢慢处理关闭连接的过程。所以断开连接是 kernel 来做的「收尾工作」，不会贡献请求处理的延迟。

综上，总结一下，实际耗时是 900ms，其中：

  • TCP 建立连接需要 1 个 RTT；
  • 如果是 HTTP 请求很小，响应也很小，那么请求和响应需要耗费 1 个 RTT；
  • 但是 HTTP 请求很大，因为 cwnd 的限制，需要额外耗费 1 个 RTT 来传输；
  • 同理，响应也很大，也需要额外花费 1 个 RTT；
  • 服务端程序处理需要花费 100ms，保持不变；

最后是 200ms * 4 个 RTT + 100ms = 900ms；

再留一个问题给读者：你知道应该如何优化，让这个请求耗费的延迟最小吗？（分析一下最小延迟是多少，一个 RTT 用来传输数据是比不可少的，服务端的 100ms 也无法节省，所以最小延迟是 300ms，如何从 900ms 优化到 300ms 呢？）

提示

目录

这个系列正在连载中，没有链接的目录还没有写完，敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器？
  7. 网工闯了什么祸？
  8. 网络中的环路和防环技术
  9. 延迟增加了多少？
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手：答案和解析
  13. 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
如果本文对您有帮助，欢迎打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
 

延迟增加了多少？

Posted on by 8 Comments

小周（就是你！）所在的团队管理着一个服务 A，这个服务 A 需要访问服务 B 的 HTTP 接口。服务 A 和服务 B 部署在同一个 IDC 中，所以延迟很低，可以忽略不计。服务 B 处理请求需要花费 100ms，所以一个 HTTP 请求的总延迟大概是 100ms。

服务A在同一个 IDC 中请求服务 B

最近由于合规的要求，服务 B 需要迁移到另一个 IDC 中，物理延迟会上升。迁移之后，如果从服务 A 的 IP 去 ping 服务 B 的 IP，ping 显示延迟为 200ms。

服务 B 迁移到了另一个 IDC，这时候 ping 是 200ms

在打开抓包文件分析之前，请问：如果服务 A 发送一个 HTTP 请求到服务 B，总延迟现在是多少？

注意：

  • TCP 需要重新建立连接
  • 请求的大小是 16KiB
  • 响应的大小是 20KiB

然后用 Wireshark 打开抓包文件，分析实际的延迟是多少？和自己的答案作对比。

tcp-latency.pcap_下载

提示：在分析延迟问题的时候，可以使用这里的方法，打开 Time Delta 列。

目录

这个系列正在连载中，没有链接的目录还没有写完，敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器？
  7. 网工闯了什么祸？
  8. 网络中的环路和防环技术
  9. 延迟增加了多少？
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手：答案和解析
  13. 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
如果本文对您有帮助，欢迎打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
 

Hot Potato Routing

Posted on by 7 Comments

Hot Potato Routing——烫手的山芋。指的是 ISP 在路由转发的时候，不会选择最优的路线，而是会选择最快能把这个包转出自己的自治域的路线。

如下图的路由中，假设有 3 个 ISP，分别控制 3 个自治系统AS（Autonomous System）。如果有一个包要从 A 转发到 X，那么在 AS1 中，A 路由器将会把包转发给 B，B 如果采用 Hot Potato Routing，将会直接把包转发给 D，完整的路线是 B-D-G-F-X，图中蓝色线路所示。而实际上最短的路径应该是 A-B-E-F-X（假设途中所有线路的 metric 相等，我们只看跳数）。

Hot Potato Routing例子，从 A 到 X 会走 A-B-D-G-F-X 路线

B 路由器之所以这样做，是因为在运营商的网络里，质量是第二要考虑的内容，Policy 才是第一要考虑的。路由器 B 已经知道全局最优路线是 E，但是如果选择全局最优路线，那么就需要经过 AS1 的另一台路由器 E，即 B-E 要转发这个包，但是如果直接丢给 D，E 就不用做转发了，这样，AS1 的工作就最少。

维基百科中说，Hot Potato Routing 是大部分运营商的路由策略。Hot-potato routing (or “closest exit routing”) is the normal behavior generally employed by most ISPs.

每个人都在用最自私的策略来降低自己的工作量，但是却让全局的工作量增加了，自己的工作量实际上也是增加了的，整体的服务质量却降低了——用户的请求需要绕得更远才能到达目标。

这不就是很多大公司的工作方式吗？

大公司给每个人规定了 KPI（就不提 OKR 了，OKR 在大部分公司的实践其实就是 KPI）。收到新的任务，每个人做的最优选择就是把和 KPI 不相关的工作「转发」出去。

刚加入蚂蚁金服的时候，带我的师兄让我找 A 同事要一个测试环境，来熟悉我要接手的业务。于是我去找 A，A 让我找 B，B 让我找 C——一直找了 6 个人，给我一点小小的震撼，我上家公司技术人员才不过 20 人，现在入职 1 天就认识了 6 个人，不愧是大公司。最神奇的是，最后一个人也没给我答案，而是让我找第一个人 A，居然出现环路了。

在蚂蚁的时光，有一半是在「闭关室」度过的。「闭关」也是一个我第一次经历、现在想想很可笑的事情。「闭关」就是一个团队不在原来的工位办公了，大家都搬到一个会议室里面工作，会议室预定几个月。美名为「项目攻关」。别人过来问问题，提需求，我们都可以说「我们在闭关，需要专心做我们的项目。」但是我们的工作也会遇到问题，需要其他的团队配合，于是我们去找其他团队合作，其他团队也是「不好意思，我们在闭关。」最后就成了你也在闭关，他也在闭关，大家都在闭关。

我觉得最理想的工作方式是像 DNS Recursive Resolver 一样。有人来问我问题，我应该给他解答。如果我不知道答案，那么我应该去问知道答案的人，得到答案告诉原来的提问者，这样一来我也知道了答案，下次如果有人来问，我就可以直接回答了，就像 DNS Recursive Resolver 的缓存一样。如果比较忙，我没有时间去问下一个人，应该拉一个群，加上提问者和能解决问题的人，由我来解释一下问题和背景。因为我经过和提问者的沟通，多少理解需求和背景了，很多提问者无法一次性把我们需要的背景解释清楚，我现在如果在群里一次性说明背景，就可以减少提问者和其他人的沟通成本。如果每个人都这么做的话，那么所有的问题都可以用最快的方式解决，整体花费的工作量就可以变小。

但是实际是行不通的，因为公司给每个人都安排好了 KPI。这些事情不在 KPI 里面，做这些工作实际上是不被绩效系统承认的，每个人要专注于完成自己的 KPI。更糟糕的是，如果做一个糟糕的「转发者」，一问三不知只会转发，那么收到的请求就越来越少，别人知道，问你不会得到答案，下次就不会问了。相反，如果这次别人问你得到了满意的答案，那么下次他还会来问你，每次都会来问你，收到的问题会越来越多，提问者甚至会变成「转发者」，他知道你能回答某些方面的问题，那么别人来问他的时候，他会立即转发给你。

也许 Hot Potato Routing 才是在大公司的生存之道，只有在小而美的公司才能做到用不自私的工作方式来工作。当初那些有理想的前同事，现在几乎都已经离职了（当然，没有离职的也有有理想的）。

 

网络中的环路和防环技术

Posted on by 10 Comments

不可以用路由器？一文的答案

这个题目很有趣，即使没有什么思路，当你打开 Wireshark 的时候，估计也能发现答案了。

电脑插上网线的时候，是可以正常上网的。但是即使能正常上网的时候，我们抓到的包也都是红色的。这些红色是有 Expert Info 标注的包。（可以通过 Wireshark Profile 配置颜色）

Expert Info 是 Wireshark 帮助我们标记出来的可疑信息。

Wireshark 打开会发现明显的 Expert Info 提示

点开下面 IP 层的包，会发现 TTL 有明显的颜色标注：Time To Live only 1. 于是就真相大白了，ISP 在把 IP 包转发给用户这边的时候，无论 TTL 还剩下多少，都改成 1 才转发给用户。这样，用户的设备可以收到包却不能转发。因为设备（比如路由器）在转发包的时候会把 TTL 减 1，如果 TTL 还是大于 0，才会转发出去；如果等于 0，就会直接丢弃。即，网络上是不存在 TTL=0 的包的，这是协议规定的。

TTL 变化的链路

TTL 的设计原本是为了防止网络出现环路，限制一个包能被转发的最大次数。每次转发都会 -1，最后到 0 的时候，如果包还没有到达目的地，设备就会丢弃这个包（然后可能发一个 ICMP 告诉 Src IP 这个包因为 TTL 减到 0 而寿终正寝了）。

要解决这个问题的话，我们就要去修改「路由器」的行为，让路由器收到 TTL=1 的包不要直接丢弃，而是修改 TTL=5（或者其他数字），然后继续转发给其他的设备。比如，可以用 iptables 来修改 TTL 的值 iptables -t mangle -A POSTROUTING -j TTL --ttl-set 5。

为什么三层 IP 协议会有一个 TTL 字段，但是二层没有呢？我们先来看二层是否会出现三层可能出现的环路问题。

网工闯了什么祸？ 一文的答案

答案是交换机出现了环路。

交换机的工作方式是：

  1. 收到一个 Ethernet 帧，查找 MAC 地址表，找到这个 Ethernet 帧目标 MAC 对应的端口，然后从这个端口转发出去。这个 MAC 地址表怎么来的呢？见 2；
  2. 对于收到的这个帧，把来源 MAC 和收到这个帧的端口写入 MAC 地址表。因为从这个端口收到了帧，说明此 来源MAC 接在这个端口下，那么下次要往这个 MAC 发送的时候，直接走此端口即可；
  3. 假设来了一个 MAC，交换机的 MAC 地址表找不到这个 MAC 地址呢？比如交换机刚启动，MAC 地址表是空的。这时候交换机就把帧发给所有的端口 (flooding)，即所有主机都能收到这个帧，只不过大部分主机检查一下目标 MAC 不是自己，就直接丢弃此帧。而之后一个主机发现是给自己的，就欣然接受，交给网络栈处理。

在我们的原题场景描述中，是扩容一个机架，一般在机架顶上加一个交换机 (Top-of-Rack Switching)。两个机架通都是在测试环境，需要连通，那么这个简单的网络拓扑现在就变成了这样子：

交换机出现环路连接

假设设备通电启动，服务器发送任何数据给交换机2（在题目中是 ARP 包），交换机2不知道目标 MAC 对应的端口，于是转发到它的所有端口，交换机1和3同时收到这个包，也不知道应该发给哪里，于是也转发到自己的所有端口，此时，交换机2又会收到1和3发过来的包，如上，这个包每次转发都会被放大2倍，直到最后，3个交换机都会在此网络中满载去转发这些流量，网络被堵满了，彻底瘫痪。

回到题目本身，这道题目是有一些困难的。因为我提供的 tcpdump 抓包文件，区分不出来网卡收到的包和发送出去的包。其实 tcpdump 的 -Q in 选项可以只抓进来的包（另外的参数是 -Q out 和默认的 -Q inout。这样就很明显了：

可以看到 .1 这台机器去 ping .4 ，它才是应该发送 ARP 询问的人，它 ingress 怎么会收到自己发出去的请求呢？那必然是环路了，自己发出去的包经过转发，又回到了自己这里。而且还被放大了很多倍，发一个请求，远远不不断收到自己发送的请求。

在最新版本的 tcpdump 中，已经默认会展示抓包的 In/Out 方向了：

那回到问题中提供的抓包文件，由于看不到进出方向这个信息，所以我们只能得到这个信息：发出去的 ARP 没有响应。原因可能就有很多了：网线没插好，交换机坏了，对面的机器故障导致收到 ARP 没有回应，有很多种可能。网络分析的时候，从哪里抓到的包这个信息非常重要。我们是从 .1 机器上抓包的，所以只能确认 ARP 包从机器上离开了，但是没获得响应。

所以能得到这个信息的读者很厉害了。

如何从给出的抓包文件得到「环路」这个信息呢？

我的 Wireshark Profile 会打开 Delta Time 这个列。方法如下。先在列头右键，选择 Column Preferences…

Wireshark 设置显示的列信息

然后添加一列，选择 Delta time displayed. 我喜欢加在 Time 的后面。

Wireshark 可以控制显示数据包的列信息

设置完成之后，列内容就看起来如下。

分析 Wireshark 包的时间信息

Delta time 的含义是：这个包抓到的时间距离上一个包过去了多久？比如第三行，表示第二个包抓到之后的 5us 抓到的。

这就很蹊跷了：主机发出 ARP 询问，为什么 5us 之后就接着又发出了另一个询问呢？难道等 5us 就开始重试了吗？（Linux ARP 重试时间是 1s，读者可以尝试一下去 ping 一个本地网络不存在的 IP 并抓包来实验一下。）虽然不同系统可能有不同的重试时间，但是 5us 就重试显然是不合理的，很多网卡的延迟都做不到 5us。那么真相只有一个——这个不是发出去的包而是收到的包，网络出现环路，导致自己发出去的包被自己收到了。进一步推断出，现在这个网络的交换机都已经被环路搞崩溃了，导致网络大塞车，所有的包都无法正常转发。

总结一下，推断出这个信息，有几个难点：

  • 要知道去分析包的时间序列；
  • 知道 tcpdump 抓到的包是双向的。这个大家应该都会知道，只不过平时下意识通过 IP 和 MAC 的来源、目标来区分方向。这个场景比较刁钻，即使来源 MAC 是自己，却是 ingress 方向；
  • 要知道二层也是可能存在环路的；

一楼 pandada8 在文章发布几小时内就贴了正确答案，恭喜！（可惜没奖品。）分析出第一段的读者也很棒，给你们发二等奖！

二层为什么不设置 TTL 字段？

既然三层使用 TTL 放环，而且二层也可能出现环路，为什么二层不加一个类似的 TTL 字段呢？我觉得原因有以下几点。

交换机速度为什么快，是因为在做转发的时候，直接看一下目标 MAC 地址，查表之后，确认出口，检查 CRC，然后交换机内的 Fabric 网络「连接」起来进入端口和出端口，数据直接转出去了。这中间不对 Frame 作修改。假设我们有一个二层 TTL 字段，那么就要修改这个字段，并且重新计算 CRC。这个问题在早期互联网很难解决，交换机硬件性能低，做这种复杂任务需要 CPU 来做。早期路由器用的就是 CPU（但即使这样，很多路由器都是不计算也不校验三层的 checksum 的，就当这个字段不存在一样，所以 IPv6 直接取消了 checksum 功能，完全依赖二层的 CRC 以及让上层协议自己去做校验），所以路由器比交换机速度慢很多。但是现在在 ASIC 上做这个事情难度不高，倒是将这个技术推向市场，升级 ASIC 芯片和协议难度会很高。说起来，按照早期硬件来设计的 Ethernet，还有很多不合理的地方，如果我们有能力一夜普及一种全新的 Ethernet 技术的话，我觉得最先升级的是 Ethernet 1500bytes MTU 的限制。

我觉得最关键的原因是，做这个事情意义不大。TTL 这个机制只能作为防环的一种最后手段，并没有解决问题。在三层上讲，假设一个包的 TTL 被从 64 减到 0 最后丢弃了，那么包已经经过了 64 次转发，这些工作量已经被浪费掉了。在二层上讲，环路一旦出现，损失就更大了，每次转发流量都会被放大好几倍，可以想象，即使有 TTL，出现环路的话一个包也会被转发成千上万次，也不会有什么改善。

所以最好的方案还是防止环路的出现。

那为什么三层还要有 TTL？因为二层网络一般是一个组织控制的，一个公司有多个网络，自己内部想怎么设计都可以。跨组织之间一般是三层，通过路由协议（最流行的是 BGP）来交换路由信息。一个网络内，我们可以通过技术手段保证没有环路，并对此负责。但是三层方面，我们不能保证邻居的网络没问题，不能保证他们不会把错误的包发送回来导致环路，所以 TTL 是一个在全局层面上，作的最后一个防线。

虽然三层有 TTL 的存在，所有的三层路由协议设计上都有防环机制，比如 Split Horizon，简单来说就是从一个接口收到的路由信息，不会再从这个接口发送。当环路出现的时候，已经造成损失了，TTL 只是减少损失而已。

从上面的分析我们可以看出：二层环路比三层更加可怕，一是因为二层没有 TTL 机制做兜底，二是二层交换机的工作原理会有流量放大。所以二层的防环技术非常重要。

二层最基础的防环机制是 STP(Spanning Tree Protocol)，简单说就是交换机在启动的时候会互相沟通，看网络是否存在环路，如果存在，就通过计算协商断开一条线，就当这条线不存在一样。逻辑上是一个无环网络。

比如上一代网络经典的核心-汇聚-接入网络，可以看到红框里面其实是一个二层环路。但是运行 STP 会断开虚线的部分。

图片来自 Cisco （框是俺加的）

STP 有一些问题：断开线路，这就是浪费了硬件资源，没有完全利用带宽，而且每次 STP 的计算需要时间，比较慢。所以现在的二层技术，都会在设计的时候考虑到防环机制，让机制在本身不会造成二层环路。但是 STP 不会关闭，会作为一个兜底机制存在。

现在几乎所有的交换机都有 STP 功能，所以几乎看不到环路的存在了，上文题目很少在现实中见到，有些刁钻，向读者道歉！

无处不在的「环路」

说完三层和二层，我们扩展继续聊聊其他的协议。

可以说：只要有转发，就可能存在环路。

HTTP 301 重定向环路

比如说我之前配置全站流量 HTTPS 重定向的时候，就出现过「环路」。即在 WordPress 上配置了 HTTP 都 301 重定向到 HTTPS，但是 Apache 反向代理收到用户的 HTTPS 请求之后，将 TLS 「卸载」了，转发到后段的是 HTTP，于是 WordPress 又发送了 301 重定向给浏览器。

301 重定向引起的环路

浏览器对此的防环机制是，如果重定向次数太多，就放弃并显示错误：ERR_TOO_MANY_REDIRECTS.

DNS CNAME 环路

假设我们设置 a.kawabangga.com 的记录为 CNAME b.kawabangga.com，然后设置 b.kawabangga.com 的记录为 CNAME a.kawabangga.com，会发生什么呢？

大多的的 DNS 客户端和 Recursive resolver 都限制了跟踪 CNAME 的次数，这样，即使发生循环，最后也会以失败停下来。不过最好的办法还是在配置的时候就发现出现了环路（配置系统进行检查？）

比如，使用 dig 来查询这种 DNS CNAME 的话，dig 会一起将两个 CNAME 结果返回。

如果不限制查询次数的话，就会出问题了。曾经就遇到过 DNS Recursive resolver 没有限制查询次数而引起的故障。

CDN 转发的环路

CDN 的一个主要功能就是把访客的请求转发给真实服务器。想象这样一个场景，假设真实服务器也是一个 CDN 呢？如果我在一家 CDN 的控制台，配置转发请求到 CDN 公司 B，然后去 CDN B 配置转发到 CDN A。那么只要发送一些请求，就可以把两家 CDN 公司的流量都占满了。

图来自 Cloudflare

解决方法就是识别出来这个请求我是否已经转发过了。RFC 7230 规定可以使用 Via 字段来标志。但是这个字段有一些历史问题，以及太大了，有性能问题，而且很多服务器无法处理。所以 Cloudflare, Fastly and Akamai 这些厂商又联合定义了一个新的类似方案。

最后总结一下，这一篇的分析中，在网络分析方面，我们学会两招：

  1. 注意 Wireshark 给我们提供的专家信息。TCP 如果发生重传，乱序等，Wireshark 就会给我们标注出来（注意后面可能要考哦～）。这些在 tcpdump 命令行是没有的，tcpdump 是抓包展示，不会有包之间的关联分析信息。
  2. 注意分析时间序列。

在网络设计方面，我们讨论了环路，做相关设计的时候要时刻提防无限循环的破坏力。顺带八卦了网络的一点历史和硬件知识。

Until next time!

目录

这个系列正在连载中，没有链接的目录还没有写完，敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器？
  7. 网工闯了什么祸？
  8. 网络中的环路和防环技术
  9. 延迟增加了多少？
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手：答案和解析
  13. 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
如果本文对您有帮助，欢迎打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！

 

四层负载均衡分析：GitHub GLB

Posted on by 6 Comments

今天我们来赏析 GitHub 的四层 LB 设计。

GitHub 的 GLB 是开源产品（当然了！），从架构上看，和之前介绍的 Cloudflare Unimog 很像，因为 GLB 是 Unimog 实现的重要参考。后面还会介绍一个叫做 Beamer 的四层负载均衡，也是参考了 GLB。所以 GLB 的连接保持设计创新性很强。

GLB 技术总览

被借鉴最多的就是 GLB 的连接保持技术，所以我们直接从最精彩的开始讨论。

连接保持技术

Cloudflare Unimog 的连接保持方案和 GitHub GLB 几乎一致，所以我们在之前几乎都已经讨论过了。

简单总结一下：GLB 作为四层负载均衡，在 GLB 实例之间不需要同步任何信息。在转发的时候，每一个 GLB 根据 TCP 连接五元组 hash，独立作出决策，选中一个 RS 进行转发。

转发的过程是：

  1. GLB 收到一个包，根据包的五元组计算 hash（不管是不是 SYN，都一样对待）；
  2. 根据 hash 查找转发表，找到对应的 2 个 RS，一个是主 RS 一个是备 RS，然后转发到主 RS；
  3. 主 RS 收到包之后，检查这个包是不是属于自己机器上的连接，如果是，就交给协议栈处理，如果不是，就转发到备 RS（备 RS 的地址记录在 GLB 发过来的包中）。
添加 GLB 的同时添加机器也没有问题，可以「二次转发」，每一个包都有「第二次机会」（图来自 GitHub）

对比 Google Maglev 保持连接的方案有「两层」来保证同一个 flow 到同一个 RS 上：每一个 LB 实例都根据 SYN 包记录连接对应的 RS，即 connection table；然后使用一致性 hash 尽可能让相同的五元组选择相同的 RS。是属于「 connection table + hash查转发表」的方式。

而 GLB 的方案中不存在任何的状态保存，SYN 包和其他的包都可以使用一样的逻辑来转发，第一次转发不对就转发第二次，可以认为是「hash查转发表+hash查转发表」。Maglev 论文中提到了一些特殊情况，比如遇到 SYN DDoS 攻击的时候可能造成内存问题，在 GLB 这里就没有。

除了不用保存数据，这个转发方案和 Google Maglev 相比还有一个优点：Maglev 论文中提到，如果 Maglev 数量有变化，RS 数量也有变化，这样就会导致之前的 TCP 连接的包被发送到一个新的 Maglev 上，这个新的 Maglev connection table 中没有保存这个连接的状态，经过自己的 hash 计算选择 RS 会和之前的不一样（因为 RS 数量变化导致 hash 结果会有可能不一样），这时候连接就断了。GLB 就没有这个问题，GLB 实例可以和 RS 同时做变化。

转发表的生成

在这个方案中，转发表的生成是关键的一步。

按照转发表转发，图中 Proxy 其实是本文的 RS（图来自 GitHub）

转发表要满足一下几个条件：

  • 在 RS （就是图中的 proxy）修改的时候，只有变化的 RS 在表中会修改，没有变化的 RS 在表中的位置不变。即不能对整个表完全重新 hash；
  • 表的生成不依赖外部的状态；
  • 每一行的两个 RS 不应该相同（不然的话就相当于没有备 RS 了）；
  • 所有 RS 在表中出现的次数应该是大致相同的 （负载均衡）；

实现方式是类似 Rendezvous hashing：对于每一行，将行号+ RS IP 进行 Hash 的到一个数字，作为「分数」，所有的 RS 在这一行按照分数排序，取前两名，作为主 RS 和 备 RS 放到表中。

然后按照以上的四个条件来分析：

  • 如果添加 RS，那么只有新 RS 排名第一的相关的行需要修改，其他的行不会改变；
  • 生成这个表只会依赖 RS 的 IP；
  • 每一行的两个 RS 不可能相同，因为取的前两名；
  • Hash 算法可以保证每一个 IP 当第一名的概率是几乎一样的；

不过要注意的是：在想要删除 RS 的时候，要交换主 RS 和 备 RS 的位置，这样，主 RS 换到备就不会有新连接了，等残留的连接都结束，就可以下线了；在添加 RS 的时候，每次只能添加1个，因为如果一次添加两个，那么这两个 RS 如果出现在同一行的第一名和第二名，之前的 RS 就会没来得及 drain 就没了，那么之前的 RS 的连接都会断掉。

转发架构和封装

GLB 也是使用的 DSR 转发架构，在这个系列之前的文章已经介绍过了，这里不重复了。

LB 到 RS 的转发， GLB 一开始使用的是用 GRE 封装然后放到 FOU 里面，现在直接换成了 GUE。上文提到的备 RS 的 IP 地址可以放到自定义的 GUE header 里面。

为什么不用 IPIP 来做封装呢？IPIP 是把一个 IP 包放到另一个 IP 里面做转发，看起来 header 更少。但是这样的话就没有地方放备 RS IP 了，唯一可行的地方是 underlay 的 IP 包的 option 里面。这会导致一个问题，就是路由器不认识这个 option，会涉及到需要 CPU 来处理，速度就更慢（叫做 Layer 2 slow path）。

为什么封装到 UDP 里面，而不是 IP 里面呢？如果是放到 UDP 包里面，那么对于负责转发的路由器来说，这个包就是一个普通的 UDP 包，可以按照四元组做 hash。如果是 IP 的话，对于路由器来说只能看到 IP 的数据，不会去解析内层的 overlay 的包内容，中间的路由器，以及 NIC，都会放到同一个 queue 中，如果一个 IP 对的流量太大的话，就会有性能瓶颈。

转发实现

GLB 是基于 DPDK 实现的。

因为设计上是无状态的，所以可以用 DPDK Packet Distributor 把工作散到任意数量的 CPU 上，并行执行，扩展性很强。

官方博客中提到支持 TCP over IPv4 or IPv6，也支持 ICMP，支持 PMTUD。没提到 UDP，应该是不支持 UDP？GitHub 的业务涉及 UDP 的应该不多。

使用 DPDK 就有一个问题：流量都被 GLB 接管了，那么那些非数据面的流量怎么办？比如 sshd 等程序，这些程序是用 Kernel socket API 编写的，不支持 DPDK 的接口。

一种方法是安排单独的网卡接口，专门用于这些应用。DPDK 的流量走单独的网卡，控制面走单独的网卡。

GLB 是用了 Flow Bifurcation，就是可以将一个物理网卡虚拟成多个虚拟网卡，Kernel 协议栈和 DPDK 流量分别走不同的虚拟网卡。硬件网卡可以将流量区分出来走哪一个虚拟网卡，这部分功能几乎是不占用 CPU 的，所以不会有额外的资源消耗，也能达到线速。

Flow Bifurcation 可以使用下面两种硬件功能来实现：

  • SR-IOV 是一个 PCI 标准，支持将一个物理卡虚拟出多个虚拟卡。云厂商虚拟机场景用的比较多。虚拟卡都有单独的 queue，MAC 地址和 IP 地址，物理卡可以根据 MAC 地址将流量分到不同的虚拟卡中；
  • 大部分的 NIC 都支持编程 Packet classification filtering，让硬件来将不同的流量分到不同的 queue；
图片来自 dpdk

其他部分

测试

使用 DPDK 的 Environment Abstraction Layer (EAL) ，可以让基于 libpcap 的 interface 像物理卡一样，不需要专用物理网卡就可以做端到端测试，配合 Linux 的 Virtual Device 功能和 Python 的 Scapy 编程库，在任意 Linux 系统上就可以跑测试，VM 都可以。

测试环境架构，图来源

健康检查

在 GLB 实例上运行健康检查程序，从实际的 tunnel 去检查后端的端口，如果认为不健康，就直接交换主 RS 和备 RS。这样新连接会去好的 RS，旧连接可以尝试不健康的 RS，最大努力保持连接。如果健康检查失败是 False Positive 也不要紧，只是影响包的转发路径而已。

RS 上的二次转发

基于 Netfilter 和 IPtables 实现：如果是 SYN 或者连接在本地存在，就接受，否则就转发到 备 RS。

参考资料：

四层负载均衡系列文章