使用 Boost ASIO 且适合 MTU 时，有效负载分为两个 TCP 数据包

Question

我在 boost::asio::ip::tcp::iostream 方面遇到问题。我正在尝试发送大约 20 个原始字节。问题是这个 20 字节的有效负载被分成两个 TCP 数据包，先是 1 字节，然后是 19 字节。简单的问题，为什么会发生我不知道。我正在为一个传统的二进制协议编写此内容，该协议非常需要有效负载适合单个 TCP 数据包（呻吟）。

从我的程序中粘贴整个源代码会很长而且过于复杂，我在这里仅在 2 个函数中发布了功能问题（经过测试，它确实重现了该问题）；

#include <iostream>

// BEGIN cygwin nastyness
// The following macros and conditions are to address a Boost compile
// issue on cygwin. https://svn.boost.org/trac/boost/ticket/4816
//
/// 1st issue
#include <boost/asio/detail/pipe_select_interrupter.hpp>

/// 2nd issue
#ifdef __CYGWIN__
#include <termios.h>
#ifdef cfgetospeed
#define __cfgetospeed__impl(tp) cfgetospeed(tp)
#undef cfgetospeed
inline speed_t cfgetospeed(const struct termios *tp)
{
    return __cfgetospeed__impl(tp);
}
#undef __cfgetospeed__impl
#endif /// cfgetospeed is a macro

/// 3rd issue
#undef __CYGWIN__
#include <boost/asio/detail/buffer_sequence_adapter.hpp>
#define __CYGWIN__
#endif
// END cygwin nastyness.

#include <boost/array.hpp>
#include <boost/asio.hpp>
#include <iostream>

typedef boost::asio::ip::tcp::iostream networkStream;

void writeTestingData(networkStream* out) {
        *out << "Hello world." << std::flush;
//      *out << (char) 0x1 << (char) 0x2 << (char) 0x3 << std::flush;
}

int main() {
        networkStream out("192.168.1.1", "502");

        assert(out.good());

        writeTestingData(&out);
        out.close();
}

更奇怪的是，如果我发送字符串“Hello world.”，它会放入一个数据包中。如果我发送 0x1、0x2、0x3（原始字节值），我会在数据包 1 中得到 0x1，然后在下一个 TCP 数据包中得到其余数据。我正在使用wireshark查看数据包，开发机器和192.168.1.1之间只有一个交换机。

Answer 1

我不确定谁会强行要求整个有效负载位于一个 TCP 数据包内。 TCP 本质上是一种流式协议，发送的数据包数量和有效负载大小等许多细节都由操作系统的 TCP 堆栈实现决定。

我会仔细检查这是否是您的协议的实际限制。

Answer 2

我同意User1的回答。您可能多次调用 operator << ；第一次调用时，它立即通过网络发送第一个字节，然后 Nagle 算法开始发挥作用，因此剩余的数据在单个数据包内发送。

然而，即使分包不是问题，即使对小块数据频繁调用套接字发送函数也是一个大问题。在套接字上调用的每个函数都会调用繁重的内核模式事务（系统调用），为每个字节调用 send 简直是疯了！

您应该首先在内存中格式化消息，然后发送。对于您的设计，我建议创建一种缓存流，它将在其内部缓冲区中累积数据并将其立即发送到底层流。

Answer 3

将通过 TCP 套接字发送的数据视为数据包是错误的。它是一个字节流，如何构建数据是特定于应用程序的。

有什么建议吗？

我建议您实现一个协议，以便接收者知道需要多少字节。实现此目的的一种流行方法是发送固定大小的标头，指示有效负载的字节数。

Answer 4

您的代码：

out << (char) 0x1 << (char) 0x2 << (char) 0x3;

将调用 3 次 operator<< 函数。

由于 TCP 的 Nagle 算法，TCP 堆栈将发送可用数据 ((char )0x1) 在第一次 operator<< 调用之后/期间立即进行对等。
因此其余数据（0x2 和 0x3）将进入下一个数据包。

避免1字节TCP段的解决方案：
使用更大的数据量调用发送函数。

Answer 5

别担心，您是唯一遇到此问题的人。肯定有解决办法。事实上，您的旧协议存在两个问题，而且不止一个。

您的旧遗留协议需要一条“应用程序消息”来适应“一个且仅一个 TCP 数据包”（因为它错误地使用 TCP 面向流的协议作为面向数据包的协议）。因此，我们必须确保：

1. 没有“应用程序消息”被分割到多个 TCP 数据包中（您所看到的问题）
2. 没有 TCP 数据包包含多个“应用程序消息”（您没有看到这一点，但它肯定会发生）

解决方案：

问题 1

您必须立即向套接字提供所有“消息”数据。目前这种情况还没有发生，因为正如其他人所概述的那样，当您使用连续的“<<”时，您使用的升压流 API 将数据以单独的调用放入套接字中。并且操作系统的底层 TCP/IP 堆栈没有足够的缓冲（并且有原因，为了更好的性能）

多种解决方案：

• 您传递一个字符缓冲区而不是单独的字符，以便您只对 << 进行一次调用
• 你忘记了 boost，打开一个操作系统套接字并在一次调用 send() 中将其提供给它（在 Windows 上，查找“winsock2”API，或在 unix/cygwin 上查找“sys/socket.h”）

问题 2

你必须激活 TCP_NODELAY 选项。此选项是专门针对此类遗留协议情况而设计的。它将确保操作系统 TCP/IP 堆栈“无延迟”发送您的数据，并且不会将其与您稍后可能发送的其他应用程序消息一起缓冲。

• 如果您坚持使用 Boost，请查找 TCP_NODELAY 选项，它在文档中
• 如果您使用操作系统套接字，则必须在您的操作系统上使用 setsockopt() 函数插座。

结论

如果你解决了这两个问题，你应该没问题！

操作系统套接字 API，无论是在 Windows 还是 Linux 上，使用起来都有点棘手，但您将获得对其行为的完全控制。 Unix 示例