深入协议栈了解TCP的三次握手、四次挥手、CLOSE-WAIT、TIME-WAIT。

        TCP网络编程的代码网上很多，这里就不再赘述，简单用一个图展示一下tcp网络编程的流程：        

1、深入connect、listen、accept系统调用，进一步理解TCP的三次握手

        这三个函数都是系统调用，我们可以分为请求连接方和被动连接两部分，我们知道请求连接方并非都是client，为了方便，本文用client代表主动连接方，server代表被动连接方。   

• connect（）是client的请求连接函数；处理client端的三次握手

  

• listen（）是server用来监听client端有没有连接请求，本质上它是监测半连接队列和全连接队列中有没有信息，这两个队列中存放的是需要和server端进行连接的客户端信息，下文对这两个队列有解释。下图listen函数的解析中可以看到，第二个参数backlog表示等待连接队列的最大长度。

  

• accept（）是server端为了独立管理每一个client连接，为其请求分配fd的函数，此函数调用时其实三次握手已经完成了。它从全连接队列中取出第一个节点，并为其分配fd。详情见下图

  

1、三次握手发生在那个函数？

   

• 三次握手具体流程：

  • client端调用connect系统调用，发起连接请求，并阻塞等待返回结果；
  • server端协议栈收到client端发来的syn请求报文后，将该client的tcb信息放入半连接队列，并回复client端syn+ack；
  • client端的connect系统调用回复server端ack；
  • server端收到client端发来的确认ack后，从半连接队列中找到此client对应的tcb，修改其连接状态，并放入全连接队列中，此时协议栈层面的三次握手完成。

        因此对于client而言，三次握手发生在connect函数中；对于server而言，三次握手是由协议栈实现，不发生在任一网络编程函数中。

2、listen（fd, backlog）中，第二个参数backlog是什么意思？

        经过对协议栈的分析，它首先创建一个半连接队列，存储发送了syn请求报文的client的信息，然后创建了一个全连接队列，存储回复了ack报文的client的信息（这个信息是从半连接队列中迁移来的），此时协议栈层面的三次握手已经完成；

        对于server来说，所有的client连接都会进行业务交互，但是这两个队列中的client连接都还未交由server的用户态管理，因此它们还都属于待连接状态，所以等待连接队列=半连接队列+全连接队列

       根据上述listen的函数解析和协议栈原理分析得知，backlog是等待连接队列的最大长度，即=半连接队列+全连接队列的最大长度和

3、accept函数的作用是什么？accept是如何分配fd的？

1. 由上述函数解析和三次握手分析得，accept的作用为：
   1. 从全连接队列中取出第一个节点信息（tcb）；
   2. 根据tcb信息为其重新分配一个sockfd。
2. accept如何分配的fd：根据取出的tcb中的ip、port等信息，创建一个新的sockfd接收这个连接，交由server管理（多路io复用epoll）。

4、什么是半连接队列与全连接队列？

        半连接队列：由协议栈创建并管理，存放只发送来了syn请求报文的client的tcb信息

        全连接队列：由协议栈创建并管理，存放已经回复了ack确认报文的client的tcb信息。

2、深入TCP的四次挥手原理，进一步理解time_wait/close_wait状态

 

         我们要明确一点，close（）关闭的只是sockfd（文件句柄，五元组），那tcp连接怎么断开呢？从accept函数我们可以知道，server为每一个连接tcb都分配了一个与之对应的sockfd，当server关闭了这个sockfd之后，与之对应的tcb也被删除，若server没有调用close（）关闭sockfd，则这个连接就一直存在，除非等到系统超时或出现网络异常。

        RFC 793 - Transmission Control Protocol

1、什么是四次挥手？为什么这样做？

• 四次挥手过程：主动断开放用client表示，被动断开方用server表示

  • client调用close（）函数，向server发送fin请求报文，client进入fin_wait_1状态；
  • server的协议栈收到fin后立即回应client一个ack报文，server进入close_wait状态；
  • server应用层得知recv() == 0时，及时调用close() 函数向client发送fin报文，server进入last_ack状态；
  • client收到fin报文后，立即回应server一个ack报文，client进入time_wait状态。

• 四次挥手的原因：
  • server连接关闭的控制权在应用层，即调用close（）后关闭，立即回复ack是协议栈的操作，所以两者不能做到同步。

2、什么是close_wait状态？产生大量close_wait的原因是什么？如何解决？

• close_wait是server端的状态，表示等待来自本地用户的连接终止请求，从server的协议栈回复ack后到用户层调用close（）关闭连接之前这段时间称为close_wait状态。
• 大量close_wait原因：收到client的断开请求报文（判断recv（）== 0）后，没有调用或没有及时调用close（）关闭连接。
• 解决：收到client的断开请求报文（判断recv（）== 0）后立即调用close（），在这之间不要出现多余的业务处理，如果无法避免就将业务抛给其他线程进行处理。

3、什么是time_wait状态？产生大量time_wait的原因是什么？如何解决？

• time_wait是client端的状态，表示等待足够的时间，以确保远程tcp接收到对其连接终止请求的确认。client给server回复ack报文后，就进入到time_wait状态。
• 大量time_wait的原因：一般只有服务器或中间服务层才会出现大量对外链接，因此服务端主动发起大量短链接关闭，导致服务端存在大量的time_wait状态（比如HTTP）。

  •  HTTP默认的Connection值为close，那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。

  • 虽然HTTP默认Connection值为close，但是，现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以，也有人说，现在没有必要通过调整参数来使TIME_WAIT降低了。 

• 解决：

  • 1、规避大量短链接的使用，
  • 2、修改/etc/sysctl.conf文件，让服务器能够快速回收和重用那些time_wait的资源。
    • 

4、close_wait/time_wait的时长各自是多少？有什么作用？

• 时长：

  • close_wait：如果没有调用close（）至少存在两个小时，直到系统崩溃。如果没有及时调用close（），那就得看具体的业务处理时长。

  • time_wait：2MSL，RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。

    • 将TCP TIME-WAIT超时时间修改为小于60秒与TCP/IP协议quiet time概念相违背，可能导致您的系统将旧数据当做新数据接收，或者复制的新数据当做旧数据拒绝。因此请在网络专家建议下调整。

    • 你可以通过运行netstat -ant | grep TIME_WAIT | wc -l命令判断服务器中是否存在大量短连接，然后再确定要不要修改。

    • 修改 TIME-WAIT时间的方法有两种：

    • echo 5 > /proc/sys/net/ipv4/tcp_tw_timeout

    • sysctl -w "net.ipv4.tcp_tw_timeout=5"

• 作用：      

  • close_wait：等待来自本地用户的连接终止请求。

  • time_wait：等待足够的时间，以确保远程tcp接收到对其连接终止请求的确认。

5、出现大量close_wait/time_wait的危害是什么？

        close_wait：1、如果因为没有调用close（）导致存在大量close_wait，那将会消耗系统资源，导致系统崩溃；2、如果因为没有及时调用close（），则危害和time_wait一样。

        time_wait：占用的端口不能及时释放被使用，要等到2MSL时间后才能使用，则没有足够的sockfd分配，将大大降低并发量。

        所以它们有一个共同的危害就是“占着茅坑不拉屎”，资源得不到充分利用。

本文说提到的client和server不是表面上的客户端与服务器，client是主动请求方；server是被动响应方。