TCP 中推送标志和紧急标志之间的区别

发布于 2025-01-02 07:49:07 字数 126 浏览 0 评论 0原文

我试图理解带有 PSH 标志的 TCP 段和带有 URG 标志的 TCP 段之间的区别。 我阅读了 RFC 但仍然无法获取它,其中一个在将数据发送到进程之前是否缓冲数据,而另一个则没有?

I'm trying to understand the difference between a TCP segment with the flag PSH and with the flag URG.
I read the RFC but still couldn't get it, does one of them buffer the data before it sends it to the process and the other doesn't ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

绿光 2025-01-09 07:49:07

它们是两种截然不同的机制。

PSH 和 PUSH 函数

当您发送数据时,您的 TCP 会对其进行缓冲。因此,如果您发送一个字符,它不会立即发送,而是等待查看是否有更多字符。但也许您希望它直接在线:这就是 PUSH 功能的用武之地。如果您 PUSH 数据,您的 TCP 将立即创建一个段(或几个段)并推送它们。

但故事并没有就此结束。当对等 TCP 接收到数据时,它会自然地缓冲它们它不会干扰每个字节的应用程序。这就是 PSH 标志发挥作用的地方。如果接收 TCP 看到 PSH 标志,它将立即将数据推送到应用程序。

没有用于设置 PSH 标志的 API。通常它是由内核清空缓冲区时设置的。来自 TCP/IP 图解:

该标志通常用于指示发送数据包一侧的缓冲区已被占用
在发送数据包的同时清空。换句话说,当设置了 PSH 位字段的数据包离开发送方时,发送方就没有更多数据可发送。

但请注意史蒂文斯还说:

推送(接收者应尽快将此数据传递给应用程序)
可能——未可靠地实现或使用

URG 和 OOB 数据

TCP 是面向流的协议。因此,如果您在一侧推送 64K 字节,您最终将在另一侧获得 64K 字节。因此,想象一下您推送了大量数据,然后收到一些消息,上面写着“嘿,您知道我刚刚发送的所有数据吗?是的,把它们扔掉”。问题的要点是,一旦您在连接上推送数据,您就必须等待接收方获取所有数据,然后才能获取新数据。

这就是 URG 标志发挥作用的地方。当您发送紧急数据时,TCP 会创建一个特殊的段,在其中设置 URG 标志以及紧急指针字段。这会导致接收 TCP 在单独的通道上将紧急数据转发到应用程序(例如,在 Unix 上,您的进程会收到 SIGURG)。这允许应用程序处理带外数据。


顺便说一句,重要的是要意识到紧急数据现在很少使用并且没有得到很好的实施。使用单独的渠道或完全不同的方法要容易得多。


1: RFC 6093 不同意这种“带外”的使用,并指出:

TCP 紧急机制不是发送“带外”的机制
数据:所谓的“紧急数据”应“在线”交付给
TCP 用户。

但随后它又承认:

默认情况下,“紧急数据”的最后一个字节是“带外”传送的
到应用程序。也就是说,它不作为
正常数据流。

应用程序必须不遗余力地指定SO_OOBINLINE 以获得符合标准的紧急语义。

如果这一切听起来很复杂,那么不要使用紧急数据

They are two vastly different mechanisms.

PSH and the PUSH function

When you send data, your TCP buffers it. So if you send a character it won't send it immediately but wait to see if you've got more. But maybe you want it to go straight on the wire: this is where the PUSH function comes in. If you PUSH data your TCP will immediately create a segment (or a few segments) and push them.

But the story doesn't stop here. When the peer TCP receives the data, it will naturally buffer them it won't disturb the application for each and every byte. Here's where the PSH flag kicks in. If a receiving TCP sees the PSH flag it will immediately push the data to the application.

There's no API to set the PSH flag. Typically it is set by the kernel when it empties the buffer. From TCP/IP Illustrated:

This flag is conventionally used to indicate that the buffer at the side sending the packet has been
emptied in conjunction with sending the packet. In other words, when the packet with the PSH bit field set left the sender, the sender had no more data to send.

But be aware Stevens also says:

Push (the receiver should pass this data to the application as soon as
possible—not reliably implemented or used)

URG and OOB data

TCP is a stream-oriented protocol. So if you push 64K bytes on one side, you'll eventually get 64k bytes on the other. So imagine you push a lot of data and then have some message that says "Hey, you know all that data I just sent ? Yeah, throw that away". The gist of the matter is that once you push data on a connection you have to wait for the receiver to get all of it before it gets to the new data.

This is where the URG flag kicks in. When you send urgent data, your TCP creates a special segment in which it sets the URG flag and also the urgent pointer field. This causes the receiving TCP to forward the urgent data on a separate channel to the application (for instance on Unix your process gets a SIGURG). This allows the application to process the data out of band¹.


As a side note, it's important to be aware that urgent data is rarely used today and not very well implemented. It's far easier to use a separate channel or a different approach altogether.


¹: RFC 6093 disagrees with this use of "out of band" and states:

The TCP urgent mechanism is NOT a mechanism for sending "out-of-band"
data: the so-called "urgent data" should be delivered "in-line" to the
TCP user.

But then it goes on to admit:

By default, the last byte of "urgent data" is delivered "out of band"
to the application. That is, it is not delivered as part of the
normal data stream.

An application has to go out of its way and specify e.g. SO_OOBINLINE to get standards-conforming urgent semantics.

If all this sounds complicated just don't use urgent data.

林空鹿饮溪 2025-01-09 07:49:07

在已回答的基础上添加更多信息。

  • 如果设置了URG位,则优先考虑数据,这意味着紧急数据将在“紧急”数据之前发送,而不是等待整个字节流被传输。紧急基础,不会等待在其前面的整个字节流被传输。

  • URG位被设置时,紧急指针也被设置(在TCP头选项字段中:16位)。

  • URG 指针指示已到达的段中有多少字节的数据是紧急的。 (例如,如果数据大小为 100 字节,并且只有前 50 个字节是紧急的,则紧急指针的值为 50)。

  • 现在进入 PSH 位。 PSH 位的目的是告诉 TCP 不要等待缓冲区变满并立即发送数据。同样,当接收方收到设置了PSH标志的报文段时,应立即将数据发送到上层,而不必等待接收缓冲区变满。实际的例子是 telnet 应用程序,其中应用程序以很少的击键形式发送数据。如果 telnet 等待缓冲区变满,然后将数据传输到接收器,那么它将变得不可用。

Adding some more information to the already answered one.

  • The URG bit, if set prioritizes the data, meaning thereby instead of waiting for the entire byte stream to be transmitted which is ahead of the "Urgent" data, the urgent data will be sent on urgent basis and will not wait for the entire byte stream to be transmitted which is ahead of it.

  • When the URG bit is set the Urgent Pointer is also set (in the TCP header Options field: 16 bit).

  • The URG pointer tell how many bytes of the data is urgent in the segment that has arrived. (Example if the data size is 100 bytes and only first 50 bytes is urgent, the urgent pointer will have a value of 50).

  • Now coming to the PSH bit. The purpose of the PSH bit is to tell TCP that do not wait for the buffer to become full and send the data immediately. Similarly when the receiver receives the segment with PSH flag set, should send the data immediately to the upper layer without waiting for the receive buffer to become full. The practical example of this is the telnet application where the application sends data in the form of few keystrokes. The telnet will become unusable if it waits for the buffer to become full and then transits the data to the receiver.

如痴如狂 2025-01-09 07:49:07

我不会太严格地接受 RFC 中的所有内容,这些标志的实现似乎存在一些含糊之处。 URG 涉及在填充缓冲区之前发送数据包,而 PSH 控制在接收端将数据向上移动到堆栈。

I wouldn't accept everything in an RFC too rigidly, it seems there is some ambiguity about the implementation of these flags. URG concerns the sending of packets before filling buffers while PSH controls moving data up the stack at the receiving end.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文