滴滴-测试开发面经（六）

最初，客户机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：已建立连接

为什么不是两次握手？

这主要是为了防止已失效的连接请求报文段突然又传送到了 B，从而造成资源浪费。

考虑一种异常情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段，但 B 收到此失效的连接请求报文段后，就误认为是 A 又发出了一次新的连接请求，于是就向 A 发出确认报文段，同意建立连接。假定不采用报文握手，那么只要 B 发出确认，新的连接就建立了。

由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据，但 B 却认为新的运输连接已经建立了，并一直等待 A 发来数据，B 的许多资源就这样浪费了。

采用三次握手的办法，可以防止上述现象的发生，例如在刚才的异常情况下，A 不会向 B 的确认发出确认，B 由于收不到确认，就知道 A 并没有要求建立连接。

为什么不是四次握手？

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

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：关闭

为什么A要等待2MSL的时间？

为了保证A发送的最后一个报文段能够到达B。因为这个 ACK 有可能丢失，从而导致处在 LAST-ACK 状态的服务器收不到对 FIN-ACK 的确认报文。服务器会超时重传这个 FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待 2MSL，而是在发送完 ACK 之后直接释放关闭，一旦这个 ACK 丢失的话，服务器就无法正常的进入关闭连接状态。

可以防止已失效的报文段。客户端在发送最后一个 ACK 之后，再经过经过 2MSL，就可以使本连接持续时间内所产生的所有报文段都从网络中消失，从保证在关闭连接后，不会有仍在网络中滞留的报文段去骚扰服务器。

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 时间。

为什么要四次挥手？

A 向 B 发送一个连接释放请求报文，代表 A 的数据传送完了，请求释放连接；

B 收到后，B 立即向 A 发送一个确认报文，代表 B 已经知道 A 没有数据要传送了，但是 B 可能还有数据要向 A 传送；

B 的数据传送完后，向 A 发送一个连接释放请求报文，代表 B 的数据也传送完了，请求释放连接；

A 收到后，也立即向 B 发送一个确认报文，同时等待 2MSL 后，连接断开。

　　注：TCP 是全双工通信，因此必须两个方向分别断开连接。

为什么建立连接三次，断开连接四次？

因为建立连接时，服务器的确认 ACK 和请求同步 SYN 可以放在一个报文里，而断开连接时，服务器可能还有数据要传送，因此，必须先发一个客户端断开连接请求的确认 ACK，以免客户端超时重传，待服务器的数据传送完毕后，再发送一个请求断开连接的报文段。

断开时次数比连接多一次，是因为连接过程，通信只需要处理「连接」，而断开过程，通信需要处理「数据+连接」。