tcp状态详解
原文链接：https://blog.csdn.net/u014426746/article/details/22481637
TCP基本知识点
- 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三次握手和四次握手的状态迁移
上面的状态迁移图，基本上把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的同时打开和同时关闭
除了上面的顺序打开，和顺序关闭方式，TCP还有同时打开和同时关闭的流程：
同时打开流程：（引自：http://hi.baidu.com/psorqkxcsfbbghd/item/70f3bd91943b9248f14215cd）
同时关闭流程：（引自：http://hi.baidu.com/psorqkxcsfbbghd/item/70f3bd91943b9248f14215cd）
如果上面的顺序流程已经非常清楚的话，那么这两个同时打开、同时关闭的状态图就不难理解了……
大家可以通过这两张图来对应上面socket关闭流程中，“第二次握手失败”的解释，其实也就不难理解，为什么客户会进入同时关闭状态了。因为客户在发送了FIN之后，没有等到ACK，而是等到了服务器的FIN，自然符合同步关闭的流程。
