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. TCP 下载速度为什么这么慢？
  14. TCP 长肥管道性能分析
  15. 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 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。

参考资料：

四层负载均衡系列文章

 

网工闯了什么祸？

Posted on by 7 Comments

上一篇很多读者一下就发现了答案，暂时先不写答案和分析，卖个关子，继续出一题。下一篇一起揭晓答案。

小王（就是你！）在一家创业型互联网公司上班。公司为了保证产品的稳定性，在上线之前会现在测试环境运行代码，保证没有问题，再发布到正式环境。

小王的公司比较拮据，为了省钱，公司购买了一些陈旧的二手设备，运行测试环境。虽然性能比较差，但是毕竟测试环境只有开发人员的测试流量，所以没有什么问题。

随着部署的东西越来越多，原来一个机架已经不够用了，他们就准备扩展一个新的机架。网工效率很高，连夜操作，设备马上上线了。网工比较邋遢，通电了就下班了。

第二天小王来一看，测试环境网络不通了。这种情况一般人直接去打网工了。但是小王不是，小王总是抓住任何一个检验自己能力的机会，用有限的环境得到尽可能多的信息，推理出最可能的根因，然后再去找相关的同事解决。而不是直接去问同事：「我这里网络不通快给我看看是什么问题。」

现在的情况是：

  • 小王发现请求发给另一个服务总是超时；
  • 小王去 ping 了一下另一个服务的地址，当前的机器地址是 10.0.0.1，去 ping 目标地址 10.0.0.4 发现是不通的；
  • 于是小王保持当前的 ping，然后在 10.0.0.1 的机器上抓包，命令是 tcpdump -i eth0，得到的抓包文件如下。

请下载这个文件，分析抓包内容，解释：当前的网络出现了什么问题？

1-can-not-ping.pcap_下载

欢迎在评论区留下你的想法。

==计算机网络实用技术 目录==

这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。

如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！

没有链接的目录还没有写完，敬请期待……

  1. 序章
  2. 抓包技术以及技巧
  3. 理解网络的分层模型
  4. 数据是如何路由的
  5. 网络问题排查的思路和技巧
  6. 不可以用路由器？
  7. 网工闯了什么祸？
  8. 网络中的环路和防环技术
  9. 延迟增加了多少？
  10. TCP 延迟分析
  11. 重新认识 TCP 的握手和挥手
  12. 重新认识 TCP 的握手和挥手：答案和解析
  13. TCP 下载速度为什么这么慢？
  14. TCP 长肥管道性能分析
  15. 后记：学习网络的一点经验分享
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
 

SRE 书单推荐

Posted on by 1 Comment

推荐一些适合 SRE 或者想要从事 SRE 的读者阅读的书籍。

其中，最里面的虚线框推荐学生阅读，非科班转 SRE 也可以从这些书入手，第二个虚线框意思是 SRE 工作中用的到的内容，从实用主义讲，推荐应届生如果第一次入职了 SRE 的岗位的话，可以阅读这些书。

我没有读完所有的书，有一些是很多高手推荐，应该不会错，所以也列在这了这里，比如 CSAPP 这本。

这个书单强调基础知识，那些经过 10 年也没有变化太多的内容，很少涉及工具。SRE 的工作对很多工具也有要求，比如 Ansible，Kubernetes，Nginx，命令行工具 awk, sed 等等，这些工具可以通过书籍学习，也可以通过其他的网站学习，内容与时俱进，我当时学习的时候看的资料可能过时了，所以不好作推荐。

但是有 3 个方面除外：Python, Vim, Tmux. 这些工具掌握了会受益终生，所以我列出来一些有关这些工具的资料。无论你第一门语言使用的是什么，都推荐学习一下 Python。编辑器和 IDE 选择哪一个并不重要，这也不是什么值得骄傲的事情，但是无论使用哪一个，都不要固步自封，每天学习一下提高效率的快捷操作。推荐一下 Vim，理由是插件丰富，键位比 Emacs 合理，（不要打我，我是 Emacs 转过来的，Emacs 动辄就是好几个键一块按）。推荐 Tmux 是因为，学会了它你可以在任何终端模拟器，比如 iTerm2, Kitty, Konsole 或者 ssh 都有一致的体验。

点击这里可以看高清图。虚线表示可以互相替代。箭头表示推荐按照顺序阅读。

其中，Google SRE 这本书可以在线免费阅读，完整地介绍了 SRE 的工作。如果之前不是做 SRE 工作的，强烈建议在入职 SRE 工作之前阅读此书。因为很多岗位是打着 SRE 的幌子却做的是运维工的工作。读完此书可以防止自己被骗。也能知道正确的工作方法是什么样子的。

The Missing Semester of Your CS Education 建议应届生阅读，介绍了当前大学教育没有教但是却非常有用的知识。