根据tcp协议进行分析

一、SYN_RECV阶段

1.1 确定半连接队列是否有丢包：

1.2 确定全连接队列是否有丢包现象

二、close_wait

三、TIME_WAIT

四、抓包分析

重要字段：

WireShark出现的常见提示

服务端存在问题的

客户端存在问题的

socket关闭函数：

一、SYN_RECV阶段

内核在监听套接字的时候，在三次握手时，会创建两个队列，在服务器收到syn 包时，会创建半连接队列，并将这条握手未完成的连接放到里面，然后回复ack，syn包给客户端，当客户端回复ack时，内核会将这条连接放到全连接队列里，调用accept就是将连接从全连接队列里取出。

如果半连接队列或者全连接队列满了，则可能发生丢包行为

1.1 确定半连接队列是否有丢包：

dmesg | grep "TCP: drop open request from"

半连接队列的连接数量也可以通过netstat命令统计SYN_RECV状态的连接得知。因为在3次握手时，收到syn包的连接的状态是SYN_RECV状态，而整个状态的持续时间是很短的，如果用netstat发现SYN_RECV状态的连接非常多，则说明半连接队列可能满了

netstat -ant|grep SYN_RECV|wc -l

半连接队列的大小由/proc/sys/net/ipv4/tcp_max_syn_backlog控制，Linux的默认是1024。

当服务端发送SYN_ACK后将会开启一个定时器，如果超时没有收到客户端的ACK，将会重发SYN_ACK包。重传的次数由/proc/sys/net/ipv4/tcp_synack_retries控制，默认是5次。

1.2 确定全连接队列是否有丢包现象

netstat -s

netstat -s | egrep "listen|LISTEN" 
// 全连接队列溢出次数
667399 times the listen queue of a socket overflowed 
// 半连接队列溢出次数
667399 SYNs to LISTEN sockets dropped

ss -lnt

[root@mcs opt]# ss -lnt
State      Recv-Q Send-Q                        Local Address:Port                                       Peer Address:Port              
LISTEN     0      100                                       *:8080                                                  *:*

在listen状态下，Send-Q表示全连接队列大小的最大值，Recv-Q表示全连接队列的使用大小，超过最大值则会溢出。

应用进程处理包缓慢，持续小于网卡的接包速度的话，将导致全连接队列很快就满了，导致丢包

二、close_wait

服务端如果出现大量close_wait的话：

这个状态是由于客户端关闭了socket连接，发送了FIN报文，服务端也发送了ACK报文，此时客户端处于FIN_WAIT_2状态，服务端处于CLOSE_WAIT状态。并且可能存在服务端没有发送第二个FIN报文导致的。出现大量close_wait。

曾经遇到的问题：

首先，我这边的大部分请求都需要查询数据库，我的数据库连接池设置的最大连接数是100，所以每一个请求创建了一个连接，等到100个请求就把连接池占满了，但是处理servlet的那个线程并没有释放这个连接，于是接下来的请求再去创建数据库连接的时候就会一直阻塞在那里，这里我所用的是DBCP作为连接池的，它的实现好像是使用apache的objectPool来实现的，如果没有可用的连接对象会导致线程等待，好了，servlet由于得不到数据库连接而阻塞了，这个客户端的请求就一直等待，客户端使用httpclient设置了5s的请求超时时间，那么超时之后就会抛出异常，关闭连接，关闭连接导致客户端发送了FIN报文，我这边的TCP/IP返回了ACK报文，但是由于处理请求的线程还处于阻塞的状态，所以当前的连接状态时CLOSE_WAIT。

三、TIME_WAIT

参考TCP四次挥手原理，主动关闭连接的一方会出现 TIME_WAIT 状态，等待的时长为 2MSL(约1分钟左右)

原因是：主动断开的一方回复 ACK 消息可能丢失，TCP 是可靠的传输协议，在没有收到 ACK 消息的另一端会重试，重新发送FIN消息，所以主动关闭的一方会等待 2MSL 时间，防止对方重试，这就出现了大量 TIME_WAIT 状态（参考: 四次挥手的最后两次）

需要注意：

1.每一个 time_wait 状态，都会占用一个「本地端口」，上限为 65535(16 bit，2 Byte)；

2.当大量的连接处于 time_wait 时，新建立 TCP 连接会出错，address already in use : connect 异常

time_wait 状态的影响：

TCP 连接中，「主动发起关闭连接」的一端，会进入 time_wait 状态
time_wait 状态，默认会持续 2 MSL（报文的最大生存时间），一般是 2x2 mins
time_wait 状态下，TCP 连接占用的端口，无法被再次使用
TCP 端口数量，上限是 6.5w（65535，16 bit）
大量 time_wait 状态存在，会导致新建 TCP 连接会出错，address already in use : connect 异常

2.现实场景：

服务器端，一般设置：不允许「主动关闭连接」
但 HTTP 请求中，http 头部 connection 参数，可能设置为 close，则，服务端处理完请求会主动关闭 TCP 连接
现在浏览器中， HTTP 请求 connection 参数，一般都设置为 keep-alive
Nginx 反向代理场景中，可能出现大量短链接，服务器端，可能存在

3.解决办法：

服务器端允许 time_wait 状态的 socket 被重用
缩减 time_wait 时间，设置为 1 MSL（即，2 mins）

四、抓包分析

重要字段：

序号(sequence number)：seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。

确认号（acknowledgement number）：ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1。

标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：

URG：紧急指针（urgent pointer）有效。

ACK：确认序号有效。（为了与确认号ack区分开，我们用大写表示）

PSH：接收方应该尽快将这个报文交给应用层。

RST：重置连接。

SYN：发起一个新连接。

FIN：释放一个连接。

WireShark出现的常见提示

Packet size limited during capture：标记了的包没抓全
TCP Previous segment not captured：Wireshark 发现后一个包的 Seq 大于 Seq+Len，就知道中间缺失了一段。
TCP ACKed unseen segment：发现被 Ack 的那个包没被抓到，就会提示。
TCP Out-of-Order：后一个包的 Seq 号小于前一个包的 Seq+Len 时。
TCP Dup ACK：当乱序或丢包发生时，接收方会收到一些 Seq 号比期望值大的包。没收到一个这种包就会 Ack 一次期望的 Seq 值，提现发送方。
TCP Fast Retransmission：三次DUP ACK之后出发快速重传。（发送端后端观测，前端抓包看一个Dup ACK就发出了，应该是有缓存，3个DUP ACK之后才真正发出）
TCP Retransmission：发送方只好等到超时了再重传。没有收到ack会触发重传机制。
TCP zerowindow：0窗口，没法再收。
TCP window Full：窗口耗尽。没法再发！
Time-to-live exceeded：分片无法正常组装

服务端存在问题的

从抓包文件中，发现760054号报文发生了超时重传，如果客户端发了包，但是服务端没有回应ack消息就会触发超时重传，重传之后，客户端也没有收到服务端的消息，并且可以看到发送挥手信号和前一个正常发送的包之间刚好是隔了差不多200ms，而200ms正是客户端设置的超时时间，应用层触发超时后，将调用close方法关闭链接，所以在760055号包里客户端发送了一个fin 挥手信号代表客户端要关闭链接了。客户端发送fin信号挥手之后呢，服务端才发来携带数据的ack消息，不过由于此时客户端已经处于要关闭状态，所以直接发送rst信号了。

抓包中出现大量TCP Dup Ack 的消息，客户端一直在向端口为6379的服务端发送ack的序号为 13364573,代表客户端已经接收到服务端序号13364573之前的包了,然而服务端连续发送的包序号seq都大于了13364573 ，所以客户端认为服务端序号seq是13364573的包丢了，所以随着服务端每一次发送消息过来，都告诉服务端，我应该接收序号是13364573开始的包，赶紧发送过来。

最终在1777232号包，客户端又一次发送了TCP Dup Ack 消息，催促服务端赶紧把丢掉的包发过来，不过这次服务端连回应都不回应了，最终触发了客户端应用层200ms的超时时间，调用close方法关闭了连接。所以在1778166号包里，可以看到客户端发送fin挥手信号，1778166 号包的发送时间和1777232号包的发送时间正式相隔了200ms

首先看第一个红色箭头处，也就是911752号包，它被wireshark标记为 Tcp Previous segment not captured，表示这个包之前的包没有被捕获到，说明这个包seq序号之前的包存在丢包情况。发现它前一个包也就是911751号包也是服务端发来的包，并且next seq 是18428124，说明911751号包下一个包的seq应该是18428124，但是911752的seq是18429584，进一步说明来自服务端的包序号在18428124到18429584之间的包存在丢包情况。

接着是客户端对911751号包的ack消息，说明序号是18428124之前的包已经全部接收到。然后接受到了911754号这个来自服务端的包，并且这包的开始seq序号是18433964，而最近一次来自服务端的911752号包的next seq是18432504，说明在18432504 和18433964之间，也存在服务端的丢包情况，所以911754号包也被标记为了Tcp Previous segment not captured。

接下来就是服务端重传包，客户端继续回应Ack的过程，但是这个过程直到914025号时就停止了，因为整个读取服务端响应的过程从开始读到当前时间已经达到了应用层设置的500ms，所以在应用层直接就关闭掉了这个链接了。