三次握手和四次挥手

                                      三次握手和四次挥手

     三次握手和四次挥手是tcp协议中创建连接和断开链接时的重要过程，下面我们就来看一下三次握手和四次挥手的过程，以及一些会问到的面试题。

字段          含义

URG         紧急指针是否有效。为1，表示某一位需要被优先处理

ACK         确认号是否有效，一般置为1。

PSH        提示接收端应用程序立即从TCP缓冲区把数据读走。

RST         对方要求重新建立连接，复位。

SYN         请求建立连接，并在其序列号的字段进行序列号的初始值设定。建立连接，设置为1

FIN           希望断开连接。

三次握手

​

1.最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。

2.TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；

3.TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。

4.TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。

5.TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。

6.当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以 开始通信了。

面试题：

    1.为什么不能用两次握手进行连接？

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

    2.三次握手那个阶段容易出现攻击？

比较典型的是 syn 泛洪攻击，或叫 syn 溢出攻击。 syn 溢出攻击，即出现在第二个阶段，如果客户机伪造出大量第一次的 sys 同步报 文，服务端就会依次耗掉很多资源来保存客户端的信息，并进行确认，实际确认是会失 败的，但失败是需要一定时间，因为服务端会连续多次进行第二次握手确认后才认定失 败。那么短时间有大量 syn 同步报文涌向服务端，服务器资源可能被耗尽，就可能导致 正常的客户端得不到响应而失败。

 

 

四次挥手

简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：

1.服务器读通道关闭

2.客户机写通道关闭

3.客户机读通道关闭

4.服务器写通道关闭

 

1.数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。

2.客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

3.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

4.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

5.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

6.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

7.服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

面试题：

1.TIME_WAIT 和 CLOSE_WAIT 有什么区别？

CLOSE_WAIT 是被动关闭的一端在接收到对端关闭请求（FIN 报文段）并且将 ACK 发送出去后所处的状态，这种状态表示：收到了对端关闭的请求，但是本端还没有完成 工作，还未关闭。 TIME_WAIT 状态是主动关闭的一端在本端已经关闭的前期下，收到对端的关闭请 求（FIN 报文段）并且将 ACK 发送出去后所处的状态，这种状态表示：双方都已经完成 工作，只是为了确保迟来的数据报能被是被并丢弃，可靠的终止 TCP 连接。

2.为什么客户端最后还要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

3.为什么建立连接是三次握手，关闭连接确是四次挥手呢？

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

4.如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。