Cloudflare 在全球範圍內每秒處理超過 6,000 萬個 HTTP 請求，其中約 70% 透過 TCP 連線接收（其餘為 QUIC/UDP）。理想情況下，與 Cloudflare 的每個新 TCP 連線都將攜帶至少一個導致成功資料交換的請求，但這遠非事實。事實上，我們發現，在全球範圍內，大約 20% 的 Cloudflare 伺服器新 TCP 連線在任何請求完成之前或在初始請求之後立即逾時或被 TCP「中止」訊息關閉。
這篇文章探討了那些由於各種原因（在我們的伺服器看來）在發生任何有用資料交換之前就意外停止的連線。我們的工作表明，雖然連線通常由用戶端終止，但也可能由於第三方乾擾而關閉。今天，我們很高興地在 Cloudflare Radar 上推出新的儀表板和 API 端點，它顯示了前往 Cloudflare 網路的 TCP 連線的近乎即時檢視，這些連線由於重設或逾時而在前 10 個輸入封包內終止，我們在本文中將其稱為異常 TCP 連線。分析這種異常行為可以深入瞭解掃描、連線竄改、DoS 攻擊、連線問題和其他行為。
我們透過 Radar 產生和共用這些資料的能力源於對連線竄改的全球調查。請讀者閱讀同行審查研究中的技術細節，或查看其對應的簡報。請繼續閱讀，瞭解如何使用和解釋資料，以及我們是如何設計和部署偵測機制的，以便其他人可以複製我們的方法。
首先，讓我們討論一下正常與異常 TCP 連線的分類。
TCP 連線從建立到關閉的過程
傳輸控制通訊協定 (TCP) 是一種用於在網際網路上兩個主機之間可靠地傳輸資料的通訊協定 (RFC 9293)。TCP 連線會經歷幾個不同的階段，從連線建立到資料傳輸，再到連線關閉。
TCP 連線是透過 3 向交握建立的。當稱為用戶端的一方傳送標有「SYN」標誌的封包以初始化連線過程時，交握就開始了。伺服器以「SYN+ACK」封包回應，其中的「ACK」標誌確認用戶端的初始化「SYN」。初始化封包及其確認中包含額外的同步資訊。最後，用戶端使用最終 ACK 封包確認伺服器的 SYN+ACK 封包以完成交握。
然後，連線就可以進行資料傳輸了。通常，用戶端將在第一個包含資料的封包上設定 PSH 標誌，以通知伺服器的 TCP 堆疊，立即將資料轉寄給應用程式。雙方繼續傳輸資料並確認收到的資料，直到不再需要連線，此時連線將關閉。
RFC 9293 描述了可能關閉 TCP 連線的兩種方式：
正常且平穩的 TCP 關閉序列使用 FIN 交換。任何一方都可以傳送設定了 FIN 標誌的封包，以表明它們沒有更多的資料要傳輸。在另一方確認該 FIN 封包後，該方向的連線將關閉。當確認方完成資料傳輸時，它會傳輸自己的 FIN 封包以關閉，因為連線的每個方向都必須獨立關閉。
一個中止或「重設」訊號，其中一方傳輸 RST 封包，指示另一方立即關閉並捨棄任何連線狀態。重設通常會在發生某些無法復原的錯誤時傳送。
下圖展示了使用 FIN 正常關閉的連線的完整生命週期。
正常的 TCP 連線以 3 向交握開始，以 FIN 交握結束
此外，TCP 連線可能會因逾時而終止，逾時指定連線在不接收資料或無確認的情況下可以處於作用中狀態的最大持續時間。例如，非作用的連線可以透過 keepalive 訊息保持開啟狀態。除非被覆寫，否則 RFC 9293 中指定的全域預設持續時間為五分鐘。
當 TCP 連線透過用戶端的重設或逾時關閉時，我們認為 TCP 連線是異常的。
異常連線的來源
異常 TCP 連線本身可能沒有問題，但它們可能是更大問題的徵兆，特別是當發生在 TCP 連線的早期（資料前）階段時。以下是我們可能觀察到重設或逾時的非詳盡潛在原因清單：
掃描程式：網際網路掃描程式可能會傳送 SYN 封包來探查伺服器是否在給定連接埠上做出回應，但一旦探查引發了伺服器的回應，則無法清理連線。
應用程式突然關閉：如果應用程式不再需要連線，可能會突然關閉開啟的連線。例如，Web 瀏覽器可能會在索引標籤關閉後傳送 RST 以終止連線，或者如果裝置斷電或連線性中斷，連線可能會逾時。
網路錯誤：網路狀況不穩定（例如，電纜連線斷開可能導致連線逾時）
攻擊：惡意用戶端可能會傳送顯示為異常連線的攻擊流量。例如，在 SYN 洪水（半開放）攻擊中，攻擊者重複向目標伺服器傳送 SYN 封包，以試圖在目標伺服器維持這些半開放連線時淹沒資源。
竄改：能夠攔截用戶端和伺服器之間封包的防火牆或其他中間件可能會捨棄封包，導致通訊雙方逾時。具有深度封包偵測 (DPI) 功能的中間件還可能利用 TCP 通訊協定未經驗證和未加密的事實來插入封包以破壞連線狀態。有關連線竄改的更多詳細資料，請參閱我們相關聯的部落格文章。
瞭解異常連線的規模和根本原因，可以幫助我們減少失敗並構建一個更強大、更可靠的網路。我們希望公開分享這些見解將有助於提高全球網路的透明度和問責制。
如何使用資料集
在本節中，我們將透過廣泛描述三個使用案例來提供如何解釋 TCP 重設和逾時資料集的指導和範例：確認先前已知的行為、探索後續研究的新目標以及擷取網路行為隨時間變化的縱向研究。
在每個範例中，情節線對應於異常連線關閉的連線階段，這為瞭解可能導致異常的原因提供了寶貴的線索。我們將每個傳入連線置於以下其中一個階段：
Post-SYN（交握期間）：伺服器收到用戶端的 SYN 封包後，連線重設或逾時。我們的伺服器已經回覆，但在重設或逾時之前，用戶端沒有傳回任何確認 ACK 封包。封包詐騙在此連線階段很常見，因此地理位置資訊特別不可靠。
Post-ACK（交握後立即）：在交握完成並成功建立連線後，連線重設或逾時。任何可能已經傳輸的後續資料都永遠不會到達我們的伺服器。
Post-PSH（第一個資料封包之後）：伺服器收到設定了 PSH 標誌的資料包後連線重設或逾時。PSH 標誌表明 TCP 封包包含已準備好傳送到應用程式的資料（例如 TLS Client Hello 訊息）。
後期（在多個資料封包之後）：在用戶端已傳出不到 10 個封包，但伺服器已收到多個資料封包後，連線重設。
無：所有其他連線。
為了將重點放在合法連線上，資料集是在 Cloudflare 的攻擊緩解系統處理和篩選連線之後構建的。有關我們如何構建資料集的更多詳細資料，請參見下文。
從自我評估開始
首先，我們鼓勵讀者造訪 Radar 儀表板，查看全球範圍以及自身所在國家/地區和 ISP 的結果。
在全球範圍內，如下所示，與 Cloudflare 網路的新 TCP 連線中，約有 20% 在用戶端傳出不到 10 個封包後因重設或逾時而關閉。雖然這個數字似乎高得驚人，但與先前的研究是一致的。正如我們將看到的，重設和逾時率因國家/地區和網路而異，並且這種差異在全球平均值中被忽略。
Cloudflare 所在地美國的異常連線率略低於全球平均水平，這主要是由於在 Post-ACK 和 Post-PSH 階段連線關閉率較低（這些階段更能反映中間件竄改行為）。由於掃描，Post-SYN 速率升高在大多數網路中都很常見，但可能包含掩蓋真實用戶端 IP 位址的封包。同樣，後期連線階段（初始資料交換之後，但仍在前 10 個封包內）的高連線重設率可能是由於應用程式回應人類動作，例如瀏覽器在索引標籤關閉後使用 RST 關閉不需要的 TCP 連線。
Cloudflare 所在 ISP AS22773 (Cox Communications) 顯示的比率與整個美國相當。這是在美國營運的大多數住宅 ISP 的典型情況。
將此與 AS15169 (Google LLC) 進行對比，AS15169 起源於 Google 的許多爬蟲程式和擷取程式。該網路在「後期」連線階段展現出明顯較低的重設率，這可能是由於自動化流量比例較大，而不是由人類使用者動作（例如關閉瀏覽器索引標籤）驅動的。
實際上，我們的機器人偵測系統將來自 AS15169 的超過 99% 的 HTTP 要求歸類為自動要求。這表明了在 Radar 上整理不同類型資料的價值。
與 Radar 上出現的大多數資料集一樣，新的異常連線資料集是被動的——它只報告可觀察到的事件，而不是導致它們的原因。本著這種精神，上面的 Google 網路圖表重點表明了證實觀察結果的原因，我們接下來將討論這些原因。
一次檢視獲取訊號，更多檢視獲取佐證
我們的被動測量方法適用於 Cloudflare 規模。然而，它本身並不能識別根本原因或基本事實。對於連線在特定階段關閉的原因，有許多合理的解釋，特別是當關閉是由於重設封包和逾時而導致時。若僅僅只是依靠這一資料來源來進行解釋，我們只能得到猜測的結果。
但是，可以透過結合其他資料來源（例如主動測量）來克服此限制。例如，使用 OONI 或 Censored Planet 的報告，或者使用實地報告佐證，可以得到更全面的資訊。因此，TCP 重設和逾時資料集的主要使用案例之一是瞭解先前所記錄現象的規模和影響。
證實網際網路規模的測量專案
查看 AS398324，其結果表明出現了嚴重錯誤，超過一半的連線在 Post-SYN 階段顯示為異常。然而，這個網路原來是 CENSYS-ARIN-01，來自網際網路掃描公司 Censys。Post-SYN 異常可能是網路層掃描的結果，其中掃描程式傳送單一 SYN 封包來探查伺服器，但不完成 TCP 交握。後期異常的發生率也很高，這可能表明存在應用程式層掃描，正如接近 100% 比例的連線被歸類為自動化流量所表明的那樣。
實際上，與 AS15169 類似，我們將 AS398324 中超過 99% 的要求歸類為自動化要求。
到目前為止，我們已經研究了會產生大量指令碼或自動化流量的網路。是時候放眼更遠的地方了。
證實連線竄改
此資料集的出發點是作為瞭解和偵測主動連線竄改的研究專案，本質與我們在 HTTPS 攔截方面的工作類似。相關聯的部落格文章中詳細解釋了我們這樣做的原因。
強制關閉連線的一種有據可查的流行技術是重設插入。透過重設插入，前往目的地之路徑上的中間件會檢查封包的資料部分。當中間件看到前往禁止網域名稱的封包時，它會將偽造的 TCP 重設 (RST) 封包插入一個或兩個通訊方，導致它們中止連線。如果中間件沒有先捨棄禁止的封包，則伺服器將收到觸發中間件竄改的用戶端封包（可能包含帶有伺服器名稱指示 (SNI) 欄位的 TLS Client Hello 訊息），隨後很快又收到偽造的 RST 封包。
在 TCP 重設和逾時資料集中，因重設插入而中斷的連線通常會顯示為 Post-ACK、Post-PSH 或後期異常（但需要注意的是，並非所有異常都是由於重設插入造成）。
例如，重設插入技術是已知的並且通常與所謂的中國防火長城 (GFW) 相關。事實上，透過查看源自中國 IP 之連線中的 Post-PSH 異常，我們發現比率高於全球平均水平。然而，從中國的各個網路來看，Post-PSH 速率差異很大，這可能是由於承載的流量類型或實施了不同技術所造成的。相較之下，大多數中國主要自治系統的 Post-SYN 異常發生率始終很高；這可能是掃描程式、欺騙性 SYN 洪水攻擊或具有附帶影響的殘餘封鎖。
AS4134 (CHINANET-BACKBONE) 的 Post-PSH 異常率低於中國其他 AS，但仍遠高於全球平均水平。
網路 AS9808 (CHINAMOBILE-CN) 和 AS56046 (CMNET-Jiangsu-AP) 符合 Post-PSH 異常的連線百分比達到了兩位數。
請參閱我們的深入解讀部落格貼文，瞭解有關連線竄改的更多資訊。
為後續研究尋找新的深入解析和目標
TCP 重設和逾時資料集還可以作為識別新的或先前未充分研究的網路行為的來源，幫助找到「突出」並值得進一步研究的網路。
無法歸因的 ZMap 掃描
以下是我們無法解釋的情況：每天在相同的 18 小時間隔內，來自英國用戶端超過 10% 的連線從未超過初始 SYN 封包，直接逾時。
內部檢查顯示，幾乎所有 Post-SYN 異常都來自使用 AS396982 (GOOGLE-CLOUD-PLATFORM) 上的 ZMap 的掃描程式，這似乎是對所有 IP 位址範圍的完整連接埠掃描。（ZMap 用戶端負責任地進行自我識別，基於稍後討論的 ZMap 負責任的自我識別。）我們看到，來自美國 AS396982 中的 IP 首碼的掃描流量與此類似。
行動網路零費率
粗略看一下國家/地區層面的異常率，可以發現一些有趣的現象。例如，看看來自墨西哥的連線，通常與連線竄改相關的 Post-ACK 和 Post-PSH 異常的比率高於全球平均水平。墨西哥連線的情況也與該地區其他國家相似。然而，墨西哥是一個「沒有書面證據表明政府或其他行為者封鎖或篩選網際網路內容的國家。」
透過查看墨西哥 HTTP 流量排名靠前的每個 AS，我們發現來自 AS28403（RadioMovil Dipsa，S.A. de C.V.，作為 Telcel 營運）的近 50% 的連線在完成 TCP 交握後（Post-ACK 連線階段）立即因重設或逾時而直接終止。在此階段，可能是有一個中間件在封包到達 Cloudflare 之前發現並捨棄了封包。
對這種行為的一種解釋可能是零費率，在這種情況下，行動數據網路提供者允許免費存取某些資源（例如訊息傳遞或社交媒體應用程式）。當使用者超過其帳戶上的資料傳輸限制時，提供者可能仍允許流量到達零費率目的地，但會封鎖與其他資源的連線。
為了實施零費率原則，ISP 可能會使用 TLS 伺服器名稱指示 (SNI) 來確定是封鎖還是允許連線。在 TCP 交握後，會立即在包含資料的封包中傳送 SNI。因此，如果 ISP 捨棄包含 SNI 的封包，伺服器仍會看到來自用戶端的 SYN 和 ACK 封包，但看不到後續封包，這與 Post-ACK 連線異常一致。
轉向資料集中具有相似概況的另一個國家秘魯，與墨西哥相比，Post-ACK 和 Post-PSH 異常的發生率甚至更高。
重點關注具體 AS，我們發現 AS1222 (Claro Peru) 顯示出與墨西哥的 AS28403 類似的高 Post-ACK 異常率。這兩個網路均由同一家母公司 América Móvil 經營，因此它們可能採用了類似的網路原則和網路管理技術。
有趣的是，AS6147 (Telefónica Del Perú) 卻顯示出較高的 Post-PSH 連線異常率。這可能表示此網路在網路層使用不同的技術來強制執行其原則。
隨時間變化的縱向檢視
我們的持續被動測量最強大的一個方面是能夠在較長時間內測量網路。
網際網路關停
在我們 2024 年 6 月的部落格文章《敘利亞、伊拉克和阿爾及利亞最近的考試期間網際網路關停情況》中，我們從 Cloudflare 網路的角度分享了與考試相關的全國網際網路關閉的情況。當時我們正在準備 TCP 重設和逾時資料集，這有助於確認外部報告並深入瞭解用於關閉的特定技術。
作為行為改變的範例，我們可以「回到過去」觀察與考試相關的封鎖發生的情況。在敘利亞，在與考試相關的關閉期間，我們看到 Post-SYN 異常的發生率激增。事實上，我們發現這些期間的流量（包括 SYN 封包）幾乎完全停止。
從 7 月最後一週開始的第二輪關停也非常突出。
查看來自伊拉克的連線，Cloudflare 所看到的考試相關關停情況似乎與敘利亞相似，都有多個 Post-SYN 峰值，不過沒那麼明顯。
考試關停部落格還描述了阿爾及利亞如何採取更細緻的方法來限制考試期間對內容的存取：有證據表明，阿爾及利亞沒有完全關閉網際網路，而是針對特定連線。事實上，在考試期間，我們發現 Post-ACK 連線異常增加。如果中間件選擇性地捨棄包含禁止內容的封包，同時保留其他封包（例如初始 SYN 和 ACK），則預計會發生這種情況。
上述範例表明，這些資料在與其他訊號相關時最有用。這些資料也可以透過 API 獲取，以便其他人可以更深入地研究。我們的偵測技術也可以轉移到其他伺服器和營運商，如下所述。
如何大規模偵測異常 TCP 連線
在本節中，我們將討論如何構建 TCP 重設和逾時資料集。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"
詳細來說，該規則安裝在處理傳入封包的鏈中的 mangle 表中（用於修改封包）(-A PREROUTING)。僅考慮設定了 SYN 標誌的 TCP 封包 (-p tcp --syn)，其中沒有連線的先前狀態 (--state NEW)。篩選器從每 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 表中。每個記錄的封包都儲存在資料庫內自己的列中。下一個挑戰是將封包重新組裝到相應的連線中以進行進一步分析。在進一步討論之前，我們需要定義用於分析目的的「連線」是什麼。
我們使用由網路五元組 protocol、source IP address、source port、destination IP address、destination port 定義的連線標準定義，並進行以下調整：
我們僅在連線中途的入口（用戶端到伺服器）對資料包進行採樣，因此看不到從伺服器到用戶端的相應回應封包。在大多數情況下，我們可以根據對伺服器設定方式的瞭解，推斷出伺服器回應的內容。最終，輸入封包足以用於瞭解異常 TCP 連線行為。
我們以 15 分鐘的間隔查詢 ClickHouse 資料集，並將該間隔內共用相同網路 5 元組的封包分組在一起。這意味著連線可能會在查詢間隔即將結束時被截斷。分析連線逾時時，我們會排除最新封包時間戳記在查詢截止時間後 10 秒內的不完整流程。
由於重設和逾時最有可能影響新連線，因此我們僅考慮以標記新 TCP 交握開始的 SYN 封包開頭的封包序列。這樣，已有的長期連線被排除在外。
記錄系統不保證精確的封包到達間隔時間戳記，因此我們僅考慮到達的封包集，而不是按到達時間排序。在某些情況下，我們可以根據 TCP 序號確定封包排序，但事實證明這不會對結果產生重大影響。
我們會篩選掉一小部分具有多個 SYN 封包的連線，以減少分析中的雜訊。
有了上述定義連線的條件，我們現在可以更詳細地描述我們的分析管道。
將連線關閉事件對應至階段
TCP 連線經歷從連線建立到最終關閉的一系列階段。異常連線關閉的階段提供了有關異常發生原因的線索。根據我們在伺服器上收到的封包，我們將每個傳入連線放入四個階段之一（Post-SYN、Post-ACK、Post-PSH、後期），上文中對此進行了詳細介紹。
僅連線關閉階段就提供了對來自各種網路的異常 TCP 連線的有用見解，如今，Cloudflare Radar 上已經顯示了相關內容。但是，在某些情況下，我們可以透過將連線與更具體的簽章進行匹配來提供更深入的見解。
套用標記來描述更具體的連線行為
上述將連線分組為階段的過程僅基於連線中封包的 TCP 標誌來完成。考慮到其他因素，例如封包到達間隔時間、TCP 標誌的確切組合以及其他封包欄位（IP 識別、IP TTL、TCP 序列和確認號碼、TCP 視窗大小等），可以允許更精細地匹配特定行為。
例如，流行的 ZMap 掃描程式軟體在其產生的 SYN 封包中將 IP 標識欄位固定為 54321，將 TCP 視窗大小固定為 65535（來源碼）。當我們看到到達網路的封包設定了這些確切的欄位時，該封包很可能是由使用 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 與我們聯繫，提出您自己的問題和意見。