对于TCP三次握手和四次挥手大多数读者想必已经烂熟于心;但是对于TCP三次握手和四次挥手之间可能出现的问题;很多时候我们并没有给予细致的关注;笔者依然如此;因而想借周末的晚上;对相关问题进行一番整理
先放一张TCP三次握手的图
再放一张TCP四次挥手的图
现象;TCP在握手/挥手阶段发出的消息在数据传播的过程中丢失
解决原则;ACK不会重传;SYN和FIN报文段有最大重传次数。无论是SYN还是FIN;达到最大重传次数后对端若仍无响应则直接进入CLOSED状态。
正常;当客户端想要与服务器建立TCP连接时;首先要发送第一个SYN报文段;然后将本端的TCP状态置为 SYN_SENT。
异常;客户端没有收到服务端的ACK确认回应;接下来便会进入超时重传阶段
超时时间判断; 不同版本的操作系统可能超时时间不同;一般为 1秒 或 3秒;由内核配置;修改需要重新编译内核。
重传次数; 由内核参数 tcp_syn_retries 配置;默认值为5;可手动修改。
重传周期; 按指数退避计算重传周期;第一次超时重传是 1秒;第二次超时重传是 2秒;第三次超时重传是 4秒;第四次超时重传是 8秒;第五次超时重传是 16秒;以类类推;直到达到最大重传次数后;客户端不再重传SYN报文段;断开TCP连接。 此时 connect会返回 -1;并设置 errno 为 ETIMEOUT。
如果达到默认最大重传次数后断开TCP连接;总耗时为;
1;2;4;8;16;32 = 63秒;大约 1分钟。
关于TCP内核参数的修改;
所有TCP/IP参数;注意是TCP/IP协议族的所有参数;不止TCP参数;都位于 /proc/sys/net目录下;注意此目录下的内容修改都是临时的;任何修改在系统重启后都会丢失。
例如对 tcp_syn_retries 参数的修改;
echo 5 > /proc/sys/net/ipv4/syn_timeout_retries
正常;服务端在收到客户端的第一次握手SYN报文段后;将TCP状态置为 SYN_RECV状态;并发送SYN;ACK报文段给客户端。
异常;如果第二次握手的报文段丢失;服务端会发起重传;客户端由于收不到SYN;ACK;无法判断是第一次握手的SYN报文段丢失;还是第二次握手的SYN;ACK报文段丢失;所以客户端也会发起重传。
这一情况可能会导致客户端和服务端一起发生重传;重传过程如第一部分所述;服务端的 SYN;ACK重传次数由参数 tcp_synack_retries 配置。
正常;客户端在收到服务端的第二次握手SYN;ACK报文段后;将TCP状态置为 ESTABLISH 状态;并发送ACK报文段给服务端。
异常;如果第三次握手的ACK报文段丢失;则服务会重传SYN;ACK报文段;直到收到ACK响应或者达到最大重传次数。
第三次握手的ACK报文段没有重传;当ACK丢失;只能依靠服务端重传SYN;ACK报文段。
如果握手阶段ACK持续丢失;那么对于服务端来说会发生以下情况;
超过服务端最大回传次数;放弃此次连接;服务端状态充值对于客户端来说;会发生以下两种情况
未发送数据;等到一定时间后;客户端会检查连接状态;发现检查失败;那状态重置;将连接从半连接状态中移除发送数据;得不到服务端的回应;然后发现连接失败;那状态重置我们知道;对于客户端和服务端之间的连接;其实存在半连接队列和全连接队列;
服务端收到客户端发送的第一次握手syn标志位;该连接进入半连接队列服务端收到客户端发送的第三次握手ack标志位;该连接进入全连接队列那从半连接到全连接之间的转化;其实并不一定成功;可能存在如下问题
服务端的全连接队列默认设置大小为50;而当client端发送ack;服务端收到时;服务端会如何处置;会根据服务端配置的tcp_abort_on_Overflow进行判断;具体会发生如下场景
syn洪泛攻击是Dos攻击的一种;服务器端的资源分配是在二次握手时分配的;而客户端的资源是在完成三次握手时分配的;所以服务器容易受到SYN洪泛攻击;SYN攻击就是Client在短时间内伪造大量不存在的IP地址;并向Server不断地发送SYN包;Server则回复SYN;ACK确认包;并等待Client确认回复ACK,而这些大量的IP是不存在的;并不会向服务端发送ack确认包;所以会大量的占领半连接队列资源;导致正常的SYN请求因为队列满而被丢弃;从而引起网络拥塞甚至系统瘫痪。
具体如图
使用syn cookie解决;服务器在第二次握手时不会为第一次握手的SYN创建半开连接;而是生成一个cookie一起发送给客户端;只有客户端在第三次握手发送ACK报文并且验证cookie成功服务器才会创建TCP连接;分配资源。
