趣谈网络协议—— TCP协议（上）：因性恶而复杂，先恶后善反轻松

天然认为网络环境是恶劣的，丢包、乱序、重传，拥塞都是常有的事情，一言不合就可能送达不了，因而要从算法层面来保证可靠性。

TCP头部

（1）源端口号和目标端口号：用来区分发往那个应用
（2）包的序号：为了解决乱序问题。
（3）确认序号：确认发送的包对方是否收到。
（4）状态位：例如 SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。
（5）窗口大小：TCP 要做流量控制，通信双方各声明一个窗口，标识自己当前能够的处理能力。
总结：
顺序问题 ，稳重不乱；
丢包问题，承诺靠谱；
连接维护，有始有终；
流量控制，把握分寸；
拥塞控制，知进知退。

TCP三次握手

请求 -> 应答 -> 应答之应答

三次握手的原因

A向B发送请求。若B不返回应答包，A不知道请求B是否收到。若B收到请求包，就知道A的存在，并且A要与之建立连接，若B不想建立连接，A重试一段时间就会放弃。若B想与之建立链接，则返回应答包给A。若A不给B再返回应答包，B不知道建立连接的请求A是否收到。并且无法避免之前A因为网络原因，之前发送的网络包现在刚到B。理论上可以需要无限验证，但一般认为只需要三次就足够了。

大部分情况下，A 和 B 建立了连接之后，A 会马上发送数据的，一旦 A 发送数据，则很多问题都得到了解决。三次握手除了双方建立连接外，主要还是为了沟通一件事情，就是**TCP 包的序号的问题。**为了避免冲突，A 要告诉 B，我这面发起的包的序号起始是从哪个号开始的，B 同样也要告诉 A，B 发起的包的序号起始是从哪个号开始的。

（1）客户端和服务端都处于 CLOSED 状态；
（2）服务端主动监听某个端口，处于 LISTEN 状态；
（3）客户端主动发起连接 SYN，之后处于 SYN-SENT 状态；
（4）务端收到发起的连接，返回 SYN，并且 ACK 客户端的 SYN，之后处于 SYN-RCVD 状态；
（5）户端收到服务端发送的 SYN 和 ACK 之后，发送 ACK 的 ACK，之后处于 ESTABLISHED 状态，因为它一发一收成功了；
（6）服务端收到 ACK 的 ACK 之后，处于 ESTABLISHED 状态，因为它也一发一收了；

TCP四次挥手

A：B 啊，我不想玩了。

B：哦，你不想玩了啊，我知道了。

这个时候，还只是 A 不想玩了，也即 A 不会再发送数据，但是 B 能不能在 ACK 的时候，直接关闭呢？当然不可以了，很有可能 A 是发完了最后的数据就准备不玩了，但是 B 还没做完自己的事情，还是可以发送数据的，所以称为半关闭的状态。

这个时候 A 可以选择不再接收数据了，也可以选择最后再接收一段数据，等待 B 也主动关闭。

B：A 啊，好吧，我也不玩了，拜拜。

A：好的，拜拜。

这样整个连接就关闭了。但是这个过程有没有异常情况呢？当然有，上面是和平分手的场面。

A 开始说“不玩了”，B 说“知道了”，这个回合，是没什么问题的，因为在此之前，双方还处于合作的状态，如果 A 说“不玩了”，没有收到回复，则 A 会重新发送“不玩了”。但是这个回合结束之后，就有可能出现异常情况了，因为已经有一方率先撕破脸。

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

（1）当 A 说“不玩了”，就进入 FIN_WAIT_1 的状态；
（2）B 收到“A 不玩”的消息后，发送知道了，就进入 CLOSE_WAIT 的状态
（3）A 收到“B 说知道了”，就进入 FIN_WAIT_2 的状态，如果这个时候 B 直接跑路，则 A 将永远在这个状态。TCP 协议里面并没有对这个状态的处理，但是 Linux 有，可以调整 tcp_fin_timeout 这个参数，设置一个超时时间。
（4）B发送了“B 也不玩了”的请求到达 A 时，A 发送“知道 B 也不玩了”的 ACK 后，从 FIN_WAIT_2 状态结束，按说 A 可以跑路了，但是最后的这个 ACK 万一 B 收不到呢？则 B 会重新发一个“B 不玩了”，这个时候 A 已经跑路了的话，B 就再也收不到 ACK 了，因而 TCP 协议要求 A 最后等待一段时间 TIME_WAIT，这个时间要足够长，长到如果 B 没收到 ACK 的话，“B 说不玩了”会重发的，A 会重新发一个 ACK 并且足够时间到达 B。

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

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