Apr
27
这周换换口味，记录一下去年踩的一个大坑。
起
大概是去年8月份，那会儿我们还在用着64GB的“小内存”机器。
由于升级一次版本需要较长的时间（1~2小时），因此我们每天只发一次车，由值班的同学负责，发布所有已merge的commit。
当天负责值班的我正开着车，突然收到 Bytedance-System 的夺命连环call，打开Lark一看：
[规则]：机器资源报警
[报警上下文]：
host: 10.x.x.x
内存使用率: 0.944
[报警方式]：电话&Lark
打开ganglia一看，更令人害怕：
起
大概是去年8月份，那会儿我们还在用着64GB的“小内存”机器。
由于升级一次版本需要较长的时间（1~2小时），因此我们每天只发一次车，由值班的同学负责，发布所有已merge的commit。
当天负责值班的我正开着车，突然收到 Bytedance-System 的夺命连环call，打开Lark一看：
引用
[规则]：机器资源报警
[报警上下文]：
host: 10.x.x.x
内存使用率: 0.944
[报警方式]：电话&Lark
打开ganglia一看，更令人害怕：
Apr
20
TCP#2: 西厢记和西厢计划
上篇《TCP：学得越多越不懂》发出来以后，有朋友很委婉地说：“如果能结合现实生产场景会有意义一点。”
经过深刻的反思，我决定虚心接受建议，写一点理论结合实践的内容。
# == 回忆杀 ==
曾经在猫扑和天涯冲浪的网虫应该都还记得，谷歌当时还是Goooooogle，是可以直接访问的。
但是如果想搜索一些奇怪的词汇（比如███），一点击"手气不错"，浏览器马上就会显示无法访问，并且这个现象会持续几分钟。
于是很多小伙伴就换到一个号称自己更懂中文的搜索引擎了。
（该爬虫当年有个广告拍得不错：https://v.qq.com/x/page/r0137s2op5j.html ）
作为一个曾被新自由主义（Neoliberalism）洗脑的年轻人，我在寻找“自由”的路上发现了墙的存在，也知道了这是方校长的杰作。
但是墙到底是个什么样的存在呢？
# == 防火墙 ==
我们的防火墙，其名源自《The Great Firewall of China: How to Build and Control an Alternative Version of the Internet》这本书。
虽然名字叫防火墙（Firewall，简称FW），但严格来说，（在早期）它其实是一个入侵检测系统（Instrusion Detection System，简称IDS）。
和FW不同的是，IDS是监听设备，不需要部署在链路中间，只要能把流量旁路引出供它分析即可。
通过旁路分析，IDS可以在不影响现有流量的情况下部署（只要路由器/交换机上有镜像端口即可），在IDS出现异常时（例如在流量高峰IDS设备性能不足时 ）也不会导致网络中断。
曾经有人发现，在流量特别大的时候，墙的检测功能有时会失效，因此推测其是旁路引流进行分析的（符合IDS的特征）。
既然是旁路的，就无法直接Drop数据包，为了达到阻断通信的目的，需要利用协议的特性来实现。
# == RST大法 ==
看了上篇《TCP：学得越多越不懂》的同学，对报文的控制位里的 RST 可能还有点印象，在遇到异常情况时，可用于通知对方重置连接（细节详见RFC 793）：
有些同学可能像我一样懒得读英文原文，所以翻译一下：
* 如果连接状态处于“非连接完成”状态（例如SYN-SEND, SYN-RECEIVED），当收到reset时会将状态返回LISTEN；
* 如果TCP状态是 ESTABLISHED, FIN-WAIT-1, ..., LAST-ACK, TIME-WAIT 其中之一时，放弃连接并通知用户。
忘了上述状态含义的话，可以再回顾下这张状态流转图：
(tcp连接状态图，截取自rfc 793)
这就是上篇里提到的“我们敬爱的防火墙很爱用它”的原因了：
当检测到“入侵行为”时（例如HTTP报文中出现了███）发送RST，按照RFC 793规范的TCP协议栈实现，收到RST后就应当放弃本次连接。
于是你就在浏览器上看到连接被重置(reset)了。
# == 反RST大法 ==
那么，如果我忽略RST包，不就可以不被墙欺骗吗？
实际上，用 iptables 来实现这一点很简单：
很不幸，方校长的团队对此的解决方法也非常简单，只要向双方都发送RST包就可以了。
当然如果在服务器一端也忽略RST，就可以成功绕过墙的忽悠——据说剑桥大学有人实验验证过，确实可行。
可惜的是，用户通常没法控制服务器端忽略RST，因此这个方法的实用价值不高。
但是这个思路为西厢计划做好了铺垫。
# == 西厢计划 ==
我看到这个项目的名字的时候 ，真佩服作者的脑洞。
了解这个计划的原理之后，就更佩服作者的脑洞了。
前面说到，墙是在检测到某个关键词的时候才会发送RST包。
为了检测关键词，它需要工作在应用层（HTTP协议）。
而为了工作在应用层，它需要维护TCP连接的状态。
由于那时的设备性能比较弱（所以会出现高峰期检测失效的情况），为了提高吞吐量，方校长团队的方案是：实现一个简化的TCP栈。
RFC 793规范中定义了很多有效性检测，例如检测序列号是否有效来过滤old duplicates等，以保证通信的可靠性。
但这不是墙的需求，因此可以去掉很多规则，从而提高分析性能。
那么，如果我可以欺骗墙，这个连接已经被关闭，那么后续该连接的包就会被墙认为是网络中滞留的无效包，绕过关键词检测。
具体该怎么办呢？
# == 第一阶段 ==
上篇提到了一个细节：
我们知道，在三次握手的最后一步，A本应发送一个ACK(seq=y+1)。
但如果这时候 A 发送了一个 FIN 呢？
B收到以后，由于此时连接尚未建立，会直接忽略这个包。
而墙实现的TCP栈比较简陋，它认为A已经关闭了链接，因此A后续发送的包就不会再触发关键词检测。
但是注意，TCP是双向的，虽然A主动关闭连接，但是B仍然可能有数据要发送（划重点：面试题“为什么TCP断开连接需要4次”的答案），因此还需要欺骗墙说在B这侧也终止链接了。
这又该怎么办呢？
# == 第二阶段 ==
显然我们不能让服务器直接发一个FIN，否则这个连接就真完了。
幸运的是，RFC 793给了一个“梯子”：
翻译：如果连接处于“非连接完成”状态，收到一个无效的ACK，应当发出一个reset。
如果A在三次握手的最后一步，没有按规范要求发送ACK(seq=y+1)，而是发送ACK(seq=y)，那么B在收到以后就会按照协议的要求回复一个RST：
这时我们可以在 A 上用“反RST大法”，忽略服务端返回的RST，这个连接就不受影响。
但是墙的TCP栈认为客户端会按照协议终止连接，于是就不再有必要检测服务端后续的报文了。
# == 大结局 ==
从此张生和崔莺莺过上了幸福的生活。
方校长的团队当然不会放任这种事情的发生，西厢计划没过多久就失效了。
随着技术的进步、性能的提升，现在墙似乎已经集成到了链路中、可以直接DROP数据包，不再需要RST大法了。
不过为了业务需要，企业可以向电信主管部门申请VPN用于正常的生产经营。
例如字节跳动，为了建设21世纪数字丝绸之路，通过技术出海，在40多个国家和地区排在应用商店总榜前列，包括韩国、印尼、马来西亚、俄罗斯、土耳其等“一带一路”沿线的主要国家。
如果你也想过上幸福的生活，不妨投个简历，一起为一带一路做贡献吧。
关于字节跳动面试的详情，可参考我之前写的《程序员面试指北：面试官视角》
https://mp.weixin.qq.com/s/Byvu-w7kyby-L7FBCE24Uw
# ~ 投递链接 ~
网盟广告（穿山甲）-后端开发(上海)
https://job.toutiao.com/s/sBAvKe
网盟广告（穿山甲）-后端开发(北京)
https://job.toutiao.com/s/sBMyxk
网盟广告（穿山甲）-广告策略研发(上海)
https://job.toutiao.com/s/sBDMAK
其他地区、其他职能线
https://job.toutiao.com/s/sB9Jqk
# 参考文章
[1] “西厢计划”原理小解
https://blog.youxu.info/2010/03/14/west-chamber/
[2] 从Linux协议栈代码和RFC看西厢计划原理
https://blog.csdn.net/dog250/article/details/7246895
[3] RFC 793 - TRANSMISSION CONTROL PROTOCOL
https://tools.ietf.org/html/rfc793
引用
自那日听琴之后，多日不见莺莺，张生害了相思病，趁红娘探病之机会，托她捎信给莺莺，莺莺回信约张生月下相会。夜晚，小姐莺莺在后花园弹琴，张生听到琴声，攀上墙头一看，是莺莺在弹琴。急欲与小姐相见，便翻墙而入，莺莺见他翻墙而入，反怪他行为下流，发誓不再见他，致使张生病情愈发严重。
《西厢记》
《西厢记》
上篇《TCP：学得越多越不懂》发出来以后，有朋友很委婉地说：“如果能结合现实生产场景会有意义一点。”
经过深刻的反思，我决定虚心接受建议，写一点理论结合实践的内容。
# == 回忆杀 ==
曾经在猫扑和天涯冲浪的网虫应该都还记得，谷歌当时还是Goooooogle，是可以直接访问的。
但是如果想搜索一些奇怪的词汇（比如███），一点击"手气不错"，浏览器马上就会显示无法访问，并且这个现象会持续几分钟。
于是很多小伙伴就换到一个号称自己更懂中文的搜索引擎了。
（该爬虫当年有个广告拍得不错：https://v.qq.com/x/page/r0137s2op5j.html ）
作为一个曾被新自由主义（Neoliberalism）洗脑的年轻人，我在寻找“自由”的路上发现了墙的存在，也知道了这是方校长的杰作。
但是墙到底是个什么样的存在呢？
# == 防火墙 ==
我们的防火墙，其名源自《The Great Firewall of China: How to Build and Control an Alternative Version of the Internet》这本书。
虽然名字叫防火墙（Firewall，简称FW），但严格来说，（在早期）它其实是一个入侵检测系统（Instrusion Detection System，简称IDS）。
和FW不同的是，IDS是监听设备，不需要部署在链路中间，只要能把流量旁路引出供它分析即可。
通过旁路分析，IDS可以在不影响现有流量的情况下部署（只要路由器/交换机上有镜像端口即可），在IDS出现异常时（例如在流量高峰IDS设备性能不足时 ）也不会导致网络中断。
曾经有人发现，在流量特别大的时候，墙的检测功能有时会失效，因此推测其是旁路引流进行分析的（符合IDS的特征）。
既然是旁路的，就无法直接Drop数据包，为了达到阻断通信的目的，需要利用协议的特性来实现。
# == RST大法 ==
看了上篇《TCP：学得越多越不懂》的同学，对报文的控制位里的 RST 可能还有点印象，在遇到异常情况时，可用于通知对方重置连接（细节详见RFC 793）：
引用
If the receiving TCP is in a non-synchronized state (i.e. SYN-SENT, SYN-RECEIVED), it returns to LISTEN on receiving an acceptable reset. If the TCP is in one of the synchronized states (ESTABLISHED, FIN-WAIT1, FIN-WAIT2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and informs its user
https://tools.ietf.org/html/rfc793
https://tools.ietf.org/html/rfc793
有些同学可能像我一样懒得读英文原文，所以翻译一下：
* 如果连接状态处于“非连接完成”状态（例如SYN-SEND, SYN-RECEIVED），当收到reset时会将状态返回LISTEN；
* 如果TCP状态是 ESTABLISHED, FIN-WAIT-1, ..., LAST-ACK, TIME-WAIT 其中之一时，放弃连接并通知用户。
忘了上述状态含义的话，可以再回顾下这张状态流转图：
(tcp连接状态图，截取自rfc 793)
这就是上篇里提到的“我们敬爱的防火墙很爱用它”的原因了：
当检测到“入侵行为”时（例如HTTP报文中出现了███）发送RST，按照RFC 793规范的TCP协议栈实现，收到RST后就应当放弃本次连接。
于是你就在浏览器上看到连接被重置(reset)了。
# == 反RST大法 ==
那么，如果我忽略RST包，不就可以不被墙欺骗吗？
实际上，用 iptables 来实现这一点很简单：
$ iptables -A INPUT -p tcp --tcp-flags RST RST -j DROP
很不幸，方校长的团队对此的解决方法也非常简单，只要向双方都发送RST包就可以了。
当然如果在服务器一端也忽略RST，就可以成功绕过墙的忽悠——据说剑桥大学有人实验验证过，确实可行。
可惜的是，用户通常没法控制服务器端忽略RST，因此这个方法的实用价值不高。
但是这个思路为西厢计划做好了铺垫。
# == 西厢计划 ==
我看到这个项目的名字的时候 ，真佩服作者的脑洞。
了解这个计划的原理之后，就更佩服作者的脑洞了。
前面说到，墙是在检测到某个关键词的时候才会发送RST包。
为了检测关键词，它需要工作在应用层（HTTP协议）。
而为了工作在应用层，它需要维护TCP连接的状态。
由于那时的设备性能比较弱（所以会出现高峰期检测失效的情况），为了提高吞吐量，方校长团队的方案是：实现一个简化的TCP栈。
RFC 793规范中定义了很多有效性检测，例如检测序列号是否有效来过滤old duplicates等，以保证通信的可靠性。
但这不是墙的需求，因此可以去掉很多规则，从而提高分析性能。
那么，如果我可以欺骗墙，这个连接已经被关闭，那么后续该连接的包就会被墙认为是网络中滞留的无效包，绕过关键词检测。
具体该怎么办呢？
# == 第一阶段 ==
上篇提到了一个细节：
引用
虽然ISN=4000，但是发送方发送的第一个包，SEQ是4001开始的，TCP协议规定 SYN 需要占一个序号（虽然SYN并不是实际传输的数据），所以前面示意图中ACK的seq是 x+1 。同样，FIN也会占用一个序号，这样可以保证FIN报文的重传和确认不会有歧义。
TCP：学得越多越不懂
https://mp.weixin.qq.com/s/xyPUEFUr_v9sSKKqlBkI7w
TCP：学得越多越不懂
https://mp.weixin.qq.com/s/xyPUEFUr_v9sSKKqlBkI7w
我们知道，在三次握手的最后一步，A本应发送一个ACK(seq=y+1)。
但如果这时候 A 发送了一个 FIN 呢？
B收到以后，由于此时连接尚未建立，会直接忽略这个包。
而墙实现的TCP栈比较简陋，它认为A已经关闭了链接，因此A后续发送的包就不会再触发关键词检测。
但是注意，TCP是双向的，虽然A主动关闭连接，但是B仍然可能有数据要发送（划重点：面试题“为什么TCP断开连接需要4次”的答案），因此还需要欺骗墙说在B这侧也终止链接了。
这又该怎么办呢？
# == 第二阶段 ==
显然我们不能让服务器直接发一个FIN，否则这个连接就真完了。
幸运的是，RFC 793给了一个“梯子”：
引用
If the connection is in any non-synchronized state (LISTEN, SYN-SENT, SYN-RECEIVED), and the incoming segment acknowledges something not yet sent (the segment carries an unacceptable ACK), or ...(省略)..., a reset is sent.
Reset Generation, RFC 793 [Page 35]
Reset Generation, RFC 793 [Page 35]
翻译：如果连接处于“非连接完成”状态，收到一个无效的ACK，应当发出一个reset。
如果A在三次握手的最后一步，没有按规范要求发送ACK(seq=y+1)，而是发送ACK(seq=y)，那么B在收到以后就会按照协议的要求回复一个RST：
这时我们可以在 A 上用“反RST大法”，忽略服务端返回的RST，这个连接就不受影响。
但是墙的TCP栈认为客户端会按照协议终止连接，于是就不再有必要检测服务端后续的报文了。
# == 大结局 ==
方校长的团队当然不会放任这种事情的发生，西厢计划没过多久就失效了。
随着技术的进步、性能的提升，现在墙似乎已经集成到了链路中、可以直接DROP数据包，不再需要RST大法了。
不过为了业务需要，企业可以向电信主管部门申请VPN用于正常的生产经营。
例如字节跳动，为了建设21世纪数字丝绸之路，通过技术出海，在40多个国家和地区排在应用商店总榜前列，包括韩国、印尼、马来西亚、俄罗斯、土耳其等“一带一路”沿线的主要国家。
如果你也想过上幸福的生活，不妨投个简历，一起为一带一路做贡献吧。
关于字节跳动面试的详情，可参考我之前写的《程序员面试指北：面试官视角》
https://mp.weixin.qq.com/s/Byvu-w7kyby-L7FBCE24Uw
# ~ 投递链接 ~
网盟广告（穿山甲）-后端开发(上海)
https://job.toutiao.com/s/sBAvKe
网盟广告（穿山甲）-后端开发(北京)
https://job.toutiao.com/s/sBMyxk
网盟广告（穿山甲）-广告策略研发(上海)
https://job.toutiao.com/s/sBDMAK
其他地区、其他职能线
https://job.toutiao.com/s/sB9Jqk
# 参考文章
[1] “西厢计划”原理小解
https://blog.youxu.info/2010/03/14/west-chamber/
[2] 从Linux协议栈代码和RFC看西厢计划原理
https://blog.csdn.net/dog250/article/details/7246895
[3] RFC 793 - TRANSMISSION CONTROL PROTOCOL
https://tools.ietf.org/html/rfc793
Apr
6
周末小课堂又开张了，这次我们来聊一聊TCP协议。
== 握手 ==
多少有点令人意外的是，大多数程序员对TCP协议的印象仅限于在创建连接时的三次握手。
严格地说，“三次握手”其实是一个不太准确的翻译，英文原文是 "3-way handshake"，意思是握手有三个步骤。
不过既然教科书都这么翻译，我就只能先忍了。
“三次握手”的步骤相信各位都非常熟悉了：
（咦，这不是远程面试的开场白吗）
那么问题来了：为什么不是2次握手或者4次握手呢？
== 3次 ==
针对“为什么不是4次”，知乎的段子手是这么回答的：
由此可见知乎质量的下降。
实际上，上面省略了真正重要的信息，在握手过程中传输的，不是“你能不能听得到”，而是：
协商一个序号的过程需要一个来回（告知 + 确认），理论上需要2个来回（4次），互相确认了双方的初始序号（ISN，Initial Sequence Number），才能真正开始通信。
由于第二个来回的“告知”可以和前一次的“确认”合并在同一个报文里（具体怎么结合后面讲），因此最终只需要3次握手，就可以建立起一个tcp链接。
这也解释了为什么不能只有2次握手：因为只能协商一个序号。
不过话说回来，知乎段子手的回复也不是全在抖机灵：毕竟，发起方怎么才能确认接收方已经知道发起方知道接收方知道了呢？即使发起方再问一遍，接收方又怎么知道发起方知道了接收方知道了呢？
很遗憾，结论是：无论多少个来回都不能保证双方达成一致。
由于实践中丢包率通常不高，因此最合理的做法就是3次握手（2个来回），少了不够，多了白搭；同时配上相应的容错机制。
例如 SYN+ACK 包丢失，那么发起方在等待超时后重传SYN包即可。
然后问题又来了：为什么需要协商初始序号，才能开始通信呢？
== 可靠 ==
我们都知道，tcp是一个“可靠”（Reliable）的协议。
这里“可靠”指的不是保证送达，毕竟网络链路中存在太多不可靠因素。
在 IETF 的 RFC 793（TCP协议）中，Reliability的具体定义是：TCP协议必须能够应对网络通信系统中损坏、丢失、重复或者乱序发送的数据。
为了保证这一点，tcp需要给每一个 [字节] 编号：双方通过三次握手，互相确定了对方的初始序号，后续 [每个包的序号 - 初始序号] 就能标识该包在字节流中所处的位置，这样就可以通过重传来保证数据的连续性。
举个例子：
* 发送方（ISN=4000）
* 发出 4001、4002、4003、4004
* （假设每个包只有1字节的数据）
* 接收方
* 收到 4001、4002、4004
* 4003因为某种原因没有抵达
* 这时上层应用只能读到4001、4002中的信息
由于接收方没有收到4003，因此给发送方的ACK中，序号最大值是4003（表示收到了4003之前的数据）。
过了一段时间（Linux下默认是1s），发送方发现4003一直没被ACK，就会重传这个包。
当接收方最终收到 4003 以后，上层应用才可以读到4003和4004，从而保证其收到的消息都是可靠的。（以及，接收方需要给发送方ACK，序号是4005）
注意：虽然ISN=4000，但是发送方发送的第一个包，SEQ是4001开始的，TCP协议规定 SYN 需要占一个序号（虽然SYN并不是实际传输的数据），所以前面示意图中ACK的seq是 x+1 。同样，FIN也会占用一个序号，这样可以保证FIN报文的重传和确认不会有歧义。
但是，为什么序号不能从 0 开始呢？
== 可靠² ==
真实世界的复杂性总是让人头秃。
我们知道，操作系统使用五元组（协议=tcp，源IP，源端口，目的IP，目的端口）来标识一个连接，当一个包抵达时，会根据这个包的信息，将它分发到对应的连接去处理。
一般情况下，服务器的端口号通常是固定的（如http 80），而操作系统会为客户端随机分配一个最近没有被使用的端口号，因此包总能被分发到正确的连接里。
但在某些特殊的场景下（例如快速、连续地开启和关闭连接），客户端使用的端口号也可能和上一次一样（或者用了其他刚断开的连接的端口号）。
而TCP协议并不对此作出限制：
那么：
* 如果前一个连接的包，因为某种原因滞留在网络中，这会儿才送达，客户端可能无法区分（其sequence number在本连接中可能是有效的）。
* 恶意第三方伪造报文的难度很小。注意，在这个场景里，第三方并 [不需要] 处于通信双方的链路之间，只要他发出的报文可以抵达通信的一方即可。
因此我们需要精心挑选一个ISN，使得上述case发生的可能性尽可能低。
注意：不是在tcp协议的层面上100%避免，因为这会导致协议变得更复杂，实现上增加额外的开销，而在绝大多数情况下是不必要的。如果需要“100%可靠”，需要在应用层协议上增加额外的校验机制；或者使用类似IPSec这样的网络层协议来保证对包的有效识别。
那么，ISN应该如何挑选呢？
== ISN生成器 ==
说起来其实很简单：
TCP协议的要求是，实现一个大约每 4 微秒加 1 的 32bit 计数器（时钟），在每次创建一个新连接时，使用这个计数器的值作为ISN。
假设传输速度是 2 Mb/s，连接使用的sequence number大约需要 4.55 小时才会溢出并绕回（wrap-around）到ISN。即使提高到 100 Mb/s，也需要大约 5.4 分钟。
而一个包在网络中滞留的时间通常是有限的，这个时间我们称之为MSL（Maximum Segment Lifetime），工程实践中一般认为不会超过2分钟。
所以我们一般不用担心本次连接的早期segment（tcp协议称之为 old duplicates）导致的混淆。
注：在家用千兆以太网已经逐渐普及、服务器间开始使用万兆以太网卡的今天，wrap-around的时间已经降低到32.8s（千兆）、3.28s（万兆），这个假定已经不太站得住脚了，因此 rfc1185 针对这种高带宽环境提出了一种扩展方案，通过在报文中加上时间戳，从而可以识别出这些 old duplicates。
主要风险在于前面提到的场景：前一个连接可能传输了较多数据，因此其序列号可能大于当前连接的ISN；如果该连接的报文因为某种原因滞留、现在又突然冒出来，当前连接将无法分辨。
因此，TCP协议要求在断开连接时，TIME-WAIT 状态需要保留 2 MSL 的时间才能转成 CLOSED（如下图底部所示）。
（tcp连接状态图，截取自rfc 793）
那么问题又来了：为什么只有 TIME-WAIT 需要等待 2MSL，而LAST-ACK不需要呢？
== 报文 ==
针对TCP协议可以提的问题太多了，写得有点累，所以这里不打算继续自问自答了。
但写了这么多，还没有看一下TCP报文是什么结构的，实在不应该，这里还是祭出 rfc 793 里的 ascii art（并顺便佩服rfc大佬的画图功力）
简单介绍下：
* 一行是4个字节（32 bits），header一般共5行（options和padding是可选的）
* 第一行包含了源端口和目的端口
* 每个端口16bits，所以端口最大是65535
* 源IP和目的IP在IP报文头里
* 第二行是本次报文的Sequence Number
* 第三行是ACK序列号
* 第四行包含了较多信息：
* 数据偏移量：4字节的倍数，最小是0101（5），表示数据从第20个字节开始（大部分情况）
* 控制位（CTL）：一共6个，其中的ACK、SYN、FIN就不介绍了
* RST是Reset，遇到异常情况时通知对方重置连接（我们敬爱的防火墙很爱用它）
* URG表示这个报文很重要，应该优先传送、接收方应该及时给上层应用。URG的数据不影响seq，实际很少被用到，感兴趣的话可以参考下RFC 854（Telnet协议）
* PSH表示这个报文不应该被缓存、应当立即被发送出去。在交互式应用中比较常用，如ssh，用户每按下一个键都应该及时发出去。注意和Nagle算法可能会有一些冲突。
* 窗口大小：表示这个包的发送方当前可以接受的数据量（字节数），从这个包里的ack序号开始算起。**用于控制滑动窗口大小的关键字段就是它了。**
举个例子，三次握手的第二步，SYN和ACK合并的报文就是这么生成的：
* Sequence Number填入从ISN生成器中获取的值
* Acknowledgement Number填入 [发送方的序号 + 1]
* 将控制位中的ACK位、SYN位都置1
写不动了，真是没完没了（相信看到这里的同学已经不多了），但是TCP协议中还有很多有意思的设计本文完全没有涉及，文末我给出一些推荐阅读的链接，供感兴趣的同学参考。
== 总结 ==
* TCP“三次握手”翻译不准确
* 握手的目的是双方协商初始序列号ISN
* 序列号是用于保证通信的可靠性
* 不使用 0 作为ISN可以避免一些坑
* TCP报文里包含了端口号、2个序列号、一些控制位、滑动窗口大小
* 我在字节跳动网盟广告业务线（穿山甲），由于业务持续高速发展，长期缺人。关于字节跳动面试的详情，可参考我之前写的
* 《程序员面试指北：面试官视角》
* https://mp.weixin.qq.com/s/Byvu-w7kyby-L7FBCE24Uw
~ 投递链接 ~
后端开发(上海) https://job.toutiao.com/s/sBAvKe
后端开发(北京) https://job.toutiao.com/s/sBMyxk
广告策略研发(上海) https://job.toutiao.com/s/sBDMAK
其他地区、职能线 https://job.toutiao.com/s/sB9Jqk
== 推荐阅读 ==
[1] RFC 793：TRANSMISSION CONTROL PROTOCOL
https://tools.ietf.org/html/rfc793
[2] Coolshell - TCP 的那些事儿 （上 & 下）
https://coolshell.cn/articles/11564.html
https://coolshell.cn/articles/11609.html
[3] 知乎 - TCP 为什么是三次握手，而不是两次或四？
https://www.zhihu.com/question/24853633
== 握手 ==
多少有点令人意外的是，大多数程序员对TCP协议的印象仅限于在创建连接时的三次握手。
严格地说，“三次握手”其实是一个不太准确的翻译，英文原文是 "3-way handshake"，意思是握手有三个步骤。
不过既然教科书都这么翻译，我就只能先忍了。
“三次握手”的步骤相信各位都非常熟悉了：
引用
A: 喂，听得到吗 (SYN)
B: 阔以，你呢 (SYN-ACK)
A: 我也阔以，开始唠吧 (ACK)
B: 阔以，你呢 (SYN-ACK)
A: 我也阔以，开始唠吧 (ACK)
（咦，这不是远程面试的开场白吗）
那么问题来了：为什么不是2次握手或者4次握手呢？
== 3次 ==
针对“为什么不是4次”，知乎的段子手是这么回答的：
引用
A: 喂，听得到吗 (SYN)
B: 阔以，你呢 (SYN-ACK)
A: 我也阔以，你呢 (SYN-ACK)
B: ...我不想和傻*说话 (FIN)
B: 阔以，你呢 (SYN-ACK)
A: 我也阔以，你呢 (SYN-ACK)
B: ...我不想和傻*说话 (FIN)
实际上，上面省略了真正重要的信息，在握手过程中传输的，不是“你能不能听得到”，而是：
引用
A: 喂，我的数据从x开始编号 (SYN)
B: 知道了，我的从y开始编号 (SYN-ACK)
A: 行，咱俩开始唠吧 (ACK)
B: 知道了，我的从y开始编号 (SYN-ACK)
A: 行，咱俩开始唠吧 (ACK)
协商一个序号的过程需要一个来回（告知 + 确认），理论上需要2个来回（4次），互相确认了双方的初始序号（ISN，Initial Sequence Number），才能真正开始通信。
由于第二个来回的“告知”可以和前一次的“确认”合并在同一个报文里（具体怎么结合后面讲），因此最终只需要3次握手，就可以建立起一个tcp链接。
这也解释了为什么不能只有2次握手：因为只能协商一个序号。
不过话说回来，知乎段子手的回复也不是全在抖机灵：毕竟，发起方怎么才能确认接收方已经知道发起方知道接收方知道了呢？即使发起方再问一遍，接收方又怎么知道发起方知道了接收方知道了呢？
很遗憾，结论是：无论多少个来回都不能保证双方达成一致。
由于实践中丢包率通常不高，因此最合理的做法就是3次握手（2个来回），少了不够，多了白搭；同时配上相应的容错机制。
例如 SYN+ACK 包丢失，那么发起方在等待超时后重传SYN包即可。
引用
想想看，如果最后一个ACK丢了会怎样？
然后问题又来了：为什么需要协商初始序号，才能开始通信呢？
== 可靠 ==
我们都知道，tcp是一个“可靠”（Reliable）的协议。
这里“可靠”指的不是保证送达，毕竟网络链路中存在太多不可靠因素。
在 IETF 的 RFC 793（TCP协议）中，Reliability的具体定义是：TCP协议必须能够应对网络通信系统中损坏、丢失、重复或者乱序发送的数据。
引用
Reliability:
The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system.
https://tools.ietf.org/html/rfc793
The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system.
https://tools.ietf.org/html/rfc793
为了保证这一点，tcp需要给每一个 [字节] 编号：双方通过三次握手，互相确定了对方的初始序号，后续 [每个包的序号 - 初始序号] 就能标识该包在字节流中所处的位置，这样就可以通过重传来保证数据的连续性。
举个例子：
* 发送方（ISN=4000）
* 发出 4001、4002、4003、4004
* （假设每个包只有1字节的数据）
* 接收方
* 收到 4001、4002、4004
* 4003因为某种原因没有抵达
* 这时上层应用只能读到4001、4002中的信息
由于接收方没有收到4003，因此给发送方的ACK中，序号最大值是4003（表示收到了4003之前的数据）。
过了一段时间（Linux下默认是1s），发送方发现4003一直没被ACK，就会重传这个包。
当接收方最终收到 4003 以后，上层应用才可以读到4003和4004，从而保证其收到的消息都是可靠的。（以及，接收方需要给发送方ACK，序号是4005）
注意：虽然ISN=4000，但是发送方发送的第一个包，SEQ是4001开始的，TCP协议规定 SYN 需要占一个序号（虽然SYN并不是实际传输的数据），所以前面示意图中ACK的seq是 x+1 。同样，FIN也会占用一个序号，这样可以保证FIN报文的重传和确认不会有歧义。
但是，为什么序号不能从 0 开始呢？
== 可靠² ==
真实世界的复杂性总是让人头秃。
我们知道，操作系统使用五元组（协议=tcp，源IP，源端口，目的IP，目的端口）来标识一个连接，当一个包抵达时，会根据这个包的信息，将它分发到对应的连接去处理。
一般情况下，服务器的端口号通常是固定的（如http 80），而操作系统会为客户端随机分配一个最近没有被使用的端口号，因此包总能被分发到正确的连接里。
但在某些特殊的场景下（例如快速、连续地开启和关闭连接），客户端使用的端口号也可能和上一次一样（或者用了其他刚断开的连接的端口号）。
而TCP协议并不对此作出限制：
引用
The protocol places no restriction on a particular connection being used over and over again. ... New instances of a connection will be referred to as incarnations of the connection.
那么：
* 如果前一个连接的包，因为某种原因滞留在网络中，这会儿才送达，客户端可能无法区分（其sequence number在本连接中可能是有效的）。
* 恶意第三方伪造报文的难度很小。注意，在这个场景里，第三方并 [不需要] 处于通信双方的链路之间，只要他发出的报文可以抵达通信的一方即可。
因此我们需要精心挑选一个ISN，使得上述case发生的可能性尽可能低。
注意：不是在tcp协议的层面上100%避免，因为这会导致协议变得更复杂，实现上增加额外的开销，而在绝大多数情况下是不必要的。如果需要“100%可靠”，需要在应用层协议上增加额外的校验机制；或者使用类似IPSec这样的网络层协议来保证对包的有效识别。
那么，ISN应该如何挑选呢？
== ISN生成器 ==
说起来其实很简单：
TCP协议的要求是，实现一个大约每 4 微秒加 1 的 32bit 计数器（时钟），在每次创建一个新连接时，使用这个计数器的值作为ISN。
假设传输速度是 2 Mb/s，连接使用的sequence number大约需要 4.55 小时才会溢出并绕回（wrap-around）到ISN。即使提高到 100 Mb/s，也需要大约 5.4 分钟。
而一个包在网络中滞留的时间通常是有限的，这个时间我们称之为MSL（Maximum Segment Lifetime），工程实践中一般认为不会超过2分钟。
所以我们一般不用担心本次连接的早期segment（tcp协议称之为 old duplicates）导致的混淆。
注：在家用千兆以太网已经逐渐普及、服务器间开始使用万兆以太网卡的今天，wrap-around的时间已经降低到32.8s（千兆）、3.28s（万兆），这个假定已经不太站得住脚了，因此 rfc1185 针对这种高带宽环境提出了一种扩展方案，通过在报文中加上时间戳，从而可以识别出这些 old duplicates。
主要风险在于前面提到的场景：前一个连接可能传输了较多数据，因此其序列号可能大于当前连接的ISN；如果该连接的报文因为某种原因滞留、现在又突然冒出来，当前连接将无法分辨。
因此，TCP协议要求在断开连接时，TIME-WAIT 状态需要保留 2 MSL 的时间才能转成 CLOSED（如下图底部所示）。
（tcp连接状态图，截取自rfc 793）
那么问题又来了：为什么只有 TIME-WAIT 需要等待 2MSL，而LAST-ACK不需要呢？
== 报文 ==
针对TCP协议可以提的问题太多了，写得有点累，所以这里不打算继续自问自答了。
但写了这么多，还没有看一下TCP报文是什么结构的，实在不应该，这里还是祭出 rfc 793 里的 ascii art（并顺便佩服rfc大佬的画图功力）
简单介绍下：
* 一行是4个字节（32 bits），header一般共5行（options和padding是可选的）
* 第一行包含了源端口和目的端口
* 每个端口16bits，所以端口最大是65535
* 源IP和目的IP在IP报文头里
* 第二行是本次报文的Sequence Number
* 第三行是ACK序列号
* 第四行包含了较多信息：
* 数据偏移量：4字节的倍数，最小是0101（5），表示数据从第20个字节开始（大部分情况）
* 控制位（CTL）：一共6个，其中的ACK、SYN、FIN就不介绍了
* RST是Reset，遇到异常情况时通知对方重置连接（我们敬爱的防火墙很爱用它）
* URG表示这个报文很重要，应该优先传送、接收方应该及时给上层应用。URG的数据不影响seq，实际很少被用到，感兴趣的话可以参考下RFC 854（Telnet协议）
* PSH表示这个报文不应该被缓存、应当立即被发送出去。在交互式应用中比较常用，如ssh，用户每按下一个键都应该及时发出去。注意和Nagle算法可能会有一些冲突。
* 窗口大小：表示这个包的发送方当前可以接受的数据量（字节数），从这个包里的ack序号开始算起。**用于控制滑动窗口大小的关键字段就是它了。**
举个例子，三次握手的第二步，SYN和ACK合并的报文就是这么生成的：
* Sequence Number填入从ISN生成器中获取的值
* Acknowledgement Number填入 [发送方的序号 + 1]
* 将控制位中的ACK位、SYN位都置1
写不动了，真是没完没了（相信看到这里的同学已经不多了），但是TCP协议中还有很多有意思的设计本文完全没有涉及，文末我给出一些推荐阅读的链接，供感兴趣的同学参考。
== 总结 ==
* TCP“三次握手”翻译不准确
* 握手的目的是双方协商初始序列号ISN
* 序列号是用于保证通信的可靠性
* 不使用 0 作为ISN可以避免一些坑
* TCP报文里包含了端口号、2个序列号、一些控制位、滑动窗口大小
* 我在字节跳动网盟广告业务线（穿山甲），由于业务持续高速发展，长期缺人。关于字节跳动面试的详情，可参考我之前写的
* 《程序员面试指北：面试官视角》
* https://mp.weixin.qq.com/s/Byvu-w7kyby-L7FBCE24Uw
~ 投递链接 ~
后端开发(上海) https://job.toutiao.com/s/sBAvKe
后端开发(北京) https://job.toutiao.com/s/sBMyxk
广告策略研发(上海) https://job.toutiao.com/s/sBDMAK
其他地区、职能线 https://job.toutiao.com/s/sB9Jqk
== 推荐阅读 ==
[1] RFC 793：TRANSMISSION CONTROL PROTOCOL
https://tools.ietf.org/html/rfc793
[2] Coolshell - TCP 的那些事儿 （上 & 下）
https://coolshell.cn/articles/11564.html
https://coolshell.cn/articles/11609.html
[3] 知乎 - TCP 为什么是三次握手，而不是两次或四？
https://www.zhihu.com/question/24853633
