TCP（上）

1 包头格式

tcp包头

序号：给包编号，解决乱序问题

确认序号：包被收到后进行确认。解决不丢包。第三次握手会确认初始序号。当操作系初始化时，有一个全局变量假设为 g_number 被初始化为 1（或 0），然后每隔 4us 加 1. 当 g_number 达到最大值的时候又绕回到 0.当新连接建立时，就把 g_number 的值赋值给 ISN.

状态位：SYN发起连接、ACK是回复，RST是重新连接、FIN是结束连接、URG和PSH暂时没搞懂

窗口大小：流量控制。标识目前处理包的能力，基于这个来控制发送包的速度。

2 TCP的三次握手

2.1 为什么是三次握手

2.1.1 两次握手存在的问题

场景1：假设A、B建立连接，如果A发起一个连接请求，B收到请求后应答了这个请求。如果B的应答包丢了，则会导致B认为已经建立了连接，但A那边认为建立连接失败。B认为的连接一直存在，没有终结的情况。

场景2：A、B建立了连接后，马上关闭了连接。但在建立连接的时候，由于长时间没收到应答，A多次发送了请求包。连接关闭后，A之前发送请求连接的包才到达B。B认为是一个正常的连接请求，因此建立了连接，但这个连接没有存在的意义。

2.2 三次握手流程

三次握手流程

2.3 三次握手的作用

建立可靠的连接

第三次握手时确认初始序号

3 TCP的四次握手

3.1 关闭原则

TCP连接是全双工的，因此每个方向都要进行关闭。这个原则是当一方它想要关闭时，就发送一个FIN来终止这个连接。我们定义发送FIN的为主动方、收到FIN的为被动方。被动方收到FIN后，仍然可以向主动方发送数据。

3.2  四次挥手

3.2.1 简要版关闭流程

1：A向B发送FIN。

2：B向A ACK

3：B处理完A之前发送的请求包后后，也向A发送FIN

4：A向B ACK

注：第2步之后，A可以选择不再接收数据，也可以在接收一段时间数据，知道B发送FIN

3.2.2 状态时序图

四次挥手状态时序图

3.2.2.1 异常情况的处理机制

A进入FIN_WAIT_2时，如果B跑路，A有可能永远在这个状态里。TCP协议里并没有对这个状态处理，linux中有tcp_fin_timeout参数，设置超时时间。

B也发送FIN后，A收到后直接跑路。如果B没有收到A的ACK，那么B会一直重发。因此TCP协议要求A需要最后等待一段时间。这段时间叫TIME_WAIT，TIME_WAIT要足够长。时间长度要保证B没有收到ACK并重发FIN、A发送ACK到B的时间。如果超过这个时间B还是没收到ACK，B会重发ACK，但A收到后会发送RST，B就知道A已经跑路了。如果在B没收到ACK，但A提前跑路，如果此时开启一个新的应用占用了这个端口。虽然序列号是重新生成的，但为了防止产生混乱，TIME_WAIT设置的长一点。

4 TCP的握手和挥手的个人理解

三次握手的目的：建立可靠的通讯，确定双方的发送和接受都是可靠的