TCP通信中的消息定界 [英] Message delimitation in TCP communication

问题描述

我是网络的新手，尤其是 TCP(我一直在用 UDP 欺骗，但仅此而已).我正在开发一个基于在两个端点之间交换消息的简单协议.这些消息需要经过认证，所以我实现了一个加密层来处理这个问题.然而，虽然 UDP 对构成一次可以传输的最小单位的数据包有一个合理的定义，但 TCP 协议(​​据我所知)是完全面向流的.

I am a newbie to networks and in particular TCP (I have been fooling a bit with UDP, but that's it). I am developing a simple protocol based on exchanging messages between two endpoints. Those messages need to be certified, so I implemented a cryptographic layer that takes care of that. However, while UDP has a sound definition of a packet that constitutes the minimum unit that can get transferred at a time, the TCP protocol (as far as my understanding goes) is completely stream oriented.

现在，这让我有点困惑.交换消息时，我如何知道一个从哪里开始，另一个在哪里结束?原则上，我显然可以传达固定长度的消息，或者首先在某些标头中传达每个消息的大小.然而，这可能会受到攻击:虽然当然不可能扭曲或确定通信的内容，但上述技术只需在中间添加一个字节就可以很容易地完全中断我的通信.

Now, this puzzles me a bit. When exchanging messages, how can I tell where one starts and the other one ends? In principle, I can obviously communicate fixed length messages or first communicate the size of each message in some header. However, this can be subject to attacks: while of course it is going to be impossible to distort or determine the content of the communication, the above technique would make it easy to completely disrupt my communication just by adding a single byte in the middle.

说我需要传输一条 1234567 字节长的消息.首先，我将 4 个字节与一个表示消息大小的整数进行通信.好的.然后我开始发送实际的消息.该消息被分成几个数据包，这些数据包分别接收.现在，攻击者只需发送一个额外的数据包，将其伪装成对话的一部分.它可以只有一个字节长:这完全破坏了我已经实现的任何同步机制！消息中间有一个伪字节，它没有被成功解码.不仅如此，第一条消息的最后一个字节会破坏第二条消息的对齐方式，依此类推:连接被破坏，并且通过简单、简单的攻击！无论如何，这种攻击的可能性和可行性有多大?

Say that I need to transfer a message 1234567 bytes long. First of all, I communicate 4 bytes with an integer representing the size of the message. Okay. Then I start sending out the actual message. That message gets split in several packets, which get separately received. Now, an attacker just sends in an additional packet, faking it as if it was part of the conversation. It can just be one byte long: this completely destroys any synchronization mechanism I have implemented! The message has a spurious byte in the middle, and it doesn't successfully get decoded. Not only that, the last byte of the first message disrupts the alignment of the second message and so on: the connection is destroyed, and with a simple, simple attack! How likely and feasible is this attack anyway?

所以我想知道:一次可以传输的最大数据单位是多少?我知道，发送调用不对应于接收调用:消息可以分成不同的块.如何以某种方式将数据包分组在一起，以便我知道它们被打包在一起?有没有办法定义一个更高级别的消息，该消息被重建和对齐在一起并触发对类似接收的函数的单个调用?如果没有，我还能找到哪些其他解决方案，即使在有攻击者的情况下也能保持我的通信重新对齐?

So I am wondering: what is the maximum data unit that can be transferred at once? I understand that to a call to send doesn't correspond a call to receive: the message can be split in different chunks. How can I group the packets together in some way so that I know that they get packed together? Is there a way to define an higher level message that gets reconstructed and aligned all together and triggers a single call to a receive-like function? If not, what other solutions can I find to keep my communication re-alignable even in presence of an attacker?

推荐答案

基本上很难控制操作系统将流分成 TCP 数据包的方式(定义 TCP 协议的 RFC 指出 TCP 堆栈应该允许客户端强制它使用推送功能发送缓冲数据，但它没有定义应该产生多少数据包.毕竟攻击者可以修改其中任何一个).

Basically it is difficult to control the way the OS divides the stream into TCP packets (The RFC defining TCP protocol states that TCP stack should allow the clients to force it to send buffered data by using push function, but it does not define how many packets this should generate. After all the attacker can modify any of them).

并且这些 TCP 数据包在通过网络的过程中可能会被分成更多的 IP 片段(可以通过不分段"IP 标志来选择退出——但是这个标志可能会导致您的数据包无法传送根本没有).

And these TCP packets can get divided even more into IP fragments during their way through the network (which can be opted-out by a 'Do not fragment' IP flag -- but this flag can cause that your packets are not delivered at all).

我认为您的问题不在于将数据包引入流协议，而在于保护它.

I think that your problem is not about introducing packets into a stream protocol, but about securing it.

IPSec 在您的场景中可能非常有用，因为它在网络层上运行.

IPSec could be very beneficial in your scenario, as it operates on the network layer.

它为每个发送的数据包提供完整性，因此任何在线修改都会被检测到并丢弃无效数据包.在 TCP 的情况下，丢弃的数据包会自动重新传输.

It provides integrity for every packet sent, so any modification on-the-wire gets detected and the invalid packets are dropped. In case of TCP the dropped packets get re-transmitted automatically.

(几乎)一切都是由操作系统自动完成的——所以你不必担心(这样做会出错).

(Almost) everything is done automatically by the OS -- so yo do not need to worry about it (and make mistakes doing so).

保密性也可以得到保证(具有不重新发明轮子的相同优势).

The confidentiality can be assured as well (with the same advantage of not re-inventing the wheel).

IPSec 应该为您提供一个可靠的传输协议，您可以在该协议上使用您喜欢的任何帧格式.

IPSec should provide you a reliable transport protocol ontop of which you can use whatever framing format you like.

另一种替代方法是在 TCP 会话之上使用 SSL/TLS，这不太可靠(因为它确实会在完整性错误时关闭整个连接).

Another alternative is using SSL/TLS on top of TCP session which is less robust (as it does close the whole connection on integrity error).

这篇关于TCP通信中的消息定界的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！