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+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

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

它几乎满足所有现有的 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"):

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

• 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.

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

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

int so_oobinline = 1;/* 是的 */
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 标志；/* 在标记处为真 */
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:

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

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 中推送和紧急标志的区别
理解紧急指针

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