标签: tcp

许多管理员一直在坚持——在 ServerFault 和其他地方——TCP-over-TCP 的想法有多糟糕，例如在 VPN 中。如果不是 TCP 崩溃，即使是最轻微的数据包丢失也会使一个人遭受至少严重的吞吐量下降，因此应严格避免 TCP-over-TCP。这可能曾经是真的，例如 2001年写这篇文章时仍然被引用。

但从那时起，我们看到了技术和协议的重大进步。现在我们几乎在所有地方都实现了“选择性 ACK”，摩尔定律给了我们更多的内存，随之而来的是针对 Gbit 上行链路优化的大型 TCP 缓冲区。如今，在非无线电链路上，数据包丢失的问题要少得多。所有这些都应该显着缓解 TCP-over-TCP 问题，不是吗？

请注意，在现实世界中，例如基于 TCP 的 VPN 比基于 UDP/ESP 的 VPN 更容易实现和操作（参见下文）。因此我的问题：

在什么情况下（链路数据包丢失和延迟），TCP-over-TCP 的性能比单独的 TCP 差得多，假设两端都有 SACK 支持和大小合适的 TCP 缓冲区？

看到一些显示（外部连接）数据包丢失/延迟和（内部连接）吞吐量/抖动之间的相关性的测量结果会很棒——对于 TCP-over-TCP，以及单独的 TCP。我发现了这篇有趣的文章，但它似乎只关心延迟，而不是解决（外部）数据包丢失问题。

另外：是否有推荐的设置（例如 TCP 选项、缓冲区设置、减少 MTU/MSS 等）来缩小 TCP 和 TCP-over-TCP 之间的性能差距？

更新：我们的理由。

这个问题在一些现实世界的场景中仍然非常相关。例如，我们在大型建筑物中部署嵌入式设备，收集传感器数据并通过 VPN 将其输入我们的平台。我们面临的问题是我们无法控制的防火墙和不正确配置的上行链路，以及不情愿的 IT 部门。请参阅此处讨论的详细示例。

在很多这样的情况下，从非 TCP 切换到基于 TCP 的 VPN（如果你像我们一样使用 OpenVPN 就很容易）是一个快速解决方案，它使我们能够避免上坡的相互指责。例如，通常 TCP 端口 443 通常是允许的（至少通过代理），或者我们可以通过简单地减少 TCP 的 MSS 选项来克服 Path-MTU 问题。

最好知道在什么情况下可以将基于 TCP 的 …

我想，以确定其中的连接使用特定的TCP端口的外部主机被阻止。Traceroute for Windows 只使用 ICMP，而 telnet 只会告诉我端口被阻塞而不是在哪里。有谁知道类似于 traceroute 的 Windows 实用程序可以实现这一点？

你好服务器故障的居民

我有一个大约 100 台计算机、2 个 Windows 域服务器和 12 部 VoIP 电话的 LAN 的恼人问题。自从他们大约一年前安装以来，每周左右，我们都会注意到 VoIP 电话会自行重置 - 偶尔在通话过程中。同时，经常会出现计算机连接暂时中断的迹象：访问网络共享时资源管理器冻结，由于与数据库服务器的连接中断导致我们的管理软件出错。

我一直在对 VoIP PBX 和网络其余部分之间的连接进行一些 Wireshark 监控。当我们记录电话重启时，Wireshark 会收集到一堆重新传输的 TCP 数据包。Wireshark 日志显示每天大约有 2 个重传集群，范围从 5 个数据包到数百个。每个集群中的那些主要在 PBX 和一些 VoIP 电话之间，但并不总是同一组。通常同时重传是针对连接到同一交换机的电话，但有时重传会同时发生在网络两端的电话上。在传递 TCP 流量时通常会有一些重传，例如在客户端机器和文件服务器之间。

重传和电话重置的尖峰与网络负载过重的时间没有很好的相关性。它们似乎在白天发生得稍微多一些，但大多数发生在晚上，此时交通应该会减少。当大多数计算机关闭并且流量应该最低时，它们经常发生在深夜。

您有什么想法可以帮助诊断此类问题的原因吗？我还没有尝试过但应该尝试的一件事是更新所有交换机的固件。

在这个问题的末尾添加了新的细节；我可能正在关注原因。

我有一个基于 UDP OpenVPN 的 VPN 设置tap模式（我需要，tap因为我需要 VPN 来传递多播数据包，这在tun网络中似乎是不可能的）与互联网上的少数客户端。我在 VPN 上经常遇到 TCP 连接冻结的情况。也就是说，我将建立一个 TCP 连接（例如一个 SSH 连接，但其他协议也有类似的问题），并且在会话期间的某个时刻，流量似乎将停止通过该 TCP 会话传输。

这似乎与发生大数据传输的点有关，例如我是否ls在 SSH 会话中执行命令，或者我是否cat是一个长日志文件。一些 Google 搜索在 Server Fault上找到了许多类似上一个这样的答案，表明可能的罪魁祸首是 MTU 问题：在高流量期间，VPN 试图发送数据包，这些数据包在两个管道之间的某处被丢弃VPN 端点。上面链接的答案建议使用以下 OpenVPN 配置设置来缓解问题：

fragment 1400
mssfix

这应该将 VPN 上使用的 MTU 限制为 1400 字节，并修复 TCP 最大段大小以防止生成任何大于该值的数据包。这似乎稍微缓解了这个问题，但我仍然经常看到冻结。我尝试了许多大小作为fragment指令的参数：1200、1000、576，所有结果都相似。我想不出两端之间有什么奇怪的网络拓扑结构会引发这样的问题：VPN 服务器运行在直接连接到 Internet的pfSense机器上，而我的客户端也在另一个位置直接连接到 Internet。

另一个奇怪的难题：如果我运行该tracepath实用程序，那么这似乎可以解决问题。示例运行如下所示：

[~]$ tracepath -n 192.168.100.91
 1:  192.168.100.90                                        0.039ms pmtu 1500
 1:  192.168.100.91                                       40.823ms …

根据这里的表格，它说 MTU = 1500 字节，有效载荷部分是 1500 - 42 字节或 1458 字节（<- 这实际上是错误的！）。现在最重要的是您必须添加 IPv4 和 UDP 标头，它们是 28 个字节（20 个 IP + 8 个 UDP）。这使我的最大可能应用程序消息为 1430 字节！但是通过在互联网上查找这个数字，我看到的是 1472。我在这里计算错误吗？

我想知道的是我可以通过网络发送的最大应用程序消息，而不会产生碎片风险。它绝对不是 1500，因为它包括帧头。有人可以帮忙吗？

令人困惑的是 PAYLOAD 实际上可以大到 1500 字节，这就是 MTU。那么现在有效载荷为 1500 的线内尺寸是多少？从该表中，它可以大到 1542 字节。

所以我可以发送的最大应用程序消息是 1472 (1500 - 20 (ip) - 8 (udp)) 最大线径为 1542。当事情实际上很简单时，事情会变得如此复杂，这让我感到惊讶。而且我不知道如果表上写的是 1542，那么有人是如何想出数字 1518 的。

这看起来与这个有关，但又有些不同。

两个公司站点之间有这个 WAN 链接，我们需要传输一个非常大的文件（Oracle 转储，~160 GB）。

我们有完整的 100 Mbps 带宽（已测试），但由于 TCP 的工作方式（ACK 等），单个 TCP 连接似乎无法将其最大化。我们使用iperf测试了链接，当增加 TCP 窗口大小时，结果发生了显着变化：使用基本设置，我们可以获得 ~5 Mbps 的吞吐量，使用更大的 WS，我们可以获得 ~45 Mbps，但仅此而已。网络延迟约为 10 毫秒。

出于好奇，我们使用多个连接运行 iperf，我们发现，当运行四个连接时，它们确实每个都能达到约 25 Mbps 的速度，填满所有可用带宽；所以关键似乎在于运行多个同时传输。

使用 FTP，情况变得更糟：即使使用优化的 TCP 设置（高窗口大小、最大 MTU 等），我们在单次传输中也无法获得超过 20 Mbps 的速度。我们尝试同时 FTP 传输一些大文件，确实比传输单个文件要好得多；但后来罪魁祸首变成了磁盘 I/O，因为从同一个磁盘读取和写入四个大文件很快就会遇到瓶颈；此外，我们似乎无法将单个大文件拆分为较小的文件然后将其合并回来，至少不能在可接受的时间内（显然我们不能将拼接/合并回文件的时间与转让）。

这里理想的解决方案是一个多线程工具，可以同时传输文件的各个块；有点像 eMule 或 BitTorrent 等点对点程序已经这样做了，但是从单一来源到单一目的地。理想情况下，该工具将允许我们选择要使用的并行连接数，当然还可以优化磁盘 I/O，以免（太）在文件的各个部分之间疯狂跳转。

有谁知道这样的工具？

或者，有人可以提出更好的解决方案和/或我们已经没有尝试过的方法吗？

PS 我们已经考虑将其备份到磁带/磁盘并将其物理发送到目的地；如果 WAN 不切断它，那将是我们的极端措施，但是，正如 AS Tanenbaum 所说，“永远不要低估一辆装满磁带的旅行车在高速公路上疾驰的带宽。”

我有一个应用程序的文件描述符用完了，显然是通过打开套接字，但我无法确切地找出这些套接字的作用。这些出现在 lsof 输出中

java    9689 appuser 1010u  sock       0,5          263746675 can't identify protocol
java    9689 appuser 1011u  sock       0,5          263746676 can't identify protocol
java    9689 appuser 1012u  sock       0,5          263746677 can't identify protocol
java    9689 appuser 1014u  sock       0,5          263746678 can't identify protocol
java    9689 appuser 1015u  sock       0,5          263746679 can't identify protocol
java    9689 appuser 1016u  sock       0,5          263746681 can't identify protocol

并在 /proc/$PID/fd 中

lrwx------ 1 appuser appuser 64 Jun 23 11:49 990 -> socket:[263732085]
lrwx------ 1 appuser …

我正在尝试在基于 Debian 的路由器上调整 Snort 性能。我看到的是这样的东西：

snort packet recv contents failure: No buffer space available

所以我将缓冲区提高到 8M，当这不起作用时，我尝试了 16M，根据http://fasterdata.es.net/fasterdata/host-tuning/linux/ 上的调整指南：

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing. …

我们正在审查来自一些客户端机器的 Wireshark 捕获，这些机器显示多个重复的 ACK 记录，然后触发重新传输和失序数据包。

这些显示在以下屏幕截图中。.26 是客户端，.252 是服务器。

是什么导致重复的ACK记录？

如果有帮助，请提供更多背景信息：

我们正在调查某一特定客户站点的网络吞吐量问题。从用户界面的角度来看，感知到的问题是，尽管 1gbps WAN 连接未得到充分利用，但数据传输速度很慢。

几乎所有的客户端机器都有同样的问题，在 20 多台机器上测试过。我们确实找到了两台没有问题的机器。我们正在确定它们的配置有何不同。我们确实注意到，在没有问题的两台机器中，我们最多只看到一个重复的 ACK 记录。有问题的机器通常有三个重复的 ACK 记录。一个显着的区别是，运行良好的机器都属于网络运营团队的成员，而所有其他机器都是为“普通”员工使用的。这些机器应该是标准的，但网络管理员可以对他们的本地系统进行更改，这是我们正在研究的另一个方面。

我们尝试更改服务器上的TcpMaxDupAcks设置，但我们真正需要的值是 5，有效范围仅为 1-3。

服务器是 Windows Server 2003。客户端都是企业管理的 Windows XP。所有客户端，包括两个正在运行的客户端，都安装了赛门铁克防病毒软件。

这是数百个出现此问题的客户端站点中唯一的一个。

pathping 显示 56 毫秒 RTT 和一致的 0/100 数据包丢失，即使是来自问题机器。

谢谢，

山姆

从我们的纽约数据中心传输到更远的位置的性能很差。

使用速度测试来测试不同的位置，我们可以轻松地使我们的 100 兆比特上行链路饱和到波士顿和费城。当我使用速度测试定位在美国或欧洲的西海岸时，我经常看到只有大约 9 mbit/s。

我的第一反应是这是一个窗口缩放问题（Bandwidth Delay Product）。但是，我已经在西海岸的一台测试机上调整了 Linux 内核参数，并使用 iperf 使窗口大小足以支持每秒 100 兆字节，但速度仍然很慢（已在捕获中验证）。我也试过禁用 Nagle 算法。

我们在 Linux 和 Windows 上的性能都很差，但使用 Windows 的速度明显更差（1/3）。

转移的形状（没有Nagle）是：

10 秒左右的下降有大约 100 个重复的 ack。

接收器随时间变化的最小窗口大小的形状为：

关于下一步去哪里确定我们的瓶颈有什么想法吗？

一些速度测试结果（使用 speedtest.net 上传）：

• 费城：44 mbit（使用我们网站的人正在使用其余的 ;-)）
• 迈阿密：15 兆比特
• 达拉斯：14 兆位
• 圣何塞：9 兆位
• 柏林：5 兆比特
• 悉尼：2.9 兆比特

更多数据：
迈阿密：69.241.6.18

 2  stackoverflow-nyc-gw.peer1.net (64.34.41.57)  0.579 ms  0.588 ms  0.594 ms
 3  gig4-0.nyc-gsr-d.peer1.net (216.187.123.6)  0.562 ms  0.569 ms  0.565 ms
 4  xe-7-2-0.edge1.newyork1.level3.net (4.78.132.65)  0.634 ms  0.640 ms  0.637 ms
 5  vlan79.csw2.newyork1.level3.net (4.68.16.126) …