我有一个非常奇怪的。
当我从两台不同的Windows 2008服务器下载文件（并且只下载）时，我的数据包丢失了过多的“TCP Dup ACK”和“TCP Fast Retransmission”。 上传速度很好。
这只有在客户端计算机（Win7）以100mb / s连接时才会发生。 在1GB，没有错误，我得到全速。 如果我把客户端网卡设置为100Mb / s，我会得到很多“TCP Dup”错误，下载速度将下降到2-5MB / s左右。 上传速度10MB / s或以上。
这只发生在Windows 2008服务器盒（戴尔，但不同的硬件）。 如果我在Win7客户端和Linux服务器之间传输，则不会发生此问题。
这就像Server 2008无法正确扩展TCP窗口，超载交换机或什么，然后暂停一点点的stream量。
由于设备较旧，部分networking以100Mb / s运行，所以这在某些build筑物中确实造成了问题。
我已经从客户端上传了一个pcap文件。 https://dl.dropboxusercontent.com/u/24907255/slow.pcap.gz
它显示一个正在写入服务器的50MB文件，然后从错误的服务器中读回。
谢谢你的帮助。 我很难过
11/28/13更多信息。
我closures了整个networking，只有一个客户端和一个服务器在networking上。 问题没有改变。
如果我将每个接口，服务器，客户端和Cisco 2960交换机都设置为100Mbs，那么问题就会消失。 如果我设置服务器和交换机接口自动或1Gbs，问题又回来了。
如果我用Netgear 10/100交换机绕开交换机，并将客户机和服务器都设置为自动，那么我没有任何问题。
我确实发现了这一点。 在正常的设置中，服务器以1Gbs交换，我插入客户端和Cisco交换机之间的Netgear 10/100交换机，我的速度问题更糟。 速度从5-7MB / s到2-3MB / s，是的，我尝试了固定和自动networking速度。 这就可以解释为什么一些在它们和主思科交换机之间有2个交换机的build筑物有更多的速度问题。
去ping。 在1GB / s的情况下，我可以ping一个完整的TCP有效载荷，ping -l 65500，它可以工作。 在100Mbs的客户端，我可以ping的最大尺寸是17752.再次，它失败了，只有Windows服务器，没有问题的Linux机器上。 在服务器和客户端之间使用Netgear 10/100，在65500处ping不出问题。
更新3
我交换了PowerConnect 2748交换机。 与1Gbs的服务器和100Mbs的客户端的同样的问题。 现在我可以平息17752。 奇怪。 所以我不认为这是思科交换机。
更新4.我试图通过使用ipref得到一些硬数字。 所有系统连接到相同的交换机，客户端设置为100Mbs，并运行命令ipref.exe -c -u -b 10m。 所以发送到服务器。 一个服务器是2008年，现在没有任何负载，其他的是一个平均负载平均为.20的Ubuntu。
在10米
推到100米
现在统计发送到10米的客户端
推到100米
因此，Server 2008通常很差，但是当连接被推送到客户端100mbs的限制时，你可以看到巨大的数据包丢失47％。
更新5。
当我使用PowerConnect 2748交换机进行testing时，我在服务器和交换机以及客户端和交换机之间使用了不同的cat5电缆。 这应该排除布线或切换问题。
在这个环境中，我有两台Windows 2008 Server，分别安装在不同的硬件上。 他们唯一分享的是Broadcom品牌的nic，但芯片组是不同的。 两者都遇到同样的问题，但我正在做一个主要的testing，以防万一出现问题，另一个仍然有效。
一台服务器有一个内置BCM5709C的两个端口，还有一个附加卡，我认为PCI卡上也带有相同的BCM5709C芯片组和两个端口。 我已经尝试了所有这些，问题依然存在。 所以这应该排除任何硬件问题。
更新6 12/3/13我安装了Intel nic。 不用找了。 我玩了ctcp设置，没有改变。 我甚至closures了SMB2，没有什么区别。
我在100Mbs做了一些更多的testing复制一个3GB的ISO映像到服务器，拖放，平均在10MB / s。 从服务器复制相同的3GB ISO映像，平均值为6.3MB / s。
将所有networking接口设置为“自动”，并在1Gbs。 将ISO复制到服务器，平均值为101MB / s从服务器复制ISO，平均值为57MB / s
所以从服务器读取速度几乎是写入速度的一半。
这听起来像一个速度/双工不匹配导致冲突和重发。 服务器和另一端之间的configuration错误可能导致这种情况。 不匹配的另一个原因可能是自动协商失败。
确保连接的两端都configuration相同的速度和双工。
我相信你应该调查是否任何NIC驱动程序/ Windows NDIS卸载设置与您的问题有关。 我非常怀疑LSO（Large Send Offload，大容量发送卸载）function，因为我已经看到它彻底破坏了一项服务（戴尔服务器和Broadcom NIC），其方式无法排除故障的所有故障诊断书的定义。
LSO在中断而不是增强时的实际效果是LSO引擎可能会通过交换机支持的更大的dataframe。 这会导致交换机默默丢弃这些帧。 不用说，这会导致性能下降和数据包丢失。 失败可能是迫在眉睫，但也可能是间歇性的，使其难以排除故障。 这在这里详细描述： 大发送卸载和networking性能
免责声明：这是对您的问题的一个可能的angular度的最好的努力想法。 执行下面的任何一项更改都会中断您的networking通信。 应用任何设置后，计算机应重新启动。 我复制/粘贴最有趣的设置作为参考，但链接包含所有的核心信息和注意事项。 我最强烈build议使用官方文档作为变更的基础，这个职位最多就像一个清单。
在进行任何这些操作之前，备份您的registry项：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 一个不合理的原因是由于下面描述的官方错误，当某些设置通过命令行发送时，会改变一些不相关的值。
我自由地承认，在Windows NIC驱动程序GUI和Windows中都存在设置的情况下，如果必须在GUI和Windows CMD / Registry中同时禁用这两个设置，或者只要禁用了这两个设置，那么我从来没有真正清楚过。 我读过的博客中提到的答案与一些小细节或其他方面的不一致，所以我从来不确定。 现在我试图在任何地方find我正在关注的设置选项。 这里没有提供GUI选项，但在官方文档中有描述。
此外，同一卡的不同NIC驱动程序可能会在GUI中的高级设置中呈现不同的粒度。
禁用任务卸载
此registry设置将禁用“ 使用registry值”以启用和禁用连接卸载中定义的任务卸载。
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\DisableTaskOffload Setting this value to one disables all of the task offloads from the TCP/IP transport. Setting this value to zero enables all of the task offloads.
如果上述设置有任何影响，您可以尝试按照链接指定的方式进行细化。 有相当多的设置pipe理这个，所以我不会把他们全部粘贴。
我会提供LSO的：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV1IPv4 HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV2IPv4 HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\LsoV2IPv6 For all three: Enabled = 1(default). Disabled = 0.
禁用连接卸载
如使用registry值来启用和禁用连接卸载所定义的。
HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\TCPConnectionOffloadIPv4 Describes whether the device enabled or disabled the offload of TCP connections over IPv4. Enabled = 1 (Default). Disabled = 0. HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\TCPConnectionOffloadIPv6 Describes whether the device enabled or disabled the offload of TCP connections over IPv6. Enabled = 1 (Default). Disabled = 0.
禁用TCP烟囱，TOE和TSO
如何如何禁用TCP烟囱，TCPIP卸载引擎（TOE）或TCP分段卸载（TSO）中指定 注意Win2008修补程序
以及Windows Server 2008中有关TCP烟囱卸载，接收端扩展和networking直接内存访问function的信息 。
Windows 2008 Server: If the operating system is Microsoft Windows Server 2008 (any version including R2), run the following from a Command prompt: 1. netsh int tcp set global chimney=disabled 2. netsh int tcp set global rss=disabled 3. netsh int tcp set global netdma=disabled Note: To display current global TCP settings, use the net shell command: netsh int tcp show global 4. Restart the server. Note: Microsoft has identified an issue running the netsh command to set global TCP parameters on Windows Server 2008 and Vista machines. Some global parameters, such as TCPTimedWaitDelay, can be changed from their default or manually set values to 0xffffffff. Before running the above command, Symantec recommends reviewing Microsoft KB Article 967224 (support.microsoft.com/kb/967224). Upon completion of the above command's execution, Symantec also recommends reviewing the TCP Parameters noted in the KB Article and applying the hotfix from the article if needed.
这个修补程序描述了这个问题：
After you run the command, the values of the following unrelated settings are changed to 0xFFFFFFFF: KeepAliveInterval KeepAliveTime TcpTimedWaitDelay In addition, the "TcpMaxDataRetransmissions" are changed to 0xFF.
再次，因此可能希望在做任何事情之前备份整个registry项：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
如果你从上面卸载你的问题，你会发现由于网卡卸载造成类似问题的post，文章和博客都没有结束。 但是，如果它仍然不起作用，那么我想你可以在堆栈上尝试其他的东西，因为它不是由于电缆，网卡或交换机的一半断了，对吗？
总是看networking设备的线索…..所以，如果思科，做一个“显示接口F0 / 11”或任何可能在你的情况。 转发也可能是由于一个糟糕的以太网端口/ NIC /电缆，如由于“串扰”…..在显示交换机的int应该告诉你这些错误统计，如果是这样的话，这将是明显的方式太高
编辑：因为这是微软，它最有可能这是你的问题，但除此之外，一般来说，从第一层开始（确保物理电缆是好的），并工作你的方式了堆栈，即层2，速度/双工/ MAC地址过滤，..然后第3层ip / udp / tcp防火墙，等等
这也可以是“先进的”网卡属性，如PowerManagement的或IRQ的优先级。 假设你有相同版本的驱动程序。 去：
Device Manager – > Network Interfaces – >网卡Properties – > Advanced Tab 。
检查并比较这里的所有值。
您是否检查过100/1000networking上的巨型帧？
UPD ：
如果使用巨型帧，则广播域上的所有networking硬件都应该使用它。 传统的100MB设备是不可能的。
我不知道win2008 tcp是如何工作的，但是提供了jombo帧，它可能会开始扩展传输窗口的数据包大小（不像往常一样）。 然后你会观察所描述的情况。
仅供参考： http : //m.windowsitpro.com/windows/q-how-do-i-enable-jumbo-frames
UPD2 ：
我查看了你所提供的数据包转储，并看到长度大于1500的很多数据包和错误的校验和（校验和的长度小于1500）。 这证实了我的假设。
我唯一不能理解的东西 – 它们与第一次会话有关：从客户端到服务器（!!! ???）：
22:25:06.041113 IP (tos 0x0, ttl 128, id 31391, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x9422 (correct), ack 1453, win 1234, length 0 22:25:06.041223 IP (tos 0x0, ttl 128, id 31392, offset 0, flags [DF], proto TCP (6), length 64280, bad cksum 0 (->285)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xc9bb), seq 718652:782892, ack 1453, win 1234, length 64240SMB-over-TCP packet:(raw data or continuation? 22:25:06.041254 IP (tos 0x0, ttl 128, id 31437, offset 0, flags [DF], proto TCP (6), length 1452) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [P.], cksum 0x0517 (correct), seq 782892:784304, ack 1453, win 1234, length 1412SMB-over-TCP packet:(raw data or continuation?) 22:25:06.041278 IP (tos 0x0, ttl 128, id 31438, offset 0, flags [DF], proto TCP (6), length 2960, bad cksum 0 (->f1df)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xfa12), seq 784304:787224, ack 1453, win 1234, length 2920SMB-over-TCP packet:(raw data or continuation?) 22:25:06.042134 IP (tos 0x0, ttl 128, id 31441, offset 0, flags [DF], proto TCP (6), length 2960, bad cksum 0 (->f1dc)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0x1d7e), seq 787224:790144, ack 1453, win 1234, length 2920SMB-over-TCP packet:(raw data or continuation?) 22:25:06.042492 IP (tos 0x0, ttl 128, id 31444, offset 0, flags [DF], proto TCP (6), length 5880, bad cksum 0 (->e671)!) 192.168.0.109.49225 > 192.168.0.252.microsoft-ds: Flags [.], cksum 0x82c0 (incorrect -> 0xa74e), seq 790144:795984, ack 1453, win 1234, length 5840SMB-over-TCP packet:(raw data or continuation?)
您在后面的发现中描述的效果与IEEE 802.3u的运行方式一致：
如果您难以设置其中一个接口（NIC / Switchport）的速度并将另一个设置为Auto，则可能会遇到双工不匹配的情况。
如果您将其中一个接口硬设置为全双工，则另一个不能自动协商双工，但也必须将其硬设置。
即使两个接口硬设置为自动/全双工，某些NIC（或写得不好的Windows驱动程序）仍然使自动协商处于工作模式，并且默认为半双工。
这是我得到这些事实的地方：
来自思科的两份文件涉及（其中包括）2900系列交换机，并将网卡故障诊断为交换机端口连接问题。 它们包括具体的故障排除步骤，尤其是对于交换机端而言，也适用于NIC。 由于思科在实际networking分析方面处于领先地位，包括对基本先决条件（如自动协商电气协议）的深入了解，PowerConnect很可能具有相似的工作条件（根据相同的协议标准开发）。 为了完整性，我会自由地引用它，并稍后形成它，但我会敦促你浏览一下：
排除Cisco Catalyst交换机对NIC兼容性问题的故障
configuration和故障处理以太网10/100 / 1000Mb半双工/全双工自动协商
在这里我引用一些非常有趣的东西：
自动协商有效configuration表
Speed determination issues can result in no connectivity. However, issues with autonegotiation of duplex generally do not result in link establishment issues. Instead, autonegotiation issues mainly result in performance-related issues. The most common problems with NIC issues deal with speed and duplex configuration. Table 1 summarizes all possible settings of speed and duplex for FastEthernet NICs and switch ports.
然后遵循一个非常有用的表格，我将尝试稍后在不丢失格式的情况下移植到此处。 该表还包括1Gbps的速度组合，具有类似的有趣效果和评论。 但是，重点包括：
* Configuration NIC (Speed/Duplex): 100Mbps, full duplex * Configuration Switch (Speed/Duplex): auto * Resulting NIC Speed/Duplex: 100Mbps * Resulting Catalyst Speed/Duplex: 100Mbps half duplex Comments: duplex mismatch (footnote 1) * Configuration NIC (Speed/Duplex): auto * Configuration Switch (Speed/Duplex): 100Mbps, full duplex * Resulting NIC Speed/Duplex: 100Mbps full duplex * Resulting Catalyst Speed/Duplex: 100Mbps half duplex Comments: duplex mismatch (footnote 1) * Configuration NIC (Speed/Duplex): 100Mbps, full duplex * Configuration Switch (Speed/Duplex): 100Mbps, full duplex * Resulting NIC Speed/Duplex: 100Mbps, full duplex * Resulting Catalyst Speed/Duplex: 100Mbps, full duplex Comments: Correct manual config (footnote 2)
表脚注是最有趣的：
(1) A duplex mismatch can result in performance issues, intermittent connectivity, and loss of communication. When you troubleshoot NIC issues, verify that the NIC and switch use a valid configuration. (2) Some third-party NIC cards can fall back to half-duplex operation mode, even though both the switchport and NIC configuration are manually configured for 100 Mbps, full-duplex. This is because NIC autonegotiation link detection still operates when the NIC is manually configured. This causes duplex inconsistency between the switchport and the NIC. Symptoms include poor port performance and frame check sequence (FCS) errors that increment on the switchport. In order to troubleshoot this issue, try to manually configure the switchport to 100 Mbps, half-duplex. If this action resolves the connectivity problems, this NIC issue is the possible cause. Try to update to the latest drivers for your NIC, or contact your NIC card vendor for additional support.
为什么只有一个链接合作伙伴不能对速度和双面进行硬编码？
As indicated in Table 1, a manual setup of the speed and duplex for full-duplex on one link partner results in a duplex mismatch. This happens when you disable autonegotiation on one link partner while the other link partner defaults to a half-duplex configuration. A duplex mismatch results in slow performance, intermittent connectivity, data link errors, and other issues. If the intent is not to use autonegotiation, both link partners must be manually configured for speed and duplex for full-duplex settings.
NIC兼容性链接的最后一个主题是对上面引用的段落中描述的效果的技术背景。 这个背景的基础是自动协商协议操作的一些关键细节：
(Table of bits shortened down for relevance) 0.13 Rate Selection (least-significant bit [LSB]) 0.6 0.13 1 1 reserved 1 0 1000 Mbps : 0 1 100 Mbps : 0 0 10 Mbps 0.12 Autonegotiation Enable 1 = autonegotiaton enabled 0 = autonegotiation disabled 0.8 Duplex Mode 1 = full-duplex 0 = half-duplex 0.6 Rate Selection (most-significant bit [MSB]). See bit 0.13 The register bits relevant to this document include 0.13, 0.12, 0.8, and 0.6. The other register bits are documented in the IEEE 802.3u specification. Based on IEEE 802.3u, in order to manually set the rate (speed), the autonegotiation bit, 0.12, must be set to a value of 0. As a result, autonegotiation must be disabled in order to manually set the speed and duplex. If the autonegotiation bit 0.12 is set to aa value of 1, bits 0.13 and 0.8 have no significance, and the link uses autonegotiation to determine the speed and duplex. When autonegotiation is disabled, the default value for duplex is half-duplex, unless the 0.8 is programmed to 1, which represents full-duplex. Based on IEEE 802.3u, it is not possible to manually configure one link partner for 100 Mbps, full-duplex and still autonegotiate to full-duplex with the other link partner. If you attempt to configure one link partner for 100 Mbps, full-duplex and the other link partner for autonegotiation, it results in a duplex mismatch. This is because one link partner autonegotiates and does not see any autonegotiation parameters from the other link partner and defaults to half-duplex.
另外，我发现了一些与思科类似的bug报告 ，但是对于交换机硬件/软件，os版本，nics和驱动程序的组合，它们是非常具体的。 不知道确切的细节，它太投机了。
我相信这可能只是通过协议定义和操作来确认你的发现。
解决scheme
所以假设这不是一个狂野（但有趣）的鹅追逐，我引用你：
1）“如果我把每个接口，服务器，客户端和Cisco 2960交换机都设置为100Mbs，那么问题就会消失，如果我将服务器和交换机接口设置为auto或1Gbs，问题就回来了。
2）“如果我用Netgear 10/100交换机绕开交换机，并将客户机和服务器都设置为自动，我没有问题。
3）尝试查找与旧开关兼容的NIC /驱动程序组合。 作为必需品购买。
4）使用可靠的技术参考和推理来激励需要升级交换机的预算。