我正在使用100 Mbps的快速以太网，其帧大小小于1500字节（根据我的教科书，有效负载为1472字节）。 在这种情况下，我能够发送和接收消息大小为65507字节的UDP数据包，这意味着数据包的大小是65507 + 20（IP Header）+8（UDP Header）= 65535。 如果帧的有效负载大小本身最大为1472字节（按照我的教科书），那么IP的数据包大小如何大于65535？ 我使用发件人代码 char buffer[100000]; for (int i = 1; i < 100000; i++) { int len = send (socket_id, buffer, i); printf("%d\n", len); } 接收器代码如 while (len = recv (socket_id, buffer, 100000)) { printf("%d\n". len); } 我观察到send在i > 65507 returns -1 ， recv打印或接收maximum of length 65507的数据包。
在编写networking软件时，是否有一个默认的，典型的或事实上的MTU尺寸标准，我应该知道这一点？ 如果是这样，那是什么？ MTU的大小为1500（这里build议： 什么是DSL标准支持的最大MTU ）是一个很好的经验法则？ 还有，我在想这个问题吗？ 在编写networking软件的时候，人们认为这些东西是否重要，但是在实际的现实世界中，由于TCP会为您处理细节，所以这些事情不会太重要。 我在这里问，而不是在StackOverflow，因为我想在系统pipe理员的angular度来看实际的支持MTU大小相关的问题。 更新：基于一些反馈和最初的答案，我缩小了焦点： 我正在编写的应用程序将通过WAN连接在台式机/服务器之间进行通信 这是典型的桌面/服务器（即不是移动）软件，虽然有线笔记本电脑可能会通过移动networking使用该软件，但我并不担心 它甚至不会尝试处理除了应用层之外的TCP栈的任何层，以进行优化 这个问题的范围可以排除VPN开销
我知道通过TCP封装TCP通常是一个可怕的想法，但是我可以处理偶尔出现的性能下降和MTU问题，TCP内部的雪球效应提供了错误控制在这两个层次上起作用的地方。 Windows 7 x64上的最新OpenVPN客户端存在可怕的延迟问题，在隧道内对主机进行ping操作会导致> 500ms的ping时间，并导致整体性能下降。 吞吐量看起来不错，它确实只是延迟。 但是，在同一台计算机上，Linux 64位上的OpenVPN客户端（Ubuntu 10.04，相同的OpenVPN版本，相同的OpenVPNconfiguration，没有不同的设置）运行完美。 〜30ms，一切都很实用。 在同一台交换机上，同样的OpenVPN客户端版本，相同的configuration文件，在Mac OS X 10.5（PowerPC）也完美地工作。 我无法解释这一点。 我已经尝试了各种各样的东西，例如将虚拟适配器的MTU值降低到1400（因为商业切换的可怕的文档提到这个不是在Windows上dynamic设置的，并且推荐这样的动作），我试过了在全球TCP设置中禁用ECN，烟囱和CTCP，开启和closuresLzo压缩，牺牲一只山羊，没有什么更好的。 有任何想法吗？ 起初，我认为在Windows上OpenVPN的PMTU支持不足是造成这种情况的原因，但是我尝试了使用Windows XP，它的工作原理也是完美无缺的。 我从用户那里得到了报告，它也能在Windows 7 32位上完美地工作。 此外，文档似乎说，MTU设置对于TCP连接是毫无价值的，并且用于UDP。 tl;博士：TCP上的OpenVPN是慢的，但只有在Windows 7的64位，一切工作正常。 是什么赋予了？ 非常感谢，如果有人能回答这个问题，我会永远欠我的睡眠债务。
我的服务器与ssh有一些问题，我无法上传大于10 KB的文件，因为在复制过程中scp会挂起。 我在这里find了解决这个问题的一个解决scheme，而且我改变了MTU，当时我不小心做了sudo ip link set eth0 mtu 0 。 现在没有人能够进入服务器。 我该怎么办？
我试图了解与NFS和各种缓冲区大小有关的networking设置（并且有不less）。 我正在运行wireshark并检查到达NFS服务器的TCP数据包。 Wireshark在扩展写入操作（客户端 – >服务器）期间显示最大数据包大小32626，假设我解释正确（“我认为networking上的字节包含所有networking层头等） 导出存储的“rsize”和“wsize”NFS设置在C / S上都设置为32k，所以我想上面的结果是这个设置的结果。 但是，增加这些值不会增加Wireshark显示的数据包大小。 所以我的问题是，还有什么其他的限制？ 我做了相当多的研究，这是我到目前为止所遇到的。 在我看来，下面的networking限制都不会限制传输大小为32k： 从sysctl： net.ipv4.tcp_mem = 4096 87380 4194304 net.ipv4.tcp_{r,w}mem = 4096 87380 4194304 net.core.{r,w}mem_max = 131071 net.core.rmem_default = 229376 我的MTU目前是8K
我一直在使用接口绑定，vlan和桥接口的组合来为xen domU提供冗余和不同的逻辑networking层。 这个设置工作正常，但是我对这些接口上的不同设置如何影响彼此有点不确定。 为了说明，这是我在一个典型的dom0上的设置： /- vlan10 — br10 eth0 -\ / > bond0 <— vlan20 — br20 eth1 -/ \ \- vlan30 — br30 考虑到绑定，vlan和bridge接口是逻辑的而不是物理的，如果物理（eth0，eth1）接口有不同的MTU集合，在这些接口上设置MTU是否有效？
当我使用设置了DF位的远程站点进行ping操作并且对于我的路由器来说太大的数据包大小时，从路由器发送第一个ICMP“需要分段”消息。 之后，消息来自我的本地主机。 Netstat -rC（在Linux上）允许我查看路由表caching，但是 1）似乎在一个名为MSS的列下显示MTU（我希望它是链路的较低的TCP MSS） 2）始终显示值为1500 我的本地主机必须将PMTUcaching到某个位置，以便生成所需的分段信息。 但是我怎么看？ 这是我的机器上的一个例子（-n在netstat禁止反向DNS查找）： [root@vbcentos ~]# ping -c 4 -M do -s 1431 212.58.244.69 PING 212.58.244.69 (212.58.244.69) 1431(1459) bytes of data. From 217.155.134.6 icmp_seq=1 Frag needed and DF set (mtu = 1458) From 217.155.134.4 icmp_seq=2 Frag needed and DF set (mtu = 1458) From 217.155.134.4 icmp_seq=2 Frag needed and […]
我正在尝试为KVM访客和主机系统之间的存储通信实现一个9000字节的MTU。 主机有一个9000字节的MTU桥（ br1 ）： host# ip link show br1 8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff inet 172.16.64.1/24 brd 172.16.64.255 scope global br1 inet6 fe80::21b:21ff:fe0e:ee39/64 scope link valid_lft forever preferred_lft forever 客人有一个接口连接到这个桥，也有一个9000字节的MTU： guest# ip addr show eth2 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000 link/ether […]
在这个问题的最后增加了新的细节; 我可能正在调整原因。 我有一个基于UDP的基于OpenVPN的VPNbuild立在互联网上的less数客户端，这些VPN是以tap模式build立的（我需要tap因为我需要VPN来传递多播包，而tunnetworking似乎不可能）。 我一直在经历VPN频繁的TCP连接冻结。 也就是说，我将build立一个TCP连接（例如SSH连接，但其他协议也有类似的问题），并且在会话期间的某个时刻，stream量似乎将停止在该TCP会话上传输。 这似乎与发生大数据传输的点有关，例如，如果我在SSH会话中执行ls命令，或者如果我logging长日志文件。 一些Googlesearch在服务器故障上出现了许多类似于这个问题的答案，表明可能的罪魁祸首是MTU问题：在高stream量期间，VPN试图发送丢弃在VPN端点。 上面链接的答案build议使用以下OpenVPNconfiguration设置来缓解该问题： fragment 1400 mssfix 这应该将VPN上使用的MTU限制为1400字节，并修复TCP最大段大小，以防止产生大于此数据包的数据包。 这似乎缓解了一些问题，但我仍然经常看到冻结。 我已经尝试了一些尺寸作为fragment指令的参数：1200，1000，576，所有的结果都相似。 我想不出两端之间有什么奇怪的networking拓扑可能引发这样的问题：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目的地的跟踪。 两个客户端都configuration了fragment 1200; mssfix; fragment 1200; mssfix; 试图限制链路上使用的MTU。 上面的结果似乎表明tracepath能够检测两个客户端之间的1500字节的pathMTU。 我会假设由于在OpenVPNconfiguration中指定的碎片设置，它会稍小一些。 我发现结果有点奇怪。 更奇怪的是，如果我有一个处于停顿状态的TCP连接（例如，一个目录列表被冻结的SSH会话），那么执行上面显示的tracepath命令会导致连接重新启动 ！ 为什么会出现这样的情况呢，我想不出什么合理的解释，但是我觉得这可能是指向一个解决scheme，最终根除问题。 […]
我没有达到线速的OpenVPN隧道的问题。 网关是在OVH托pipe的Debian Jessy虚拟服务器。 客户端是我的freebsd 10.2 homeserver（Intel I3 Ivy Bridge）或我的RaspberryPI2。 我停用了encryption和authentication。 我有一个100mbit / s的对称FTTH连接，但隧道只能达到20-40mbit / s的速度。 直接连接（无隧道）总是产生我期望的100mbit / s。 我用iperf3testing了性能。 我第一次尝试使用我的freebsd homeserver。 我尝试了所有关于mssfix，fragment等的推荐设置。没有任何帮助。 然后我想也许这是我的freebsd机器。 所以我在RPI2上安装了一个新的rasbian Jessy，并做了一些更深入的testing： 首先，我从OpenVPNconfiguration中删除了所有的MTU设置，并让pathMTU处理事情（希望）。 由于我在两台机器上都没有防火墙，所以它应该可以工作。 这些是我的VPNconfiguration： server 10.8.0.0 255.255.255.0 port 1194 proto udp dev tun sndbuf 0 rcvbuf 0 user nobody group nogroup persist-key persist-tun ifconfig-pool-persist ipp.txt keepalive 10 120 push "redirect-gateway def1" […]