Skip to main content

3. Specification (规范)

3.1. TCP Packet Format (TCP 数据包格式)​

DTH 标志使用 TCP 头部中控制位字段 (Control bits field) 的第四个比特位,如图 1 [RFC9293] 所示。第四个比特位是特意选择的,因为中文中的"四"是 Sì;它的发音类似于 Sǐ,意思是"死"。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |D|     |C|E|U|A|P|R|S|F|                               |
| Offset|T| Rsr |W|C|R|C|S|S|Y|I|            Window             |
|       |H| vd  |R|E|G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |         Urgent Pointer        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           [Options]                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               :
:                             Data                              :
:                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

注意:一个刻度标记代表一个比特位。

图 1: 带有 DTH 标志位的 TCP 头部

当 TCP 会话很可能即将终止时,TCP 会话对等体应该 (SHOULD) 传输 DTH 段。它可以从服务器和客户端双方发送。即使应用程序或 TCP 堆栈知道会话将被终止,也可以 (MAY) 选择不发送 DTH 段。这会给对等体带来戏剧性的惊喜;然而,最终用户可能会认为结局太过方便或过于简单。不鼓励使用与会话终止无关的 DTH 段,但这是允许的。(这通常被称为"戏弄"或假阳性 DTH 标志。)

DTH 标志是信息性的 (informational)。不实现此功能的 TCP 软件可以安全地忽略此标志。然而,为了充分欣赏会话,用户应该意识到会话叙述的微妙迹象。

DTH 标志本身不会改变序列号或确认号。它不需要任何确认。

标志的接收者不需要在接收时采取不同的行动;但是,建议 (RECOMMENDED) 将信息传递给应用层,以便可以通知最终用户该事件。DTH 段的接收者不应该 (SHOULD NOT) 在接收时立即关闭套接字;它应该 (SHOULD) 等待 RST 或 FIN 段。

本规范未规定一个 TCP 会话中允许的 DTH 段的最大数量;但是,建议 (RECOMMENDED) 将它们限制为几个,以最大化戏剧效果。

3.2. When to Send (何时发送)​

只要发送方认为向 TCP 对等体发出其不可避免的结束信号很重要,就可以使用 DTH。下面的示例场景说明了何时发送 DTH 段。

恶意行为者可以在突然悔改时发送标志;例如,当发送方突然后悔参与 DDoS 攻击并意外停止攻击时。大反派通常会在行为改变后残酷无情地终止发送方(或者他们因保护英雄而被杀)。DTH 传输的时机取决于实现。它可以在背叛的早期迹象到行为改变之前的任何时间发送。

当发送方停止使用加密保护并显示其明文内容时,可以发送标志,例如,戴着面具的神秘角色通常在暴露面部后死亡。在此示例中,DTH 段将在发送从 HTTPS 到 HTTP [RFC9110] 的重定向 (30x) 之前发送。同样,当伪造的 User-Agent 或 Server HTTP 头字段更改为实际值时,当他们的真实身份被揭露时(例如,"我是你失散多年的双胞胎","我是间谍"等),可以设置标志。这偶尔会导致角色死亡。

当 TCP 对等体注意到资源问题时,建议 (RECOMMENDED) 发送标志,例如内存空间或带宽减少。AI 机器人、半机械人、使用禁忌协议的魔法师应用程序等,当它开始大量咳出错误消息时,应该 (SHOULD) 考虑发送标志。

执行任务能力较差的应用程序可以 (MAY) 不时发送标志。它迟早会因效率低下而被操作系统(大反派)或 CTRL-C(最终用户)杀死。内存占用过多的应用程序也可能发生同样的情况,例如,试图获取所有宝藏的不择手段的角色通常会意外死亡(例如从悬崖上掉下来)。

应用程序在访问"蜜罐"(honeypot) 或闹鬼服务器之前真的应该 (SHOULD) 三思而后行。如果您的选择有限(例如,您最喜欢的服务器在荒郊野外发生故障,而不在 DNS 上的黑暗服务器是您唯一可以庇护的地方),定期发送标志是个好主意。该会话很可能受到诅咒。

3.3. When Not to Send (何时不发送)​

DTH 标志不应该 (SHOULD NOT) 与 FIN 标志一起捎带 (piggybacked)。如果存在,接收者应该 (SHOULD) 静默忽略 DTH 标志。唯一的例外是当接收者是北斗神拳 (Hokuto-Shinken, "Big Dipper Divine Fist") [WIKI-FNS] 的专家时。在这种情况下,发送方已经死了,但仍保持活跃几秒钟(这被非正式地称为"半僵尸打开"状态)。

DTH 标志不应该 (SHOULD NOT) 与 URG 标志 [RFC6093] 一起发送。新实现中不建议使用 URG 标志 [RFC9293]。

不建议 (NOT RECOMMENDED) 在 TCP 会话的早期阶段使用该标志。在早期阶段死亡的角色被认为是非必要的,因此他们的死亡不会对会话质量做出贡献。(显然,也有例外。)

3.4. Use with the IP Evil Bit (与 IP Evil Bit 配合使用)​

一些实验性实现使用 IP 头部的 Evil bit [RFC3514] 来指示会话是否描绘了一个邪恶角色。DTH 标志不是为表征 TCP 会话而设计的。它旨在显示会话的命运,而不管会话的性质如何。当 Evil bit 和 DTH 标志都存在时,它们必须 (MUST) 独立解释。

参考文献​

  • [RFC3514]: Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 2003
  • [RFC6093]: Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, January 2011
  • [RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, June 2022
  • [RFC9293]: Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, August 2022
  • [WIKI-FNS]: Wikipedia, "List of Fist of the North Star characters", March 2023
Last updated on