我正在对生成 IP 标头的 ID 字段的方法做一些研究。
我已经阅读了源代码和其他文档，并确认 Linux 会为与其通信的每个对等点（IP）生成一个随机数，然后它会将发送给该对等点的后续 IP 数据包的 ID 加 1。
我的问题是，您知道这种行为背后的原因/方法吗？为什么要跟踪内核与之通信的对等点（以及所有这些内容所需的内存和 CPU 时间）？
我已经开始这项研究是因为我正在研究空闲扫描技术。
最好有更详细的参考文献。
答案1
当您的计算机与对等计算机（甚至是“远程”服务器）对话，然后收到来自该对等计算机或远程计算机的响应时，仅仅知道该响应来自谁是不够的。您还需要知道正在响应哪个对话。
随着时间的推移，在任何给定时间，您的计算机与另一台对等计算机（或多台计算机）之间可能会打开多个对话。您可能已使用相同或不同的协议组合请求了各种信息。某些请求的响应时间可能比其他请求长得多。这些请求的响应是异步的，不会以相同或任何可预测的顺序接收。某些请求可能会收到多个响应。
所有这些都需要跟踪，以便在收到响应时能够识别它属于哪个“对话”。
对于您所描述的情况，我找不到对此的具体引用，但它类似于 IMAP 期望客户端提供通常随每个新“命令”递增的“标签”的方式。为此，我怀疑在您询问的情况下，不需要在每次使用时“增加”标签（因此，不太可能找到任何引用）。唯一的要求是标签在每次使用时都是唯一的。以唯一的字符串（或数字）开始，然后在每次使用时递增它，可确保它是唯一的，而不必特别记住哪些“标签”已被使用。（IMAP RFC 3501：第 2.2.1 节）。
答案2
序列号（见RFC 6528）对于无法访问数据流的人来说应该是不可猜测的（某些攻击，特别是米特尼克 (Mitnick) 的著名作品，都是基于猜测并模仿对方）。这就是为什么 Linux 在这里使用真正的随机数。其他操作系统则更加草率，nmap检查他们做这件事的谨慎程度（可能还包含一个关于系统如何做的大量数据库）。没有可靠的随机数源对于 WiFi 路由器等机器来说尤其令人不安。
（是的，自从 TCP 的第一个版本以来，这种漏洞就已经为人所知并被警告；是的，许多操作系统/网络堆栈编写者由于懒惰，只是使用了一个固定的值，或者定期增加它，或者一些同样“智能”的东西，主要是为了“性能”。）