SYN_SENT 连接堆积 10-20 秒

Question 1

编辑：起初我以为这是你打开了多少个浏览器选项卡的功能，因此你的 TCP/IP 堆栈会“正常”运行 - 新 TCP 连接的速率限制（以及可用的临时端口耗尽）。但我重新阅读了你的原始帖子，发现你说 SYN_SENT 连接正在堆积。这意味着你的机器确实在同时创建大量连接。我将保留我原始答案的旧文本（如果不是因为我花了几个小时研究它，而且它非常有趣），但我只是想在开头添加此编辑以避免读者失望。我帖子的结尾介绍了路由器限制，我怀疑这就是问题所在。你可以在不同的互联网连接上尝试相同的测试（例如，使用 iPhone 的个人热点的 3G）。

原始帖子...

我刚刚做了一个实验 - 我使用 Chrome 的开发者工具窗口来监控页面加载，同时加载 www.ft.com。然后，我浏览了开发者工具窗口“网络”选项卡上的每一行，并手动复制了加载 www.ft.com 主页时访问的每个唯一主机/服务器。总共访问了 71 个唯一服务器：

ft.com
s1.ft-static.com
navigation.webservices.ft.com
s4.media.ft.com
s2.ft-static.com
im.ft-static.com
www.googleadservices.com
www.ft-static.com
amch.questionmarket.com
reg.ft-static.com
service.maxymiser.net
personalisation.ft.com
pong.qubitproducts.com
track.ft.com
stats.ft.com
www.googletagservices.com
js.revsci.net
cdn.krxd.net
partner.googleadservices.com
admin.brightcove.com
mostpopular.sp.ft-static.com
googleads.g.doubleclick.net
fastft.ftdata.co.uk
widget-cdn.rpxnow.com
static.chartbeat.com
pubads.g.doubleclick.net
www.google.com
4235225.fls.doubleclick.net
ads.rubiconproject.com
ping.chartbeat.net
pagead2.googlesyndication.com
c.brightcove.com
ads.revsci.net
media.ft.com
pix04.revsci.net
beacon.krxd.net
secure.fastclick.net
leadback.advertising.com
ib.adnxs.com
api.adsymptotic.com
optimized-by.rubiconproject.com
cdn.quilt.janrain.com
s1.test.ft-static.com
www.facebook.com
b.scorecardresearch.com
tap2-cdn.rubiconproject.com
b.scorecardresearch.com
im.test.ft-static.com
clamo.ftdata.co.uk
assets.rubiconproject.com
tap.rubiconproject.com
x.bidswitch.net
rp.gwallet.com
rc.d.chango.com
i.w55c.net
tags.bluekai.com
rbp.mxptint.net
ads.p161.net
magnetic.t.domdex.com
ads.mediade.sk
ad.turn.com
video.ft.com
pool.adizio.com
cdn.trn.com
p.brilig.com
s.ixiaa.com
api.bizographics.com
metrics.brightcove.com
goku.brightcove.com
www.google-analytics.com
brightcove.vo.llnwd.net

但情况更糟！请注意，许多主机都被多次访问，但我们假设 Web 浏览器（或操作系统）足够智能，可以将 TCP 连接保持打开状态几秒钟并重新使用它们。使用lsof -n -p 8420 | grep -c "IPv4"（Chrome 使用的是 PID 8420，而我在 Chrome 中没有打开其他页面；我事先完全清除了缓存并禁用了 AdBlock 等）。在重新加载页面时，我只是lsof反复向上箭头命令，上面的管道grep会给我一个计数，即：

$ lsof -n -p 8420 | grep -c "IPv4"
42
$ lsof -n -p 8420 | grep -c "IPv4"
64
$ lsof -n -p 8420 | grep -c "IPv4"
75
$ lsof -n -p 8420 | grep -c "IPv4"
85
$ lsof -n -p 8420 | grep -c "IPv4"
111
$ lsof -n -p 8420 | grep -c "IPv4"
129
$ lsof -n -p 8420 | grep -c "IPv4"
127
$ lsof -n -p 8420 | grep -c "IPv4"
128
$ lsof -n -p 8420 | grep -c "IPv4"
129
$ lsof -n -p 8420 | grep -c "IPv4"
128
$ lsof -n -p 8420 | grep -c "IPv4"
128
$

如您所见，加载单个网页导致 TCP 连接达到峰值 129 个。无论它们是处于 ESTABLISHED 还是某种关闭状态（如 CLOSE_WAIT）都无关紧要 - 这些源端口此时无法使用，并且（默认情况下）需要 60-480 秒才能返回到池中（RFC793 最初指定 MSL（最大段寿命）为 4 分钟，但我认为现在默认为 60-120 秒）。在 Windows XP 和 Vista 中，只有几千个临时端口可用（默认情况下），因此如您所见，您的机器很容易用完可用端口。 *重要的是要注意，正如您从第一次lsof执行中看到的那样，我的系统已经打开了 42 个连接，因此此网页导致打开了 87 个新连接。我运行了几次以确保其他应用程序（电子邮件客户端等）在测试期间不会暂时增加这些数字。

还有其他限制 - 我只能在这里谈论 Linux，因为我没有时间在 Windows 上研究这个问题（我已经花了几个小时研究这个问题，而且我需要吃饭！）... 但在 Linux（和 OSX）中，文件描述符的最大数量是有限制的每进程，并且该限制在几个地方设置。限制为 256。请记住，有些 Web 浏览器每个选项卡启动一个进程，所以我不确定您是否会遇到此问题，但更改限制并重新测试会很容易。在 Google 上搜索“ulimit max file descriptors”和“launchctl maxfiles”，以找到设置它的两个地方。另请参阅此 Stackoverflow 帖子。

从我使用 OSX 之前就知道，Windows XP 对新 TCP 连接的创建有速率限制。这是通过限制蠕虫创建新 TCP 连接的速度来减少 Sasser 等蠕虫的传播，但也是为了防止操作系统资源被耗尽 - 每个新的 TCP 连接都需要资源，这些资源通常由操作系统在启动期间预先分配（每次打开/关闭 TCP 连接时分配/销毁缓冲区会花费更长时间，因此操作系统会提前创建连接表）。如果您查看 Torrent 客户端（例如 Transmission）的配置页面，它们对新 TCP 连接的默认全局限制为 120，每个 torrent 的限制为 60。他们的用户手册建议坚持使用 120，而且我发现如果我将其设置为 200-240，我的网页浏览性能就会大幅下降。TCP MSL 真正限制了这里的情况 - TCP 端口返回TIME_WAIT池所需的时间。

我的直觉告诉我，您受到的限制是，每个浏览器选项卡都会创建大量新的 TCP 连接，而通过一次加载 15 个选项卡，您要求操作系统同时打开大量 TCP 连接。当您重新运行测试时，请确保在测试运行之间等待至少 4 分钟，然后使用netstat -n -p tcp（在 Windows 中只需使用netstat -no）。如果您使用的是 *nix，请lsof -n -i | grep -c事先使用以查看您的计算机已打开了多少个连接。

最后...检查您的路由器/网关。我以前见过很多基于 BusyBox 的 ADSL 路由器，其最大并发 TCP 连接数限制为 1024（在任何状态下，即 established、close_wait 等）。一个运行 P2P 下载的客户端足以使路由器完全停止运行 - 症状与您描述的完全一样，但即使您只尝试加载一个网页。1024 个连接可能在几分钟内被 p2p 吞噬，因为您所要做的就是在 4 分钟内打开和关闭 1024 个连接，并且不允许建立任何新连接。常见的抱怨是“当我运行 eMule 时，即使下载速度限制很慢，我家里的每个人都抱怨互联网几乎无法使用”。家庭互联网路由器之所以关心 TCP 连接，是因为它们几乎总是运行 NAT/PAT，并且通常具有状态/SPI 防火墙 - 两者都需要跟踪所有连接。话虽如此，过去几年制造的路由器应该能更好地处理这个问题。

希望有所帮助。

Answer