TCP协议由浅入深(2)——TCP状态变迁

在上一篇中我们了解了TCP的连接和终止，现在来讨论TCP的状态变迁。
一、TCP状态变迁图

下面我们来结合上一篇连接方式来解读这个图
1.正常连接与终止

各个状态的含义与作用：
LISTEN:侦听来自远方的TCP端口连接请求
SYN_SENT:客户端发送SYN报文，等待服务端的匹配请求(SYN+ACK)
SYN_RCVD:服务端收到客户端的SYN报文后发出SYN+ACK并等待客户端的确认
ESTABLISHED:客户端发送ACK报文都进入此状态，服务端接受到客户端的ACK进入此状态，此状态表示一个连接的打开，可以进行数据的传输。
FIN_WAIT_1:主动关闭端调用close，向对端发送FIN报文后进入此状态，等待对端ACK。
FIN_WAIT_2:接收到对端的ACK后进入此状态，在此状态中还是能进行数据的传输。
CLOSE_WAIT:被动关闭端等待本地用户发来的中断请求,如果长时间处于此状态，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。
·LAST_ACK:等待最后一次ACK。
TIME_WAIT:TIME_WAIT也叫2msl状态，msl是报文最大存活时间，系统默认为30S。这个状态的存在有两个意义：
1.当客户端发送的最后一个ACK报文丢失时，服务端无法收到这个ACK报文，在msl这个时间内会发送一个重发信号，而这个信号最大存活时间也是msl，如果客户端在2msl中为收到重发的信息，则代表服务端收到最后一个ACK，可以关闭。
2.允许迟到的报文流逝。
当连接处于TIME_WAIT状态时，这个连接端口不能再次被使用，如果老的连接由于网络问题导致某些带有数据的报文段迟到，而这时开启了新的连接，这时候就会导致新连接收到了这些迟到的报文，而TIME_WAIT给了足够的时间让这些报文流逝。
2.其他方式连接的变迁
1.同时打开

两方状态变迁都是：SYN_SENT—>SYN_RCVD—>ESTABLISHED
2.同时关闭

这个时候出现了一个叫CLOSING的状态，这个状态只会在同时关闭的情况下出现，代表的是客户端和服务端同时close。

还有一些其他的状态迁移，这些状态迁移针对服务器和客户端两方面的总结如下
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状态并等待关闭。

---

从这些知识可以看出TCP的设计很巧妙有效的建立了可靠地连接，那么它是如何解决连接过程中的异常问题呢？
1.当在三次握手是左后一个ACK报文丢失
答：这是服务端的状态为SYN_RCVD状态，并且重发SYN+ACK(这个重发次数可在/proc/sys/net/ipv4/tcp_synack_retries修改)，如果在超过这个次数后，服务端会自动断开连接。但是此时的客户端不知道服务端没收到ACK，这时客户端回想服务端写数据，在此时服务端会回复RST报文，重新进行连接。
2.TIME_WAIT带来的问题
TIME_WAIT这个状态如果过多会占用很多资源，导致无法建立新的连接。
这是后我们可以开启TIME_WAIT的重用。修改内核选项tcp_tw_reuse或者使用SO_REUSEADDR
3.SYN Flood攻击
原理：攻击者首先伪造地址对 服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。