服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

澄清有关Linux TCP窗口大小和延迟

通过TCP通道发送数据时,我遇到了延迟,我无法理解。 链路是1Gb链路,端到端延迟大约为40ms。 在我目前的设置中,等待时间(从发送者用户空间到接收者用户空间的一条消息的时间)可以达到100ms。 发件人套接字使用TCP_NODELAY选项进行configuration。 发送缓冲区(SO_SNDBUF)被configuration为8MB。 接收缓冲区(SO_RCVBUF)也被configuration为8MB。 TCP窗口缩放被激活。 update-1 :我使用zeromq 3.1.1中间件来传输数据。 套接字configuration,包括TCP_NODELAY标志由中间件执行。 有些选项可以像rx和tx一样发送缓冲区大小而不是TCP_NODELAY。 据我所知,TCP_NODELAY被激活,以确保数据被发送尽可能。 同时,实际的套接字发送和发送消息的决定是在两个独立的线程中执行的。 如果批量中的第一条消息发送时有多条消息可用,则进行正确的批处理。 我用tcpdump从下面的帧中提取了一个捕获。 初始TCP握手后,发送方(172.17.152.124)开始发送数据。 初始窗口大小为接收方为5840字节,发送方为5792字节。 我的问题是,发送者发送两个帧(#6和#7),然后停下来,等待一个确认从接收器回来。 据我所知,接收器的窗口大小没有达到,传输不应停止(384字节未完成,初始接收窗口大小为5840字节)。 我开始认为我没有正确理解TCP是什么。 有人可以帮助澄清? 更新-2 :我的数据有效载荷由一个幻数和一个时间戳组成。 我通过比较有效负载的时间戳和tcpdump的时间戳,隔离了延迟的数据包。 帧#9的有效载荷ts非常接近帧#6和#7,并且明显小于帧#8中接收到的应答的时间戳。 update-1 :帧#9不立即发送的事实可以通过TCP通道的慢启动来解释。 事实上,一旦连接运行了几分钟,问题也会出现,所以慢启动似乎不是一般的解释。 20:53:26.017415 IP 172.17.60.9.39943> 172.17.152.124.56001:标志[S],seq 2473022771,win 5840,选项[mss 1460,sackOK,TS val 4219180820 ecr 0,nop,wscale 8],长度为0 20:53:26.017423 IP 172.17.152.124.56001> 172.17.60.9.39943:Flags [S.],seq 2948065596,ack 2473022772,win 5792,options [mss 1460,sackOK,TS val 186598852 ecr 219180820,nop,wscale […]