深入协议栈了解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的？

由上述函数解析和三次握手分析得，accept的作用为：
1. 从全连接队列中取出第一个节点信息（tcb）；
2. 根据tcb信息为其重新分配一个sockfd。
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接收到对其连接终止请求的确认。