在编写networking软件时，是否有一个默认的，典型的或事实上的MTU尺寸标准，我应该知道这一点？ 如果是这样，那是什么？
MTU的大小为1500（这里build议： 什么是DSL标准支持的最大MTU ）是一个很好的经验法则？
还有，我在想这个问题吗？ 在编写networking软件的时候，人们认为这些东西是否重要，但是在实际的现实世界中，由于TCP会为您处理细节，所以这些事情不会太重要。
我在这里问，而不是在StackOverflow，因为我想在系统pipe理员的angular度来看实际的支持MTU大小相关的问题。
更新：基于一些反馈和最初的答案，我缩小了焦点：
您不应该关心MTU，因为networking堆栈将负责进行必要的优化。 如果您使用的是TCP，堆栈可能会使用计算最大分段大小（MSS）的方法，这反过来会导致数据包小于path中最低的MTU。 其中之一是PMTU的发现 。
一般来说，你不应该试图超越堆栈 – TCP / IP的分层架构使用抽象是有原因的。 除非你有更好的，否则你应该把分割和分割的function放在devise的地方。
正如其他人所写，除了最小定义的MTU外，没有“安全的MTU” – 这是68字节 ，由于巨大的开销，因此具有相当低的实际价值。
由于MTU限制，典型的支持问题主要有两方面：
在应用程序中，这两个因素都不是你应该处理的。
这是一个相当广泛的问题。
1500是常见的？ 是的，绝对是在局域网上的传统以太网。
假设1500或期望它是否可以安全地连接？ 不可以。从任何地方连接的移动用户可能在不同的时间有不同的MTU。
我们有时会减less可能通过VPN连接向远程办公室提供服务的数据中心服务器的MTU。
一般情况下，VPN连接的MTU很可能会降低，而且这些连接都已经到位。 它可能是1410,1390,1362或其他一些好奇的数字。
如果您对给定tcp连接的最大有效负载大小感兴趣，则可能会发现协商的“最大段大小”更有意义。 对于标准的1500MTU局域网连接，通常是1460，但结果是它应该反映两台主机都能接受的大小。
对于经过许多跳跃的连接，期望所有跳都具有“标准”MTU或可以可靠地确定MTU是不现实的。 请参阅有关该主题的pathMTU发现讨论。
pathMTU发现
http://en.wikipedia.org/wiki/Path_MTU_discovery#Problems_with_PMTUD
用MSS Clamping避开pathMTU发现问题
http://lartc.org/howto/lartc.cookbook.mtu-mss.html
回答：
1）很难回答这个问题，因为在接触networking时总会有影响软件性能的事情。 一个MTU优化的交换机端口到交换机端口通信不会对你的广域网链路有什么好处，或者更糟的是一个VPN将会增加开销和潜在的碎片。
2）是的，但在任何情况下都无法控制上游的情况！
3）是的，你正在推翻它，你真的正在编写软件，这将回到第2层进行优化？ 如果你正在写… iSCSI驱动程序，那么是的，你可能需要考虑这样的事情。
坚持协议的要求，并假设你可以轻松地传递数据。 但是，尽量避免使用刚好超过MTU的固定长度块或其一小部分。