目录
1.TCP连接建立 -- 三次握手全过程1.三次握手的第一个报文(客户端发起)2.三次握手的第二个报文(服务端发起)3.三次握手的第三个报文(客户端发起) 2.为什么是三次握手？不是两次、四次？1.三次握手才可以阻止重复历史连接的初始化2.三次握手才可以同步双方的初始化序列号3.三次握手才可以避免资源浪费4.小结 3.三次握手失败会发生什么？1.第一次握手失败，会发生什么？2.第二次握手失败，会发生什么？3.第三次握手失败，会发生什么？ 4.TCP连接断开1.四次挥手全过程2.为什么要四次挥手 5.四次挥手失败，会发生什么？1.第一次挥手失败，会发生什么？2.第二次挥手失败，会发生什么？3.第三次挥手失败，会发生什么？4.第四次挥手失败，会发生什么？ 6.TIME_WAIT状态0.问题抛出1.为什么TIME_WAIT等待的时间是2MSL？2.为什么需要TIME_WAIT状态3.解决TIME_WAIT状态引起的bind失败 7.CLOSED_WAIT状态
1.TCP连接建立 – 三次握手全过程
1.三次握手的第一个报文(客户端发起)
客户端会随机初始化序列号**(client_isn)，将此序号置于TCP首部序号字段中，同时把SYN标志位置为1**，表示SYN报文接着把第一个SYN报文发生给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN_SENT状态
2.三次握手的第二个报文(服务端发起)
服务端收到客户端的SYN报文后，首先服务端也随机初始化自己的序号**(server_isn)**，将此序号填入TCP首部的序号字段中其次把TCP首部的确认应答号字段填入client_isn + 1, 接着把SYN和ACK标志位置为1最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于SYN-RCVD状态
3.三次握手的第三个报文(客户端发起)
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文TCP首部ACK标志位置为 1 ，其次确认应答号字段填入server_isn + 1，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于ESTABLISHED状态服务器收到客户端的应答报文后，也进入ESTABLISHED状态一旦完成三次握手，双方都处于ESTABLISHED状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了2.为什么是三次握手？不是两次、四次？
主要有以下三个原因： 三次握手才可以阻止重复历史连接的初始化三次握手才可以同步双方的初始化序列号三次握手才可以有效避免SYN攻击和避免资源浪费1.三次握手才可以阻止重复历史连接的初始化
假设有这样一种场景，客户端给服务端发送了一个SYN报文(seq=100)，但是这个报文由于网络波动阻塞了，于是客户端又重新发送了一个新的SYN报文(seq=200)，注意不是重传，重传的SYN的序列号是一样的
从上图可以看出，当客户端发送的SYN报文被网络阻塞后，再次发送新的SYN报文，由于旧的报文比新的报文先抵达服务端，服务端肯定会回一个SYN+ACK报文给客户端，此时客户端就可以根据这个报文来判断这是一个历史连接，由此客户端就会发送一个RST报文，要求断开此次连接(即历史连接)。等新的SYN报文抵达服务端后，才会正式的建立连接
如果是两次握手，那就不能阻止历史连接，两次握手成功的状态图如下所示
当服务端收到客户端发来的SYN报文后，就进入了ESTABLISHED状态，这就意味着服务端此时就可以给客户端发送数据了，但是客户端还没有进入ESTABLISHED状态，必须收到服务端的SYN+ACK报文后，才会进入ESTABLISHED状态
从上图可以看出，当服务端收到第一个SYN报文后(旧的)就已近建立了连接(服务端并不知道这是历史连接)，并且在回复给客户端的报文中携带了数据，但是客户端通过收到的SYN+ACK报文，发现这是历史连接；对于客户端来说，它根本来不及在服务端给客户端发送数据前来阻止这个历史连接，导致这个历史连接被创建，服务端白白发送了数据(数据创建是需要时间和空间的)，造成资源浪费；只有在收到客户端发来的RST报文后才会断开连接
因此，要解决这样的问题，客户端就必须在服务端发送数据之前来阻止掉这个历史连接，而要实现这个功能就需要三次握手2.三次握手才可以同步双方的初始化序列号
TCP协议通信的双方，都必须要维护序列号，序列号是实现可靠传输的一个关键因素，其作用如下： 接收端可以根据序列号进行重复数据的去重接收端可以根据序列号按序接受通过ACK报文中的序列号可以识别发出去的数据包中，哪些已经被对方收到了 当客户端给服务端发送SYN(携带着自己的序列号)报文的时候，需要服务端回一个ACK应答报文，表明客户端的SYN报文已经成功接收；同样，在这个报文中除了ACK应答号还有服务端自己的序列号(发送的是SYN+ACK报文)，也需要客户端回一个ACK应答报文，来确保服务端的SYN被成功接收；这样一来一回就能保证双方的初始化序列号被可靠同步从下图可以看出： 四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了三次握手而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收
3.三次握手才可以避免资源浪费
4.小结
TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输不使用两次握手和四次握手的原因两次握手：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号四次握手：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数3.三次握手失败会发生什么？
1.第一次握手失败，会发生什么？
当客户端想和服务端建立TCP连接的时候，首先第一个发的就是SYN报文，然后进入到SYN_SENT状态在此之后，如果客户端迟迟收不到服务端的SYN-ACK报文(第二次握手)，就会触发超时重传机制，重传SYN报文不同版本的操作系统可能超时时间不同，这个超时时间是写死在内核里的，Linux预设是1秒 如果想要更改则需要重新编译内核，比较麻烦 当客户端在1秒后没收到服务端的SYN-ACK报文后，客户端就会重发SYN报文，那到底重发几次呢？ 在 Linux 里，客户端的SYN报文最大重传次数由tcp_syn_retries(客户端SYN包的重试次数)内核参数控制这个参数是可以自定义的，默认值一般是6，可以通过命令进行查看cat /proc/sys/net/ipv4/tcp_syn_retries 通常，第一次超时重传是在1秒后，第二次超时重传是在2秒后，第三次超时重传是在4秒后，第四次超时重传是在8秒后 每次超时的时间是上一次的2倍 当第五次超时重传后，会继续等待32秒，如果服务端仍然没有回应ACK，客户端就不再发送SYN包，然后断开TCP连接所以，总耗时是 1+2+4+8+16+32=63 秒，大约1分钟左右 2.第二次握手失败，会发生什么？
当服务端收到客户端的第一次握手后，就会回SYN-ACK报文给客户端，此时服务端会进入SYN_RCVD状态
第二次握手的SYN-ACK报文其实有两个目的
第二次握手里的ACK，是对第一次握手的确认报文第二次握手里的SYN，是服务端发起建立TC 连接的报文所以，如果第二次握手丢了，就会发生比较有意思的事情，具体会怎么样呢？
因为第二次握手报文里是包含对客户端的第一次握手的ACK确认报文，所以，如果客户端迟迟没有收到第二次握手，那么客户端就觉得可能自己的SYN报文(第一次握手)丢失了，于是客户端就会触发超时重传机制，重传SYN报文然后，因为第二次握手中包含服务端的SYN报文，所以当客户端收到后，需要给服务端发送 ACK确认报文(第三次握手)，服务端才会认为该SYN报文被客户端收到了 如果第二次握手丢失了，服务端就收不到第三次握手，于是服务端这边会触发超时重传机制，重传SYN-ACK报文在 Linux 下，SYN-ACK报文的最大重传次数由tcp_synack_retries**(**服务端SYN+ACK包的重试次数)内核参数决定，默认值是 5，可以通过命令进行查看cat /proc/sys/net/ipv4/tcp_synack_retries
因此，当第二次握手丢失了，客户端和服务端都会重传
客户端会重传SYN报文，也就是第一次握手，最大重传次数由tcp_syn_retries内核参数决定服务端会重传SYN-ACK报文，也就是第二次握手，最大重传次数由tcp_synack_retries内核参数决定3.第三次握手失败，会发生什么？
客户端收到服务端的SYN-ACK报文后，就会给服务端回一个ACK报文，此时客户端状态进入到ESTABLISH状态因为这个第三次握手的ACK是对第二次握手的SYN的确认报文，所以当第三次握手丢失了，如果服务端那一方迟迟收不到这个确认报文，就会触发超时重传机制，重传SYN-ACK报文，直到收到第三次握手，或者达到最大重传次数注意：ACK报文是不会有重传的，当ACK丢失了，应该由服务端重传SYN+ACK4.TCP连接断开
1.四次挥手全过程
客户端打算关闭连接，此时会发送一个FIN报文，之后客户端进入FIN_WAIT_1状态服务端收到FIN报文后，就会向客户端回一个ACK应答报文，然后服务端进入CLOSED_WAIT状态客户端收到服务端的ACK应答报文后，之后进入FIN_WAIT_2状态等待服务端处理完数据后，也向客户端发送FIN报文，之后服务端进入LAST_ACK状态客户端收到服务端的FIN报文后，回一个ACK应答报文，之后进入TIME_WAIT状态服务器收到了ACK应答报文后，就进入了CLOSED状态，至此服务端已经完成连接的关闭客户端在经过2MSL一段时间后，自动进入CLOSED状态，至此客户端也完成连接的关闭注意：主动关闭连接的，才有TIME_WAIT状态**
2.为什么要四次挥手
首先，断开连接是客户端和服务端协商的一个过程客户端发送FIN报文，想要告诉服务端，我没有任何数据需要请求了，我想和你断开连接 这里表明客户端不会再给服务端发送数据，但是还可以接受数据 而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送FIN报文给客户端来表示同意现在关闭连接从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的ACK和FIN一般都会分开发送，从而比三次握手导致多了一次前两次握手是客户端请求断开连接的，后两次握手是服务器请求断开连接的，因此4次挥手是协商次数最少的5.四次挥手失败，会发生什么？
1.第一次挥手失败，会发生什么？
当客户端调用close函数后，就会向服务端发送FIN报文，试图与服务端断开连接，此时客户端的连接进入到FIN_WAIT_1状态正常情况下，如果能及时收到服务端的ACK，则会很快变为FIN_WAIT_2状态如果第一次挥手丢失了，那么客户端迟迟收不到被动方的ACK的话，也就会触发超时重传机制，重传FIN报文 重发次数由tcp_orphan_retries参数控制，默认值是0，特指8次 当客户端重传FIN报文的次数超过tcp_orphan_retries后，就不再发送FIN报文，直接进入到close状态2.第二次挥手失败，会发生什么？
当服务端收到客户端的第一次挥手后，就会先回一个ACK确认报文，此时服务端的连接进入到CLOSE_WAIT状态在前面也提到了，ACK报文是不会重传的，所以如果服务端的第二次挥手丢失了，客户端就会触发超时重传机制，重传FIN报文，直到收到服务端的第二次挥手，或者达到最大的重传次数这里提一下，当客户端收到第二次挥手，也就是收到服务端发送的ACK报文后，客户端就会处于FIN_WAIT_2状态，在这个状态需要等服务端发送第三次挥手，也就是服务端的FIN报文对于close函数关闭的连接，由于无法再发送和接收数据，所以FIN_WAIT_2状态不可以持续太久，而tcp_fin_timeout控制了这个状态下连接的持续时长，默认值是60秒 这意味着对于调用close关闭的连接，如果在60秒后还没有收到FIN报文，客户端的连接就会直接关闭3.第三次挥手失败，会发生什么？
当服务端收到客户端的FIN报文后，内核会自动回复ACK，同时连接处于CLOSE_WAIT状态，顾名思义，它表示等待应用进程调用close函数关闭连接此时，内核是没有权利替代进程关闭连接的，必须由进程主动调用close函数来触发服务端发送FIN报文服务端处于CLOSE_WAIT状态时，调用了close函数，内核就会发出FIN报文，同时连接进入LAST_ACK状态，等待客户端返回ACK来确认连接关闭如果迟迟收不到这个ACK，服务端就会重发FIN报文，重发次数仍然由tcp_orphan_retries参数控制，这与客户端重发FIN报文的重传次数控制方式是一样的4.第四次挥手失败，会发生什么？
当客户端收到服务端的第三次挥手的FIN报文后，就会回ACK报文，此时客户端连接进入TIME_WAIT状态 在Linux系统，TIME_WAIT状态会持续2MSL后才会进入关闭状态 然后，服务端没有收到ACK报文前，还是处于LAST_ACK状态如果第四次挥手的ACK报文没有到达服务端，服务端就会重发FIN报文，重发次数仍然由前面介绍过的tcp_orphan_retries参数控制6.TIME_WAIT状态
0.问题抛出
若启动Server后，Ctrl+C终止Server，再马上运行Server，会有以下报错bind error：Address already in use
TCP协议规定，主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL的时间后才能回到CLOSED状态
使用Ctrl-C终止了Server，所以Server是主动关闭连接的一方，在TIME_WAIT期间仍然不能再次监听同样的Server端口1.为什么TIME_WAIT等待的时间是2MSL？
MSL是Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃TIME_WAIT等待2倍的MSL，比较合理的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待2倍的时间 比如：如果被动关闭方没有收到断开连接的最后的ACK报文，就会触发超时重发FIN报文，另一方接收到FIN后，会重发ACK给被动关闭方， 一来一去正好2个MSL 可以看到2MSL时长，这其实是相当于至少允许报文丢失一次 比如：若ACK在一个MSL内丢失，这样被动方重发的FIN会在第2个MSL内到达，TIME_WAIT状态的连接可以应对 为什么不是4或者8MSL的时长呢？ 可以想象一个丢包率达到百分之一的糟糕网络，连续两次丢包的概率只有万分之一，这个概率实在是太小了，忽略它比解决它更具性价比 2MSL的时间是从客户端接收到FIN后发送ACK开始计时的 如果在TIME-WAIT时间内，因为客户端的ACK没有传输到服务端，客户端又接收到了服务端重发的FIN报文，那么2MSL时间将重新计时 在 Linux系统里2MSL默认是60秒，那么一个MSL也就是30秒。Linux系统停留在TIME_WAIT的时间为固定的60秒2.为什么需要TIME_WAIT状态
主动发起断开连接的一方才会有TIME_WAIT状态，它是四次挥手的最后一个状态
它的出现，就是为了解决网络的丢包和网络不稳定所带来的其他问题需要TIME_WAIT状态有以下两个原因
防止历史连接中因网络延迟的数据包或者丢失重传的数据包，被新的连接(与历史连接的端口号相同)复用保证被动关闭连接的一方，能够正确关闭防止历史连接中因网络延迟的数据包或者丢失重传的数据包，被新的连接(与历史连接的端口号相同)复用
服务端向客户端发送了 Seq=300的报文和Seq=301的报文，因为是处于连接状态的，此次报文必然是夹带着数据的，由于网络原因，导致Seq=301的报文阻塞在网络中紧接着，服务端以相同的四元组重新打开了新连接，前面被延迟的Seq=301这时抵达了客户端，而且该数据报文的序列号刚好在客户端接收窗口内，因此客户端会正常接收这个数据报文，但是这个数据报文是上一个连接残留下来的，这样就产生数据错乱等严重的问题为了防止历史连接中的数据，被后面相同四元组的连接错误的接收，因此TCP设计了TIME_WAIT状态，状态会持续2MSL时长，这个时间足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的
确保连接方能在时间范围内，关闭自己的连接
客户端在进行四次挥手后进TIME_WAIT状态，如果第四次挥手的报文丢包了，客户端在一段时间内仍然能够接收服务器重发的FIN报文并对其进行响应，能够较大概率保证最后一个ACK被服务器收到3.解决TIME_WAIT状态引起的bind失败
在Server的TCP连接没有完全断开之前不允许重新监听，某些情况下可能是不合理的 服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短，但是每秒都有很大数量的客户端来请求) 这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃，就需要被服务器端主动清理掉)，就会产生大量TIME_WAIT连接由于请求量很大，就可能导致TIME_WAIT的连接数很多，每个连接都会占用一个通信五元组(源ip，源端口，目的ip，目的端口，协议) 其中服务器的ip和端口和协议是固定的，如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了，就会出现问题 使用**setsockopt()设置socket描述符的选项SO_REUSEADDR为1**，表示允许创建端口号相同但IP地址不同的多个socket描述符int opt = 1;setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
