网络协议 8 - TCP协议（上）：性恶就要套路深 - 好文

系列文章：

* 网络协议 1 - 概述 <https://www.cnblogs.com/BeiGuo-FengGuang/p/9848805.html>
* 网络协议 2 - IP 是怎么来，又是怎么没的？
<https://www.cnblogs.com/BeiGuo-FengGuang/p/9877801.html>
* 网络协议 3 - 从物理层到 MAC 层
<https://www.cnblogs.com/BeiGuo-FengGuang/p/9923983.html>
* 网络协议 4 - 交换机与 VLAN：办公室太复杂，我要回学校
<https://www.cnblogs.com/BeiGuo-FengGuang/p/9940063.html>
* 网络协议 5 - ICMP 与 ping：投石问路的侦察兵
<https://www.cnblogs.com/BeiGuo-FengGuang/p/9970831.html>
* 网络协议 6 - 路由协议：敢问路在何方？
<https://www.cnblogs.com/BeiGuo-FengGuang/p/9990693.html>
* 网络协议 7 - UDP 协议：性善碰到城会玩
<https://www.cnblogs.com/BeiGuo-FengGuang/p/10015576.html>
上次说了“性本善”的 UDP 协议，这哥们秉承“网之初，性本善，不丢包，不乱序”的原则，徜徉在网络世界中。

与之相对应的，TCP
就像是老大哥一样，了解了社会的残酷，变得复杂而成熟，秉承“性恶论”。它认为网络环境是恶劣的，丢包、乱序、重传、拥塞都是常有的事儿，一言不合可能就会丢包，送达不了，所以从算法层面来保证可靠性。

TCP 包头格式

老规矩，咱们先来看看 TCP 头的格式。

从上面这个图可以看出，它比 UDP 要复杂的多。而复杂的地方，也正是它为了解决 UDP 存在的问题所必需的字段。

首先，源端口号和目标端口号是两者都有，不可缺少的字段。

接下来是包的序号。给包编号就是为了解决乱序的问题。老大哥做事，稳重为主，一件件来，面临再复杂的情况，也临危不乱。

除了发送端需要给包编号外，接收方也会回复确认序号。做事靠谱，答应了就要做到，暂时做不到也要给个回复。

这里要注意的是，TCP 是个老大哥没错，但不能说他一定会保证传输准确无误的完成。从 IP 层面来讲，如果网络的确那么差，是没有任何可靠性保证的，即使
TCP 老大哥再稳，他也管不了 IP 层丢包，他只能尽可能的保证在他的层面上的可靠性。

然后是一些状态位。有以下常见状态位：

* SYN（Synchronize Sequence Numbers，同步序列编号）：发起一个连接
* ACK（Acknowledgement，确认字符）：回复
* RST（Connection reset）：重新连接
* FIN：结束连接
从这些状态位就可以看出，TCP 基于“性恶论”，警觉性就很高，不像 UDP
和小朋友似的，随便一个不认识的小朋友都能玩到一起，他与别人的信任要经过多次交互才能建立。

还有一个窗口大小。这个是 TCP
用来进行流量控制的。通信双方各声明一个窗口，标识自己当前的处理能力，让发送端别发送的太快，要不然撑死接收端。也不能发送的太慢，要不然就饿死接收端了。

根据上述对 TCP 头的分析，我们知道对于 TCP 协议要重点关注以下几个问题：

* 顺序问题，稳重不乱；
* 丢包问题，承诺靠谱；
* 连接伟豪，有始有终；
* 流量控制，把握分寸；
* 拥塞控制，知进知退。
TCP 的三次握手

了解完 TCP 头，我们就来看下 TCP 建立连接的过程，这就是著名的“三次握手”。

三次握手，过程是这样子的：

* A：你好，我是 A（SYN）。
* B：你好 A，我是 B（SYN，ACK）。
* A：你好 B（ACK 的 ACK）。
着重记忆上述过程，后续很多分析都是基于这个过程来的。

记得刚接触三次握手的时候，就一直很纳闷，为啥一定要三次？两次不行吗？四次不行吗？然后很多人就解释，如果是两次，就怎样怎样，四次，又怎样怎样？但这其实都是
从结果推原因，没有说明本质。

我们应该知道，握手是为了建立稳定的连接，这个是最终目的。而要达到这个目的，就要通信双方的交互形成一个确认的闭环。

拿上述 A、B 通信的例子来看，A 给 B 发信息，B 要告诉 A 他收到信息了。这时候，算是一个确认闭环吗？明显不是，因为 B 没有收到来自 A
的确认信息。

所以，要达到我们上述的目标，还要 A 给 B 一个确认信息，这样就形成了一个确认闭环。

A 给 B 的确认信息发出后，遇到网络不好的情况，也会出现丢包的情况。按理来说，还应该有个回应，但是，我们发现，好像这样下去就没玩没了啦。

所以，我们说，只要通信双方形成一个确认闭环后，就认为连接已建立。一旦连接建立，A 会马上发送数据，而 A 发送数据，后续的很多问题都得到了解决。

例如 A 发给 B 的确认消息丢了，当 A 后续发送的数据到达的时候，B 可以认为这个连接已经建立。如果 B 直接挂了，A 发送的数据就会报错，说
B 不可达，这样，A 也知道 B 出事情了。

三次握手除了通信双方建立连接外，主要还是为了沟通 TCP 包的序号问题。

A 要告诉 B，我发起的包的序号起始是从哪个号开始的，B 也要告诉 A，B 发起的包的序号的起始号。

TCP 包的序号是会随时间变化的，可以看成一个 32 位的计数器，每 4ms 加一。计算一下，这样到出现重复号，需要 4 个多小时。但是，4
个小时后，还没到达目的地的包早就死翘翘了。这是因为 IP 包头里的 TTL（生存时间）。

为什么序号不能从 1 开始呢？因为这样会很容易出现冲突。

例如，A 连上 B 之后，发送了 1、2、3 三个包，但是发送 3 的时候，中间丢了，或者绕路了，于是重新发送，后来 A 掉线了，重新连上 B
后，序号又从 1 开始，然后发送 2，但是压根没想发送 3，而如果上次绕路的那个 3 刚好又回来了，发给了 B ，B 自然就认为，这就是下一包，于是发生了错误。

就这样，双方历经千辛万苦，终于建立了连接。前面也说过，为了维护这个连接，双方都要维护一个状态机，在连接建立的过程中，双方的状态变化时序图就像下面这样：

整体过程是：

* 客户端和服务端都处于 CLOSED 状态；
* 服务端主动监听某个端口，处于 LISTEN 状态；
* 客户端主动发起连接 SYN，处于 SYN-SENT 状态。
* 服务端收到客户端发起的连接，返回 SYN，并且 ACK 客户端的 SYN，处于 SYN-RCVD 状态；
* 客户端收到服务端发送的 SYN 和 ACK 之后，发送 ACK 的 ACK，处于 ESTABLISHED 状态；
* 服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态。
TCP 的四次挥手

说完了连接，接下来就来了解下 TCP 的“再见模式”。这也常被称为四次挥手。

还拿 A 和 B 举例，挥手过程：

* A：B 啊，我不想和你玩了。
* B：哦，你不想玩了啊，我知道了。这个时候，还只是 A 不想玩了，就是说 A 不会再发送数据，但是 B
此时还没做完自己的事情，还是可以发送数据的，所以此时的 B 处于半关闭状态。
* B：A啊，好吧，我也不想和你玩了，拜拜。
* A：好的，拜拜。
这样这个连接就关闭了。看起来过程很顺利，是的，这是通信双方“和平分手”的场面。

A 开始说“不玩了”，B 说“知道了”，这个回合，是没什么问题的，因为在此之前，双方还处于合作的状态。

如果 A 说“不玩了”，没有收到回复，那么 A
会重新发送“不玩了”。但是这个回合结束之后，就很可能出现异常情况了，因为有一方率先撕破脸。这种撕破脸有两种情况。

一种情况是，A 说完“不玩了”之后，A 直接跑路，这是会有问题的，因为 B 还没有发起结束，而如果 A 直接跑路，B 就算发起结束，也得不到回答，B
就就不知道该怎么办了。

另一种情况是，A 说完“不玩了”，B 直接跑路。这样也是有问题的，因为 A 不知道 B 是还有事情要处理，还是过一会发送结束。

为了解决这些问题，TCP 专门设计了几个状态来处理这些问题。接下来，我们就来看看断开连接时的状态时序图。

整体过程是：

* A 说“不玩了”，就进入 FIN_WAIT_1 状态；
* B 收到 “A 不玩”的消息后，回复“知道了”，就进入 CLOSE_WAIT 状态；
* A 收到“B 说知道了”，进入 FIN_WAIT_2 状态。这时候，如果 B 直接跑路，则 A 将永远在这个状态。TCP
协议里面并没有对这个状态的处理，但是 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间；
* B 没有跑路，发送了“B 也不玩了”的消息，处于 LAST_ACK 状态；
* A 收到“B 说不玩了”的消息，回复“A 知道 B 也不玩了”的消息后，从 FINE_WAIT_2 状态结束。
最后一个步骤里，如果 A 直接跑路了，也会出现问题。因为 A 的最后一个回复，B 如果没有收到的话就会重复第 4 步，但是因为 A 已经跑路了，所以
B 会一直重复第 4 步。

因此，TCP 协议要求 A 最后要等待一段时间，这个等待时间是 TIME_WAIT，这个时间要足够长，长到如果 B 没收到 A 的回复，B 重发给
A，A 的回复要有足够时间到达 B。

A 直接跑路还有一个问题是，A 的端口就空出来了，但是 B 不知道，B 原来发过的很多包可能还在路上，如果 A
的端口被新的应用占用了，这个新的应用会受到上个连接中 B 发过来的包，虽然序列号是重新生成的，但是这里会有一个双保险，防止产生混乱。因此也需要 A
等待足够长的时间，等到 B 发送的所有未到的包都“死翘翘”，再空出端口。

这个等待的时间设为 2MSL，MSL 是 Maximum Segment Lifetime，即报文最大生存时间
。它是任何报文再网络上存在的最长时间，超过这个时间的报文就会被丢弃。

因为 TCP 报文基于 IP 协议，而 IP 头中有一个 TTL 域，是 IP 数据报可以经过的最大路有数，每经过一个处理他的路由器，此值就减
1，当此值为 0 时，数据报就被丢弃，同时发送 ICMP 报文通知源主机。协议规定 MSL 为 2 分钟，实际应用中常用的是 30 秒、1分钟和 2 分钟等。

还有一种异常情况，B 超过了 2MS 的时间，依然没有收到它发的 FIN 的 ACK。按照 TCP 的原理，B 当然还会重发 FIN，这个时候 A
再收到这个包之后，就表示，我已经等你这么久，算是仁至义尽了，再来的数据包我就不认了，于是直接发送 RST，这样 B 就知道 A 跑路了。

TCP 状态机

将连接建立和连接断开的两个时序状态图综合起来，就是著名的 TCP 状态机。我们可以将这个状态机和时序状态机对照看，就会更加明了。

图中加黑加粗部分，是上面说到的主要流程，相关说明：

* 阿拉伯数字序号：建立连接顺序；
* 大写中文数字序号：断开连接顺序；
* 加粗实线：客户端 A 的状态变迁；
* 加粗虚线：服务端 B 的状态变迁；
总结

* TCP 包头很复杂，主要关注 5 个问题。顺序问题、丢包问题、连接维护、流量控制、拥塞控制；
* 建立连接三次握手，断开连接四次挥手，状态图要牢记。
参考：

* 百度百科-TCP 词条；
* 刘超-趣谈网络协议系列课；

热门工具换一换