深入理解TCP三握四挥

Dear 丶 2023-03-12 12:21 16阅读 0赞

## 一、三次握手 ##

首先来看一张图

![format_png][]

最初，客户机A与服务器B的TCP进程都处于 CLOSED 状态。

然后由服务器B先创建TCB（传输控制块），进入到 LISTEN 状态，准备随时响应客户请求

下面开始三握：

>  *  第一次握手
> 
> 　　A的TCP进程创建TCB（传输控制块），然后向B发出连接请求报文段。段首部中的 同步位SYN=1，同时选择一个初始序列号seq=x；（SYN报文段不能携带数据，但需要消耗一个序列号）这时客户端A进入到 SYN-SENT（同步已发送）状态。
> 
>  *  第二次握手
> 
> 　　B收到连接请求报文段，如果同意建立连接，则向A发送确认。在确认报文段中 同步位SYN=1、确认位ACK=1、确认号ack=x+1（对接收的序列号seq=x的报文段进行确认，并期望接收的下一个报文段的序号seq=x+1），同时也为自己选择一个初始序列号seq=y，这时服务器B进入 SYN-RCVID 状态。
> 
> 　　注：该报文段是ACK报文段的同时也是SYN报文段，所以该报文段也不能携带数据。
> 
>  *  第三次握手
> 
> 　　A收到B的确认以后，再向B发出确认。确认报文 ACK=1、确认号ack=y+1（对接收的序列号seq=y的报文段进行确认，并期望接收的下一个报文段的序号seq=y+1）。这时A进入到 ESTAB-LISHED 状态。当B接收到A的确认后，也进入 ESTAB-LISHED 状态。连接建立完成
> 
> 　　注：ACK报文段可以携带数据，但如果不携带数据则不消耗序列号，在这种情况下，下一个报文段的序号不变，seq仍是x+1。

下面对 同步位SYN、确认位ACK、确认号ack 以及 三次握手时出现的五个状态 进行下解释

> 同步位SYN：在建立连接时用来同步序号；当SYN=1，ACK=0时，表明这是一个连接请求报文段。当SYN=1，ACK=1时，表明这是一个连接接收报文段；
> 
> 确认位ACK：当ACK=1时，确认号ack才生效。在请求建立连接后（第一次握手后），所有的报文段都必须把ACK置1。
> 
> 确认号ack：期望收到的下一个报文段的第一个数据字节的序号，比如：B正确接收到了A发送过来的一个报文段，序号是501，数据长度是200字节；这表明B正确接收到了序号501-700的数据。所以，B期望的下一个序号是701，于是B在发送给A的确认报文段中确认号ack=701。

> CLOSED：初始关闭状态
> 
> LISTEN：监听状态，等待客户连接
> 
> SYB-SENT：同步已发送
> 
> SYN-RCVD：同步已接收
> 
> ESTAB-LISHED：已建立连接

**面试问题1：**为什么不是两次握手？

> 这主要是为了防止已失效的连接请求报文段突然又传送到了 B，从而造成资源浪费。
> 
> 考虑一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段，但 B 收到此失效的连接请求报文段后，就误认为是 A 又发出了一次新的连接请求，于是就向 A 发出确认报文段，同意建立连接。假定不采用报文握手，那么只要 B 发出确认，新的连接就建立了。
> 
> 由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据，但 B 却认为新的运输连接已经建立了，并一直等待 A 发来数据，B 的许多资源就这样浪费了。
> 
> 采用三次握手的办法，可以防止上述现象的发生，例如在刚才的异常情况下，A 不会向 B 的确认发出确认，B 由于收不到确认，就知道 A 并没有要求建立连接。

**面试问题2：**为什么不是四次握手？

> 完全可靠的通信协议是根本不存在的，我们任何的通信协议都是在接受这样的现实情况之上进行的。 三次握手后，A 和 B 至少可以确认之前的通信情况，但无法确认之后的情况。在这个道理上说，无论是四次还是五次或是更多次都是徒劳的。

##  二、四次挥手 ##

再来看一张图

![format_png 1][]

A与B想要断开连接，需要经过四次挥手

>  *  第一次挥手：A先发送连接释放报文段，段首部的终止控制位FIN=1，序号seq=u（等于A前面发送数据的最后一个序号加1）；然后A进入 FIN-WAIT-1（终止等待1）状态，等待B的确认。A
> 
> 　　注：FIN报文段即使不携带数据也要消耗一个序列。
> 
>  *  第二次挥手：B收到A的连接释放报文段后，立刻发出确认报文段，确认号ack=u+1，序号seq=v（等于B前面发送数据的最后一个序号加1）；然后B进入CLOSE-WAIT（关闭等待）状态。
> 
> 　　注：TCP服务器这时会通知高层应用进程，从A到B这个方向的连接就断开了，这时TCP连接处于半关闭（half-close）状态；但B到A这个方向的连接并没有断，B任然可以向A发送数据。
> 
>  *  第三次挥手：A收到B的确认报文段后进入到 FIN-WAIT-2（终止等待2）状态，继续等待B发出连接释放报文段；若B已经没有数据要发送，B就会向A发送连接释放报文段，段首部的终止控制位 FIN=1，序号seq=w（半关闭状态可能又发送了一些数据），确认号ack=u+1，这时B进入LAST-ACK（最后确认）状态，等待A的确认。
> 
> 　　特别注意：确认号ack没有变，仍然为上次发送过的确认号u+1。
> 
>  *  第四次挥手：A收到B的连接释放报文段并发出确认，确认段中 确认位ACK=1，确认号ack=w+1，序号seq=u+1；然后A进入到TIME-WAIT（时间等待）状态。当B再接收到该确认段后，B就进入CLOSED状态。
> 
> 　　注：处于TIME-WAIT状态的A必须等待2MSL时间后，才会进入CLOSED状态。MSL（Maximum Segment Lifetime）最长报文段寿命，RFC 793 建议设为两分钟，对于现在的网络，MSL=2分钟可能太长了一些，我们可根据具体情况使用更小的MSL值。

四挥的七个状态：

> ESTAB-LISHED：已建立连接
> 
> FIN-WAIT-1：终止等待1
> 
> CLOSE-WAIT：关闭等待
> 
> FIN-WAIT-2：终止等待2
> 
> LAST-ACK：最后确认
> 
> TIME-WAIT：时间等待
> 
> CLOSED：关闭

**面试问题1：**为什么A要等待2MSL的时间？

>  *  为了保证A发送的最后一个报文段能够到达B。因为这个 ACK 有可能丢失，从而导致处在 LAST-ACK 状态的服务器收不到对 FIN-ACK 的确认报文。服务器会超时重传这个 FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待 2MSL，而是在发送完 ACK 之后直接释放关闭，一旦这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。
> 
>  *  可以防止已失效的报文段。客户端在发送最后一个 ACK 之后，再经过经过 2MSL，就可以使本连接持续时间内所产生的所有报文段都从网络中消失，从保证在关闭连接后，不会有仍在网络中滞留的报文段去骚扰服务器。

**面试问题2：**linux服务器出现大量 TIME-WAIT 状态的TCP连接 的处理方法

> 通过调整内核参数解决，  
> vi /etc/sysctl.conf 
> 
>  
> 
> 编辑文件，加入以下内容：  
> net.ipv4.tcp\_syncookies = 1  
> net.ipv4.tcp\_tw\_reuse = 1  
> net.ipv4.tcp\_tw\_recycle = 1  
> net.ipv4.tcp\_fin\_timeout = 30
> 
>  
> 
> 然后执行 /sbin/sysctl -p 让参数生效。 
> 
> net.ipv4.tcp\_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；
> 
> net.ipv4.tcp\_tw\_reuse = 1 表示开启重用。允许将 TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
> 
> net.ipv4.tcp\_tw\_recycle = 1 表示开启TCP连接中 TIME-WAIT sockets的快速回收，默认为0，表示关闭。
> 
> net.ipv4.tcp\_fin\_timeout 修改系統默认的 TIMEOUT 时间。

**面试问题3：**为什么要四次挥手？

>  *  A 向 B 发送一个连接释放请求报文，代表 A 的数据传送完了，请求释放连接；
>  *  B 收到后，B 立即向 A 发送一个确认报文，代表 B 已经知道 A 没有数据要传送了，但是 B 可能还有数据要向 A 传送；
>  *  B 的数据传送完后，向 A 发送一个连接释放请求报文，代表 B 的数据也传送完了，请求释放连接；
>  *  A 收到后，也立即向 B 发送一个确认报文，同时等待 2MSL 后，连接断开。
> 
> 　　注：TCP 是全双工通信，因此必须两个方向分别断开连接。

**面试问题4：**为什么建立连接三次，断开连接四次？

>  *  因为建立连接时，服务器的确认 ACK 和请求同步 SYN 可以放在一个报文里，而断开连接时，服务器可能还有数据要传送，因此，必须先发一个客户端断开连接请求的确认 ACK，以免客户端超时重传，待服务器的数据传送完毕后，再发送一个请求断开连接的报文段。
>  *  断开时次数比连接多一次，是因为连接过程，通信只需要处理「连接」，而断开过程，通信需要处理「数据+连接」。

[format_png]: /images/20230312/5d2c7d6a7da74583a23c0764cf8ccd11.png
[format_png 1]: /images/20230312/29b68cbb8d3241a3bd37161d6a291948.png