gpt4 book ai didi

networking - TCP URG(紧急数据)是否被确认?

转载 作者:可可西里 更新时间:2023-11-01 02:35:36 30 4
gpt4 key购买 nike

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

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

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

最佳答案

一些背景知识:

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


关于紧急指针的差异:

RFC 793 (1981 年,第 17 页):

The urgent pointer points to the sequence number of the octetfollowing the urgent data.

RFC 1011 (1987 年,第 8 页):

Page 17 is wrong. The urgent pointer points to the last octet ofurgent 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 receiverimplement the same semantics for the Urgent Pointer there is nofunctional difference in having the Urgent Pointer point to "thesequence number of the octet following the urgent data" vs. "the lastoctet of urgent data", and that all known implementations interpretthe semantics of the Urgent Pointer as pointing to "the sequencenumber of the octet following the urgent data".

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

the urgent pointer points to the sequence number of the octetfollowing 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 信号通知。数据将与普通数据流分开读取。

  • 在未设置 MSG_OOB 标志的情况下使用 recv。以前,您应该这样设置 SO_OOBINLINE 套接字选项:

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

    数据保持“在线”状态。您可以借助 ioctl 确定紧急指针:

    int 标志;/* 在标记处为真 */
    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 theTCP user.

同样来自 RFC 793:

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

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

因此,对于您关于丢弃所有其他数据时的确认的问题,答案是“您可以在您的应用程序中实现它”。
至于tcp-ack,在紧急数据的情况下,我觉得没什么特别的。



关于“紧急数据”的长度

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

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

因此TCP紧急模式及其紧急指针在实践中无法提供紧急数据边界的标记。
有传言说有一些实现对每个接收到的紧急字节进行排队。众所周知,其中一些未能对他们排队的“紧急数据”数量实现任何限制。因此,它们很容易受到简单的资源耗尽攻击。


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


一些更有用的链接:
TCP Urgent Pointer, buffer management, and the "Send" call
Difference between push and urgent flags in TCP
Understanding the urgent pointer

关于networking - TCP URG(紧急数据)是否被确认?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40241437/

30 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com