是否确认了TCP URG(紧急数据)? [英] Is TCP URG (urgent data) acknowledged?

问题描述

在带有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):

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

The urgent pointer points to the sequence number of the octet following the urgent data.

RFC 1011 (1987年，第8页):

RFC 1011 (1987, page 8):

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

Page 17 is wrong. The urgent pointer points to the last octet of urgent data (not to the first octet of non-urgent data).

RFC 1122 (1989，第84页)中的相同之处:

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

..紧急指针指向LAST八位位组的序号 (而不是LAST + 1)在紧急数据序列中.

..the urgent pointer points to the sequence number of the LAST octet (not LAST+1) in a sequence of urgent data.

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

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

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

Considering that as long as both the TCP sender and the TCP receiver implement the same semantics for the Urgent Pointer there is no functional difference in having the Urgent Pointer point to "the sequence number of the octet following the urgent data" vs. "the last octet of urgent data", and that all known implementations interpret the semantics of the Urgent Pointer as pointing to "the sequence number of the octet following the urgent data".

因此，更新后的RFC 793，RFC 1011和RFC 1122是

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

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

the urgent pointer points to the sequence number of the octet following the urgent data.

它几乎可以满足所有现有的TCP实现.

It meets virtually all existing TCP implementations.

注意:Linux提供了net.ipv4.tcp_stdurg sysctl来覆盖默认行为，但是此sysctl仅影响传入段的处理.传出段中的紧急指针仍将按照RFC 793中的规定进行设置.

Note: Linux provides the net.ipv4.tcp_stdurg sysctl to override the default behaviour but this sysctl only affects the processing of incoming segments. The Urgent Pointer in outgoing segments will still be set as specified in RFC 793.

关于数据处理

您可以通过两种方式获取紧急数据(请注意，紧急数据"的TCP概念已作为带外数据"映射到套接字API):

You can gain urgent data in two ways (keep in mind that the TCP concept of "urgent data" is mapped to the socket API as "out-of-band data"):

• 在设置了MSG_OOB标志的情况下使用recv. (通常，您应该使用fcntl(sock, F_SETOWN, getpid());之类的名称建立套接字的所有权，并为SIGURG的类别建立信号处理程序).因此，您将收到SIGURG信号通知.数据将与普通数据流分开读取.

• 使用未设置MSG_OOB标志的recv.以前，您应该这样设置SO_OOBINLINE套接字选项:

• using recv with MSG_OOB flag set. (normally you should establish ownership of the socket with something like fcntl(sock, F_SETOWN, getpid()); and establish a signal handler for SIGURG). Thus you will be notified with SIGURG signal. The data will be read separately from the normal data stream.

• using recv without MSG_OOB flag set. Previously, you should set SO_OOBINLINE socket option such way:

int so_oobinline = 1; /* true */
setsockopt(sock, SOL_SOCKET, SO_OOBINLINE, &so_oobinline, sizeof so_oobinline);

数据保持在线"状态.您可以借助ioctl来确定紧急指针:

The data remain "in-line". And you can determine the Urgent Pointer with a help of ioctl:

int flag; /* True when at mark */
ioctl(sock, SIOCATMARK, &flag);

此外，建议用于新的应用程序不要使用如上所述，所有紧急数据都可以在线使用(如果需要)的机制.
从RFC 1122开始:

Besides it is recommended for new applications not to use the mechanism of urgent data at all to use (if so) receiving in-line, as mentioned above.
From RFC 1122:

TCP紧急机制不是用于发送带外"机制 数据:所谓的紧急数据"应在线"传递给 TCP用户.

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.

同样来自RFC 793:

Also from RFC 793:

TCP不会尝试定义用户具体要执行的操作 被通知有待处理的紧急数据

TCP does not attempt to define what the user specifically does upon being notified of pending urgent data

因此您可以根据需要进行处理.这是一个应用程序级别的问题.

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:

如果在 应用程序读取未决的带外"字节，即未决的字节 将被丢弃(即被新的紧急"字节覆盖 数据").

If successive indications of "urgent data" are received before the application reads the pending "out-of-band" byte, that pending byte will be discarded (i.e., overwritten by the new byte of "urgent data").

因此，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中的推送和紧急标志之间的区别
了解紧急指针

Some more useful links:
TCP Urgent Pointer, buffer management, and the "Send" call
Difference between push and urgent flags in TCP
Understanding the urgent pointer

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