Questions tagged «tcp»

如果一台计算机可以拥有的端口数量受到限制，并且套接字只能绑定到未使用的端口号，那么请求量非常大（超过最大端口号）的服务器如何处理呢？是否只是通过使系统分布式（即，多台机器上的许多服务器）来完成？

29 web-server  http  port  tcp  traffic-management 

Windows中默认的TCP连接超时是哪个？有用于配置它的注册表项，还是它是动态设置的？

28 windows  tcpip  tcp 

我想知道如何进行故障排除，为什么对Web服务器的curl请求不起作用。我并不是在寻求依赖于我的环境的帮助，我只是想知道如何收集有关通信的哪一部分发生故障，端口号等的信息。 chad-integration:~ # curl -v 111.222.159.30 * About to connect() to 111.222.159.30 port 80 (#0) * Trying 111.222.159.30... connected * Connected to 111.222.159.30 (111.222.159.30) port 80 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.19.0 (x86_64-suse-linux-gnu) libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libidn/1.10 > Host: 111.222.159.30 > Accept: */* > * Empty reply from …

27 tcp  curl 

许多管理员（在ServerFault和其他地方）一直保持不变，例如，在VPN中，TCP-over-TCP是多么糟糕的想法。即使不是TCP崩溃，即使是最轻微的数据包丢失也将使至少遭受严重的吞吐量下降，因此必须严格避免TCP-over-TCP。这可能曾经是真的，例如2001 年撰写本文时仍在引用。 但是从那以后，我们看到了技术和协议的重大进步。如今，几乎在所有地方都实现了“选择性ACK”，摩尔定律为我们提供了更多的存储空间，随之而来的是为千兆位上行链路优化的大型TCP缓冲区。如今，在非无线电链路上，数据包丢失也不再是问题。所有这些都可以大大缓解TCP-over-TCP问题，不是吗？ 请注意，在现实世界中，例如，基于TCP的VPN比基于UDP / ESP的VPN更易于实现和操作（请参阅下文）。因此我的问题是： 在什么情况下（链路数据包丢失和等待时间），TCP-over-TCP的性能要比单独的TCP差很多，假设SACK支持并且两端的TCP缓冲区大小合适。 太棒了，因此请查看一些测量结果，以显示（外部连接）数据包丢失/延迟与（内部连接）吞吐量/抖动之间的相关性-对于TCP-over-TCP和TCP / TCP。我找到了这篇有趣的文章，但它似乎只关心延迟，而不是解决（外部）数据包丢失。 另外：是否有建议的设置（例如TCP选项，缓冲区设置，减少MTU / MSS等）以缩小TCP和TCP-over-TCP之间的性能差距？ 更新：我们的理由。 在某些实际情况下，这个问题仍然非常重要。例如，我们在大型建筑物中部署嵌入式设备，这些设备收集传感器数据并将其通过VPN馈入我们的平台。我们面临的问题是防火墙和配置不当的上行链路（不受我们控制），加上IT部门的不情愿。请参阅此处讨论的详细示例。 在很多情况下，从非TCP切换到基于TCP的VPN（如果像我们这样使用OpenVPN则非常容易）是一种快速解决方案，可让我们规避艰难的指责之战。例如，通常通常允许使用TCP端口443（至少通过代理），或者我们可以通过简单地减少TCP的MSS选项来克服Path-MTU问题。 最好知道在什么情况下基于TCP的VPN可以被认为是可行的选择，因此我们可以做出明智的决定，胜过任何一种选择的利弊。例如，我们知道非无线链路上可以使用TCP-VPN，但是在3G上行链路上确实有相当一部分远程客户端，但丢包率很高且延迟很高-TCP-VPN在那里将如何执行？ 我试图相应地改善标题和核心问题。我希望这是有道理的。

25 networking  vpn  ip  tcp  network-protocols 

您好服务器故障的居民 我的局域网有大约100台计算机，2台Windows域服务器和12台VoIP电话，这令人烦恼。自从大约一年前安装它们以来，大约每周一次，我们注意到VoIP电话会自行重置-有时在通话过程中会重置。同时，经常有计算机暂时断开连接的迹象：访问网络共享时资源管理器中的冻结，由于与数据库服务器的连接断开而导致的管理软件错误。 我一直在对VoIP PBX与网络其余部分之间的连接进行Wireshark监视。当我们记录电话重启时，Wireshark会拾取大量重传的TCP数据包。Wireshark日志每天显示大约2个重传群集，范围从5个数据包到数百个。每个群集中的电话主要位于PBX和VoIP电话的某些组之间，但并不总是同一组。通常，同时重传是连接到同一交换机的电话，但是有时重传会一起发生在网络相对端的电话。在传递TCP通信时，通常会有一些重发，例如在客户端计算机和文件服务器之间。 重传和电话重置的峰值与网络负载较重时没有很好的关联。它们似乎在白天发生的次数略多，但在晚上的大部分时间（应减少流量）。它们通常在深夜发生，这时大多数计算机都已关闭，并且流量应该最低。 您有任何想法可以帮助诊断此类问题的原因吗？我尚未尝试但应该尝试的一件事是更新所有交换机的固件。

25 networking  tcp  voip 

很难说出这里的要求。这个问题是模棱两可，含糊，不完整，过于宽泛或夸张的，不能以目前的形式合理地回答。如需帮助澄清此问题以便可以重新打开， 请访问帮助中心。 6年前关闭。 我试图确定使用特定TCP端口到外部主机的连接在哪里被阻止。Windows的Traceroute仅使用ICMP，而telnet仅告诉我该端口被阻止，而不是在哪里。有谁知道一个类似于traceroute的Windows实用程序可以实现这一目标？

23 windows  networking  tcp  trace 

根据此处的表，它表示MTU = 1500字节，有效负载部分为1500-42字节或1458字节（<-这实际上是错误的！）。现在最重要的是，您必须添加IPv4和UDP标头，它们是28个字节（20 IP + 8 UDP）。这使我最大可能的应用程序消息为1430字节！但是通过在Internet上查找此数字，我看到的是1472。我在这里计算错误吗？ 我要查找的是我可以通过网络发送的最大应用程序消息，而不会出现碎片的风险。绝对不是1500，因为它包括帧头。有人可以帮忙吗？ 令人困惑的是，PAYLOAD实际上可能高达1500个字节，这就是MTU。那么，现在有效负载为1500的线径是多少？从该表中，它可以最大为1542字节。 因此，我可以发送的最大应用消息是1472（1500-20（ip）-8（udp）），最大电线尺寸为1542。这让我感到惊讶的是，当事情实际上很简单时，事情会变得如此复杂。而且我不知道如果桌子上写着1542，有人会怎么想出数字1518。

22 networking  tcp  ethernet  udp  mtu 

已锁定。已禁用对此问题的评论，但它仍在接受新的答案和其他交互方式。了解更多。 这看起来与这一个，但它是有所不同的。 两个公司站点之间存在此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不削减它，这将是我们的极端措施，但正如Tanenbaum所说，“永远不要低估充满胶带的旅行车的带宽。”

21 networking  bandwidth  tcp  file-transfer 

从我们的纽约数据中心传输到较远的位置的性能很差。 使用速度测试来测试各个位置，我们可以轻松地使到波士顿和费城的100 Mbps上行链路饱和。当我使用速度测试到美国或欧洲的西海岸进行定位时，我通常只会看到大约9 Mbps。 我的第一反应是这是一个窗口缩放问题（带宽延迟乘积）。但是，我已经在西海岸的一台测试机上调整了Linux内核参数，并使用iperf，使Window的大小足以支持每秒100 MB，但速度仍然很慢（已在Capture中验证）。我也尝试过禁用Nagle算法。 Linux和Windows的性能都差，但是使用Windows的速度却差得多（1/3）。 传输的形状（没有Nagle）为： 10秒钟左右的浸入有大约100个重复的插口。 接收器的最小窗口大小随时间变化的形状为： 有什么想法可以解决瓶颈吗？ 一些速度测试结果（使用speedtest.net上传）： 费城：44兆比特（使用我们网站的人正在使用其余的;-)） 迈阿密：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) …

19 networking  tcp 

我们正在审查来自几台客户端计算机的Wireshark捕获，这些计算机显示了多个重复的ACK记录，这些记录随后触发了重传和乱序数据包。 这些显示在以下屏幕截图中。.26是客户端，.252是服务器。 是什么导致重复的ACK记录？ 更多背景，如果有帮助的话： 我们正在调查一个特定客户端站点上的网络吞吐量问题。从用户界面的角度来看，人们意识到的问题是，尽管没有充分利用1gbps的WAN连接，数据仍在缓慢传输。 几乎所有客户端计算机都存在相同的问题，并在超过20台计算机上进行了测试。我们确实找到了两台没有问题的机器。我们正在确定其配置有何不同。我们确实注意到，在两台没有问题的机器中，我们最多只能看到一个重复的ACK记录。有问题的计算机通常具有三个重复的ACK记录。一个显着的区别是，运行良好的计算机全部属于网络运营团队的成员，而其他所有计算机则用于“正规”员工。这些机器应该是标准机器，但是网络管理员可以在其本地系统上进行更改，这是我们正在研究的另一方面。 我们尝试更改服务器上的TcpMaxDupAcks设置，但我们真正需要的值为5，有效范围仅为1-3。 服务器是Windows Server2003。客户端都是企业管理的Windows XP。所有客户端（包括两个正常运行的客户端）均已安装Symantec Anti-Virus。 这是数百个出现此问题的唯一客户端站点。 pathping 即使有问题的机器也显示出56ms的RTT和一致的0/100数据包丢失。 谢谢， 山姆

19 windows-server-2003  windows-xp  tcp  wireshark 

我有一个应用程序快要用完文件描述符了，显然是通过打开套接字来实现的，但是我无法确切地找到这些套接字的作用。这些在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 …

19 linux  networking  tcp  udp  socket 

在此问题末尾添加了新的详细信息；我有可能正在调查原因。 我在Internet上与少数客户端建立了一个基于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 reached 1: 192.168.100.91 19.846ms reached Resume: pmtu 1500 hops 1 back 64 上面的运行是在VPN上的两个客户端之间：我启动了从192.168.100.90到目的地的跟踪192.168.100.91。配置两个客户端fragment 1200; mssfix;以尝试限制链接上使用的MTU。以上结果似乎表明它tracepath能够检测到两个客户端之间的1500字节的路径MTU。我会假设由于OpenVPN配置中指定的分段设置，它会稍微小一些。我发现结果有些奇怪。 但是，甚至更陌生：如果我的TCP连接处于停止状态（例如，SSH会话的目录列表在中间冻结），则执行tracepath上面显示的命令会使连接再次启动！对于这种情况，我无法找到任何合理的解释，但是我觉得这可能指向最终解决该问题的解决方案。 有人对其他尝试有任何建议吗？ 编辑：我回来了，进一步看了一下，发现只有更多令人困惑的信息： 我将OpenVPN连接设置为1400字节分段，如上所示。然后，我从Internet上连接到VPN，并使用Wireshark查看发生停顿时发送到VPN服务器的UDP数据包。没有一个大于指定的1400字节计数，因此碎片似乎正常运行。 为了验证哪怕一个1400字节的MTU也足够，我使用以下（Linux）命令对VPN服务器执行了ping操作： ping <host> -s 1450 -M …

19 vpn  openvpn  tcp  mtu 

我正在尝试在基于Debian的路由器上调整Snort的性能。我看到的东西是： snort packet recv contents failure: No buffer space available 因此，根据http://fasterdata.es.net/fasterdata/host-tuning/linux/上的调优指南，我将缓冲区增加到8M，当不起作用时我尝试了16M ： #!/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. # # …

19 linux  tcp  linux-networking 

我正在寻找有关我确定是一个古老问题的帮助。我处于一种渴望更加清晰地了解网络吞吐量的情况，但是我似乎找不到能够使其“点击”的信息 我们有一些服务器按地理位置分布，运行各种版本的Windows。假设我们始终使用一台主机（台式机）作为源，那么在将数据从该主机复制到全国其他服务器时，我们发现速度会有很大差异。在某些情况下，我们可以一致地以12MB / s的速度复制数据，而在其他情况下，则可以看到0.8 MB / s。应该指出的是，在测试了8个目标之后，我们似乎始终处于0.6-0.8MB / s或11-12 MB / s的速度。在我们主要关心的建筑物中，我们有一个OC-3连接到ISP。 我知道有很多变量在起作用，但是我想我希望这里的专家可以帮助回答一些基本问题，以帮助加深我的理解。 1.）对于运行Windows XP，Server 2003等，具有100Mbps以太网卡和72毫秒典型延迟的较旧计算机，0.8 MB / s的声音完全合理吗？还是您认为速度足够慢以指示问题？ 2.）在我们的情况下，经典的“吞吐量= TCP窗口/等待时间”的“数学最快速度”计算为0.8 MB / s（64Kb / 72 ms）。我的理解是，这是一个上限。您永远都无法达到的目标（由于开销），更不用说超过该速度了。在某些情况下，我们看到的速度为12.3 MB / s。网络中散布着Steelhead加速器，这些加速器能解释这么高的传输速率吗？ 3.）建议使用SMB与SMB2可以解释速度上的差异。确实，正如我们预期的那样，数据包捕获显示这两种捕获都根据所使用的操作系统版本来使用。我了解决定使用或不使用SMB2的因素，但我很想知道SMB2可以带来什么样的性能提升。 我的问题似乎只是缺乏经验，更重要的是，在什么是和不是什么合理的网络速度方面都缺乏洞察力。任何人都可以帮助传授上下文/观点吗？

18 windows  networking  tcp  wide-area-network  network-speed 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为服务器故障的主题。 8年前关闭。 今天我意识到我从根本上不了解端口通信的工作原理。 如果我启动了侦听端口80的Web服务器的实例，则它可以响应来自许多不同浏览器选项卡的许多请求，所有这些选项卡都通过端口80进行通信。 但是，我无法启动服务器的两个实例，它们都在端口80上侦听，因为这会导致端口冲突。 我一直把它当作一个给定的东西（在任何给定时间只能有一个进程绑定到特定的端口），却从来没有真正考虑过-端口80上是否有多个进程进行通信？（即，浏览器中正在运行的每个选项卡？）

18 networking  tcp  port