网络协议 8 - TCP协议（上） - Linux

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

上次说了“性本善”的 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 跑路了。