【Linux】TCP的三报文握手和四报文挥手相关面试题

三报文握手

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通讯通信中必不可少的过程。因此，运输连接就有三个阶段连接，即，建立数据传送和连接释放
TCP连接的建立采用客户服务器的方式，主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。
一、三报文握手的过程
TCP的建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。这也就是三报文握手的过程。如下图所示：

它的过程如下所述：

• 一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进程就处于LISTEN (收听)状态，等待客户的连接请求。如有，即作出响应。

• A的TCP客户进程也是首先创建传输控制模块TCB。然后，在打算建立TCP连接时, .向B发出连接请求报文段，这时首部中的同步位SYN =1,同时选择一个初始序号seq =x。TCP规定，SYN报文段(即SYN=1的报文段)不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT (同步已发送)状态。

• B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack=x+ 1，同时也为自己选择一个初始序号seq= y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时TCP服务器进程进入SYN~RCVD (同步收到)状态。

• TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack=y+ 1,而自己的序号seq=x+ 1。TCP的标准规定，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED(已建立连接)状态。

• 当B收到A的确认后，也进入ESTABLISHED状态。

二、相关问题的处理
1、为什么A最后还要发送一次确认？
这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。
2、已失效的连接请求报文段是如何产生的
（1）正常的情况
A发出连接请求，但因连接请求报文丢失而为收到确认。于是A再重传一次连续请求，后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，A共发送了两个连接请求报文段，其中一个丢失，第二个到达了B，没有“已失效的连接请求报文段”。
（2）异常情况
A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早都失效的报文段，但B收到此失效的连接请求报文段，，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。
假定不采用报文握手，那么只要B发出确认，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。
采用三报文握手的办法就可以防止上述现象的发生。
3、为什么是三次握手？不是两次四次
（1）避免历史连接
网络环境是错综复杂的，并不是先发送的数据包，就先到达目标主机，可能会由于网络拥堵等原因，使旧的数据包先到达目标主机
客户端连续发送多次 SYN 建立连接的报文，在网络拥堵等情况下：

• 一个旧 SYN 报文比新的 SYN 报文早到达了服务端；
• 那么此时服务端就会回一个 SYN + ACK 报文给客户端；
• 客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
  如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：
• 如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；
• 如果不是历史连接，则第三次发送的报文是ACK 报文，通信双方就会成功建立连接。
  （2）同步双方初始序列号
  TCP 协议的通信双方， 都必须维护一个序列号， 序列号是可靠传输的一个关键因素，它的作用有：
• 接收方可以去除重复的数据
• 接收方可以根据数据包的序列号按序接收
• 可以标识发送出去的数据包中， 哪些是已经被对方收到的
  可见，序列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带初始序列号的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送初始序列号给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
  四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了三次握手。而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
  3、避免资源浪费
  如果只有两次握手，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接。如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
  即两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求 SYN 报文，而造成重复分配资源。
  总结
  TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。
  不使用两次握手和四次握手的原因：
  两次握手：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
  四次握手：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

四报文挥手

一、四报文挥手的过程
数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1，其序号seq=u,它等于前面已传送过的数据的最后一个字节的序号加1。 这时A进入FIN-WAIT-1 状态，等待B的确认。如下图所示：

它的过程如下所述：

• B收到连接释放报文段后即发出确认，确认号是ack=u+1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。
• A收到来自B的确认后，就进入FIN-WAIT-2 状态，等待B发出的连接释放报文段。
• 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN=1。现假定B的序号为w。B还必须重复上次已发送过的确认号ack=u+ 1。这时B就进入LAST-ACK状态，等待A的确认。
• A在收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置1, 确认号ack=w+ 1,而自己的序号是seq=u+ 1
  (根据TCP标准，前面发送过的FIN报文段要消耗一个序号)。然后进入到TIME-WAIT状态。但是现在TCP连接还没有释放掉。必须经过时间等待计时器设置的时间2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命 TCP允许不同的实现可根据具体情况使用更小的MSL值。因此，从A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。
  二、相关问题
  为什么A在TIME-WAIT状态必须等待2MSL的时间呢?
  1、为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN + ACK报文段的确认。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN + ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。
  2、防止“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。B只要收到了A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传输控制块TCB后，就结束了这次的TCP连接。
  为什么挥手需要四次？
  因为在挥手过程中，客户端关闭连接和服务端关闭连接是独立的，可能客户端没有数据了想关闭连接，但是服务端可能还在处理数据，那么不能立马关闭。
  也就是说，客户端发起的一次关闭请求只保证自己关闭，而不管服务端是否能关闭。那服务端也是用理。这里双方都一来一回就是四次挥手。