问题描述
有人知道对方是如何以及为什么会收到合并的TCP数据包而不是单独的包？我已经在套接字级别将TCP Nodelay设置为true，但tcpdump仍然将某些数据包视为已合并。
在发送大小为310字节的4个成功数据包之后，我获得了3 x 1400字节而不是15 x 310字节。这导致了一些重要的延迟。谢谢。
Does anybody knows how and why a counter party would receive TCP packets merged instead of individually packages? I already set TCP Nodelay to true at socket level, but tcpdump still sees some packets as merged.After 4 successful packets sent with size of 310 bytes, I got 3 x 1400 bytes instead of 15 x 310 bytes. This is causing some important latency. Thanks.
s = new Socket(host, port);
s.setTcpNoDelay(true);
s.getOutputStream().write(byteMsg);
s.getOutputStream().flush()
推荐答案
TCP是基于流的协议。它不保留与发送 / recv 调用相关的边界。唯一保证的是发送的串联将与 recv 的串联相同（在正常情况下）。
TCP is a stream-based protocol. It doesn't preserve boundaries with respect to send/recv calls. The only thing guaranteed is that the concatenation of send's will be the same as the concatenation of recv's (under normal circumstances).
如果您正在实施自定义协议并需要某种方法将数据拆分为多个逻辑消息，则需要用于编码。
If you're implementing a custom protocol and need some way to split the data into multiple logical messages, you need an encoding for that.
简单编码是将每条消息编码为32位无符号整数，表示消息有效负载的长度，后跟实际的消息有效负载。然后，在接收侧，根据该编码正确地解码输入。为此，您需要一个缓冲区来存储部分接收的消息。如果操作原始整数是个问题，你可以用其他方式对长度进行编码，例如：作为十进制数后跟换行符。
A simple encoding is to encode each message as a 32-bit unsigned integer denoting the length of the message payload, followed by the actual message payload. Then, on the receiving side, properly decode the input according to this encoding. To do that, you will need a buffer that will store a partially received message. If manipulating raw integers is a problem, you can encode the length some other way, e.g. as a decimal number followed by a newline.
这篇关于TCP数据包在网络级合并的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！