三次握手和四次挥手

1.三次握手和四次挥手的过程

1.1三次握手

三次握手是tcp通信中客户端和服务器端建立连接的过程

(1)首先客户端对服务器端发送报文，并且将报文中的SYN字段置为1，表示需要建立TCP连接，并随机生成一个初始化序列号(seq)x，(SYN=1，seq=x，x为随机生成数值）然后客户端处于发送完连接请求后等待一个匹配的连接请求的状态(SNY_SENT)。

(2)然后服务端收到了客户端发送的连接请求，如果同意和该客户端建立连接，就返回给客户端一个报文，其中包含seq序列号，是由回复端随机生成的，并且将SYN置为1，而且会产生ACK字段，ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP建立请求已得到验证。（SYN=1，ACK=x+1，seq=y，y为随机生成数值）这里的ack加1可以理解为是确认和谁建立连接；此时TCP服务器进程进入到SYN-RCVD（同步收到）阶段。

(3)TCP客户端收到服务器的确认后，还要再向服务器给出确认。确认报文段中ACK置为1，确认号为ack=y+1(因为之前服务器给客户机发送的序号为y，因此现在客户机向服务器发送的确认号为ack=y+1）此时客户机的发送序号为x+1。

注意：在进行第三次握手时，ACK报文段可以携带数据，也可以不携带数据，如果携带数据，则消耗一个序列，这样客户机下次发送报文段时的序号为x+2，如果不携带数据则不消耗序号，下次客户机发送报文段时的序号为x+1。这时TCP连接已经建立，客户机和服务器都进入到ESTABLISHED（已建立连接）状态。

1.2相关问题

问题：三次握手中，为什么客户机最后还要再向服务器发送一次确认呢？（为什么不能是两次握手呢？）

原因1：主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而导致不必要的错误和资源的浪费。

我们可以考虑一下这样的场景，客户端发送的第一个请求连接没有失效，只是因为在网络中滞留的时间太长了，导致客户端迟迟没有收到服务器端的确定报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。如果此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。

如果采用的是三次握手，就算那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端已经连接结束了，就不会再次发出确认报文了。由于服务器收不到确认报文，就知道客户端并没有请求连接，就不会再次建立连接。

原因2：两次握手只能保证单向连接是畅通的。因为TCP是一个双向传输协议，只有经过第三次握手，才能确保双向都可以接收到对方的发送的数据。

我们通过上面的过程可以知道，经过两次握手之后，服务器端处在SYN_RCVD状态，只有经过第三次握手，服务器端才可以进入ESTABLISHDE状态。

我们可以这样理解，前两次握手客户端向服务器端发送请求报文，服务器端向客户端发送确定报文，这个时候客户端知道了服务器端可接收和发送信息，服务器端只知道客户端可发送信息。如果没有第三次握手服务器端就不知道客户端接送到自己的确定报文没有，也就不知道客户端是否可接收信息。第三次握手以后，服务器端收到了客户端的确定报文，说明客户端可以接收信息，这个时候双方就可以正常建立连接通信了

2.四次挥手过程

2.1四次挥手

四次挥手是tcp通信中客户端也服务器端断开来链接的过程

(1)假设客户机请求完资源了，想要释放连接。首先，客户机的应用进程先向服务器发出连接释放报文段，该报文段中将首部的终止控制位FIN置为１，并且序号为ｕ**（注意：此时的ｕ不是随机产生的，而是之前客户机传送的数据的最后一个字节的序号加１）。**此时客户机进入到FIN－WAIT－１（终止等待１）状态，等待服务器的确认。

(2)服务器收到连接释放报文后发出确认，在发送报文中将首部中的ACK置为１，并且产生序号ｖ（注意：此时的v不是随机产生的，而是之前服务器传送的数据的最后一个字节的序号加１），并且发出确认号为u+１，此时服务器就进入CLOSE－WAIT（关闭等待）状态，客户机进入FIN-WAIT-2状态。

此时，从客户机到服务器这个方向的连接就被释放了，也就是说，客户机已经没有数据要向服务器发送了，但是如果服务器向客户机发送数据，客户机仍要接收数据。也就是说：从客户机到服务器的连接已经被释放了，但是从服务器到客户机的连接还没被释放。此时，TCP连接处于半关闭状态。

(3)如果服务器向客户机也没有要发送的数据的话，那么服务器就可以向客户端发出连接释放报文段**（注意此时还是服务器向客户机发送数据）**，该报文段中将首部的终止控制位FIN置为1，序号为w （此时的w不一定等于v+1。如果在客户机释放了连接之后，服务器向客户端发送了一部分数据，那么此时w不等于v+1，但是如果期间没有再发送数据，那么w就等于v+1）， 并且发送确认号为u+1，此时服务器就进入了LAST-ACK（最后确认）状态。

(4)此时客户端收到了服务端的结束报文后，发送确定报文，确认号为w+1，序号为u+1，此时服务器进入到TIME-WAIT（等待时间）状态。但是，此时TCP连接还没有被释放掉。必须经过2MSL后服务器才能进入到CLOSED状态。（MSL叫做最长报文段寿命，RFC建议为两分钟，也就是说，要经过四分钟才能进入到CLOSED状态）。

2.2相关问题

问题：为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：应为连接过程中，当服务器端收到了客户端的SYN报文时，服务器端可以直接发送SYN和ACK报文；但是关闭连接的时候会出现，服务器端收到客户端发送的FIN报文时，服务器端还有报文没有给客户端发完，服务器端只能先回复客户端一个ACK报文，表示自己收到了客户端发的FIN报文。当服务器端送完数据后，才可以向客户端发送FIN报文。因此不可以一步完成，所以需要四次挥手。

问题：为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是如果网络是不可靠的，有可以最后一个ACK报文丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在客户端端发送出最后的ACK回复，但该ACK可能丢失。服务器端如果没有收到ACK报文，将不断重复发送FIN报文，所以客户端不能立即关闭，它必须确认服务器端接收到了该ACK报文。客户端会在发送出ACK报文之后进入到TIME_WAIT状态。客户端会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么客户端会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，客户端都没有再次收到FIN报文，那么C客户端推断ACK已经被成功接收，则结束TCP连接。