socket通信原理三次握手和四次挥手详解及原因

喜欢ヅ旅行 2021-11-29 14:42 182阅读 0赞

## 1.socket在网络层中的位置 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70]

## 2.socket大致流程 ##

先从服务器端说起。服务器端先初始化Socket，然后与端口绑定(bind)，对端口进行监听(listen)，调用accept阻塞，等待客户端连接。在这时如果有个客户端初始化一个Socket，然后连接服务器(connect)，如果连接成功，这时客户端与服务器端的连接就建立了。客户端发送数据请求，服务器端接收请求并处理请求，然后把回应数据发送给客户端，客户端读取数据，最后关闭连接，一次交互结束。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70 1]  
概述  
我们都知道 TCP 是 可靠的数据传输协议，UDP是不可靠传输，那么TCP它是怎么保证可靠传输的呢？那我们就不得不提 TCP 的三次握手和四次挥手。

## 3. 三次握手 ##

下图为三次握手的流程图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70 2]  
**第一次握手**  
建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；（x 是随机生成的一个 int 数值）然后，客户端进入SYN\_SEND状态，等待服务器的确认；  
**第二次握手**  
服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为 y （y 是随机生存的一个 int 数值）；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN\_RECV状态；  
**第三次握手**  
客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

## 4.四次挥手 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70 3]  
**第一次挥手：**  
Client （可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment Number，向 Server发送一个FIN报文段；此时，Client 进入FIN\_WAIT\_1状态；这表示 Client 没有数据要发送给 Server了；  
**客户端发送第一次挥手后，就不能在向 服务端发送数据了。**

**第二次挥手：**  
Server 收到了 Client 发送的FIN报文段，向 Client 回一个ACK报文段，Acknowledgment Number 为 Sequence Number 加 1；Client 进入 FIN\_WAIT\_2 状态；Server 告诉 Client ，我“同意”你的关闭请求；  
**Server 第一次响应后，还可以继续向 Client 发送数据，这里只是告诉 Client ，我收到你发送的关闭请求。**

**第三次挥手**  
Server 向 Client 发送 FIN 报文段，请求关闭连接，同时 Server 进入 CLOSE\_WAIT 状态；  
**当 Server 的数据响应完成后，再告诉 Client，我这边也可以关闭请求了， 这时  
Server 就不能再向 Client 发送数据了**

**第四次挥手**  
Client 收到 Server 发送的 FIN 报文段，向 Server 发送 ACK 报文段，然后 Client 进入  
TIME\_WAIT 状态；Server 收到 Client 的 ACK 报文段以后，就关闭连接；此时，Client  
**等待2MSL后依然没有收到回复，则证明 Server 端已正常关闭，那好，Client 也可以关闭连接了。**  
什么是MSL

MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为tcp报文（segment）是ip数据报（datagram）的数据部分，具体称谓请参见《数据在网络各层中的称呼》一文，而ip头中有一个TTL域，TTL是time to live的缩写，中文可以译为“生存时间”，这个生存时间是由源主机设置初始值但不是存的具体时间，而是存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。

2MSL即两倍的MSL，TCP的TIME\_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME\_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME\_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。不过在实际应用中可以通过设置SO\_REUSEADDR选项达到不必等待2MSL时间结束再使用此端口。

TTL与MSL是有关系的但不是简单的相等的关系，MSL要大于等于TTL。

## 5.为什么要三次握手？ ##

TCP 建立连接，其实通过两次握手就可以建立连接了，为什么要三次呢？是不是多此一举呢？  
1、《计算机网络》中是这样说的：  
为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。  
在书中同时举了一个例子，如下：  
已失效的连接请求报文段”的产生在这样一种情况下：**client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了**，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

2、网络故障

比如，现在网络出现了故障，只能发请求数据包，而接收不到响应数据包，那么只要发送一次请求，服务器就建立请求，这样肯定也是不对的，网络请求有来有回才能完成通讯。所以三次握手是必不可少的。

## 6.为什么要四次挥手呢 ##

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当 Client 发出FIN报文段时，只是表示 Client 已经没有数据要发送了，Client 告诉 Server，它的数据已经全部发送完毕了；但是，这个时候 Client 还是可以接受来自 Server 的数据；当 Server 返回ACK报文段时，表示它已经知道 Client 没有数据发送了，但是 Server 还是可以发送数据到 Client 的；当 Server 也发送了FIN报文段时，这个时候就表示 Server 也没有数据要发送了，就会告诉 Client ，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理，就需要了解四次分手过程中的状态变化。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70]: /images/20211129/6631d08232f344bbb0837b24769f3dae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70 1]: /images/20211129/b4003f2a31da4d22b46be6e6b4607ee5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70 2]: /images/20211129/a1fccce144454380a8faecffdb8e6ce8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMDA0Mjg5_size_16_color_FFFFFF_t_70 3]: /images/20211129/9c16a8fea793433086c6464cfc49d3da.png