标签：注意 软件 能力 数据包 bsp rom 并发 time remote
我们通过了解各个 TCP 状态，可以排除和定位网络或系统故障。
TCP/IP 协议中，TCP 协议提供可靠的连接服务，采用三次握手建立一个连接
由于 TCP 连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向的连接。收到一个 FIN 只意味着这一方向没有数据流动，一个 TCP 连接在收到一个 FIN 后仍能发送数据。首先进行关闭的一房将执行主动关闭，而另一方执行被动关闭。
TCP 的连接断开需要发送四个包，因此称为四次握手。客户端或服务器均可主动发起，在 socket 编程中，任何一方执行 close() 操作即可产生。
端口提供某种服务才会处于 LISTENING 状态。提供服务时服务端需要打开一个 socket 进行监听，状态为 LISTEN。
例如：提供 www 服务默认开的是80端口，提供 ftp 服务默认的端口为21，当提供的服务没有被连接时就处于 LISTENING 状态。FTP 服务启动后首先处于侦听（LISTENING）状态。处于侦听 LISTENING 状态时，该端口是开放的，等待连接，但还没有被连接。就像你房子的门已经敞开的，但还没有人进来。
看 LISTENING 状态最主要的是看本机开了哪些端口，这些端口都是哪个程序开的，关闭不必要的端口是保证安全的一个非常重要的方面，服务端口都对应一个服务（应用程序），停止该服务就关闭了该端口。
客户端通过应用程序调用 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 出现。
收到和发送一个连接请求后等待对方对连接请求的确认。
当服务器收到客户端发送的同步信号时，将标志位 ACK 和 SYN 置 1 发送给客户端，此时服务器端处于 SYN_RCVD 状态，如果连接成功了就变为 ESTABLISHED，正常情况下 SYN_RCVD 状态非常短暂。如果发现有很多 SYN_RCVD 状态，那你的机器有可能被 SYN Flood 的 DoS(拒绝服务攻击) 攻击了。
SYN Flood 的攻击原理是：
在进行三次握手时，攻击软件向被攻击的服务器发送 SYN_SENT （握手的第一步），但是这个地址是伪造的，服务器在收到连接请求时将标志位 ACK 和 SYN 置 1 发送给客户端（握手的第二步），但是这些客户端的IP地址都是伪造的，服务器根本找不到客户机，也就是说握手的第三步不可能完成。
这种情况下服务器端一般会重试（再次发送 SYN+ACK 给客户端）并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为 SYN Timeout，一般来说这个时间是分钟的数量级（大约为30秒-2分钟）；一个用户出现异常导致服务器的一个线程等待1分钟并不是什么很大的问题，但如果有一个恶意的攻击者大量模拟这种情况，服务器端将为了维护一个非常大的半连接列表而消耗非常多的资源—-数以万计的半连接，即使是简单的保存并遍历也会消耗非常多的 CPU 时间和内存，何况还要不断对这个列表中的 IP 进行 SYN+ACK 的重试。此时从正常客户的角度看来，服务器失去响应，这种情况我们称做：服务器端受到了 SYN Flood 攻击
ESTABLISHED 状态是表示两台机器正在传输数据，观察这个状态最主要的就是看哪个程序正在处于 ESTABLISHED 状态。
当客户端未主动 close 的时候就断开连接：即客户端发送的 FIN 丢失或未发送。这时候若客户端断开的时候发送了 FIN 包，则服务端将会处于 CLOSE_WAIT 状态；若客户端断开的时候未发送 FIN 包，则服务端处还是显示 ESTABLISHED 状态；结果客户端重新连接服务器。而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是 ESTABLISHED ; 如果客户端重复的上演这种情况，那么服务端将会出现大量的假的 ESTABLISHED 连接和 CLOSE_WAIT 连接。最终结果就是新的其他客户端无法连接上来，但是利用 netstat 还是能看到一条连接已经建立，并显示 ESTABLISHED，但始终无法进入程序代码。
主动关闭(active close)端应用程序调用 close ，于是其 TCP 发出 FIN 请求主动关闭连接，之后进入 FIN_WAIT1 状态。
The socket is closed, and the connection is shutting down. 等待远程TCP的连接中断请求，或先前的连接中断请求的确认
如果服务器出现 shutdown 再重启，使用 netstat -nat 查看，就会看到很多 FIN-WAIT-1 的状态。就是因为服务器当前有很多客户端连接，直接关闭服务器后，无法接收到客户端的ACK。
主动关闭端接到 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 状态，而直到应用层来决定关闭这个状态。
被动关闭(passive close)端 TCP 接到 FIN 后，就发出 ACK 以回应 FIN 请求(它的接收也作为文件结束符传递给上层应用程序),并进入 CLOSE_WAIT。
The remote end has shut down, waiting for the socket to close. 等待从本地用户发来的连接中断请求
比较少见.
Both sockets are shut down but we still don’t have all our data sent. 等待远程TCP对连接中断的确认
被动关闭端一段时间后，接收到文件结束符的应用程序将调用 CLOSE 关闭连接。这导致它的 TCP 也发送一个 FIN，等待对方的 ACK。就进入了 LAST-ACK。
The remote end has shut down, and the socket is closed. Waiting for acknowledgement. 等待原来发向远程TCP的连接中断请求的确认。
使用并发压力测试的时候，突然断开压力测试客户端，服务器会看到很多 LAST-ACK。
在主动关闭端接收到 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 时间的过去才能进行下一次连接。
被动关闭端在接受到 ACK 包后，就进入了 closed 的状态。连接结束
The socket is not being used. 没有任何连接状态
标签：注意 软件 能力 数据包 bsp rom 并发 time remote
原文地址：https://www.cnblogs.com/petewell/p/11601648.html
