tcp/ip的状态及状态转移分析

状态	描述	下一状态	事件条件
LISTEN	等待其他链接	无	无
SYN-SENT	某端发送了SYN消息，请求连接后处于此状态	ESTABLISHED	收到对端发送的ACK消息
SYN-RECEIVED	某段收到另一端发送的SYN消息,回复ACK后，处于此状态	ESTABLISHED	收到对端发送的ACK消息
ESTABLISHED	已连接状态	FIN-WAIT-1 或 CLOSE-WAIT	主动发送CLOSE消息或收到对端发送的CLOSE消息
FIN-WAIT-1	某端主动发送CLOSE消息	FIN-WAIT-2	收到对端的ACK消息
FIN-WAIT-2	某端在FIN-WAIT-1状态时收到ACK消息	TIME-WAIT	收到对端发送的CLOSE消息
TIME-WAIT	某端在FIN-WAIT-2时收到对端发送的CLOSE消息	CLOSED	2msl时间到达
CLOSE-WAIT	某端收到对端的CLOSE消息，给对方发送ACK消息之后处于此状态	LAST-ACK	开发者调用Close函数主动关闭，向对端发送CLOSE消息
LAST-ACK	向对端发送CLOSE消息后处于此状态	CLOSED	收到处于TIME-WAIT状态的端的ACK回复
CLOSED	关闭,默认不显示	无	无

在实际状态中，最常见的状态应该为CLOSED(默认不显示),LISTEN,ESTABLISHED，TIME-WAIT.其余的状态理论上来说存在的时间都会非常短。如果有其他状态长期存在，那么程序可能会有异常存在。以下是异常状态分析：

状态	原因
SYN-SENT	某端连接了无响应的ip，可能是ip无效，也可能是该ip设备不在线，超时后释放
SYN-RECEIVED	理论来说对端发起了连接，但是本端回复确认后，对方又不返回了。这种情况不好测试。可以在网络非常卡的情况下，某端连接请求发出后，立马拔掉网线，然后看对端状态……
FIN-WAIT-1	对端拔掉网线，本段在处于连接状态时发起关闭请求。否则理论来说，几乎不会出现。
FIN-WAIT-2	对端的程序忙于处理其他的，没有来记得CLose掉对应的Socket
CLOSE-WAIT	对端发起了关闭请求，本端一直没有关闭，可能是程序忙于读写，也可能是程序bug忘记CLose掉了。
LAST-ACK	除了拔网线和操作系统bug，想不到怎么出现……