Linux性能優化實戰學習筆記：第四十五講

1、上節回顧

專欄更新至今，四大基礎模塊的最後一個模塊——網絡篇，咱們就已經學完了。很開心你尚未掉隊，仍然在積極學習思考和實踐操做，熱情地留言和互動。還有很多同窗分享了
在實際生產環境中，碰到各類性能問題的分析思路和優化方法，這裏也謝謝大家。

今天是性能優化答疑的第五期。照例，我從網絡模塊的留言中，摘出了一些典型問題，做爲今天的答疑內容，集中回覆。一樣的，爲了便於你學習理解，它們並非嚴格按照文章
順序排列的。

每一個問題，我都附上了留言區提問的截屏。若是你須要回顧內容原文，能夠掃描每一個問題右下方的二維碼查看。

2、網絡收發過程當中緩衝區的位置

一、問題：

二、解答：

第一點，是網絡收發過程當中，收發隊列和緩衝區位置的疑問。在 關於 Linux 網絡，你必需要知道這些 中，我曾介紹過 Linux 網絡的收發流程。這個流
程涉及到了多個隊列和緩衝區，包括：

• 網卡收發網絡包時，經過 DMA 方式交互的環形緩衝區；
• 網卡中斷處理程序爲網絡幀分配的，內核數據結構 sk_buff 緩衝區；
• 應用程序經過套接字接口，與網絡協議棧交互時的套接字緩衝區。

不過相應的，就會有兩個問題。

首先，這些緩衝區的位置在哪兒？是在網卡硬件中，仍是在內存中？這個問題其實仔細想一下，就很容易明白——這些緩衝區都處於內核管理的內存中。

其中，環形緩衝區，因爲須要 DMA 與網卡交互，理應屬於網卡設備驅動的範圍。

sk_buff 緩衝區，是一個維護網絡幀結構的雙線鏈表，鏈表中的每個元素都是一個網絡幀（Packet）。雖然 TCP/IP 協議棧分了好幾層，但上下不一樣層之間的傳遞，實際上只需
要操做這個數據結構中的指針，而無需進行數據複製。

套接字緩衝區，則容許應用程序，給每一個套接字配置不一樣大小的接收或發送緩衝區。應用程序發送數據，實際上就是將數據寫入緩衝區；而接收數據，其實就是從緩衝區中讀取。
至於緩衝區中數據的進一步處理，則由傳輸層的 TCP 或 UDP 協議來完成。

其次，這些緩衝區，跟前面內存部分講到的 Buffer 和 Cache 有什麼關聯嗎？

這個問題其實也不難回答。我在內存模塊曾提到過，內存中提到的 Buffer ，都跟塊設備直接相關；而其餘的都是 Cache。

實際上，sk_buff、套接字緩衝、鏈接跟蹤等，都經過 slab 分配器來管理。你能夠直接經過 /proc/slabinfo，來查看它們佔用的內存大小。

3、問題 2：內核協議棧，是經過一個內核線程的方式來運行的嗎

一、問題：

第二個問題，內核協議棧的運行，是按照一個內核線程的方式嗎？在內核中，又是如何執行網絡協議棧的呢？

二、解答：

說到網絡收發，在中斷處理文章中我曾講過，其中的軟中斷處理，就有專門的內核線程ksoftirqd。每一個 CPU 都會綁定一個 ksoftirqd 內核線程，好比， 2 個 CPU 時，就會有
ksoftirqd/0 和 ksoftirqd/1 這兩個內核線程。

不過要注意，並不是全部網絡功能，都在軟中斷內核線程中處理。內核中還有不少其餘機制（好比硬中斷、kworker、slab 等），這些機制一塊兒協同工做，才能保證整個網絡協議棧
的正常運行。

關於內核中網絡協議棧的工做原理，以及如何動態跟蹤內核的執行流程，專欄後續還有專門的文章來說。若是對這部分感興趣，你能夠先用咱們提到過的 perf、systemtap、bcc-
tools 等，試着來分析一下。

4、問題 3：最大鏈接數是否是受限於 65535 個端口

一、問題：

 

 

二、解答：

咱們知道，不管 TCP 仍是 UDP，端口號都只佔 16 位，也就說其最大值也只有 65535。是否是說，若是使用 TCP 協議，在單臺機器、單個 IP 地址時，併發鏈接數最大也只有
那65535 呢？

對於這個問題，首先你要知道，Linux 協議棧，經過五元組來標誌一個鏈接（即協議，源IP、源端口、目的 IP、目的端口)。

明白了這一點，這個問題其實就有了思路。咱們應該分客戶端和服務器端，這兩種場景來分析。

對客戶端來講，每次發起 TCP 鏈接請求時，都須要分配一個空閒的本地端口，去鏈接遠端的服務器。因爲這個本地端口是獨佔的，因此客戶端最多隻能發起 65535 個鏈接。

對服務器端來講，其一般監聽在固定端口上（好比 80 端口），等待客戶端的鏈接。根據五元組結構，咱們知道，客戶端的 IP 和端口都是可變的。若是不考慮 IP 地址分類以及資
源限制，服務器端的理論最大鏈接數，能夠達到 2 的 48 次方（IP 爲 32 位，端口號爲 16位），遠大於 65535。

因此，綜合來看，客戶端最大支持 65535 個鏈接，而服務器端可支持的鏈接數是海量的。固然，因爲 Linux 協議棧自己的性能，以及各類物理和軟件的資源限制等，這麼大的鏈接
數，仍是遠遠達不到的（實際上，C10M 就已經很難了）。

5、問題 4： 「如何優化 NAT 性能」課後思考

一、問題：

二、解答：

在 如何優化 NAT 性能 的最後， 我給你留了兩個思考題。

MASQUERADE 是最經常使用的 SNAT 規則之一，一般用來爲多個內網 IP 地址，提供共享的出口 IP。假設如今有一臺 Linux 服務器，用了 MASQUERADE 方式，爲內網全部 IP 提供
出口訪問功能。那麼，

• 當多個內網 IP 地址的端口號相同時，MASQUERADE 還能正常工做嗎？
• 內網 IP 地址數量或者請求數比較多的時候，這種使用方式有沒有什麼潛在問題呢？

對於這兩個思考題，我來也、ninuxer 等同窗，都給出了不錯的答案：

 

 

 

 

先看第一點，當多個內網 IP 地址的端口號相同時，MASQUERADE 固然仍能夠正常工做。不過，你確定也據說過，配置 MASQUERADE 後，須要各個應用程序去手動配置修
改端口號。

實際上，MASQUERADE 經過 conntrack 機制，記錄了每一個鏈接的信息。而在剛纔第三個問題 中，我提到過，標誌一個鏈接須要五元組，只要這五元組不是同時相同，網絡鏈接就
能夠正常進行。

再看第二點，在內網 IP 地址和鏈接數比較小時，這種方式的問題不大。但在 IP 地址或併發鏈接數特別大的狀況下，就可能碰到各類各樣的資源限制。

好比，MASQUERADE 既然把內部多個 IP ，轉換成了相同的外網 IP（即 SNAT），那麼，爲了確保發送出去的源端口不重複，原來網絡包的源端口也可能會被從新分配。這樣
的話，轉換後的外網 IP 的端口號，就成了限制鏈接數的一個重要因素。

除此以外，鏈接跟蹤、MASQUERADE 機器的網絡帶寬等，都是潛在的瓶頸，而且還存在單點的問題。這些狀況，在咱們實際使用中都須要特別注意。

今天主要回答這些問題，同時也歡迎你繼續在留言區寫下疑問和感想，我會持續不斷地解答。但願藉助每一次的答疑，能夠和你一塊兒，把文章知識內化爲你的能力，咱們不只在實戰中演練，也要在交流中進步。