Cloudflare 在全球范围内每秒处理超过 6000 万个 HTTP 请求，其中大约 70% 的请求均通过 TCP 连接接收（其余的请求则通过 QUIC/UDP 连接接收）。理想情况下，与 Cloudflare 的每个新 TCP 连接都会携带至少一个导致数据交换成功的请求，但事实远非如此。实际上，我们发现，在全球范围内，大约 20% 与 Cloudflare 服务器的新 TCP 连接，其在请求完成之前或在初始请求之后会出现超时或关闭，并显示 TCP 连接“中止”消息。
本文将探讨 Cloudflare 服务器在进行有用的数据交换之前，那些出于各种原因而意外中断的连接。我们的研究表明，虽然连接通常由客户端中止，但也可能因受到第三方干扰而关闭。今天，我们很高兴地宣布将在 Cloudflare Radar 中推出一个新的仪表板和 API 端点，它会显示因重置或超时而在前 10 个入口数据包内终止的 Cloudflare 网络 TCP 连接，本文中我们将此类连接称为异常 TCP 连接。通过分析这种异常行为，可以获得关于扫描、连接篡改、DoS 攻击、连接问题，以及其他行为的见解。
根据对连接篡改的全球调查，我们能够通过 Radar 生成和共享这些数据。欢迎读者阅读同行评审研究中的技术细节，或参阅相应的演示文稿。请继续阅读，了解关于使用和解读数据的入门说明，以及我们如何设计和部署检测机制，以便其他人可以复制我们的方法。
首先，我们来论述正常与异常 TCP 连接的分类。
TCP 连接从建立到关闭
传输控制协议 (TCP) 是用于在互联网上的两台主机之间可靠地传输数据的协议 (RFC 9293)。TCP 连接会经历几个不同的阶段，也就是从连接建立到数据传输，再到连接关闭。
TCP 通过三次握手建立连接。握手始于其中称为“客户端”的一方，发送一个带有“SYN”标志的数据包来初始化连接流程。服务器回应一个“SYN+ACK”数据包，其中“ACK”标志会确认客户端的初始化“SYN”。初始化数据包与确认中均包含额外的同步信息。最后，客户端发送一个最终 ACK 数据包，确认接收到服务器的 SYN+ACK 数据包。至此，完成握手。
然后，连接准备就绪，可以进行数据传输。通常，客户端会在第一个包含数据的数据包上设置 PSH 标志，向服务器的 TCP 堆栈发出信号，要求其立即将数据转发给应用程序。双方继续传输数据并确认已收到的数据，直到不再需要连接。此时，将关闭连接。
RFC 9293 描述了关闭 TCP 连接的两种方式：
标准且正常的 TCP 关闭序列使用 FIN 交换。任何一方都可以发送设置了 FIN 标志的数据包，表明其没有更多数据要传输。在另一方确认 FIN 数据包之后，关闭该方向的连接。确认方完成数据传输后，它将传输自己的 FIN 数据包来关闭连接，因为必须独立关闭每个方向的连接。
中止或“重置”信号，其中一方传输 RST 数据包，指示另一方立即关闭并丢弃连接状态。通常情况下，如果发生了某些不可恢复的错误，则会发送重置请求。
下面的序列图展示了使用 FIN 标志，正常关闭连接的完整生命周期。
标准的 TCP 连接以三次握手开始，以 FIN 握手结束
此外，TCP 连接可能会因超时而终止，该超时设置指定了在未收到数据或确认的情况下，连接保持处于活动状态的最长持续时间。例如，可以使用 keepalive 消息让非活动状态的连接处于打开状态。除非设置遭到覆盖，RFC 9293 中指定的全局默认持续时间为五分钟。
如果 TCP 连接因客户端重置或超时而关闭，我们认为这属于异常连接。
异常连接的来源
异常 TCP 连接本身可能没有问题，但这可能是更大问题的征兆，特别是发生在 TCP 连接的早期（数据传输前）阶段时。以下是一份非详尽列表，展示了我们可能观察到重置或超时的潜在原因：
扫描程序：互联网扫描程序可能会发送 SYN 数据包来探测服务器是否在指定端口上做出响应，可一旦该探测获得源自服务器的响应，便无法清除连接。
应用程序突然关闭：应用程序可能会突然关闭已打开但不再需要的连接。例如，Web 浏览器可能会在关闭选项卡后发送 RST 来终止连接，或者如果设备断电或失去连接，连接可能会超时。
网络错误：网络条件不稳定（例如，电缆连接断开可能会导致连接超时）
攻击：恶意客户端可能会发送显示为异常连接的攻击流量。例如，在 SYN 洪水攻击（半开连接）中，攻击者反复向目标服务器发送 SYN 数据包，企图在维护这些半开连接时挤兑各种资源。
篡改：防火墙或其他能够拦截客户端与服务器之间的数据包的中间盒可能会丢弃数据包，导致通信双方超时。具备深度包检测 (DPI) 功能的中间盒也可能利用 TCP 协议未经身份验证且没有加密的事实来注入数据包，进而破坏连接状态。如需了解关于连接篡改的更多详细信息，请参阅我们随附的博客文章。
了解异常连接的规模和根本原因，可以帮助我们减少故障并构建一个更稳健、更可靠的网络。我们希望，公开分享这些见解有助于提高全球网络的透明度并加强问责制。
如何使用数据集
在本节中，我们通过广泛描述以下三个用例，提供关于如何理解 TCP 重置和超时数据集的指导与示例：确认之前已知的行为，探索后续研究的新目标，以及进行纵向研究来记录网络行为随时间变化的情况。
在每个示例中，情节主线与异常连接关闭的连接阶段相对应，这为找出可能导致异常的原因提供了有价值的线索。我们将每个入站连接置于以下任一阶段：
SYN 后（握手过程中）：服务器收到客户端的 SYN 数据包后，连接重置或超时。我们的服务器已做出回复，但在重置或超时之前，没有从客户端返回确认 ACK 数据包。数据包欺骗在此连接阶段很常见，因此，地理位置信息特别不可靠。
ACK 后（握手后紧接着）：握手完成且成功建立连接后，连接重置或超时。后续数据（本可能已传输的数据）都不会到达我们的服务器。
PSH 后（第一个数据包后）：服务器收到设置了 PSH 标志的数据包后，连接重置或超时。PSH 标志表明，TCP 数据包中包含已准备好发送给应用程序的数据（例如，TLS 客户端问候消息）。
后期（多个数据包后）：在服务器已接收了多个数据包后，连接在来自客户端的前 10 个数据包内重置。
无：所有其他连接。为了持续关注合法连接，我们在 Cloudflare 攻击缓解系统处理和过滤连接后构建了数据集。如需了解关于我们如何构建数据集的更多详细信息，请参阅下文。
从自我评估开始
首先，我们鼓励读者访问 Radar 上的仪表板，查看全球范围及自己所在国家/地区和 ISP 的结果。
如下图所示，在全球范围内，大约 20% 的 Cloudflare 网络新 TCP 连接因重置或超时，而在来自客户端的前 10 个数据包内关闭。虽然这个数字似乎出奇地高，但它与之前的研究结果一致。我们可以看到，重置率和超时率因国家/地区和网络而存在巨大差异，但这种差异在全球平均值中却消失不见。
我的祖国，美国的异常连接率略低于全球平均水平，主要是因为在 ACK 后与 PSH 后阶段的连接关闭率较低（这两个阶段更能反映中间盒篡改行为）。由于扫描，SYN 后的异常连接率偏高在大多数网络中属于常见现象，但可能包括欺骗真实客户端 IP 地址的数据包。同样地，后期阶段（初始数据交换后，但仍然在前 10 个数据包内）的连接重置率较高可能是因为应用程序对人为操作做出响应，例如在关闭选项卡后，浏览器使用 RST 关闭无用的 TCP 连接。
我的家庭 ISP AS22773 (Cox Communications) 显示的异常连接率与整个美国的比例不相上下。大多数在美国运营的住宅 ISP 都是如此。
将其与 AS15169 (Google LLC) 进行对比，后者是 Google 的众多爬网程序和提取程序的来源。此网络在“后期”阶段的连接重置率明显更低，这可能是因为自动化流量比例更高，而非由人类用户操作（例如，关闭浏览器选项卡）驱动。
事实上，我们的机器人检测系统将源自 AS15169 的 99% 以上的 HTTP 请求归类为自动化请求。这显示了整理 Radar 上不同类型数据的价值。
与 Radar 上出现的大多数数据集一样，新的异常连接数据集为被动数据，它只报告可观察的事件，而不是导致这些事件的原因。本着这一精神，上面的 Google 网络图表强化了确证观察的原因，我们接下来会展开讨论。
一个视图释放信号，多个视图可供确证
我们的被动衡量方法在 Cloudflare 规模上行之有效。但是，它自行识别根本原因或确定基本事实。对于某个连接在特定阶段关闭的原因，存在很多合理的解释，尤其是在因重置数据包和超时而关闭连接的情况下。企图仅仅依靠这个数据源来解释具体原因，只能得出推测。
不过，可以通过结合其他数据源（例如，主动衡量）来克服这种局限性。例如，与 OONI 或 Censored Planet 报告，或者实地报告相互印证，可以提供更完整的故事。因此，TCP 重置和超时数据集的主要用例之一是了解之前记录的异常现象的规模和影响。
确证互联网规模的衡量项目
查看 AS398324 可知，出现了严重错误，一半以上连接在 SYN 后阶段显示为异常连接。然而，此网络原来是来自互联网扫描公司 Censys 的 CENSYS-ARIN-01。SYN 后的异常连接可能是网络层扫描的结果，即扫描程序发送单个 SYN 数据包来探测服务器，但没有完成 TCP 握手。“后期”阶段的异常连接率也很高，这可能表明进行了应用层扫描，因为接近 100% 的连接被归类为自动化连接。
实际上，与 AS15169 类似，我们将源自 AS398324 的 99% 以上的请求归类为自动化请求。
到目前为止，我们了解了生成大量脚本流量或自动化流量的网络。现在，是时候放眼长远。
确证连接篡改
本着类似于我们在 HTTPS 拦截方面的工作精神，此数据集的起点是一个研究项目，旨在了解和检测活跃连接篡改。我们着手这样做的原因在随附的博客文章中有详细介绍。
强制关闭连接的一种有据可查的常见方法是重置注入。通过重置注入，到达目的地路径上的中间盒会检查数据包的数据部分。如果中间盒发现了发送至禁用域名的数据包，它向通信一方或双方注入伪造的 TCP 重置 (RST) 数据包，导致连接中止。如果中间盒没有首先丢弃禁用数据包，则服务器会收到触发中间盒篡改的客户端数据包，其中可能包含带有服务器名称指示 (SNI) 字段的 TLS 客户端问候消息，随后不久会收到伪造的 RST 数据包。
在 TCP 重置和超时数据集中，通过重置注入中断的连接通常显示为 ACK 后、PSH 后或“后期”阶段的异常（但需要提醒的一点是，并非所有异常连接都是由重置注入造成）。
例如，重置注入技术是已知的，并且通常与所谓的中国防火墙 (GFW) 相关。诚然，通过源自中国 IP 地址的连接中出现的 PSH 后阶段异常情况来看，我们发现其异常连接率高于全球平均水平。然而，从中国的各个网络来看，PSH 后异常连接率差异很大，这可能是由于承载的流量类型或实施的技术不同所致。相比之下，中国大多数主要自治系统 (AS) 的 SYN 后阶段异常连接率一直很高；可能的原因是扫描程序、欺骗性 SYN 洪水攻击，或残差块及其附带影响。
AS4134 (CHINANET-BACKBONE) 显示的 PSH 后连接异常率低于其他的中国 AS，但仍然远高于全球平均水平。
AS9808 (CHINAMOBILE-CN) 和 AS56046 (CMNET-Jiangsu-AP) 两个网络均显示，与 PSH 后异常连接相匹配的连接比例达到两位数。
如需了解关于连接篡改的更多信息，请参阅我们的深入剖析博客文章。
寻找后续研究的新见解和目标
TCP 重置和超时数据集也可以成为识别新的或以前未得到充分研究的网络行为的数据源，帮助找到“突出”且值得进一步研究的网络。
无法归因的 ZMap 扫描
这里有一个我们无法解释的问题：每天在相同的 18 小时间隔内，来自英国客户端的超过 10% 的连接从未经历过初始 SYN 数据包阶段，然后出现超时问题。
内部检查显示，几乎所有 SYN 后阶段异常连接都源自 AS396982（谷歌云平台）上使用 ZMap 的扫描程序，它似乎会对所有 IP 地址范围进行完整的端口扫描。（ZMap 客户端以负责任的态度进行自我识别，这是基于 ZMap 负责任的自我识别功能，请参见下文所述。）我们看到，源自 AS396982 的美国 IP 地址前缀的扫描流量也达到类似水平。
移动网络中的零费率
粗略观察一下国家/地区层面的异常连接率，便会发现一些有趣的结果。例如，看看源自墨西哥的连接，通常与连接篡改相关的 ACK 后和 PSH 后阶段异常连接率均高于全球平均水平。墨西哥的连接情况也与该区域的其他国家相似。不过，墨西哥这个国家“没有书面证据表明，该国政府或其他行为者阻止或过滤互联网内容”。
通过观察按 HTTP 流量体量排名靠前的墨西哥 AS，我们发现源自 AS28403 (RadioMovil Dipsa, S.A. de C.V., operating as Telcel) 的近 50% 的连接在完成 TCP 握手（ACK 后连接阶段）后因重置或超时而终止。在此阶段，中间盒可能在数据包到达 Cloudflare 之前就发现数据包并将其丢弃。
出现这种行为的一种原因可能是零费率服务，即，蜂窝网络提供商允许用户免费访问某些资源，例如消息发送或社交媒体应用程序。当用户超出其帐户的数据传输限制时，提供商可能仍然会允许流量流向零费率目的地，但同时阻止与其他资源的连接。
为了执行零费率政策，ISP 可能会使用 TLS 服务器名称指示 (SNI) 来确定是否阻止或允许连接。完成 TCP 握手之后，立即在包含数据的数据包中发送 SNI。因此，如果 ISP 丢弃包含 SNI 的数据包，服务器仍然可以看到源自客户端的 SYN 和 ACK 数据包，但看不到后续的数据包，这与 ACK 后阶段的连接异常相符。
再看一看秘鲁，这是数据集中拥有类似特征的另一个国家，其 ACK 后和后 PSH 阶段的异常连接率甚至比墨西哥更高。
就特定 AS 而言，我们发现 AS12252 (Claro Peru) 的 ACK 后阶段高异常连接率与墨西哥的 AS28403 不相上下。这两个网络均由同一家母公司 América Móvil 运营，因此，人们可能会认为二者采用了类似的网络策略和网络管理技术。
有趣的是，AS6147 (Telefónica Del Peru) 反而显示了较高的 PSH 后阶段异常连接率。这可能表明，此网络在网络层使用了不同技术来执行其策略。
随时间变化的纵向视图
我们持续的被动衡量最强大的一面在于，能够衡量网络在更长时间段内的性能。
互联网关闭
在 2024 年 6 月“关于叙利亚、伊拉克和阿尔及利亚最近的互联网关闭事件调查”这篇博客文章中，我们从 Cloudflare 网络的角度分享了上述国家与考试相关的全国互联网关闭的观点。当时我们正在准备 TCP 重置和超时数据集，这有助于确认外部报告并深入了解关闭网络所使用的具体方法。
作为行为改变的示例，我们可以“回到过去”，观察考试相关的网络阻止情况。在叙利亚，在与考试相关的网络关闭期间，我们看到 SYN 后阶段的异常连接率激增。实际上，我们看到这些时间段内的流量几乎全面下降（包括 SYN 数据包）。
从 7 月最后一周开始的第二轮网络关闭相当突出。
来看看伊拉克的情况，Cloudflare 对该国与考试相关的网络关闭的看法与叙利亚的情况类似，尽管没那么明显，但是在 SYN 后阶段出现了多次异常连接的峰值。
与考试相关的网络关闭博客还描述了阿尔及利亚在该国考试期间如何采取一种更微妙的方法来限制网络访问：有证据表明，阿尔及利亚没有完全关闭互联网，而是有针对性地关闭特定连接。实际上，我们发现，考试期间的 ACK 后阶段连接异常有所增加。如果中间盒选择性地丢弃包含禁止内容的数据包，同时保留其他数据包，则会出现这种行为（正如初始 SYN 和 ACK 后阶段）。
上述示例进一步证明，此数据与其他信号关联时最有用。也可以通过 API 获得此数据，以便其他人可以更深入地了解。我们的检测方法也可以转换应用于其他服务器和运营商，详见下文所述。
如何大规模检测异常 TCP 连接
在本节中，我们将讨论构建 TCP 重置和超时数据集的方法。Cloudflare 全球网络的规模为数据处理和分析带来了独特的挑战。我们在此分享各种方法，帮助读者了解 Cloudflare 的方法论，解读数据集，以及在其他网络或服务器中复制这些机制。
Cloudflare 的方法论可以总结为以下几点：
记录到达面向客户端的服务器的连接样本。这是一种完全被动的取样系统，也就是说，它无法解密流量，并且只能访问通过网络发送的现有数据包。
根据捕获的数据包重建连接。我们设计的一个新颖之处在于只需要观察一个方向，也就是从客户端到服务器。
将重建的连接与一组鲜明特征进行匹配，找出因重置或超时而终止的异常连接。这些特征由两部分组成：一个连接阶段，以及一组标记，这些标记表明了根据文献和自身观察得出的具体行为。
这些设计选项可确保加密数据包安全，并且可在任何地方加以复制，而无需访问目标服务器。
首先，取样连接
我们的主要目标是设计一种可扩展的机制，让我们能够全面了解到达 Cloudflare 网络的所有连接。虽然可以在每个面向客户端的服务器上运行流量捕获，但却无法扩展。我们还需要确切地知道应该在何处和何时进行观察，这导致难以持续记录见解。相反，我们从 Cloudflare 的所有服务器中取样连接并将其记录在一个中心位置，以便在该处执行离线分析。
这时，我们遇到了第一个障碍：Cloudflare 分析系统使用的现有数据包记录管道会记录单个数据包，但是一个连接由许多数据包组成。为了检测连接异常，我们需要查看指定连接中的所有数据包，或至少足够多数量的数据包。幸好我们能够利用 Cloudflare DoS 团队构建的灵活日志记录系统来分析 DDoS 攻击中涉及的数据包，结合调用精心设计的两个 iptables 规则来实现我们的目标。
第一个 iptables 规则会随机选择并标记新连接进行取样。在我们的案例中，我们决定每 10,000 个入口 TCP 连接中取样一个。这个数字并没有什么神奇之处，但考虑到 Cloudflare 网络的规模，它在捕获足够多的数据与不给数据处理和分析管道带来压力之间取得了平衡。 iptables 规则仅适用于通过 DDoS 缓解系统之后的数据包。鉴于 TCP 连接可能会长期存在，我们只对新的 TCP 连接进行取样。以下是用于标记待取样连接的 iptables 规则：
-t mangle -A PREROUTING -p tcp --syn -m state
--state NEW -m statistic --mode random
--probability 0.0001 -m connlabel --label <label>
--set -m comment --comment "Label a sample of ingress TCP connections"
分解来说，这个规则安装在处理入站数据包 (-A PREROUTING) 的链中的 mangle 表（用于修改数据包）中。仅当连接没有先前状态 (--state NEW) 时才考虑设置 SYN 标志的 TCP 数据包 (-p tcp --syn)。过滤器会在每 10,000 个 SYN 数据包中选择一个数据包 (-m statistic –mode random --probability 0.0001) 并将标签应用于连接 (-m connlabel --label <label> --set)。
第二个 iptables 规则会记录连接中的后续数据包，最多记录 10 个数据包。同样地，数字 10 也没有什么神奇之处，因为通常情况下，这些数据包足以捕获连接建立、后续请求数据包，以及在预期时间之前已关闭连接的重置。
-t mangle -A PREROUTING -m connlabel --label
<label> -m connbytes ! --connbytes 11
--connbytes-dir original --connbytes-mode packets
-j NFLOG --nflog-prefix "<logging flags>" -m
comment --comment "Log the first 10 incoming packets of each sampled ingress connection"
这个规则安装在与上一个规则相同的链中。它仅匹配来自已取样连接 (-m connlabel --label <label>) 的数据包，并且仅匹配每个连接的前 10 个数据包 (-m connbytes ! --connbytes 11 --connbytes-dir original --connbytes-mode packets)。匹配的数据包将会发送到 NFLOG (-j NFLOG --nflog-prefix "<logging flags>") ，日志记录系统会在此处提取这些数据包并将其保存到一个集中位置，以供离线分析。
根据已取样数据包重建连接
作为分析管道的一个步骤，在服务器上记录的数据包会插入 ClickHouse 表中。每个已记录的数据包都会存储在数据库中自己的数据行中。下一个挑战是将数据包重新组装到相应的连接中，以供进一步分析。但在进一步说明之前，我们需要定义本次分析所述的“连接”的具体含义。
我们使用由网络 5 元组，即 protocol, source IP address, source port 界定的连接标准定义，并进行以下调整：
我们仅在连接的入口（客户端到服务器）部分对数据包进行取样，因此，看不到从服务器到客户端的相应的响应数据包。在大多数情况下，我们可以根据对服务器配置方式的了解来推断服务器的响应内容。最终，入口数据包足以用于了解异常 TCP 连接行为。
我们每隔 15 分钟查询一次 ClickHouse 数据集，将在该间隔内共享相同网络 5 元组的数据包分组在一起。也就是说，连接可能会在查询间隔结束时被截断。在分析连接超时时，我们会排除不完整的流，即该流最新的数据包时间戳与查询截止相差不超过 10 秒。
由于重置和超时最有可能影响新连接，因此，我们只考虑以 SYN 数据包开头的数据包序列，这些数据包是新的 TCP 握手流程开始的标志，从而将长期存在的现有连接排除在外。
日志记录系统无法保证精确的数据包到达间隔时间戳，因此，我们仅考虑到达的数据包集合，而不是按其到达时间排序。在某些情况下，我们可能会根据 TCP 序列号确定数据包顺序，但事实证明，这不会对结果产生显著影响。
我们会过滤掉一小部分包含多个 SYN 数据包的连接，以减少分析中的干扰因素。
说明上述定义连接的条件之后，我们现在可以更详细地描述 Cloudflare 分析管道。
将连接关闭事件映射到不同阶段
TCP 连接从建立连接到最终关闭会经历一系列阶段。异常连接关闭的阶段会提供异常发生原因的线索。根据我们在服务器上接收的数据包，我们将每个入站连接置于四个阶段之一（SYN 后、ACK 后、PSH 后、后期），如上文所述。
仅连接关闭阶段就可以提供关于源自各种网络的异常 TCP 连接的有用见解，这正是目前 Cloudflare Radar 上显示的内容。然而，在某些情况下，我们可以通过将连接与更具体的特征进行匹配，提供更深入的见解
应用标记来描述更具体的连接行为
上文所述的连接阶段分组均完全基于连接中数据包的 TCP 标志。考虑各种其他因素，例如数据包的到达间隔时间、TCP 标志的精确组合以及其他数据包字段（IP 标识、IP TTL、TCP 序列和确认编号、TCP 窗口大小等），可以更精细化地匹配具体行为。
例如，流行的 ZMap 扫描程序软件在其生成的 SYN 数据包（源代码）中将 IP 标识字段固定为 54321，将 TCP 窗口大小固定为 65535。当我们看到到达 Cloudflare 网络的数据包中设置了确切的这些字段时，该数据包很可能是由使用 ZMap 的扫描程序生成。
还可以使用标记将连接与篡改中间盒的已知特征进行匹配。大量主动衡量研究（例如，Weaver、Sommer 和 Paxson）发现，一些中间盒部署在通过重置注入来中断连接的过程中表现出一致的行为，例如，设置与客户端发送的其他数据包不同的 IP TTL 字段，或同时发送 RST 数据包和 RST+ACK 数据包。如需了解关于特定连接篡改特征的更多信息，请参阅博客文章和同行评审论文。
目前，我们定义了以下标记，并打算随着时间的推移逐步完善和扩展这些标签。有些标记只有在设置了另一个标记的情况下才适用，如下面的层次结构表示方法所示（例如，fin 标记只有在设置了 reset 标记时才适用）。
timeout：因超时而终止reset：因重置而终止（数据包设置了 RST 标志）fin：至少收到了一个 FIN 数据包，以及一个或多个 RST 数据包
single_rst：连接终止，收到了一个 RST 数据包multiple_rsts：连接终止，收到了多个 RST 数据包acknumsame：RST 数据包中的确认编号全部相同且非零acknumsame0：RST 数据包中的确认编号全部为零acknumdiff：RST 数据包中的确认编号各不相同且全部非零acknumdiff0：RST 数据包中的确认编号各不相同，且其中之一为零
single_rstack：连接终止，收到了单个 RST+ACK 数据包（同时设置了 RST 和 ACK 标志）multiple_rstacks：连接终止，收到了多个 RST+ACK 数据包rst_and_rstacks：连接终止，收到了 RST 和 RST+ACK 数据包的组合
zmap：SYN 数据包与 ZMap 扫描程序生成的数据包匹配
目前 Radar 仪表板和 API 中均无法查看连接标记，但我们计划在未来发布这项额外功能。
接下来？
Cloudflare 的使命是帮助构建更好的互联网，我们认为提高透明度和加强问责制是实现使命的关键所在。希望我们分享的这些见解和工具，有助于揭示世界各地的异常网络行为。
虽然现有的 TCP 重置和超时数据集应该会立即证明对网络运营商、研究人员和互联网用户有用，但我们不会止步于此。未来，我们希望增添几项改进功能：
扩展见解，涵盖从 Cloudflare 到客户源服务器的连接。
添加 QUIC 支持。目前 Cloudflare 全球范围内 30% 以上的 HTTP 请求都使用 QUIC。
如果您认为本博客有趣，我们鼓励您阅读随附的博客文章和白皮书，深入了解连接篡改，以及探索 Cloudflare Radar 上的 TCP 重置和超时仪表板和 API。如有任何问题和意见，欢迎您通过 radar@cloudflare.com 联系我们。