tcp十一种状态及问题处理方法
TCP十一种状态
全部11种状态
1. 客户端独有的：（1）SYN_SENT （2）FIN_WAIT1 （3）FIN_WAIT2 （4）CLOSING （5）TIME_WAIT 。
2. 服务器独有的：（1）LISTEN （2）SYN_RCVD （3）CLOSE_WAIT （4）LAST_ACK 。
3. 共有的：（1）CLOSED （2）ESTABLISHED 。
各个状态的意义如下：
LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；各个状态详解：
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的连接中断请求，或先前的连接中断请求的确认 */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的连接中断请求的确认 */
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时间的过去才能进行下一次连接。
CLOSED：没有任何连接状态
被动关闭端在接受到ACK包后，就进入了closed的状态。连接结束./* The socket is not being used. 没有任何连接状态 */
TCP状态迁移
大家对netstat -a命令很熟悉，但是，你注意到STATE一栏没，基本上显示着established,time_wait,close_wait等，这些到底是 什么意思呢？
大家很明白TCP初始化连接三次握手吧：发SYN包，然后返回SYN/ACK包，再发ACK包，连接正式建立。但是这里有点出入，当请求者收到SYS /ACK包后，就开始建立连接了，而被请求者第三次握手结束后才建立连接。但是大家明白关闭连接的工作原理吗？关闭连接要四次握手：发FIN包，ACK 包，FIN包，ACK包，四次握手！！为什么呢，因为TCP连接是全双工，我关了你的连接，并不等于你关了我的连接。
客户端正常情况下TCP状态迁移：
|
|
服务器正常情况下TCP状态迁移：
|
|
当客户端开始连接时，服务器还处于LISTENING，
客户端发一个SYN包后，他就处于SYN_SENT状态,服务器就处于SYS收到状态,
然后互相确认进入连接状态ESTABLISHED.
当客户端请求关闭连接时,客户端发送一个FIN包后,客户端就进入FIN_WAIT_1状态,等待对方的确认包,
服务器发送一个ACK包给客户,客户端收到ACK包后结束FIN_WAIT_1状态,进入FIN_WAIT_2状态,等待服务器发过来的关闭请求,
服务器发一个FIN包后,进入CLOSE_WAIT状态,
当客户端收到服务器的FIN包,FIN_WAIT_2状态就结束,然后给服务器端的FIN包给以一个确认包,客户端这时进入TIME_WAIT,
当服务器收到确认包后,CLOSE_WAIT状态结束了,
这时候服务器端真正的关闭了连接.但是客户端还在TIME_WAIT状态下,
什么时候结束呢.我在这里再讲到一个新名词:2MSL等待状态,其实TIME_WAIT就是2MSL等待状态,
为什么要设置这个状态,原因是有足够的时间让ACK包到达服务器端,如果服务器端没收到ACK包，超时了，然后重新发一个FIN包，直到服务器收到ACK 包.
TIME_WAIT状态等待时间是在TCP重新启动后不连接任何请求的两倍.
大家有没有发现一个问题:如果对方在第三次握手的时候出问题,如发FIN包的时候,不知道什么原因丢了这个包,然而这边一直处在FIN_WAIT_2状 态,而且TCP/IP并没有设置这个状态的过期时间,那他一直会保留这个状态下去,越来越多的FIN_WAIT_2状态会导致系统崩溃.
上面我碰到的这个问题主要因为TCP的结束流程未走完，造成连接未释放。现设客户端主动断开连接，流程如下:
|
|
由于Server的Socket在客户端已经关闭时而没有调用关闭，造成服务器端的连接处在“挂起”状态，而客户端则处在等待应答的状态上。
此问题的典型特征是：一端处于FIN_WAIT2 ，而另一端处于CLOSE_WAIT。不过，根本问题还是程序写的不好，有待提高
-------------------------------------------------------------------------
CLOSE_WAIT，TCP的癌症，TCP的朋友。
CLOSE_WAIT状态的生成原因
首先我们知道，如果我们的服务器程序APACHE处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！
因为如果是CLIENT端主动断掉当前连接的话，那么双方关闭这个TCP连接共需要四个packet：
Client ---> FIN ---> Server
Client <--- ACK <--- Server
这时候Client端处于FIN_WAIT_2状态；而Server 程序处于CLOSE_WAIT状态。
Client <--- FIN <--- Server
这时Server 发送FIN给Client，Server 就置为LAST_ACK状态。
Client ---> ACK ---> Server
Client回应了ACK，那么Server 的套接字才会真正置为CLOSED状态。
Server 程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没有发FIN给Client，那么可能是在关闭连接之前还有许多数据要发送或者其 他事要做，导致没有发这个FIN packet。
通常来说，一个CLOSE_WAIT会维持至少2个小时的时间。如果有个流氓特地写了个程序，给你造成一堆的 CLOSE_WAIT，消耗你的资源，那么通常是等不到释放那一刻，系统就已经解决崩溃了。
只能通过修改一下TCP/IP的参数，来缩短这个时间：修改tcp_keepalive_*系列参数有助于解决这个 问题。
解决这个问题的方法是修改系统的参数，系统默认超时时间的是7200秒，也就是2小时， 这个太大了，可以修改如下几个参数：
|
|
然后，执行sysctl命令使修改生效。
连接进程是通过一系列状态表示的，这些状态有：
LISTEN，SYN-SENT，SYN-RECEIVED，ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE- WAIT，CLOSING，LAST-ACK，TIME-WAIT和CLOSED
1、建立连接协议（三次握手）
（1）客户 端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。
（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标 志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通 讯。
（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。
2、连接终止协议（四次握手）
由于TCP连 接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终 止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接 在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1） TCP客 户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。
（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一 样，一个FIN将占用一个序号。
（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。
（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。
CLOSED: 这个没什么好说的了，表示初始状态。
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处 于监听状态，可以接受连接了。
SYN_RCVD: 这个状态表示接受到了SYN报 文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手 过程中最后一个ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文 后，它会进入到ESTABLISHED状态。
SYN_SENT: 这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。
ESTABLISHED：这个容易理解了，表示连接已经建立了。
FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报 文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况 下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。
FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点 数据需要传送给你，稍后再关闭连接。
TIME_WAIT: 表示收到了对方的FIN报 文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标 志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。
CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发 送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报 文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报 文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一 个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一 个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文 给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话， 那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报 文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。
最后有2个问题 的回答，我自己分析后的结论（不一定保证100%正确）
1、 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起 应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文 通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文 和FIN报文多数情况下都是分开发送的。
2、 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状 态？
这是因为：虽然双方 都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状 态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报 文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报 文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报 文，并保证于此。
断开连接的时候， 当发起主动关闭的左边这方发送一个FIN过去后，
右边被动关闭的这方要回应一个ACK，这个ACK是TCP回应的，而不是应用程序发送的，
此时，被动关闭的一方就处于CLOSE_WAIT状态了。
如果此时被动关闭的这一方不再继续调用closesocket,那么他就不会发送接下来的FIN，导致自己老是处于CLOSE_WAIT。
只有被动关闭的这一方调用了 closesocket,才会发送一个FIN给主动关闭的这一方，同时也使得自己的状态变迁为LAST_ACK。
比如被动关闭的是客户端
当对方调用closesocket的时候，你的程序正在
int nRet = recv(s,....);
if (nRet == SOCKET_ERROR)
{
// closesocket(s);
return FALSE;
}我的理解，
当主动关闭的一方发送FIN到被动关闭这边后，被动关闭这边的TCP马上回应一个ACK过去，同时向上面应用程序提交一个ERROR，
导致上面的SOCKET的send或者recv返回SOCKET_ERROR.
正常情况下，如果上面在返回SOCKET_ERROR后调用了closesocket, 那么被动关闭的者一方的TCP就会发送一个FIN过去，自己的状态就变迁到LAST_ACK.
服务器上出现大量的close_wait的例子和解决方法（例子从网上找的，基本差不多）
$ /usr/sbin/lsof -i | grep 6800
$ /usr/sbin/lsof -i | grep 6800
Oracle 22725 oracle9i 3u IPv4 18621468 TCP RHEL3:6800 (LISTEN)
oracle 22725 oracle9i 4u IPv4 18621469 TCP RHEL3:6800->RHEL3:2174 (CLOSE_WAIT)
oracle 22725 oracle9i 8u IPv4 18621568 TCP RHEL3:6800->RHEL3:2175 (CLOSE_WAIT)
oracle 22725 oracle9i 9u IPv4 18621578 TCP RHEL3:6800->RHEL3:2176 (CLOSE_WAIT)
oracle 22726 oracle9i 3u IPv4 18621468 TCP RHEL3:6800 (LISTEN)
oracle 22726 oracle9i 4u IPv4 18621469 TCP RHEL3:6800->RHEL3:2174 (CLOSE_WAIT)
oracle 22726 oracle9i 8u IPv4 18621568 TCP RHEL3:6800->RHEL3:2175 (CLOSE_WAIT)
oracle 22726 oracle9i 9u IPv4 18621578 TCP RHEL3:6800->RHEL3:2176 (CLOSE_WAIT)
$ kill -9 22725
# 22725, 22726就是使用该6800端口的进程号(PID)。
$ /usr/sbin/lsof -i | grep 6800该问题的出现原因网上到处都是，也就是Socket的Client端出现异常没有Close就退出了。
TCP连接过程是状态的转换，促使发生状态转换的是用户调用
- TCP三次握手和四次握手的状态迁移
- 在任意时刻发生丢包或者重复包时，TCP/IP的处理策略
- Linux系统调用对TCP/IP可以进行哪些设置，主要针对哪些方面的优化
- TCP由RFC793、RFC1122、RFC1323、RFC2001、RFC2018以及RFC2581定义
- TCP提供可靠性保证
- TCP发送数据后，要求对方返回确认，如果没有收到确认，TCP会进行重传，数次重传失败后，TCP才会放弃
- TCP含有动态估算RTT（round-trip time）的算法，可以根据网络拥塞情况动态调整RTT，重新传等待时间就是使用RTT来确定的
- TCP通过给所发送数据的每一个字节关联一个序列号进行排序，从而处理分包非顺序到达和重复包的情况
- TCP提供流量控制。TCP总能告诉对方自己还能接收多少字节的数据（advertised window——通告窗口），防止接收缓冲区溢出。窗口随着数据的到来和从缓冲区中取走数据而动态变化。
- TCP是全双工的。所以TCP必须跟踪每个方向数据流的状态信息（如序列号和通告窗口的大小）
上面的状态迁移图，基本上把TCP三次握手和四次握手的大致流程描述的非常清楚了，下面我们用文字将上面的过程描述一遍，并对异常情况进行分析：
三次握手概述：
- 服务器主动进入LISTEN状态，监听端口
- 客户发送第一次握手请求，发送完毕后进入SYN_SEND状态，等待服务器响应
- 服务器收到第一次握手请求，向客户确认第一次请求，连带发送第二次握手请求，发送完毕后进入SYN_RECV状态，等待客户响应
- 客户收到确认和第二次握手请求，对第二次握手请求进行确认（第三次握手），发送确认完毕后，进入ESTABLISHED状态
- 服务器收到对第二次握手请求的确认之后（第三次握手），进入ESTABLISHED状态
- 至此，三次握手完成，客户-服务器完成连接的建立，开始数据通信
- 服务器通过socket()、bind()和listen()来完成CLOSED状态到LISTEN状态的转化，称为被动打开。被动打开完成之后，accept()阻塞，等待客户请求
- 客户通过connect()进行主动打开。这引起客户TCP发送一个SYN分节，用于通知服务器客户将在连接中发送数据的初始序列号（一般SYN分节不包含任何数据，只有TCP和IP的头部信息）
- 服务器以单个分节，同时对客户的SYN序列号进行确认，并发送自己的SYN序列号（此时accept()还在阻塞中）
- 客户对服务器的SYN数据进行确认。客户在收到服务器SYN并进行确认之后，connect()返回
- 服务器收到客户的确认，accept()返回
- 第一次握手丢包：默认情况下，connect()是阻塞式的，如果请求无法发送到服务器，那么connect会进行一段很长时间的等待和重试（重传次数和时间间隔我们暂且不去深究），此时我们可以使用通过设置SO_SNDTIMEO来为connect设置超时以减少connect的等待时间
- 第二次握手丢包：对于客户来说，依然是connect超时，所以处理方式和第一次握手丢包是一样的。对于服务器来说，由于收不到第三次握手请求，所以会进行等待重传，直到多次重传失败后，关闭半连接。
- 这里需要提一下的是，服务器会维护一个半连接队列，用于等待客户的第三次握手请求。当收到第三次握手请求或者多次重传失败后，服务器会将该半连接从队列中删除。（这里暂且不去深究半连接队列的等待重新策略和配置）
- 我们经常听说的DDos攻击，就可以这个环节实现，syn flood就是一种常见的DDos攻击方式。简单来说，syn flood就是只发送第一次握手请求后，就关闭连接，将服务器的半连接队列占满，从而让正常用户无法得到服务。
- 第三次握手丢包：由于客户在发送第三次握手包后，不再等待确认，就直接进入了ESTABLISHED状态，所以一旦第三次握手失败，客户和服务器的状态就不同步了。当然，此时服务器会进行多次重发，一旦客户再次收到SYN+ACK（第二次握手请求），会再次确认。不过，如果第三次握手一直失败，则会出现，客户已经建立连接，而服务器关闭连接的情况。随后，一旦客户向服务器发送数据，则会收到一条RST回应，告诉用户连接已经重置，需要重新进行三次握手。
- RST和SIGPIPE：有过网络编程经验的人都知道在写网络通信的时候，需要屏蔽SIGPIPE信号，否则的话，一旦收到PIPE信号会导致程序异常退出。其实这个SIGPIPE就是由于write()的时候，我们自己的状态是ESTABLISHED而对方的状态不是ESTABLISHED，那么对方就会给我们一个RST回应，收到这个回应之后，系统就会自动生成一个PIPE信号。
四次握手概述：
- 客户发送FIN请求（第一次握手），通知关闭连接，然后进入FIN_WAIT1状态
- 服务器收到FIN请求后，发送ACK（第二次握手），对客户的FIN进行确认，然后进入CLOSE_WAIT状态
- 服务器进行一些收尾工作，然后主动相客户发送FIN请求（第三次握手），通知关闭连接，然后进入LAST_ACK状态
- 客户收到FIN，对FIN进行确认（第四次握手），并进入TIME_WAIT状态
- 服务器收到客户的确认，关闭连接
- 客户等待一段时间后，关闭连接
- 客户调用close()执行主动关闭，发送FIN到服务器，FIN表示不会再发送数据了
- 服务器收到FIN进行被动关闭，由TCP对FIN进行确认。FIN作为文件结束符，传递给recv()。因为收到FIN以后就意味着不会再有数据了
- 一段时间后，服务器调用close()关闭自己的socket，并发送FIN给客户，宣告自己不会再发送数据了
- 客户收到FIN后，不再确认，等待一段时间后，自行关闭自己的socket
- TCP是全双工的连接，所以关闭的过程必须是两个方向都关闭才行，这也就是为什么需要两次不同方向的FIN
- FIN并不像SYN一样，一定是一个独立的包，有时FIN会随着数据一起发送，而对方也有可能将ACK和FIN放在一个包中进行发送，这成为捎带。捎带的机制在数据传输中也会出现。
- 四次握手的过程不像三次握手一样，一定是由客户发起。虽然一般来说，是由客户发起，但是某些协议（例如HTTP）则是服务器执行主动关闭
两个WAIT：
- CLOSE_WAIT：CLOSE_WAIT的状态位于向对方确认FIN之后，向对方发送FIN之前，这段时间由于对方已经发送了FIN，也就表示不会再收到数据，但是这并不表示自己没有数据要发，毕竟只有在发送了FIN之后，才表示发送完毕。所以，CLOSE_WAIT这段时间主要的工作就是给对方发送必要的数据，对自己的数据进行收尾，所有工作结束之后，调用close()，发送FIN，等待LAST_ACK
- TIME_WAIT：存在TIME_WAIT状态有如下两个理由：
- 实现终止TCP全双工连接的可靠性：假如LAST-ACK丢失，对方重发，但是自己已经关闭连接，那么会返回一个RST包，对放会将其解释为错误，从而无法正常关闭。也就是说，TIME_WAIT的作用之一就是解决LAST-ACK可能丢包的情况，因为在有些网络不好的情况下，不得不重发LAST-ACK
- 允许老的网络分组在网络中消逝：2MSL的时间足够让所有的FIN数据在网络中消失，如果不等待，并立即开始一个新的连接，有可能出现老FIN关闭了新连接的情况，因为在IP和端口一直的情况下，很难区分一个数据包是属于哪一次连接的
四次握手的异常：
- 第一次握手丢包：FIN_WAIT1丢失会导致客户重传，如果多次重传失败，则客户超时关闭连接，而服务器依然保持ESTABLISHED状态。如果服务器主动发送数据，则会收到一个RST包，重置连接。设置KeepAlive道理相同，核心是要求服务器主动发数据。如果服务器永远不会主动发数据，那么就会一直保持这样一个“假连接”
- 第二次握手丢包：由于服务器第二次握手不会重发，所以即使丢包也不管，直接向对方发送FIN，此时客户执行”同时关闭“的流程（这个流程后面再说），等待TIME_WAIT时间后关闭。在客户进入TIME_WAIT之后，自己由于FIN没有相应，会重发，如果被客户TIME_WAIT收到并发送LAST-ACK，则流程正常结束，如果反复重发没有响应，那么超时关闭
- 第三次握手丢包：服务器会持续等待在LAST_ACK状态，而客户会持续等待在FIN_WAIT2状态，最后双方超时关闭
- 第四次握手丢包：客户端进入TIME_WAIT状态，等待2MSL，服务器由于收不到LAST-ACK则进行重发，如果多次重发失败，则超时关闭（这个流程和第二次握手丢包的后半段状态是一样的）
TCP的同时打开和同时关闭
主机a中一应用程序使用7777作为本地端口，并连接到主机b 8888端口做主动打开。
主机b中一应用程序使用8888作为本地端口，并连接到主机a 7777端口做主动打开。
tcp协议在遇到这种情况时，只会打开一条连接。
这个连接的建立过程需要4次数据交换，而一个典型的连接建立只需要3次交换(即3次握手)
但多数伯克利版的tcp/ip实现并不支持同时打开
同时关闭也需要有4次报文交换，与典型的关闭相同。
TCP通信中服务器处理客户端意外断开
如果TCP连接被对方正常关闭，也就是说，对方是正确地调用了closesocket(s)或者shutdown(s)的话，那么上面的Recv或Send调用就能马上返回，并且报错。这是由于close socket(s)或者shutdown(s)有个正常的关闭过程，会告诉对方“TCP连接已经关闭，你不需要再发送或者接受消息了”。
但是，如果意外断开，客户端(3g的移动设备)并没有正常关闭socket。双方并未按照协议上的四次挥手去断开连接。
那么这时候正在执行Recv或Send操作的一方就会因为没有任何连接中断的通知而一直等待下去，也就是会被长时间卡住。
像这种如果一方已经关闭或异常终止连接，而另一方却不知道，我们将这样的TCP连接称为半打开 的。
解决意外中断办法都是利用保活机制。而保活机制分又可以让底层实现也可自己实现。
1、 自己编写心跳包程序
简单的说也就是在自己的程序中加入一条线程，定时向对端发送数据包，查看是否有ACK，如果有则连接正常，没有的话则连接断开
2、 启动TCP编程里的keepAlive机制
一）双方拟定心跳(自实现)
一般由客户端发送心跳包，服务端并不回应心跳，只是定时轮询判断一下与上次的时间间隔是否超时(超时时间自己设定)。服务器并不主动发送是不想增添服务器的通信量，减少压力。
但这会出现三种情况：
情况1.
客户端由于某种网络延迟等原因很久后才发送心跳(它并没有断)，这时服务器若利用自身设定的超时判断其已经断开，而后去关闭socket。若客户端有重连机制，则客户端会重新连接。若不确定这种方式是否关闭了原本正常的客户端，则在ShutDown的时候一定要选择send,表示关闭发送通道，服务器还可以接收一下，万一客户端正在发送比较重要的数据呢，是不?
情况2.
客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端已经判断出其超时，并主动close，则四次挥手成功交互。
情况3.
客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端的轮询还未判断出其超时，在未主动close的时候该客户端已经重新连接。
这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态;
这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态;
而新连接上来的客户端(也就是刚才断掉的重新连上来了)在服务端肯定是ESTABLISHED;这时候就有个问题，若利用轮询还未检测出上条旧连接已经超时(这很正常，timer总有个间隔吧)，而在这时，客户端又重复的上演情况3，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。
最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码。个人最初感觉导致这种情况是因为假的ESTABLISHED连接和 CLOSE_WAIT连接会占用较大的系统资源，程序无法再次创建连接(因为每次我发现这个问题的时候我只连了10个左右客户端却已经有40多条无效连接)。而最近几天测试却发现有一次程序内只连接了2，3个设备，但是有8条左右的虚连接，此时已经连接不了新客户端了。这时候我就觉得我想错了，不可能这几条连接就占用了大量连接把，如果说几十条还有可能。但是能肯定的是，这个问题的产生绝对是设备在不停的重启，而服务器这边又是简单的轮询，并不能及时处理，暂时还未能解决。
二）利用KeepAlive
其实keepalive的原理就是TCP内嵌的一个心跳包,
以服务器端为例，如果当前 server 端检测到超过一定时间(默认是 7,200,000 milliseconds ，也就是 2 个小时)没有数据传输，那么会向 client 端发送一个 keep-alive packet (该 keep-alive packet 就是 ACK和 当前 TCP 序列号减一的组合)，此时 client 端应该为以下三种情况之一：
1. client 端仍然存在，网络连接状况良好。此时 client 端会返回一个 ACK 。server 端接收到 ACK 后重置计时器(复位存活定时器)，在 2 小时后再发送探测。如果 2 小时内连接上有数据传输，那么在该时间基础上向后推延 2 个小时。
2. 客户端异常关闭，或是网络断开。在这两种情况下， client 端都不会响应。服务器没有收到对其发出探测的响应，并且在一定时间(系统默认为 1000 ms )后重复发送 keep-alive packet ，并且重复发送一定次数( 2000 XP 2003 系统默认为 5 次 , Vista 后的系统默认为 10 次)。
3. 客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。对于应用程序来说，2小时的空闲时间太长。因此，我们需要手工开启Keepalive功能并设置合理的Keepalive参数。
全局设置可更改 /etc/sysctl.conf ,加上:
net.ipv4.tcp_keepalive_intvl = 20
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 60
在程序中设置如下:
#include
#include
#include
#include
#include
int keepAlive = 1; // 开启keepalive属性
int keepIdle = 60; // 如该连接在60秒内没有任何数据往来,则进行探测
int keepInterval = 5; // 探测时发包的时间间隔为5 秒
int keepCount = 3; // 探测尝试的次数.如果第1次探测包就收到响应了,则后2次的不再发.
setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));
setsockopt(rs, SOL_TCP, TCP_KEEPIDLE, (void*)&keepIdle, sizeof(keepIdle));
setsockopt(rs, SOL_TCP, TCP_KEEPINTVL, (void *)&keepInterval, sizeof(keepInterval));
setsockopt(rs, SOL_TCP, TCP_KEEPCNT, (void *)&keepCount, sizeof(keepCount));