TCP URG(紧急数据)是否得到确认?

问题描述

在带有 URG 标志的 TCP 段中也可能有正常数据.接收主机如何处理紧急数据包?如果它不是数据流的一部分，它如何确认紧急数据?它承认其余部分吗?

In a TCP segment with the URG flag up there might be normal data as well. How does the receiving host handles the urgent packet? How does it acknowledge the urgent data if it is not part of the data stream? Does it acknowledge the rest of it?

我知道它通常不使用，但是如果两个主机都支持相同的关于 URG 标志的 RFC，它们如何处理带外数据?

I understand that it is not usually used, but if both hosts support the same RFC about the URG flag, how do they handle out-of-band data?

如果紧急数据是中止消息，接收方将丢弃所有其他数据，但发送方仍需要确认消息已收到.

If the urgent data is an abort message, the receiver will drop all other data, but the sender will still want an acknowledgment that the message was received.

推荐答案

一点背景:

TCP 紧急机制允许将数据流中的一个点指定为紧急信息的结尾.因此，我们有一个紧急指针，它包含与此 tcp 段中的序列号的正偏移量.该字段仅在设置了 URG 控制位时才有意义.

The TCP urgent mechanism permits a point in the data stream to be designated as the end of urgent information. Thus we have the Urgent Pointer that contains a positive offset from the sequence number in this tcp segment. This field is significant only with the URG control bit set.

关于紧急指针的差异:

RFC 793(1981 年，第 17 页):

RFC 793 (1981, page 17):

紧急指针指向八位字节的序号紧跟紧急数据.

RFC 1011(1987 年，第 8 页):

RFC 1011 (1987, page 8):

第 17 页是错误的.紧急指针指向最后一个八位字节紧急数据(不是非紧急数据的第一个八位字节).

RFC 1122(1989，第 84 页)中的相同内容:

The same thing in RFC 1122 (1989, page 84):

..紧急指针指向最后一个八位字节的序列号(不是 LAST+1)在一系列紧急数据中.

可理解的 RFC 6093(2011，第 6-7 页)说:

The intelligible RFC 6093 (2011, pages 6-7) says:

考虑到只要 TCP 发送方和 TCP 接收方为紧急指针实现相同的语义没有使紧急指针指向紧跟在紧急数据之后的八位位组的序列号"；与最后一个紧急数据的八位字节"，并且所有已知的实现都解释紧急指针的语义指向序列"紧急数据"之后的八位字节数".

因此更新 RFC 793、RFC 1011 和 RFC 1122 是

Thus the updating RFC 793, RFC 1011, and RFC 1122 is

使用(如果是)在线接收，如上所述.
来自 RFC 1122:

Besides it is recommended for new applications to use (if so) receiving in-line, as mentioned above.
From RFC 1122:

TCP 紧急机制不是发送带外"信息的机制.数据:所谓的紧急数据"；应该在线"交付到TCP 用户.

同样来自 RFC 793:

Also from RFC 793:

TCP 不会尝试定义用户具体做什么收到待处理紧急数据的通知

所以你可以随心所欲地处理.这是一个应用程序级别的问题.

So you can handle as you want. It is an application level issue.

因此，关于删除所有其他数据时的确认问题的答案是您可以在您的应用程序中实现它".
至于tcp-ack，在紧急数据的情况下，我没发现有什么特别之处.

Accordingly, the answer to your question about acknowledgements when all other data was dropped is "You can implement it in your application".
As for tcp-ack, I found nothing special about it in the case of urgent data.

关于紧急数据"的长度

几乎所有的实现都只能提供一个字节的带外数据".
RFC 6093 说:

Almost all implementations really can provide only one byte of "out-of-band data".
RFC 6093 says:

如果紧急数据"的连续指示之前收到应用程序读取待处理的带外"；字节，待处理的字节将被丢弃(即，被urgent"的新字节覆盖数据").

所以TCP紧急模式及其紧急指针在实践中不能提供紧急数据的边界标记.
有传言说有一些实现将每个接收到的紧急字节排队.已知它们中的一些未能对它们排队的紧急数据"的数量实施任何限制.因此，它们很容易受到微不足道的资源耗尽攻击.

So TCP urgent mode and its urgent pointer cannot provide marking the boundaries of the urgent data in practice.
Rumor has it that there are some implementations that queue each of the received urgent bytes. Some of them have been known to fail to enforce any limits on the amount of "urgent data", that they queue. Thus, they become vulnerable to trivial resource exhaustion attacks.

P.S. 以上所有内容可能比所要求的要多一点，但这只是为了让不熟悉这个问题的人清楚.

P. S. All of the above probably covers a little more than was asked, but that's only to make it clear for people unfamiliar with this issue.

一些更有用的链接:
TCP 紧急指针、缓冲区管理和发送"打电话
TCP 中推送和紧急标志的区别
理解紧急指针

这篇关于TCP URG(紧急数据)是否得到确认?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！