TCP URG（紧急数据）是否被确认？
Is TCP URG (urgent data) acknowledged?
在带有 URG 标志的 TCP 段中，也可能有正常数据。接收主机如何处理紧急数据包？如果它不是数据流的一部分，它如何确认紧急数据？它是否承认其余部分？
我知道它通常不被使用，但是如果两个主机都支持关于 URG 标志的相同 RFC，它们如何处理带外数据？
如果紧急数据是中止消息，接收方将丢弃所有其他数据，但发送方仍需要收到消息的确认。
一些背景知识：
TCP紧急机制允许将数据流中的一个点指定为紧急信息的结束点。因此，我们有一个紧急指针，它包含与此 tcp 段中的序列号的正偏移量。此字段仅在设置了 URG 控制位时才有意义。
关于紧急指针的差异：
RFC 793（1981 年，第 17 页）：
The urgent pointer points to the sequence number of the octet
following the urgent data.
RFC 1011（1987 年，第 8 页）：
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 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 页）说：
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 是
the urgent pointer points to the sequence number of the octet
following the urgent data.
它几乎满足所有现有的 TCP 实现。
注意：Linux 提供 net.ipv4.tcp_stdurg sysctl 来覆盖默认行为，但此 sysctl 仅影响传入段的处理。传出段中的紧急指针仍将按照 RFC 793 中的规定进行设置。
关于数据处理
您可以通过两种方式获取紧急数据（请记住“紧急数据”的 TCP 概念映射到套接字 API 作为“带外数据”）：
使用 recv 并设置了 MSG_OOB 标志。
（通常您应该使用 fcntl(sock, F_SETOWN, getpid()); 之类的东西建立套接字的所有权，并为 SIGURG 建立信号处理程序）。因此，您将收到 SIGURG 信号通知。数据将与普通数据流分开读取。
使用 recv，但未设置 MSG_OOB 标志。以前，您应该这样设置 SO_OOBINLINE 套接字选项：
int so_oobinline = 1; /* true */
setsockopt(sock, SOL_SOCKET, SO_OOBINLINE, &so_oobinline, sizeof so_oobinline);
数据保持“在线”状态。您可以借助 ioctl:
确定紧急指针
int flag; /* True when at mark */
ioctl(sock, SIOCATMARK, &flag);
此外 recommended 新应用 根本不使用紧急数据机制 使用（如果使用）在线接收，如上所述.
来自 RFC 1122：
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：
TCP does not attempt to define what the user specifically does upon
being notified of pending urgent data
所以你可以随心所欲地处理。这是一个应用程序级别的问题。
因此，对于您关于丢弃所有其他数据时的确认的问题，答案是“您可以在您的应用程序中实现它”。
至于tcp-ack，在紧急数据的情况下，我觉得没什么特别的。
关于“紧急数据”的长度
几乎所有的实现都只能提供一个字节的“带外数据”。
RFC 6093 说：
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紧急模式及其紧急指针在实践中无法提供紧急数据边界的标记。
有传言说有一些实现对每个接收到的紧急字节进行排队。众所周知，其中一些未能对他们排队的“紧急数据”数量实施任何限制。因此，它们很容易受到简单的资源耗尽攻击。
P. S. 以上所有内容可能比被问到的要多一些，但这只是为了让不熟悉这个问题的人清楚。
一些更有用的链接：
TCP Urgent Pointer, buffer management, and the "Send" call
Difference between push and urgent flags in TCP
Understanding the urgent pointer
在带有 URG 标志的 TCP 段中，也可能有正常数据。接收主机如何处理紧急数据包？如果它不是数据流的一部分，它如何确认紧急数据？它是否承认其余部分？
我知道它通常不被使用，但是如果两个主机都支持关于 URG 标志的相同 RFC，它们如何处理带外数据？
如果紧急数据是中止消息，接收方将丢弃所有其他数据，但发送方仍需要收到消息的确认。
一些背景知识：
TCP紧急机制允许将数据流中的一个点指定为紧急信息的结束点。因此，我们有一个紧急指针，它包含与此 tcp 段中的序列号的正偏移量。此字段仅在设置了 URG 控制位时才有意义。
关于紧急指针的差异：
RFC 793（1981 年，第 17 页）：
The urgent pointer points to the sequence number of the octet following the urgent data.
RFC 1011（1987 年，第 8 页）：
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 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 页）说：
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 是
the urgent pointer points to the sequence number of the octet following the urgent data.
它几乎满足所有现有的 TCP 实现。
注意：Linux 提供 net.ipv4.tcp_stdurg sysctl 来覆盖默认行为，但此 sysctl 仅影响传入段的处理。传出段中的紧急指针仍将按照 RFC 793 中的规定进行设置。
关于数据处理
您可以通过两种方式获取紧急数据（请记住“紧急数据”的 TCP 概念映射到套接字 API 作为“带外数据”）：
使用
recv并设置了MSG_OOB标志。 （通常您应该使用fcntl(sock, F_SETOWN, getpid());之类的东西建立套接字的所有权，并为SIGURG建立信号处理程序）。因此，您将收到SIGURG信号通知。数据将与普通数据流分开读取。使用
recv，但未设置MSG_OOB标志。以前，您应该这样设置SO_OOBINLINE套接字选项：int so_oobinline = 1; /* true */
setsockopt(sock, SOL_SOCKET, SO_OOBINLINE, &so_oobinline, sizeof so_oobinline);数据保持“在线”状态。您可以借助
确定紧急指针ioctl:int flag; /* True when at mark */
ioctl(sock, SIOCATMARK, &flag);
此外 recommended 新应用 根本不使用紧急数据机制 使用（如果使用）在线接收，如上所述.
来自 RFC 1122：
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：
TCP does not attempt to define what the user specifically does upon being notified of pending urgent data
所以你可以随心所欲地处理。这是一个应用程序级别的问题。
因此，对于您关于丢弃所有其他数据时的确认的问题，答案是“您可以在您的应用程序中实现它”。
至于tcp-ack，在紧急数据的情况下，我觉得没什么特别的。
关于“紧急数据”的长度
几乎所有的实现都只能提供一个字节的“带外数据”。
RFC 6093 说：
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紧急模式及其紧急指针在实践中无法提供紧急数据边界的标记。
有传言说有一些实现对每个接收到的紧急字节进行排队。众所周知，其中一些未能对他们排队的“紧急数据”数量实施任何限制。因此，它们很容易受到简单的资源耗尽攻击。
P. S. 以上所有内容可能比被问到的要多一些，但这只是为了让不熟悉这个问题的人清楚。
一些更有用的链接：
TCP Urgent Pointer, buffer management, and the "Send" call
Difference between push and urgent flags in TCP
Understanding the urgent pointer