问题标签 [mtu]

我正在尝试对应用程序进行逆向工程，我需要帮助了解 TCP 窗口大小的工作原理。我的 MTU 是 1460 我的应用程序使用 TCP 将文件从 A 点传输到 B。我知道以下内容：

• 文件被分成大小为 8K 的段
• 每个段都被压缩
• 然后每个段通过 TCP 发送到 B 点。文本文件的这些段大小可以是 148 字节，而 pdf 文件的大小可以是 6000 字节。

对于文本文件，我是否应该看到 148 段相互连接以形成一个大型 TCP 流？然后根据Window Size进行拆分？

任何帮助表示赞赏。

是否可以通过使用 ICMP 数据包太大消息在 IPv6 中创建 DoS 攻击？

例如，假设您想通过以某种方式欺骗 ICMP 数据包太大消息来拒绝访问某个地方，并将大小设置为 68 个八位字节（IPv4 的最小值），以限制特定节点接收的任何流量。这种攻击可能吗？

在 RFC 1981 中它说

节点不得将其对路径 MTU 的估计降低到低于 IPv6 最小链路 MTU。注意：节点可能会收到一个 Packet Too Big 消息，报告下一跳 MTU 小于 IPv6 最小链路 MTU。在这种情况下，节点不需要将路径上发送的后续数据包的大小减小到小于 IPv6 最小链路 MTU，而是必须在这些数据包中包含一个片段头 [IPv6-SPEC]。

因此，RFC 1981 中的这种情况通常只会发生在 IPv6-IPv4 转换的情况下，其中 IPv4 节点的 MTU 小于 1280。但是，如果我的理解是正确的，如果沿路径有 IPv6-IPv4 隧道，我们可以显着减慢流量，因为 IPv6-IPv4 节点会将其分段。

但是，这对我来说不太有意义，因为 IPv6 不允许分段。

我正在使用 UDP 数据包，我想澄清以下几点：
1 - “recvfrom”返回的究竟是什么？我的意思是，如果我发送一个大小为 450 字节 + 20 字节 IP 头 + 8 字节 UDP 头的数据包，recvfrom 会整体返回 478 字节，或者可能是这样的：
它收到了 10 字节、300 字节、100 字节、68字节？
2 - “recvfrom”的返回值是否与数据包碎片有关？

注意：
*我假设“recvfrom”成功
*我选择 450 字节以确保 Im 小于最小 MTU

我正在学习内核模块并且是新手。我想更改 eth0 的 MTU 大小。这是我编写的模块程序。

目的是将 eth0 的 MTU 大小更改为 1000。但它没有改变。谁能告诉我，我错过了什么。如果方法本身是错误的，你能指出我正确的方向吗？

我正在尝试测试通过 1 GbE 直接连接的两台计算机之间的吞吐量并使用 iperf 进行测试。当 MTU 介于 5000 和 5050 之间时，我的吞吐量约为 980Mbps，但是在 MTU=5050 以上时，它会急剧下降到 680Mbps 左右。我检查了不同的窗口大小，但结果相同。增加 MTU 应该会减少开销，从而应该增加带宽或至少不应该下降。我无法弄清楚这种奇怪的行为。顺便测试一下 TCP 吞吐量。任何帮助！谢谢大家。这是我在任何论坛上发布的帖子（问题）:) 通常我会找到答案....

附加信息！两个 centos 系统 一个系统是 Xen 4.2 主机（但这应该不是问题） 检查 /pro/sys/net/ipv4 中不同的缓冲区大小

我通过发出以下命令从我的 linux 主机找到我的服务器的 mtu 值：

所以我假设我的最大 MTU 是 1340 (1312 + 28)。

但是，当我从我的 java 客户端捕获到该服务器的 http 帖子时，我可以在 wireshark 中看到一个大小为1354的 tcp 包，并且整个请求/响应是成功的。

我想知道如何在包大小 > 最大 MTU 大小的情况下取得成功？

谢谢，

默认情况下，当我们说 TCP 以太网数据包 1460 和 MTU 的 MSS 是 1500 时。

MSS = MTU - 20（IP 标头）- 20（TCP 标头）= 1460

从上面计算的 TCP 标头options在 TCP 标头中没有任何内容。如果任何数据包包含optionTCP 标头中的值，它是否会减小 MSS 大小？

那么optionTCP 标头中的 MSS 大小将是多少

我通过多个路由器将 1 MB 的 UDP 数据从一个系统发送到另一个系统。两个系统都有 1500 MTU，在两台主机之间我有一台 MTU 较低的路由器，如 576。

那么路由器（具有较低 MTU（576））会将 UDP 数据包分段并发送到接收主机，还是将ICMP 消息（PMTU）发送到发送主机以进行进一步分段？

作用于 UDP 套接字时，什么会导致sendto()发送的字节数少于请求的字节数？

问这个问题的动机是弄清楚我需要采取的预防措施，以确保我总是在一次调用中收到完整的消息sendto()，并了解我需要采取哪些进一步的步骤才能将消息放入单个 IP 数据包中。我是否只需要确保我的消息小于某个大小，如果是，该大小有多大？除了操作系统特定的 UDP 数据报大小限制和 MTU 之外，是否还有其他因素在起作用（例如 i/o 缓冲区容量、反复无常的操作系统）？

在问了上面的原则问题之后，在这篇文章的标题中，我将继续一些相关的后续问题，然后在最后把事情放到上下文中。

进一步的问题

更详细地说，再次假设我们正在对 UDP 套接字进行操作：

1. 每次成功调用是否都会sendto()发送1 个UDP 数据报？（我很欣赏这可能会分成多个 IP 数据包）

2. 每次成功调用都会recvfrom()准确检索1 个UDP 数据报吗？

3. 如果一条消息需要N次调用才能发送，即使接收机器是不同的平台sendto()，它是否也需要恰好N次调用才能接收？recvfrom()（我很欣赏数据报的顺序将是不可预测的）

4. 假设我尝试发送一条消息，其大小等于或小于本地和远程系统支持的最大 UDP 数据报大小中的较小者，（并且出现一些会导致返回值-1的错误）sendto()保证一口气发送我的全部信息？或者它可能会报告它发送的字节数少于我要求它发送的字节数？如果是这样，为什么？回到问题 1。

5. 除了问题 4 中的假设之外，假设我的消息不大于（MTU - UDP 标头 - IP 标头）大小，是保证适合1 个IP 数据包的 UDP 数据报（至少在我的本地网络上） ?

语境

我刚刚开始编写我的第一个基于 UDP 的通信协议（跨平台：例如 linux、mac、windows、ios、android 等）。我是一个套接字新手，但我知道使用像 UDP 这样简单的协议所带来的“成本”，并研究了以下算法/策略：

• 可靠性和流量控制
• 将大消息拆分为多个小消息
• 喷泉码有助于补偿一些数据包丢失（通过减少重新发送请求）。
• 加密（见 http://srp.stanford.edu/）

我试图将我的所有通信分解为原子消息（即单个、自包含的 UDP 数据报），这些消息可能（但不一定）需要适合单个 IP 数据包（例如 1500 字节）。吞吐量和数据包丢失的实时评估将确定我是否必须缩小数据报以适应单个 IP 数据包（这会导致额外标头的大小损失）。其中一些将通过 wifi/无线电链接，所以我希望自适应地确定“最佳”数据报大小。我知道我所有接口的 MTU，并且意识到在我的本地网络之外，数据包可能会被进一步拆分，但这超出了我的控制范围，所以我可以忍受它。

但是一切都取决于能够构造一个原子消息，并且有 100% 的信心我可以通过一次调用成功发送它sendto()，并通过一次调用接收 if recvfrom()。sendto()我所有的应用程序级可靠性、拆分、编码和加密信息都存在于我自己的协议头中，并且在调用返回短消息后我无法重新拆分消息。例如，考虑一个消息校验和：如果整个消息没有一次性通过，则标头中的校验和对于已发送的消息部分不再有效。

是否可以使用 rtp 在互联网上实时发送分辨率为 800x600 的视频流？

我已经阅读了有关 MTU 限制的信息，但我不知道如何使用此分辨率实现此限制，即使使用 h264 对其进行压缩也是如此。

什么技术使用流行的视频聊天程序来做到这一点？

我尝试了很多压缩，但我只能以 400x300 的分辨率发送。