Closed draveness closed 2 years ago
文章写的不错。
4.x后移除的tcp_tw_recycle是依赖timestamp配置,timestamp在nat下有包混乱的问题。
“但是如果主机在过去一分钟时间内创建的 TCP 连接数超过 28,232,那么再创建新的 TCP 连接就会发生错误”。
这里28,232应该是不准确的吧, 有这么多端口号可用不代表只能创建这么多个TCP连接, 因为对于一个端口号可以和不同的远端建立不同的TCP连接, 一个TCP连接是由源地址、源端口、目的地址以及目的端口来唯一确定的。 这里能打开的连接数更可能是受限于服务器上对同时打开的文件描述符数目的限制。
“但是如果主机在过去一分钟时间内创建的 TCP 连接数超过 28,232,那么再创建新的 TCP 连接就会发生错误”。
这里28,232应该是不准确的吧, 有这么多端口号可用不代表只能创建这么多个TCP连接, 因为对于一个端口号可以和不同的远端建立不同的TCP连接, 一个TCP连接是由源地址、源端口、目的地址以及目的端口来唯一确定的。 这里能打开的连接数更可能是受限于服务器上对同时打开的文件描述符数目的限制。
你说的对,我来重新表述一下
请问客户端在发送第一个FIN之后,服务器为什么不将ACK和FIN一起发送回客户端(就像三次握手那样),而是将ACK和FIN分别发送呢?
请问客户端在发送第一个FIN之后,服务器为什么不将ACK和FIN一起发送回客户端(就像三次握手那样),而是将ACK和FIN分别发送呢?
因为服务端在收到 FIN 时,可能还有数据要发送给客户端,FIN 意味着本端没有待发送的数据了。
每秒最大连接数470计算,其实有前提的,连接处理时间得在接近60s的情况下。当然一般情况是几乎不可能了。
@wolf-joe 请问客户端在发送第一个FIN之后,服务器为什么不将ACK和FIN一起发送回客户端(就像三次握手那样),而是将ACK和FIN分别发送呢?
这很容易理解,服务器收到fin后,要回复客户端“我收到了”,要不然客户端以为服务端没收到,就会重发,但是服务端自己本身可能还有数据没发送完成,等自身的数据发送完成后,再向客户端发送close请求。
TCP这块最重要的应该属滑动窗口吧,期待老哥能写个文章讲一讲。
作者方便加个微信吗?看了你好多文章,尤其是go源码的。加个微信一起讨论
可是为什么是2msl啊
https://draveness.me/whys-the-design-tcp-time-wait
在这个系列前面的文章中,我们已经多次讨论 TCP 协议的设计原理,其中包括 TCP 协议的三次握手、流量控制和重传机制、最大数据段以及粘包等问题。本文将继续分析 TCP 协议的实现细节,今天要分析的问题是为什么 TCP 协议需要 TIME_WAIT 状态以及该状态的作用究竟是什么。TIME_WAIT 仅在主动断开连接的一方出现,被动断开连接的一方会直接进入 CLOSED 状态,进入 TIME_WAIT 的客户端需要等待 2 MSL 才可以真正关闭连接。