网络协议：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 状态机。我们可以将这个状态机和时序状态机对照看，就会更加明了。