TCP 状态

TCP状态  

linux查看tcp的状态命令：

• netstat -nat  查看TCP各个状态的数量
• lsof  -i:port  可以检测到打开套接字的状况
• sar -n SOCK 查看tcp创建的连接数
• tcpdump -iany tcp port 9000 对tcp端口为9000的进行抓包

网络测试常用命令：

• ping：检测网络连接的正常与否，主要是测试延时、抖动、丢包率。但是很多服务器为了防止攻击，一般会关闭对ping的响应。所以ping一般作为测试连通性使用。ping命令后，会接收到对方发送的回馈信息，其中记录着对方的IP地址和TTL。TTL是该字段指定IP包被路由器丢弃之前允许通过的最大网段数量。TTL是IPv4包头的一个8bit字段。例如IP包在服务器中发送前设置的TTL是64，你使用ping命令后，得到服务器反馈的信息，其中的TTL为56，说明途中一共经过了8道路由器的转发，每经过一个路由，TTL减1。
• traceroute：跟踪数据包到达网络主机所经过的路由工具。traceroute hostname。
• pathping：是一个路由跟踪工具，它将 ping 和 tracert 命令的功能与这两个工具所不提供的其他信息结合起来，综合了二者的功能。pathping www.baidu.com。
• mtr：以结合ping nslookup tracert 来判断网络的相关特性。
• 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.104、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状态。

　　/* The socket is closed, and the connection is shutting down. 等待远程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状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。这个状态在很大程度上保证了双方都可以正常结束。

　　MSL：报文的最大生存时间，默认是2min，但可以设置。

　　但是，问题也来了：由于插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是无法再次使用同一个插口的，对于客户程序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插口被使用）。为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

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

CLOSED

　　没有任何连接状态。

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

　　/* The socket is not being used. 没有任何连接状态 */

TCP状态迁移路线图

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

 

　　这是一个看起来比较复杂的状态迁移图，因为它包含了两个部分---服务器的状态迁移和客户端的状态迁移，如果从某一个角度出发来看这个图，就会清晰许多，这里面的服务器和客户端都不是绝对的，发送数据的就是客户端，接受数据的就是服务器。

客户端的状态迁移图

　　CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED

　　以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。

服务器的状态迁移图

　　CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED

　　在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后（注意不是第四次）。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。

其他状态迁移

　　还有一些其他的状态迁移，这些状态迁移针对服务器和客户端两方面的总结如下：

• LISTEN->SYN_SENT，对于这个解释就很简单了，服务器有时候也要打开连接的嘛。
• SYN_SENT->SYN收到，服务器和客户端在SYN_SENT状态下如果收到SYN数据报，则都需要发送SYN的ACK数据报并把自己的状态调整到SYN收到状态，准备进入ESTABLISHED
• SYN_SENT->CLOSED，在发送超时的情况下，会返回到CLOSED状态。
• SYN_收到->LISTEN，如果受到RST包，会返回到LISTEN状态。
• SYN_收到->FIN_WAIT_1，这个迁移是说，可以不用到ESTABLISHED状态，而可以直接跳转到FIN_WAIT_1状态并等待关闭。

问题

1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

　　这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。

　　但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET，也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

2．为什么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元组，这时候连接就可能接收到网络上的延迟报文就可能干扰最新建立的连接。

　　TIME_WAIT状态等2MSL后会自动变成CLOSED状态

3、发现系统存在大量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 时间

4、同时打开

　　两个应用程序同时执行主动打开的情况是可能的，虽然发生的可能性较低。每一端都发送一个SYN,并传递给对方，且每一端都使用对端所知的端口作为本地端口。例如：

　　主机a中一应用程序使用7777作为本地端口，并连接到主机b 8888端口做主动打开。

　　主机b中一应用程序使用8888作为本地端口，并连接到主机a 7777端口做主动打开。

　　tcp协议在遇到这种情况时，只会打开一条连接。

　　这个连接的建立过程需要4次数据交换，而一个典型的连接建立只需要3次交换（即3次握手）

　　但多数伯克利版的tcp/ip实现并不支持同时打开。

5、同时关闭

　　如果应用程序同时发送FIN，则在发送后会首先进入FIN_WAIT_1状态。在收到对端的FIN后，回复一个ACK，会进入CLOSING状态。在收到对端的ACK后，进入TIME_WAIT状态。这种情况称为同时关闭。

　　同时关闭也需要有4次报文交换，与典型的关闭相同。

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

　　引用地址：http://blog.csdn.net/kkkkkxiaofei/article/details/12966407

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

　　但是，如果意外断开，客户端（3g的移动设备）并没有正常关闭socket。双方并未按照协议上的四次挥手去断开连接。那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去，也就是会被长时间卡住。

　　像这种如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这样的TCP连接称为半打开的。

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

     1、自己编写心跳包程序

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

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