关注TCP/IP的若干事

TCP协议组成

• TCP头部组成

  

TCP3次握手

过程描述

• 客户端（client）-> 发起请求：携带 SYN=1 ACK=0 Seq=x (SYN=1不能携带数据，但需要一个序号)
• 服务端（server）-> 回复确认：携带 SYN=1 ACK=x+1 Seq=y
• 客户端（client）-> 二次确认：携带 ACK=y+1 Seq=x+1

为什么需要3次握手

• 信道不可靠，通信双方需要就某个问题达成一致；

TCP4次挥手

过程描述

• 客户端（client）-> 发起释放请求：携带 FIN=1 Seq=u
• 服务端（server）-> 回复确认：携带 ACK=u+1 ， seq=v -> Close-Wait
• 服务端（server）-> 发送数据 ： 携带 FIN=1 ACK=u+1 Seq=w -> Close Wait
• 客户端（client）-> 再次确认：携带 ACK=w+1 Seq=u+1 ->Time-Wait

为什么需要等待

• 客户端接到服务端的释放连接请求之后 -> 发送一个确认信息
• 信息丢失，服务端未收到确认释放连接指令
• 服务端重发释放连接请求
• 此时，客户端处于TIME_WAIT状态，再次给服务端发送一个确认消息

为什么TIME_WAIT状态需要等2*MSL秒后才能返回到CLISED状态

• 网络不可靠，无法保证最后发送的ACK报文一定会被对方收到，作用是用来重发可能丢失的ACK报文

TCP11种状态

• CLOSED 初始状态，TCP连接未打开

• LISTEN 处于socket监听状态，等待接受客户端连接

• SYN_RCVD 表示服务器接收到了来自客户端请求连接的SYN报文

• SYN_SENT 表示客户端已发送SYN报文

• ESTABLISHED 表示TCP连接已经成功建立

• FIN_WAIT_1

• FIN_WAIT_2

• TIME_WAIT 表示收到了对方的FIN报文，并发送出了ACK报文

• CLOSING 表示双方都正在关闭SOCKET连接

  

• CLOSE_WAIT 表示正在等待关闭

• LAST_ACK 当被动关闭的一方在发送FIN报文后，等待对方的ACK报文的时候，就处于LAST_ACK 状态

参考

[1] https://www.cnblogs.com/qingergege/p/6603488.html?from=singlemessage&isappinstalled=0