转：TCP链接的状态详解以及故障排查

https://blog.csdn.net/m0_37886429/article/details/82620868

1、TCP状态

一、linux查看tcp的状态命令

1) netstat -nat 查看TCP各个状态的数量

2) lsof -i:port 能够检测到打开套接字的情况

3) sar -n SOCK 查看tcp建立的链接数

4) tcpdump -iany tcp port 9000 对tcp端口为9000的进行抓包

二、网络测试经常使用命令

1) ping:检测网络链接的正常与否,主要是测试延时、抖动、丢包率。

可是不少服务器为了防止攻击，通常会关闭对ping的响应。因此ping通常做为测试连通性使用。 ping命令后，会接收到对方发送的回馈信息，其中记录着对方的IP地址和TTL。TTL是该字段指定IP包被路由器丢弃以前容许经过的最大网段数量。 TTL是IPv4包头的一个8 bit字段。例如IP包在服务器中发送前设置的TTL是64，你使用ping命令后，获得服务器反馈的信息，其中的TTL为56，说明途中一共通过了8道路由器的转发，每通过一个路由，TTL减1。

2）traceroute：raceroute 跟踪数据包到达网络主机所通过的路由工具

traceroute hostname

3）pathping：是一个路由跟踪工具，它将 ping 和 tracert 命令的功能与这两个工具所不提供的其余信息结合起来，综合了两者的功能

pathping www.baidu.com

4）mtr：以结合ping nslookup tracert 来判断网络的相关特性

5) nslookup:用于解析域名，通常用来检测本机的DNS设置是否配置正确。

---

状态分析：

①LISTENING：侦听来自远方的TCP端口的链接请求。

首先服务端须要打开一个socket进行监听，状态为LISTEN。 有提供某种服务才会处于LISTENING状态，TCP状态变化就是某个端口的状态变化，提供一个服务就打开一个端口。

例如：提供www服务默认开的是80端口，提供ftp服务默认的端口为21，当提供的服务没有被链接时就处于LISTENING状态。

FTP服务启动后首先处于侦听（LISTENING）状态。处于侦听LISTENING状态时，该端口是开放的，等待链接，但尚未被链接。就像你房子的门已经敞开的，但尚未人进来。 看LISTENING状态最主要的是看本机开了哪些端口，这些端口都是哪一个程序开的，关闭没必要要的端口是保证安全的一个很是重要的方面，服务端口都对应一个服务（应用程序），中止该服务就关闭了该端口，例如要关闭21端口只要中止IIS服务中的FTP服务便可。关于这方面的知识请参阅其它文章。 若是你不幸中了服务端口的木马，木马也开个端口处于LISTENING状态。

②SYN-SENT：客户端SYN_SENT状态：

再发送链接请求后等待匹配的链接请求:客户端经过应用程序调用connect进行active open.

客户端tcp发送一个SYN以请求创建一个链接.以后状态置为SYN_SENT. 

The socket is actively attempting to establish a connection. 在发送链接请求后等待匹配的链接请求 

当请求链接时客户端首先要发送同步信号给要访问的机器，此时状态为SYN_SENT，若是链接成功了就变为ESTABLISHED，正常状况下SYN_SENT状态很是短暂。

例如要访问网站http://www.baidu.com,若是是正常链接的话，用TCPView观察IEXPLORE.EXE（IE）创建的链接会发现很快从SYN_SENT变为ESTABLISHED，表示链接成功。SYN_SENT状态快的也许看不到。

若是发现有不少SYN_SENT出现，那通常有这么几种状况:

一是你要访问的网站不存在或线路很差。  

二是用扫描软件扫描一个网段的机器，也会出出现不少SYN_SENT，另外就是可能中了病毒了，例如中了”冲击波”，病毒发做时会扫描其它机器，这样会有不少SYN_SENT出现。

③SYN-RECEIVED：服务器端状态SYN_RCVD

再收到和发送一个链接请求后等待对方对链接请求的确认 当服务器收到客户端发送的同步信号时，将标志位ACK和SYN置1发送给客户端，此时服务器端处于SYN_RCVD状态，若是链接成功了就变为ESTABLISHED，正常状况下SYN_RCVD状态很是短暂。

若是发现有不少SYN_RCVD状态，那你的机器有可能被SYN Flood的DoS(拒绝服务攻击)攻击了。

SYN Flood的攻击原理是：

在进行三次握手时，攻击软件向被攻击的服务器发送SYN链接请求（握手的第一步），可是这个地址是伪造的，如攻击软件随机伪造了51.133.163.10四、65.158.99.152等等地址。
  服务器在收到链接请求时将标志位ACK和SYN置1发送给客户端（握手的第二步），可是这些客户端的IP地址都是伪造的，服务器根本找不到客户机，也就是说握手的第三步不可能完成。
  这种状况下服务器端通常会重试（再次发送SYN+ACK给客户端）并等待一段时间后丢弃这个未完成的链接，这段时间的长度咱们称为SYN Timeout，通常来讲这个时间是分钟的数量级（大约为30秒-2分钟）；
  一个用户出现异常致使服务器的一个线程等待1分钟并非什么很大的问题，但若是有一个恶意的攻击者大量模拟这种状况，服务器端将为了维护一个很是大的半链接列表而消耗很是多的资源——数以万计的半链接。
  即便是简单的保存并遍历也会消耗很是多的CPU时间和内存，况且还要不断对这个列表中的IP进行SYN+ACK的重试。
  此时从正常客户的角度看来，服务器失去响应，这种状况咱们称作：服务器端受到了SYN Flood攻击（SYN洪水攻击）

④ESTABLISHED：表明一个打开的链接。

ESTABLISHED状态是表示两台机器正在传输数据，观察这个状态最主要的就是看哪一个程序正在处于ESTABLISHED状态。

服务器出现不少ESTABLISHED状态： netstat -nat |grep 9502或者使用lsof -i:9502能够检测到。

当客户端未主动close的时候就断开链接：即客户端发送的FIN丢失或未发送。

这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态；

这时候若客户端断开的时候未发送FIN包，则服务端处仍是显示ESTABLISHED状态；

结果客户端从新链接服务器。

而新链接上来的客户端（也就是刚才断掉的从新连上来了）在服务端确定是ESTABLISHED; 若是客户端重复的上演这种状况，那么服务端将会出现大量的假的ESTABLISHED链接和CLOSE_WAIT链接。 最终结果就是新的其余客户端没法链接上来，可是利用netstat仍是能看到一条链接已经创建，并显示ESTABLISHED，但始终没法进入程序代码。

⑤FIN-WAIT-1：等待远程TCP链接中断请求，或先前的链接中断请求的确认

主动关闭(active close)端应用程序调用close，因而其TCP发出FIN请求主动关闭链接，以后进入FIN_WAIT1状态。等待远程TCP的链接中断请求，或先前的链接中断请求的确认

若是服务器出现shutdown再重启，使用netstat -nat查看，就会看到不少FIN-WAIT-1的状态。就是由于服务器当前有不少客户端链接，直接关闭服务器后，没法接收到客户端的ACK。

⑥FIN-WAIT-2：从远程TCP等待链接中断请求

主动关闭端接到ACK后，就进入了FIN-WAIT-2  Connection is closed, and the socket is waiting for a shutdown from the remote end. 从远程TCP等待链接中断请求

这就是著名的半关闭的状态了，这是在关闭链接时，客户端和服务器两次握手以后的状态。

在这个状态下，应用程序还有接受数据的能力，可是已经没法发送数据，可是也有一种多是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。

⑦CLOSE-WAIT：等待从本地用户发来的链接中断请求

被动关闭(passive close)端TCP接到FIN后，就发出ACK以回应FIN请求(它的接收也做为文件结束符传递给上层应用程序),并进入CLOSE_WAIT.

The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的链接中断请求

⑧CLOSING：等待远程TCP对链接中断的确认

Both sockets are shut down but we still don’t have all our data sent. 等待远程TCP对链接中断的确认

⑨LAST-ACK：等待原来的发向远程TCP的链接中断请求的确认

被动关闭端一段时间后，接收到文件结束符的应用程序将调用CLOSE关闭链接。这致使它的TCP也发送一个 FIN,等待对方的ACK.就进入了LAST-ACK .

The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的链接中断请求的确认

使用并发压力测试的时候，忽然断开压力测试客户端，服务器会看到不少LAST-ACK。

⑩TIME-WAIT：等待足够的时间以确保远程TCP接收到链接中断请求的确认

在主动关闭端接收到FIN后，TCP就发送ACK包，并进入TIME-WAIT状态。

The socket is waiting after close to handle packets still in the network.等待足够的时间以确保远程TCP接收到链接中断请求的确认

TIME_WAIT等待状态，这个状态又叫作2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报之后，要进入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。

这个状态在很大程度上保证了双方均可以正常结束，可是，问题也来了。

因为插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是没法再次使用同一个插口的，对于客户程序还好一些，可是对于服务程序，例如httpd，它老是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插口被使用）。

为了不这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然能够从新启动服务器，可是这个服务器仍是要平静的等待2MSL时间的过去才能进行下一次链接。

详情请看：TIME_WAIT引发Cannot assign requested address报错

⑪ CLOSED：没有任何链接状态

被动关闭端在接受到ACK包后，就进入了closed的状态。链接结束

The socket is not being used. 没有任何链接状态

2、TCP状态迁移路线图

client/server两条路线讲述TCP状态迁移路线图：

 

3、TCP链接创建三次握手

TCP是一个面向链接的协议，因此在链接双方发送数据以前，都须要首先创建一条链接。

Client链接Server： 当Client端调用socket函数调用时，至关于Client端产生了一个处于Closed状态的套接字。

(1)第一次握手：Client端又调用connect函数调用，系统为Client随机分配一个端口，连同传入connect中的参数(Server的IP和端口)，这就造成了一个链接四元组，客户端发送一个带SYN标志的TCP报文到服务器。

这是三次握手过程当中的报文1。connect调用让Client端的socket处于SYN_SENT状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)。

(2)第二次握手： 服务器收到syn包，必须确认客户的SYN（ack=j+1），同时本身也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；

(3) 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户器和客务器进入ESTABLISHED状态，完成三次握手。链接已经能够进行读写操做。

一个完整的三次握手也就是： 请求—-应答—-再次确认。 TCP协议经过三个报文段完成链接的创建，这个过程称为三次握手(three-way handshake)。

　　链接出现链接不上的问题，通常是网路出现问题或者网卡超负荷或者是链接数已经满啦。

4、TCP链接的终止（四次握手释放）

因为TCP链接是全双工的，所以每一个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的链接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP链接在收到一个FIN后仍能发送数据。

首先进行关闭的一方将执行主动关闭，而另外一方执行被动关闭。

创建一个链接须要三次握手，而终止一个链接要通过四次握手，这是由TCP的半关闭(half-close)形成的，

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。  

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN同样，一个FIN将占用一个序号。  

（3）服务器B关闭与客户端A的链接，发送一个FIN给客户端A。  

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。

5、为何创建链接协议是三次握手，而关闭链接倒是四次握手

服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它能够把ACK和SYN（ACK起应答做用，而SYN起同步做用）放在一个报文里来发送。但关闭链接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；

但未必你全部的数据都所有发送给对方了，因此你能够未必会立刻会关闭SOCKET,也即你可能还须要发送一些数据给对方以后，再发送FIN报文给对方来表示你赞成如今能够关闭链接了，因此它这里的ACK报文和FIN报文多数状况下都是分开发送的。

6、为何TIME_WAIT状态还须要等2MSL后才能返回到CLOSED状态

由于虽然双方都赞成关闭链接了，并且握手的4个报文也都协调和发送完毕，按理能够直接回到CLOSED状态（就比如从SYN_SEND状态到ESTABLISH状态那样）

一方面是可靠的实现TCP全双工链接的终止，也就是当最后的ACK丢失后，被动关闭端会重发FIN，所以主动关闭端须要维持状态信息，以容许它从新发送最终的ACK。

另外一方面，可是由于咱们必需要假想网络是不可靠的，你没法保证你最后发送的ACK报文会必定被对方收到，所以对方处于LAST_ACK状态下的SOCKET可能会由于超时未收到ACK报文，而重发FIN报文，因此这个TIME_WAIT状态的做用就是用来重发可能丢失的ACK报文。

TCP在2MSL等待期间，定义这个链接(4元组)不能再使用，任何迟到的报文都会丢弃。设想若是没有2MSL的限制，刚好新到的链接正好知足原先的4元组，这时候链接就可能接收到网络上的延迟报文就可能干扰最新创建的链接。

7、大量TIME_WAIT状态问题解决

发现系统存在大量TIME_WAIT状态的链接，能够经过调整内核参数解决：vi /etc/sysctl.conf 加入如下内容：

net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_fin_timeout = 30

而后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少许SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1 表示开启重用。容许将TIME-WAIT sockets从新用于新的TCP链接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1 表示开启TCP链接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

　　备注：这种方式不是很好，我以前试过修改内核参数只是一会没有问题，可是时间长了仍是没有效果，建议采用长链接方式。

8、同时打开

两个应用程序同时执行主动打开的状况是可能的，虽然发生的可能性较低。每一端都发送一个SYN,并传递给对方，且每一端都使用对端所知的端口做为本地端口。例如： 主机a中一应用程序使用7777做为本地端口，并链接到主机b 8888端口作主动打开。 主机b中一应用程序使用8888做为本地端口，并链接到主机a 7777端口作主动打开。 tcp协议在遇到这种状况时，只会打开一条链接。 这个链接的创建过程须要4次数据交换，而一个典型的链接创建只须要3次交换（即3次握手） 但多数tcp/ip实现并不支持同时打开。

9、同时关闭

若是应用程序同时发送FIN，则在发送后会首先进入FIN_WAIT_1状态。在收到对端的FIN后，回复一个ACK，会进入CLOSING状态。在收到对端的ACK后，进入TIME_WAIT状态。这种状况称为同时关闭。 同时关闭也须要有4次报文交换，与典型的关闭相同。

10、TCP的FLAGS说明

在TCP层，有个FLAGS字段，这个字段有如下几个标识：SYN, FIN, ACK, PSH, RST, URG. 其中，对于咱们平常的分析有用的就是前面的五个字段。

字段含义：

一、SYN表示创建链接： 步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手创建TCP链接时有效。它提示TCP链接的服务端检查序列编号，该序列编号为TCP链接初始端(通常是客户端)的初始序列编号。在这里，能够把TCP序列编号看做是一个范围从0到4，294，967，295的32位计数器。经过TCP链接交换的数据中每个字节都通过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

二、FIN表示关闭链接：

三、ACK表示响应： 确认编号(Acknowledgement Number)栏有效。大多数状况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收全部数据。

四、PSH表示有DATA数据传输：

五、RST表示链接重置：复位标志有效。用于复位相应的TCP链接。

字段组合含义：

其中，ACK是可能与SYN，FIN等同时使用的，好比SYN和ACK可能同时为1，它表示的就是创建链接以后的响应， 若是只是单个的一个SYN，它表示的只是创建链接。 TCP的几回握手就是经过这样的ACK表现出来的。 但SYN与FIN是不会同时为1的，由于前者表示的是创建链接，然后者表示的是断开链接。

RST通常是在FIN以后才会出现为1的状况，表示的是链接重置。 通常地，当出现FIN包或RST包时，咱们便认为客户端与服务器端断开了链接；

RST与ACK标志位都置一了，而且具备ACK number，很是明显，这个报文在释放TCP链接的同时，完成了对前面已接收报文的确认。

而当出现SYN和SYN＋ACK包时，咱们认为客户端与服务器创建了一个链接。

PSH为1的状况，通常只出如今 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。

TCP的链接创建和链接关闭，都是经过请求－响应的模式完成的。

11、TCP通讯中服务器处理客户端意外断开

若是TCP链接被对方正常关闭，也就是说，对方是正确地调用了closesocket(s)或者shutdown(s)的话，那么上面的Recv或Send调用就能立刻返回，而且报错。这是因为close socket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方“TCP链接已经关闭，你不须要再发送或者接受消息了”。

可是，若是意外断开，客户端（3g的移动设备）并无正常关闭socket。双方并未按照协议上的四次挥手去断开链接。

那么这时候正在执行Recv或Send操做的一方就会由于没有任何链接中断的通知而一直等待下去，也就是会被长时间卡住。

像这种若是一方已经关闭或异常终止链接，而另外一方殊不知道，咱们将这样的TCP链接称为半打开的。

解决意外中断办法都是利用保活机制。而保活机制分又可让底层实现也可本身实现。

一、本身编写心跳包程序

简单的说也就是在本身的程序中加入一条线程，定时向对端发送数据包，查看是否有ACK，若是有则链接正常，没有的话则链接断开

二、启动TCP编程里的keepAlive机制

1）双方拟定心跳（自实现） 通常由客户端发送心跳包，服务端并不回应心跳，只是定时轮询判断一下与上次的时间间隔是否超时（超时时间本身设定）。服务器并不主动发送是不想增添服务器的通讯量，减小压力。

2）利用KeepAlive 其实keepalive的原理就是TCP内嵌的一个心跳包,

以服务器端为例，若是当前server端检测到超过必定时间（默认是 7,200,000 milliseconds，也就是2个小时）没有数据传输，那么会向client端发送一个keep-alive packet（该keep-alive packet就是ACK和当前TCP序列号减一的组合），此时client端应该为如下三种状况之一：

client端仍然存在，网络链接情况良好。此时client端会返回一个ACK。server端接收到ACK后重置计时器（复位存活定时器），在2小时后再发送探测。若是2小时内链接上有数据传输，那么在该时间基础上向后推延2个小时。
  客户端异常关闭，或是网络断开。在这两种状况下，client端都不会响应。服务器没有收到对其发出探测的响应，而且在必定时间（系统默认为1000 ms）后重复发送keep-alive packet，而且重复发送必定次数（2000 XP 2003 系统默认为5次, Vista后的系统默认为10次）。
  客户端曾经崩溃，但已经重启。这种状况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引发服务器对链接的终止。

对于应用程序来讲，2小时的空闲时间太长。所以，咱们须要手工开启Keepalive功能并设置合理的Keepalive参数。

全局设置可更改/etc/sysctl.conf,加上:

net.ipv4.tcp_keepalive_intvl = 20 net.ipv4.tcp_keepalive_probes = 3 net.ipv4.tcp_keepalive_time = 60

在程序中表现为,当tcp检测到对端socket再也不可用时(不能发出探测包,或探测包没有收到ACK的响应包),select会返回socket可读,而且在recv时返回-1,同时置上errno为ETIMEDOUT.