linux tcp三路握手详解

最新推荐文章于 2024-04-19 03:18:54 发布

我就没事闲溜溜

最新推荐文章于 2024-04-19 03:18:54 发布

阅读量1k

点赞数

分类专栏：网络文章标签： linux tcp 三路握手

本文链接：https://blog.csdn.net/maxlovezyy/article/details/70338456

版权

网络专栏收录该内容

6 篇文章 1 订阅

订阅专栏

转载请附本文链接：https://blog.csdn.net/maxlovezyy/article/details/70338456

可能很多人都觉得自己懂tcp的三路握手，他知道那么三下子如下图。
　　　　这里写图片描述
　　但我更想问，你知道这些有个卵用。。。能排查出连接问题吗？可能你觉得用wireshark啊，tcpdump啊抓包能分析，但是你不了解协议栈怎么实现的，是很难做到良好的分析的。本文就告诉你，到底握手的过程中协议栈是怎么一步步处理的。

协议栈处理过程

假设server的半连接和连接队列都是空的，过程如下。

client向server发送【SYN】，状态为【SYN SENT】

server收到client的【SYN】并回复【SYN+ACK】，这时候这个连接进入到server半连接队列，状态为【SYN RECEIVED】
client收到server 【SYN+ACK】，回发【ACK】，client端认为三路握手成功，状态为【ESTABLISHED】
server收到client的【ACK】，这时候这个连接就从server的半连接队列被转入已连接队列，server三路握手成功，状态为【ESTABLISHED】
server调用了accept，这时候连接就从已连接队列移除了。

这里就有几个问题了。比如server端已连接队列满了，server会怎么处理？半连接队列满了呢？又会怎么处理？以下就做一个说明。

如果已连接队列满了，协议栈就会概率性地丢弃收到的SYN包，而对于不决定丢弃留下的SYN包，会回复SYN/ACK，但是之后收到的client回复的ACK会被丢弃，就等于没有收到ACK，进而server会有机制重发SYN/ACK，之后client收到之后就会认为原来我之前发的ACK server没收到啊，继续就会重发ACK。server直至超时都没有完成握手就发送RST，但如果超时时间内已连接队列有空间了并且收到了client的重试的ACK，那么就三路握手成功了。
如果半连接队列满了呢？直接丢弃呗，还想啥。。
三路握手和accept没关系，握手纯属协议栈的事。
理论上只要server足够快地accept，那么backlog队列应该一直是"空"的，只有系统负载比较高的时候，才有必要用一个比较大的backlog值。
只有在服务器和客户端之间的RTT特别大的时候，半连接队列才容易满；否则一般就是被DDOS攻击了。

趣事

我之前做过这样的一个测试：server端listen(fd, 100)，client拿着blocking的fd无限地连接，统计connect返回的成功连接的个数。
　　这时候client发生了有趣的现象：前100多一点个连接一瞬间完成；之后统计的已连接数就开始慢慢悠悠的一个个增加。这是为什么呢？通过上面的陈述，你完全可以自己解决了。