iOS知识复习笔记（17）---tcp建立连接和断开连接

一、TCP建立连接过程---三次握手

1. 第一次握手 ，客户端发送连接请求 同步位SYN = 1 ,随机选择起始序号：seq=x，不携带数据（消耗一个序号） ,客户端进入同步已发送状态（SYN_SEND）。
2. 第二次握手，服务器收到请求连接后若同意连接则向客户端发送连接确认，同步位SYN=1，确认标记ACK=1，随机起始序号：seq=y，确认号字段 ack=x+1,不携带数据. 服务器进入同步已接收状态（SYN_RCVD）。
3. 第三次握手，客户端收到确认报文后，向服务器再次发送连接确认报文，ACK=1，序号：seq=x+1,确认号字段 ack = y+1,可携带数据，客户端、服务器都进入已创建状态（ESTABLISHED）

为什么要三次握手，不能两次？

1. 主要原因是为了防止旧的重复连接引起连接混乱的问题。
   因为在网络状况复杂或者是比较差的情况下，发送方很可能建立多次连接请求，由于网络问题导致的过期请求发送到了服务端，造成错误连接。如果是三次连接，那么客户端在收到服务端返回的确认请求后能判断是否为历史连接，如果是历史连接，就会向服务端发送终止报文来给服务端终止连接。不过不是就和服务端正常建立连接。

2. 同步初始化和序列号
   因为我们知道tcp一个重要特征是可靠性，他就是需要“序列号”来保证自己数据的可靠性，防止数据包的重复发送，和解决数据包顺序颠倒问题。

   
   三次握手.png

二、TCP断开连接过程---四次挥手

1. 第一次挥手，客户端向服务器发送连接释放报文，中止位FIN=1，序号为最后一个字节序号加1 ，seq=u，可携带数据，客户端进入中止等待状态（FIN-WAIT-1）
2. 第二次挥手，服务器收到释放连接后，则向客户端发回连接释放确认报文，ACK=1，序号seq=v,确认号 ack=u+1, 服务器进入关闭等待状态（CLOSE-WAIT）, 客服端收到服务器确认后，进入终止等待2状态（FIN-WAIT-2）,等待服务器发送连接释放请求，至此客服端->服务端的tcp已经断开，处于半关闭状态
3. 第三次挥手，若服务器已无要向客服端发送数据，则发出连接释放报文，FIN=1，ACK=1
   seq=w,确认好 ack= u+1,可携带数据，服务器进入最后确认状态（LAST-ACK）
4. 第四次挥手，客服端收到连接释放报文后，则向服务器发回释放连接确认报文，ACK=1，seq=u+1 确认号ack=w+1，可携带数据, 客服端进入时间等待状态（TIME-WAIT）,服务器进入关闭状态（CLOSED）, 此时TCP连接还未释放，须经过时间等待计时器设置的时间2MSL后，客服端才进入关闭状态，即服务器关闭比客户端关闭早一些。

为什么要四次挥手而不是三次？

为了确保通信双方都能通知到对方去释放和断开连接，因为服务端可能在接收到FIN报文的时候还有数据没发完，所以一般都是先回一个ACK确认报文，然后等数据发送完毕了，再发一个FIN报文通知客户端。

客户端为啥还要等2MSL才进行关闭？

为了保证客户发送的最后一个报文能到达服务端
2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长

如果服务端在1MSL内没收到ACK报文，就会重新发送FIN，如果客户端在2MSL内收到FIN说明之前发送ACK，服务端没收到，会重新计时，然后再才发送ACK报文给服务端，如果2MSL内没有收到FIN，这说明服务端收到了ACK报文，这是客户端就可以正常关闭了。 四次挥手.png