Cloudflare Radar已引入關于TCP重置和超時的洞察及見解

來源：Cloudflare

作者：Cloudflare

時間：2024-11-01

Cloudflare在全球范圍內每秒處理超過6000萬個HTTP請求，其中大約70%的請求均通過TCP連接接收（其余的請求則通過QUIC/UDP連接接收）。

Cloudflare在全球范圍內每秒處理超過6000萬個HTTP請求，其中大約70%的請求均通過TCP連接接收（其余的請求則通過QUIC/UDP連接接收）。理想情況下，與Cloudflare的每個新TCP連接都會攜帶至少一個導致數(shù)據(jù)交換成功的請求，但事實遠非如此。實際上，我們發(fā)現(xiàn)，在全球范圍內，大約20%與Cloudflare服務器的新TCP連接，其在請求完成之前或在初始請求之后會出現(xiàn)超時或關閉，并顯示TCP連接“中止”消息。

本文將探討Cloudflare服務器在進行有用的數(shù)據(jù)交換之前，那些出于各種原因而意外中斷的連接。我們的研究表明，雖然連接通常由客戶端中止，但也可能因受到第三方干擾而關閉。為此，我們很高興地宣布將在Cloudflare Radar中推出一個新的儀表板和API端點，它會顯示因重置或超時而在前10個入口數(shù)據(jù)包內終止的Cloudflare網絡TCP連接，本文中我們將此類連接稱為異常TCP連接。通過分析這種異常行為，可以獲得關于掃描、連接篡改、DoS攻擊、連接問題，以及其他行為的洞察及見解。

根據(jù)對連接篡改的全球調查，我們能夠通過Radar生成和共享這些數(shù)據(jù)。歡迎讀者閱讀同行評審研究中的技術細節(jié)，或參閱相應的演示文稿。請繼續(xù)閱讀，了解關于使用和解讀數(shù)據(jù)的入門說明，以及我們如何設計和部署檢測機制，以便其他人可以復制我們的方法。

首先，我們來論述正常與異常TCP連接的分類。

TCP連接從建立到關閉

傳輸控制協(xié)議（TCP）是用于在互聯(lián)網上的兩臺主機之間可靠地傳輸數(shù)據(jù)的協(xié)議（RFC 9293）。TCP連接會經歷幾個不同的階段，也就是從連接建立到數(shù)據(jù)傳輸，再到連接關閉。

TCP通過三次握手建立連接。握手始于其中稱為“客戶端”的一方，發(fā)送一個帶有“SYN”標志的數(shù)據(jù)包來初始化連接流程。服務器回應一個“SYN+ACK”數(shù)據(jù)包，其中“ACK”標志會確認客戶端的初始化“SYN”。初始化數(shù)據(jù)包與確認中均包含額外的同步信息。最后，客戶端發(fā)送一個最終ACK數(shù)據(jù)包，確認接收到服務器的SYN+ACK數(shù)據(jù)包。至此，完成握手。

然后，連接準備就緒，可以進行數(shù)據(jù)傳輸。通常，客戶端會在第一個包含數(shù)據(jù)的數(shù)據(jù)包上設置PSH標志，向服務器的TCP堆棧發(fā)出信號，要求其立即將數(shù)據(jù)轉發(fā)給應用程序。雙方繼續(xù)傳輸數(shù)據(jù)并確認已收到的數(shù)據(jù)，直到不再需要連接。此時，將關閉連接。

RFC 9293描述了關閉TCP連接的兩種方式：

-標準且正常的TCP關閉序列使用FIN交換。任何一方都可以發(fā)送設置了FIN標志的數(shù)據(jù)包，表明其沒有更多數(shù)據(jù)要傳輸。在另一方確認FIN數(shù)據(jù)包之后，關閉該方向的連接。確認方完成數(shù)據(jù)傳輸后，它將傳輸自己的FIN數(shù)據(jù)包來關閉連接，因為必須獨立關閉每個方向的連接。

-中止或“重置”信號，其中一方傳輸RST數(shù)據(jù)包，指示另一方立即關閉并丟棄連接狀態(tài)。通常情況下，如果發(fā)生了某些不可恢復的錯誤，則會發(fā)送重置請求。

下面的序列圖展示了使用FIN標志，正常關閉連接的完整生命周期。

標準的TCP連接以三次握手開始，以FIN握手結束

此外，TCP連接可能會因超時而終止，該超時設置指定了在未收到數(shù)據(jù)或確認的情況下，連接保持處于活動狀態(tài)的最長持續(xù)時間。例如，可以使用keepalive消息讓非活動狀態(tài)的連接處于打開狀態(tài)。除非設置遭到覆蓋，RFC 9293中指定的全局默認持續(xù)時間為五分鐘。

如果TCP連接因客戶端重置或超時而關閉，我們認為這屬于異常連接。

異常連接的來源

異常TCP連接本身可能沒有問題，但這可能是更大問題的征兆，特別是發(fā)生在TCP連接的早期（數(shù)據(jù)傳輸前）階段時。以下是一份非詳盡列表，展示了我們可能觀察到重置或超時的潛在原因：

-掃描程序：互聯(lián)網掃描程序可能會發(fā)送SYN數(shù)據(jù)包來探測服務器是否在指定端口上做出響應，可一旦該探測獲得源自服務器的響應，便無法清除連接。

-應用程序突然關閉：應用程序可能會突然關閉已打開但不再需要的連接。例如，Web瀏覽器可能會在關閉選項卡后發(fā)送RST來終止連接，或者如果設備斷電或失去連接，連接可能會超時。

-網絡錯誤：網絡條件不穩(wěn)定（例如，電纜連接斷開可能會導致連接超時）

-攻擊：惡意客戶端可能會發(fā)送顯示為異常連接的攻擊流量。例如，在SYN洪水攻擊（半開連接）中，攻擊者反復向目標服務器發(fā)送SYN數(shù)據(jù)包，企圖在維護這些半開連接時擠兌各種資源。

-篡改：防火墻或其他能夠攔截客戶端與服務器之間的數(shù)據(jù)包的中間盒可能會丟棄數(shù)據(jù)包，導致通信雙方超時。具備深度包檢測（DPI）功能的中間盒也可能利用TCP協(xié)議未經身份驗證且沒有加密的事實來注入數(shù)據(jù)包，進而破壞連接狀態(tài)。如需了解關于連接篡改的更多詳細信息，請參閱我們隨附的博客文章。

了解異常連接的規(guī)模和根本原因，可以幫助我們減少故障并構建一個更穩(wěn)健、更可靠的網絡。我們希望，公開分享這些見解有助于提高全球網絡的透明度并加強問責制。

如何使用數(shù)據(jù)集

在本小節(jié)中，我們通過廣泛描述以下三個用例，提供關于如何理解TCP重置和超時數(shù)據(jù)集的指導與示例：確認之前已知的行為，探索后續(xù)研究的新目標，以及進行縱向研究來記錄網絡行為隨時間變化的情況。

在每個示例中，情節(jié)主線與異常連接關閉的連接階段相對應，這為找出可能導致異常的原因提供了有價值的線索。我們將每個入站連接置于以下任一階段：

-SYN后（握手過程中）：服務器收到客戶端的SYN數(shù)據(jù)包后，連接重置或超時。我們的服務器已做出回復，但在重置或超時之前，沒有從客戶端返回確認ACK數(shù)據(jù)包。數(shù)據(jù)包欺騙在此連接階段很常見，因此，地理位置信息特別不可靠。

-ACK后（握手后緊接著）：握手完成且成功建立連接后，連接重置或超時。后續(xù)數(shù)據(jù)（本可能已傳輸?shù)臄?shù)據(jù)）都不會到達我們的服務器。

-PSH后（第一個數(shù)據(jù)包后）：服務器收到設置了PSH標志的數(shù)據(jù)包后，連接重置或超時。PSH標志表明，TCP數(shù)據(jù)包中包含已準備好發(fā)送給應用程序的數(shù)據(jù)（例如，TLS客戶端問候消息）。

-后期（多個數(shù)據(jù)包后）：在服務器已接收了多個數(shù)據(jù)包后，連接在來自客戶端的前10個數(shù)據(jù)包內重置。

-無（None）：所有其他連接。為了持續(xù)關注合法連接，我們在Cloudflare攻擊緩解系統(tǒng)處理和過濾連接后構建了數(shù)據(jù)集。如需了解關于我們如何構建數(shù)據(jù)集的更多詳細信息，請參閱下文。

從自我評估開始

首先，我們鼓勵讀者訪問Radar上的儀表板，查看全球范圍及自己所在國家/地區(qū)和ISP的結果。

如下圖所示，在全球范圍內，大約20%的Cloudflare網絡新TCP連接因重置或超時，而在來自客戶端的前10個數(shù)據(jù)包內關閉。雖然這個數(shù)字看似出奇地高，但它與之前的研究結果一致。我們可以看到，重置率和超時率因國家/地區(qū)和網絡而存在巨大差異，但這種差異在全球平均值中卻消失不見。

通過Cloudflare Radar

美國的異常連接率略低于全球平均水平，主要是因為在ACK后與PSH后階段的連接關閉率較低（這兩個階段更能反映中間盒篡改行為）。由于掃描，SYN后的異常連接率偏高在大多數(shù)網絡中屬于常見現(xiàn)象，但可能包括欺騙真實客戶端IP地址的數(shù)據(jù)包。同樣地，后期階段（初始數(shù)據(jù)交換后，但仍然在前10個數(shù)據(jù)包內）的連接重置率較高可能是因為應用程序對人為操作做出響應，例如在關閉選項卡后，瀏覽器使用RST關閉無用的TCP連接。

通過Cloudflare Radar

我的家庭ISP AS22773（Cox Communications）顯示的異常連接率與整個美國的比例不相上下。大多數(shù)在美國運營的住宅ISP都是如此。

通過Cloudflare Radar

將其與AS15169（Google LLC）進行對比，后者是Google的眾多爬網程序和提取程序的來源。此網絡在“后期”階段的連接重置率明顯更低，這可能是因為自動化流量比例更高，而非由人類用戶操作（例如，關閉瀏覽器選項卡）驅動。

通過Cloudflare Radar

事實上，我們的機器人檢測系統(tǒng)將源自AS15169的99%以上的HTTP請求歸類為自動化請求。這顯示了整理Radar上不同類型數(shù)據(jù)的價值。

通過Cloudflare Radar

與Radar上出現(xiàn)的大多數(shù)數(shù)據(jù)集一樣，新的異常連接數(shù)據(jù)集為被動數(shù)據(jù)，它只報告可觀察的事件，而不是導致這些事件的原因。本著這一精神，上面的Google網絡圖表強化了確證觀察的原因，我們接下來會展開討論。

一個視圖釋放信號，多個視圖可供確證

我們的被動衡量方法在Cloudflare規(guī)模上行之有效。但是，它自行識別根本原因或確定基本事實。對于某個連接在特定階段關閉的原因，存在很多合理的解釋，尤其是在因重置數(shù)據(jù)包和超時而關閉連接的情況下。企圖僅僅依靠這個數(shù)據(jù)源來解釋具體原因，只能得出推測。

不過，可以通過結合其他數(shù)據(jù)源（例如，主動衡量）來克服這種局限性。例如，與OONI或Censored Planet報告，或者實地報告相互印證，可以提供更完整的故事。因此，TCP重置和超時數(shù)據(jù)集的主要用例之一是了解之前記錄的異?，F(xiàn)象的規(guī)模和影響。

確證互聯(lián)網規(guī)模的衡量項目

查看AS398324可知，出現(xiàn)了嚴重錯誤，一半以上連接在SYN后階段顯示為異常連接。然而，此網絡原來是來自互聯(lián)網掃描公司Censys的CENSYS-ARIN-01。SYN后的異常連接可能是網絡層掃描的結果，即掃描程序發(fā)送單個SYN數(shù)據(jù)包來探測服務器，但沒有完成TCP握手?！昂笃凇彪A段的異常連接率也很高，這可能表明進行了應用層掃描，因為接近100%的連接被歸類為自動化連接。

通過Cloudflare Radar

實際上，與AS15169類似，我們將源自AS398324的99%以上的請求歸類為自動化請求。

通過Cloudflare Radar

到目前為止，我們了解了生成大量腳本流量或自動化流量的網絡。現(xiàn)在，我們可以再從相對寬泛長遠的視角來看一下。

確證連接篡改

本著類似于我們在HTTPS攔截方面的工作精神，此數(shù)據(jù)集的起點是一個研究項目，旨在了解和檢測活躍連接篡改。我們著手這樣做的原因在隨附的博客文章中有詳細介紹。

強制關閉連接的一種有據(jù)可查的常見方法是重置注入。通過重置注入，到達目的地路徑上的中間盒會檢查數(shù)據(jù)包的數(shù)據(jù)部分。如果中間盒發(fā)現(xiàn)了發(fā)送至禁用域名的數(shù)據(jù)包，它向通信一方或雙方注入偽造的TCP重置（RST）數(shù)據(jù)包，導致連接中止。如果中間盒沒有首先丟棄禁用數(shù)據(jù)包，則服務器會收到觸發(fā)中間盒篡改的客戶端數(shù)據(jù)包，其中可能包含帶有服務器名稱指示（SNI）字段的TLS客戶端問候消息，隨后不久會收到偽造的RST數(shù)據(jù)包。

在TCP重置和超時數(shù)據(jù)集中，通過重置注入中斷的連接通常顯示為ACK后、PSH后或“后期”階段的異常（但需要提醒的一點是，并非所有異常連接都是由重置注入造成）。

例如，重置注入技術是已知的，并且通常與所謂的中國防火墻（GFW）相關。誠然，通過源自中國IP地址的連接中出現(xiàn)的PSH后階段異常情況來看，我們發(fā)現(xiàn)其異常連接率高于全球平均水平。然而，從中國的各個網絡來看，PSH后異常連接率差異很大，這可能是由于承載的流量類型或實施的技術不同所致。相比之下，中國大多數(shù)主要自治系統(tǒng)（AS）的SYN后階段異常連接率一直很高；可能的原因是掃描程序、欺騙性SYN洪水攻擊，或殘差塊及其附帶影響。

通過Cloudflare Radar

AS4134（CHINANET-BACKBONE）顯示的PSH后連接異常率低于其他的中國AS，但仍然遠高于全球平均水平。

通過Cloudflare Radar

AS9808（CHINAMOBILE-CN）和AS56046（CMNET-Jiangsu-AP）兩個網絡均顯示，與PSH后異常連接相匹配的連接比例達到兩位數(shù)。

通過Cloudflare Radar

尋找后續(xù)研究的新見解和目標

TCP重置和超時數(shù)據(jù)集也可以成為識別新的或以前未得到充分研究的網絡行為的數(shù)據(jù)源，幫助找到“突出”且值得進一步研究的網絡。

無法歸因的ZMap掃描

這里有一個我們無法解釋的問題：每天在相同的18小時間隔內，來自英國客戶端的超過10%的連接從未經歷過初始SYN數(shù)據(jù)包階段，然后出現(xiàn)超時問題。

通過Cloudflare Radar

內部檢查顯示，幾乎所有SYN后階段異常連接都源自AS396982（谷歌云平臺）上使用ZMap的掃描程序，它似乎會對所有IP地址范圍進行完整的端口掃描。（ZMap客戶端以負責任的態(tài)度進行自我識別，這是基于ZMap負責任的自我識別功能，請參見下文所述。）我們看到，源自AS396982的美國IP地址前綴的掃描流量也達到類似水平。

通過Cloudflare Radar

移動網絡中的零費率

粗略觀察一下國家/地區(qū)層面的異常連接率，便會發(fā)現(xiàn)一些有趣的結果。例如，看看源自墨西哥的連接，通常與連接篡改相關的ACK后和PSH后階段異常連接率均高于全球平均水平。墨西哥的連接情況也與該區(qū)域的其他國家相似。不過，墨西哥這個國家“沒有書面證據(jù)表明，該國政府或其他行為者阻止或過濾互聯(lián)網內容”。

通過Cloudflare Radar

通過觀察按HTTP流量體量排名靠前的墨西哥AS，我們發(fā)現(xiàn)源自AS28403（RadioMovil Dipsa,S.A.de C.V.,operating as Telcel）的近50%的連接在完成TCP握手（ACK后連接階段）后因重置或超時而終止。在此階段，中間盒可能在數(shù)據(jù)包到達Cloudflare之前就發(fā)現(xiàn)數(shù)據(jù)包并將其丟棄。

出現(xiàn)這種行為的一種原因可能是零費率服務，即，蜂窩網絡提供商允許用戶免費訪問某些資源，例如消息發(fā)送或社交媒體應用程序。當用戶超出其帳戶的數(shù)據(jù)傳輸限制時，提供商可能仍然會允許流量流向零費率目的地，但同時阻止與其他資源的連接。

為了執(zhí)行零費率政策，ISP可能會使用TLS服務器名稱指示（SNI）來確定是否阻止或允許連接。完成TCP握手之后，立即在包含數(shù)據(jù)的數(shù)據(jù)包中發(fā)送SNI。因此，如果ISP丟棄包含SNI的數(shù)據(jù)包，服務器仍然可以看到源自客戶端的SYN和ACK數(shù)據(jù)包，但看不到后續(xù)的數(shù)據(jù)包，這與ACK后階段的連接異常相符。

通過Cloudflare Radar

再看一看秘魯，這是數(shù)據(jù)集中擁有類似特征的另一個國家，其ACK后和后PSH階段的異常連接率甚至比墨西哥更高。

通過Cloudflare Radar

就特定AS而言，我們發(fā)現(xiàn)AS12252（Claro Peru）的ACK后階段高異常連接率與墨西哥的AS28403不相上下。這兩個網絡均由同一家母公司América Móvil運營，因此，人們可能會認為二者采用了類似的網絡策略和網絡管理技術。

通過Cloudflare Radar

有趣的是，AS6147（Telefónica Del Peru）反而顯示了較高的PSH后階段異常連接率。這可能表明，此網絡在網絡層使用了不同技術來執(zhí)行其策略。

通過Cloudflare Radar

隨時間變化的縱向視圖

我們持續(xù)的被動衡量最強大的一面在于，能夠衡量網絡在更長時間段內的性能。

互聯(lián)網關閉

在2024年6月“關于敘利亞、伊拉克和阿爾及利亞最近的互聯(lián)網關閉事件調查”這篇博客文章中，我們從Cloudflare網絡的角度分享了上述國家與考試相關的全國互聯(lián)網關閉的觀點。當時我們正在準備TCP重置和超時數(shù)據(jù)集，這有助于確認外部報告并深入了解關閉網絡所使用的具體方法。

作為行為改變的示例，我們可以“回到過去”，觀察考試相關的網絡阻止情況。在敘利亞，在與考試相關的網絡關閉期間，我們看到SYN后階段的異常連接率激增。實際上，我們看到這些時間段內的流量幾乎全面下降（包括SYN數(shù)據(jù)包）。

通過Cloudflare Radar

從7月最后一周開始的第二輪網絡關閉相當突出。

通過Cloudflare Radar

來看看伊拉克的情況，Cloudflare對該國與考試相關的網絡關閉的看法與敘利亞的情況類似，盡管沒那么明顯，但是在SYN后階段出現(xiàn)了多次異常連接的峰值。

通過Cloudflare Radar

與考試相關的網絡關閉博客還描述了阿爾及利亞在該國考試期間如何采取一種更微妙的方法來限制網絡訪問：有證據(jù)表明，阿爾及利亞沒有完全關閉互聯(lián)網，而是有針對性地關閉特定連接。實際上，我們發(fā)現(xiàn)，考試期間的ACK后階段連接異常有所增加。如果中間盒選擇性地丟棄包含禁止內容的數(shù)據(jù)包，同時保留其他數(shù)據(jù)包，則會出現(xiàn)這種行為（正如初始SYN和ACK后階段）。

通過Cloudflare Radar

上述示例進一步證明，此數(shù)據(jù)與其他信號關聯(lián)時最有用。也可以通過API獲得此數(shù)據(jù)，以便其他人可以更深入地了解。我們的檢測方法也可以轉換應用于其他服務器和運營商，詳見下文所述。

如何大規(guī)模檢測異常TCP連接

在本節(jié)中，我們將討論構建TCP重置和超時數(shù)據(jù)集的方法。Cloudflare全球網絡的規(guī)模為數(shù)據(jù)處理和分析帶來了獨特的挑戰(zhàn)。我們在此分享各種方法，幫助讀者了解Cloudflare的方法論，解讀數(shù)據(jù)集，以及在其他網絡或服務器中復制這些機制。

Cloudflare的方法論可以總結為以下幾點：

1.記錄到達面向客戶端的服務器的連接樣本。這是一種完全被動的取樣系統(tǒng)，也就是說，它無法解密流量，并且只能訪問通過網絡發(fā)送的現(xiàn)有數(shù)據(jù)包。

2.根據(jù)捕獲的數(shù)據(jù)包重建連接。我們設計的一個新穎之處在于只需要觀察一個方向，也就是從客戶端到服務器。

3.將重建的連接與一組鮮明特征進行匹配，找出因重置或超時而終止的異常連接。這些特征由兩部分組成：一個連接階段，以及一組標記，這些標記表明了根據(jù)文獻和自身觀察得出的具體行為。

這些設計選項可確保加密數(shù)據(jù)包安全，并且可在任何地方加以復制，而無需訪問目標服務器。

首先，取樣連接

我們的主要目標是設計一種可擴展的機制，讓我們能夠全面了解到達Cloudflare網絡的所有連接。雖然可以在每個面向客戶端的服務器上運行流量捕獲，但卻無法擴展。我們還需要確切地知道應該在何處和何時進行觀察，這導致難以持續(xù)記錄見解。相反，我們從Cloudflare的所有服務器中取樣連接并將其記錄在一個中心位置，以便在該處執(zhí)行離線分析。

這時，我們遇到了第一個障礙：Cloudflare分析系統(tǒng)使用的現(xiàn)有數(shù)據(jù)包記錄管道會記錄單個數(shù)據(jù)包，但是一個連接由許多數(shù)據(jù)包組成。為了檢測連接異常，我們需要查看指定連接中的所有數(shù)據(jù)包，或至少足夠多數(shù)量的數(shù)據(jù)包。幸好我們能夠利用Cloudflare DoS團隊構建的靈活日志記錄系統(tǒng)來分析DDoS攻擊中涉及的數(shù)據(jù)包，結合調用精心設計的兩個iptables規(guī)則來實現(xiàn)我們的目標。

第一個iptables規(guī)則會隨機選擇并標記新連接進行取樣。在我們的案例中，我們決定每10,000個入口TCP連接中取樣一個。這個數(shù)字并沒有什么神奇之處，但考慮到Cloudflare網絡的規(guī)模，它在捕獲足夠多的數(shù)據(jù)與不給數(shù)據(jù)處理和分析管道帶來壓力之間取得了平衡。iptables規(guī)則僅適用于通過DDoS緩解系統(tǒng)之后的數(shù)據(jù)包。鑒于TCP連接可能會長期存在，我們只對新的TCP連接進行取樣。以下是用于標記待取樣連接的iptables規(guī)則：

分解來說，這個規(guī)則安裝在處理入站數(shù)據(jù)包（-A PREROUTING）的鏈中的mangle表（用于修改數(shù)據(jù)包）中。僅當連接沒有先前狀態(tài)（--state NEW）時才考慮設置SYN標志的TCP數(shù)據(jù)包（-p tcp--syn）。過濾器會在每10,000個SYN數(shù)據(jù)包中選擇一個數(shù)據(jù)包（-m statistic–mode random--probability 0.0001）并將標簽應用于連接（-m connlabel--label--set）。

第二個iptables規(guī)則會記錄連接中的后續(xù)數(shù)據(jù)包，最多記錄10個數(shù)據(jù)包。同樣地，數(shù)字10也沒有什么神奇之處，因為通常情況下，這些數(shù)據(jù)包足以捕獲連接建立、后續(xù)請求數(shù)據(jù)包，以及在預期時間之前已關閉連接的重置。

這個規(guī)則安裝在與上一個規(guī)則相同的鏈中。它僅匹配來自已取樣連接（-m connlabel--label）的數(shù)據(jù)包，并且僅匹配每個連接的前10個數(shù)據(jù)包（-m connbytes!--connbytes 11--connbytes-dir original--connbytes-mode packets）。匹配的數(shù)據(jù)包將會發(fā)送到NFLOG（-j NFLOG--nflog-prefix""），日志記錄系統(tǒng)會在此處提取這些數(shù)據(jù)包并將其保存到一個集中位置，以供離線分析。

根據(jù)已取樣數(shù)據(jù)包重建連接

作為分析管道的一個步驟，在服務器上記錄的數(shù)據(jù)包會插入ClickHouse表中。每個已記錄的數(shù)據(jù)包都會存儲在數(shù)據(jù)庫中自己的數(shù)據(jù)行中。下一個挑戰(zhàn)是將數(shù)據(jù)包重新組裝到相應的連接中，以供進一步分析。但在進一步說明之前，我們需要定義本次分析所述的“連接”的具體含義。

我們使用由網絡5元組，即protocol,source IP address,source port界定的連接標準定義，并進行以下調整：

-我們僅在連接的入口（客戶端到服務器）部分對數(shù)據(jù)包進行取樣，因此，看不到從服務器到客戶端的相應的響應數(shù)據(jù)包。在大多數(shù)情況下，我們可以根據(jù)對服務器配置方式的了解來推斷服務器的響應內容。最終，入口數(shù)據(jù)包足以用于了解異常TCP連接行為。

-我們每隔15分鐘查詢一次ClickHouse數(shù)據(jù)集，將在該間隔內共享相同網絡5元組的數(shù)據(jù)包分組在一起。也就是說，連接可能會在查詢間隔結束時被截斷。在分析連接超時時，我們會排除不完整的流，即該流最新的數(shù)據(jù)包時間戳與查詢截止相差不超過10秒。

-由于重置和超時最有可能影響新連接，因此，我們只考慮以SYN數(shù)據(jù)包開頭的數(shù)據(jù)包序列，這些數(shù)據(jù)包是新的TCP握手流程開始的標志，從而將長期存在的現(xiàn)有連接排除在外。

-日志記錄系統(tǒng)無法保證精確的數(shù)據(jù)包到達間隔時間戳，因此，我們僅考慮到達的數(shù)據(jù)包集合，而不是按其到達時間排序。在某些情況下，我們可能會根據(jù)TCP序列號確定數(shù)據(jù)包順序，但事實證明，這不會對結果產生顯著影響。

我們會過濾掉一小部分包含多個SYN數(shù)據(jù)包的連接，以減少分析中的干擾因素。

說明上述定義連接的條件之后，我們現(xiàn)在可以更詳細地描述Cloudflare分析管道。

將連接關閉事件映射到不同階段

TCP連接從建立連接到最終關閉會經歷一系列階段。異常連接關閉的階段會提供異常發(fā)生原因的線索。根據(jù)我們在服務器上接收的數(shù)據(jù)包，我們將每個入站連接置于四個階段之一（SYN后、ACK后、PSH后、后期），如上文所述。

僅連接關閉階段就可以提供關于源自各種網絡的異常TCP連接的有用見解，這正是目前Cloudflare Radar上顯示的內容。然而，在某些情況下，我們可以通過將連接與更具體的特征進行匹配，提供更深入的見解

應用標記來描述更具體的連接行為

上文所述的連接階段分組均完全基于連接中數(shù)據(jù)包的TCP標志。考慮各種其他因素，例如數(shù)據(jù)包的到達間隔時間、TCP標志的精確組合以及其他數(shù)據(jù)包字段（IP標識、IP TTL、TCP序列和確認編號、TCP窗口大小等），可以更精細化地匹配具體行為。

例如，流行的ZMap掃描程序軟件在其生成的SYN數(shù)據(jù)包（源代碼）中將IP標識字段固定為54321，將TCP窗口大小固定為65535。當我們看到到達Cloudflare網絡的數(shù)據(jù)包中設置了確切的這些字段時，該數(shù)據(jù)包很可能是由使用ZMap的掃描程序生成。

還可以使用標記將連接與篡改中間盒的已知特征進行匹配。大量主動衡量研究（例如，Weaver、Sommer和Paxson）發(fā)現(xiàn)，一些中間盒部署在通過重置注入來中斷連接的過程中表現(xiàn)出一致的行為，例如，設置與客戶端發(fā)送的其他數(shù)據(jù)包不同的IP TTL字段，或同時發(fā)送RST數(shù)據(jù)包和RST+ACK數(shù)據(jù)包。如需了解關于特定連接篡改特征的更多信息，請參閱博客文章和同行評審論文。

目前，我們定義了以下標記，并打算隨著時間的推移逐步完善和擴展這些標簽。有些標記只有在設置了另一個標記的情況下才適用，如下面的層次結構表示方法所示（例如，fin標記只有在設置了reset標記時才適用）。

-timeout：因超時而終止

-reset：因重置而終止（數(shù)據(jù)包設置了RST標志）

-fin：至少收到了一個FIN數(shù)據(jù)包，以及一個或多個RST數(shù)據(jù)包

-single_rst：連接終止，收到了一個RST數(shù)據(jù)包

-multiple_rsts：連接終止，收到了多個RST數(shù)據(jù)包

-acknumsame：RST數(shù)據(jù)包中的確認編號全部相同且非零

-acknumsame0：RST數(shù)據(jù)包中的確認編號全部為零

-acknumdiff：RST數(shù)據(jù)包中的確認編號各不相同且全部非零

-acknumdiff0：RST數(shù)據(jù)包中的確認編號各不相同，且其中之一為零

-single_rstack：連接終止，收到了單個RST+ACK數(shù)據(jù)包（同時設置了RST和ACK標志）

-multiple_rstacks：連接終止，收到了多個RST+ACK數(shù)據(jù)包