前言

連接跟蹤（“conntrack”）是 Linux 內(nèi)核網(wǎng)絡(luò)棧的核心特性。它允許內(nèi)核跟蹤所有的邏輯網(wǎng)絡(luò)連接或數(shù)據(jù)包流，從而識(shí)別組成每個(gè)流的所有數(shù)據(jù)包，以便能夠統(tǒng)一的處理它們。

Conntrack 是一個(gè)重要的內(nèi)核特性，它支撐了一些關(guān)鍵的很重要的應(yīng)用場(chǎng)景：

• NAT 根據(jù)連接跟蹤信息，可以以相同的方式轉(zhuǎn)換這個(gè)流中的所有數(shù)據(jù)包。例如，當(dāng)一個(gè) pod 訪問(wèn) Kubernetes 服務(wù)時(shí)，kube-proxy 的負(fù)載平衡使用 NAT 將連接重定向到一個(gè)特定的后端 pod。這個(gè)連接就是記錄到 conntrack 表中，到服務(wù) IP 的數(shù)據(jù)包應(yīng)該都發(fā)送到相同的后端 pod，從后端 pod 返回的數(shù)據(jù)包應(yīng)該做反向 NAT 才能返回到源 pod。

• 有狀態(tài)防火墻，例如 Calico，根據(jù)連接跟蹤信息來(lái)精確地將“響應(yīng)”流量列入白名單。你可以編寫一個(gè)網(wǎng)絡(luò)策略，如“允許我的 pod 連接到任何遠(yuǎn)程 IP”，而不是編寫策略顯式地允許響應(yīng)流量。(如果沒(méi)有這一點(diǎn)，你就需要添加更不安全的規(guī)則如“允許數(shù)據(jù)包從任何 IP 進(jìn)入我的 pod”。)

此外，conntrack 通常可以提高性能(減少 CPU 和數(shù)據(jù)包延遲)，因?yàn)橹挥袛?shù)據(jù)流中的第一個(gè)數(shù)據(jù)包需要經(jīng)過(guò)完整的網(wǎng)絡(luò)堆棧處理，通過(guò)第一個(gè)包的處理確定后續(xù)包怎么處理。請(qǐng)參閱“compare kube-proxy-modes”博客，可以進(jìn)一步深入理解。

但是，conntrack 也是有局限性的。。。

那它會(huì)在哪里出問(wèn)題呢？

conntrack 表有一個(gè)可配置的最大值，如果 conntrack 表被添加到了最大值，連接通常會(huì)開(kāi)始被拒絕或丟棄。對(duì)于大多數(shù)工作負(fù)載來(lái)說(shuō)，conntrack 表的大小是沒(méi)問(wèn)題的，也永遠(yuǎn)都不是問(wèn)題。然而，在一些情況下，conntrack 表需要多注：

• 最明顯的情況是如果你的服務(wù)同時(shí)處理大量的活動(dòng)連接。例如，如果你的 conntrack 表配置為128k 的大小，但您有>128k 的并發(fā)連接，那么肯定會(huì)遇到問(wèn)題！

• 另外一種不太明顯的情況是，如果服務(wù)每秒鐘處理非常高的連接數(shù)。即使是短連接，Linux 也會(huì)持續(xù)跟蹤一段時(shí)間的（默認(rèn)為120秒）連接。例如，如果 conntrack 表被配置為128k 大小，并且想每秒處理 1100 個(gè)連接，那么即使是短連接，這也將超過(guò)conntrack表的大?。?28k / 120s = 1092個(gè)連接/秒）。

有一些小眾的工作負(fù)載類型就屬于這些類別。此外，如果處于一個(gè)敵對(duì)的環(huán)境中，用大量半開(kāi)的連沖擊沒(méi)你的服務(wù)就可以被用作拒絕服務(wù)攻擊。在這兩種情況下，conntrack 都可能成為系統(tǒng)中的瓶頸。對(duì)于某些場(chǎng)景，通過(guò)增加 conntrack 表大小或減少 conntrack 超時(shí)時(shí)間來(lái)調(diào)優(yōu) conntrack 可能足以滿足你的需求（但如果調(diào)優(yōu)錯(cuò)誤，可能會(huì)帶來(lái)很多麻煩）。對(duì)于其他場(chǎng)景，你要讓違規(guī)流量繞過(guò) conntrack。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺(jué)得比較好的學(xué)習(xí)書(shū)籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書(shū)、實(shí)戰(zhàn)項(xiàng)目及代碼)? ??

一個(gè)真實(shí)的例子

舉一個(gè)具體的例子，我們合作過(guò)的一個(gè)大型 SaaS 提供商有一組 memcached 服務(wù)運(yùn)行在裸服務(wù)器上（未虛擬化或容器化），每臺(tái)服務(wù)器每秒處理 50k+ 短連接。實(shí)際上這遠(yuǎn)遠(yuǎn)超出了標(biāo)準(zhǔn) Linux 配置所能處理的范圍。

他們已經(jīng)嘗試通過(guò)調(diào)優(yōu) conntrack 配置來(lái)增加表的大小和減少超時(shí)時(shí)間，但是這種場(chǎng)景下這樣的調(diào)優(yōu)并不是最佳辦法，最大的問(wèn)題就是增加了內(nèi)存的使用(大概是 GBytes!)，而且是短連接的情況下， conntrack 沒(méi)有提供通常的性能優(yōu)勢(shì)(減少 CPU 使用或是包延遲)。

相反，他們使用了 Calico。Calico 的網(wǎng)絡(luò)策略允許特定的流量繞開(kāi)conntrack（使用 doNotTrack 標(biāo)志）。這為他們提供了所需的性能，以及 Calico 帶來(lái)的額外安全好處。

繞開(kāi) conntrack 有什么好處?

• 不跟蹤網(wǎng)絡(luò)策略通常必須是對(duì)稱的。在 saas 提供者的那個(gè)案例中，他們的工作負(fù)載是內(nèi)部的，因此使用網(wǎng)絡(luò)策略，他們可以小范圍地將所有允許訪問(wèn) memcached 服務(wù)的工作負(fù)載的流量列入白名單。

• 不跟蹤策略不關(guān)注連接的方向。因此，如果一個(gè) memcached 服務(wù)被破壞，理論上只要它使用了正確的源端口，它就可以嘗試連接到任何一個(gè) memcached 客戶端。但是，假設(shè)你為 memcached 客戶端定義了正確的網(wǎng)絡(luò)策略，那么這些連接嘗試仍然會(huì)在客戶端被拒絕。

• 不跟蹤網(wǎng)絡(luò)策略應(yīng)用于每個(gè)包，而正常網(wǎng)絡(luò)策略只應(yīng)用于流中的第一個(gè)包。這可能會(huì)增加每個(gè)包的 CPU 成本，因?yàn)槊總€(gè)包都需要由網(wǎng)絡(luò)策略處理。但是對(duì)于短連接，這種額外的處理開(kāi)銷被不使用 conntrack 的優(yōu)化所抵消。例如，在SaaS提供商的案例中，每個(gè)連接中的數(shù)據(jù)包數(shù)量非常少，因此對(duì)每個(gè)數(shù)據(jù)包應(yīng)用策略的額外開(kāi)銷是合理的。

真實(shí)測(cè)試

我們測(cè)試了單個(gè) memcached 服務(wù) pod 和許多運(yùn)行在遠(yuǎn)程節(jié)點(diǎn)上的客戶端 pod，因此我們可以每秒發(fā)動(dòng)非常多的連接。memcached 服務(wù) pod 主機(jī)是 8 核的和一個(gè) 512k 配置的 conntrack 表（主機(jī)大小的標(biāo)準(zhǔn)設(shè)置）。我們測(cè)量了以下幾種情況下的性能差異：無(wú)網(wǎng)絡(luò)策略；Calico 正常網(wǎng)絡(luò)策略和 Calico 不跟蹤網(wǎng)絡(luò)策略。

在第一個(gè)測(cè)試中，我們將每秒的連接限制在 4000 個(gè)，這樣我們就可以關(guān)注 CPU 的差異。無(wú)策略和正常策略在性能上沒(méi)有可測(cè)量的差異，但不跟蹤策略的 CPU 負(fù)載減少了大約 20%。

在第二個(gè)測(cè)試中，我們推送了盡可能多的客戶端連接，并測(cè)量了 memcached 服務(wù)器每秒能夠處理的最大連接數(shù)。正如預(yù)期的那樣，沒(méi)有策略和正常策略都達(dá)到了 conntrack 表限制，即略高于每秒 4,000 個(gè)連接（512k / 120s = 4,369個(gè)連接/秒）。在不跟蹤政策實(shí)施的情況下，我們的客戶每秒推送了 60,000 個(gè)連接，而沒(méi)有遇到任何問(wèn)題。我們很有信心，我們可以通過(guò)增加更多的客戶來(lái)超越這一點(diǎn)，但感覺(jué)數(shù)字已經(jīng)足夠說(shuō)明這篇博客的要點(diǎn)!

結(jié)論

Conntrack 是一個(gè)重要的內(nèi)核特性。它很擅長(zhǎng)自己的工作場(chǎng)景。許多主要的使用場(chǎng)景都依賴于它。然而，對(duì)于一些小眾場(chǎng)景，conntrack 的開(kāi)銷超過(guò)了它所帶來(lái)的正常好處。在這些場(chǎng)景中，可以使用 Calico 網(wǎng)絡(luò)策略選擇性地繞過(guò) conntrack，同時(shí)仍可以加強(qiáng)網(wǎng)絡(luò)安全性。對(duì)于所有其他流量，conntrack 仍然是你的好朋友!

原文作者：黑光信息