TCP Dup ACK / Retransmission，配置错误？

我正在调查朋友局域网的网络问题（再次）。互联网连接非常缓慢且不可靠，有时服务根本不起作用。

我使用Wireshark监控了一段时间的流量。我终于想出了一个可重复的问题，一个git pull在ssh没有工作。以下是Wireshark日志的git pull样子：

TCP重新传输始终在启动密钥交换时启动。服务器没有从我的机器接收数据包，或者我的机器没有收到答案。我有一种感觉，其原因也是局域网所有其他网络问题的原因。

我1514想到的一件事是，这里所有坏包的分组长度虽然没有分段位设置，但LAN路由器配置为MTU 1492。我无法为大于的MTU配置路由器1500。数据包是否太大，以至于它们卡在路由器上？

此外，大多数安全连接（https，ssh）似乎受到影响，但这些连接总是需要更大的数据包大小。

你知道，我没有很多网络经验，所以我希望你们中的一些人能够更多地了解这一点。

编辑：刚才，git pull再次正常工作。MTU配置不能成为问题的原因......

具有“不碎片”的大包是正常的。这就是操作系统执行MTU发现的方式 - 它不是让网络悄悄地分段数据包，而是要求返回ICMP“需要分段”错误（这将具有正确的MTU）。

如果您看到重传的大数据包，则意味着中间的某些路由器配置错误，阻止ICMP错误数据包，或者在需要时不发送它们。

我认为只有当接收者看到序列号中的间隙时才会发生重复的ack ，这意味着数据包在去往它的路上被丢弃了; 所以问题从192.168.0.8到远程服务器的方向开始。事实上，尽管有几次重传，但没有回复（甚至没有重复的确认），这可能意味着某些东西在这个方向完全搞砸了。（这可能意味着远程方不能发送，但这与先前的重复确认不一致，后来也与fin-ack不一致。这意味着有2个问题而不是1。）

以下是一些想法：

• 如果连接是在一个糟糕的公共wifi或3G上，那么你可以获得100％丢包的短暂时段。通过同时使用其他服务进行检查，看看它是否也受到中断的影响。
• 有协议感知防火墙可能需要一些时间来确定你在做什么之前决定在特定连接上丢弃数据包。您的朋友是否正在运行可以关闭的异国防火墙？ISP是否有一些使用规则？
• 尝试更新驱动程序或从Linux Live CD启动，看看是否发生了同样的事情。尝试使用其他服务更改连接的其他方面，以缩小出错的范围。