深入理解Linux網(wǎng)絡
加入技術交流群
同 CPU、內(nèi)存以及 I/O 一樣，網(wǎng)絡也是 Linux 系統(tǒng)最核心的功能。網(wǎng)絡是一種把不同計算機或網(wǎng)絡設備連接到一起的技術，它本質(zhì)上是一種進程間通信方式，特別是跨系統(tǒng)的進程間通信，必須要通過網(wǎng)絡才能進行。
本文引用地址：http://butianyuan.cn/article/202402/455767.htm網(wǎng)絡模型
多臺服務器通過網(wǎng)卡、交換機、路由器等網(wǎng)絡設備連接到一起，構成了相互連接的網(wǎng)絡。由于網(wǎng)絡設備的異構性和網(wǎng)絡協(xié)議的復雜性，國際標準化組織定義了一個七層的 OSI 網(wǎng)絡模型，但是這個模型過于復雜，實際工作中的事實標準，是更為實用的 TCP/IP 模型。
在計算機網(wǎng)絡時代初期，各大廠商推出了不同的網(wǎng)絡架構和標準，為統(tǒng)一標準，國際標準化組織 ISO 推出了統(tǒng)一的 OSI 開放式系統(tǒng)互聯(lián)通信參考模型（Open System Interconnection Reference Model）。
網(wǎng)絡分層解決了網(wǎng)絡復雜的問題，在網(wǎng)絡中傳輸數(shù)據(jù)中，我們對不同設備之間的傳輸數(shù)據(jù)的格式，需要定義一個數(shù)據(jù)標準，所以就有了網(wǎng)絡協(xié)議。
為了解決網(wǎng)絡互聯(lián)中異構設備的兼容性問題，并解耦復雜的網(wǎng)絡包處理流程，OSI 模型把網(wǎng)絡互聯(lián)的框架分為應用層、表示層、會話層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層以及物理層等七層，每個層負責不同的功能。其中，
? 應用層：負責為應用程序提供統(tǒng)一的接口。
? 表示層：負責把數(shù)據(jù)轉(zhuǎn)換成兼容接收系統(tǒng)的格式。
? 會話層：負責維護計算機之間的通信連接。
? 傳輸層：負責為數(shù)據(jù)加上傳輸表頭，形成數(shù)據(jù)包。
? 網(wǎng)絡層：負責數(shù)據(jù)的路由和轉(zhuǎn)發(fā)。
? 數(shù)據(jù)鏈路層：負責 MAC 尋址、錯誤偵測和改錯。
? 物理層：負責在物理網(wǎng)絡中傳輸數(shù)據(jù)幀。
但是 OSI 模型還是太復雜了，也沒能提供一個可實現(xiàn)的方法。所以，在 Linux 中，實際上使用的是另一個更實用的四層模型，即 TCP/IP 網(wǎng)絡模型。
TCP/IP 模型，把網(wǎng)絡互聯(lián)的框架分為應用層、傳輸層、網(wǎng)絡層、網(wǎng)絡接口層等四層，其中，
? 應用層：負責向用戶提供一組應用程序，比如 HTTP、FTP、DNS 等。
? 傳輸層：負責端到端的通信，比如 TCP、UDP 等。
? 網(wǎng)絡層：負責網(wǎng)絡包的封裝、尋址和路由，比如 IP、ICMP 等。
? 網(wǎng)絡接口層：負責網(wǎng)絡包在物理網(wǎng)絡中的傳輸，比如 MAC 尋址、錯誤偵測以及通過網(wǎng)卡傳輸網(wǎng)絡幀等。
TCP/IP 與 OSI 模型的關系如下圖：
雖說 Linux 實際按照 TCP/IP 模型，實現(xiàn)了網(wǎng)絡協(xié)議棧，但在平時的學習交流中，我們習慣上還是用 OSI 七層模型來描述。
比如，說到七層和四層負載均衡，對應的分別是 OSI 模型中的應用層和傳輸層（而它們對應到 TCP/IP 模型中，實際上是四層和三層）。
Linux網(wǎng)絡棧
有了 TCP/IP 模型后，在進行網(wǎng)絡傳輸時，數(shù)據(jù)包就會按照協(xié)議棧，對上一層發(fā)來的數(shù)據(jù)進行逐層處理；然后封裝上該層的協(xié)議頭，再發(fā)送給下一層。
當然，網(wǎng)絡包在每一層的處理邏輯，都取決于各層采用的網(wǎng)絡協(xié)議。比如在應用層，一個提供 REST API 的應用，可以使用 HTTP 協(xié)議，把它需要傳輸?shù)?JSON 數(shù)據(jù)封裝到 HTTP 協(xié)議中，然后向下傳遞給 TCP 層。
而封裝做的事情就很簡單了，只是在原來的負載前后，增加固定格式的元數(shù)據(jù)，原始的負載數(shù)據(jù)并不會被修改。
比如，以通過 TCP 協(xié)議通信的網(wǎng)絡包為例，通過下面這張圖，我們可以看到，應用程序數(shù)據(jù)在每個層的封裝格式。
其中：
? 傳輸層在應用程序數(shù)據(jù)前面增加了 TCP 頭；
? 網(wǎng)絡層在 TCP 數(shù)據(jù)包前增加了 IP 頭；
? 而網(wǎng)絡接口層，又在 IP 數(shù)據(jù)包前后分別增加了幀頭和幀尾。
這些新增的頭部和尾部，增加了網(wǎng)絡包的大小，但我們都知道，物理鏈路中并不能傳輸任意大小的數(shù)據(jù)包。
網(wǎng)絡接口配置的最大傳輸單元（MTU），就規(guī)定了最大的 IP 包大小。在我們最常用的以太網(wǎng)中，MTU 默認值是 1500bytes（這也是 Linux 的默認值）。
在Linux操作系統(tǒng)中執(zhí)行 ifconfig 可以查看到每個網(wǎng)卡的mtu值，有1450、1500等不同的值。
[root@dev ~]# ifconfig
cni0: flags=4163 mtu 1450
inet 10.244.0.1 netmask 255.255.255.0 broadcast 10.244.0.255
inet6 fe80::6435:53ff:fea0:638b prefixlen 64 scopeid 0x20
ether 66:35:53:a0:63:8b txqueuelen 1000 (Ethernet)
RX packets 124 bytes 12884 (12.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 122 bytes 29636 (28.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099 mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
ether 02:42:12:9c:9e:91 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ens33: flags=4163 mtu 1500
inet 192.168.2.129 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::a923:989b:b165:8e3b prefixlen 64 scopeid 0x20
ether 00:0c:29:d9:5e:32 txqueuelen 1000 (Ethernet)
RX packets 131 bytes 13435 (13.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 73 bytes 17977 (17.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0一旦網(wǎng)絡包超過 MTU 的大小，就會在網(wǎng)絡層分片，以保證分片后的 IP 包不大于 MTU 值。
顯然，MTU 越大，需要的分包也就越少，自然，網(wǎng)絡吞吐能力就越好。
理解了 TCP/IP 網(wǎng)絡模型和網(wǎng)絡包的封裝原理后，對Linux 內(nèi)核中的網(wǎng)絡棧，其實也類似于 TCP/IP 的四層結構。
如下圖所示，就是 Linux 通用 IP 網(wǎng)絡棧的示意圖：
從上到下來看這個網(wǎng)絡棧，你可以發(fā)現(xiàn)，
? 最上層的應用程序，需要通過系統(tǒng)調(diào)用，來跟套接字接口進行交互；
? 套接字的下面，就是我們前面提到的傳輸層、網(wǎng)絡層和網(wǎng)絡接口層；
? 最底層，則是網(wǎng)卡驅(qū)動程序以及物理網(wǎng)卡設備。
網(wǎng)卡是發(fā)送和接收網(wǎng)絡包的基本設備。
在系統(tǒng)啟動過程中，網(wǎng)卡通過內(nèi)核中的網(wǎng)卡驅(qū)動程序注冊到系統(tǒng)中。而在網(wǎng)絡收發(fā)過程中，內(nèi)核通過中斷跟網(wǎng)卡進行交互。
網(wǎng)絡包的處理非常復雜，所以，網(wǎng)卡硬中斷只處理最核心的網(wǎng)卡數(shù)據(jù)讀取或發(fā)送，而協(xié)議棧中的大部分邏輯，都會放到軟中斷中處理。
Linux網(wǎng)絡包收發(fā)流程
了解了 Linux 網(wǎng)絡棧后，我們再來看看， Linux 到底是怎么收發(fā)網(wǎng)絡包的。
PS：以下內(nèi)容都以物理網(wǎng)卡為例。Linux 還支持眾多的虛擬網(wǎng)絡設備，而它們的網(wǎng)絡收發(fā)流程會有一些差別。
網(wǎng)絡包的接收流程
我們先來看網(wǎng)絡包的接收流程。
1. 當一個網(wǎng)絡幀到達網(wǎng)卡后，網(wǎng)卡會通過 DMA 方式，把這個網(wǎng)絡包放到收包隊列中；然后通過硬中斷，告訴中斷處理程序已經(jīng)收到了網(wǎng)絡包。
2. 接著，網(wǎng)卡中斷處理程序會為網(wǎng)絡幀分配內(nèi)核數(shù)據(jù)結構（sk_buff），并將其拷貝到 sk_buff 緩沖區(qū)中；然后再通過軟中斷，通知內(nèi)核收到了新的網(wǎng)絡幀。
3. 接下來，內(nèi)核協(xié)議棧從緩沖區(qū)中取出網(wǎng)絡幀，并通過網(wǎng)絡協(xié)議棧，從下到上逐層處理這個網(wǎng)絡幀。比如，
在鏈路層檢查報文的合法性，找出上層協(xié)議的類型（ IPv4 還是 IPv6），再去掉幀頭、幀尾，然后交給網(wǎng)絡層。
1. 網(wǎng)絡層取出 IP 頭，判斷網(wǎng)絡包下一步的走向，比如是交給上層處理還是轉(zhuǎn)發(fā)。當網(wǎng)絡層確認這個包是要發(fā)送到本機后，就會取出上層協(xié)議的類型（TCP 還是 UDP），去掉 IP 頭，再交給傳輸層處理。
2. 傳輸層取出 TCP 頭或者 UDP 頭后，根據(jù) < 源 IP、源端口、目的 IP、目的端口 > 四元組作為標識，找出對應的 Socket，并把數(shù)據(jù)拷貝到 Socket 的接收緩存中。
3. 最后，應用程序就可以使用 Socket 接口，讀取到新接收到的數(shù)據(jù)了。
具體過程如下圖所示，這張圖的左半部分表示接收流程，而圖中的粉色箭頭則表示網(wǎng)絡包的處理路徑。
網(wǎng)絡包的發(fā)送流程
網(wǎng)絡包的發(fā)送流程就是上圖的右半部分，很容易發(fā)現(xiàn)，網(wǎng)絡包的發(fā)送方向，正好跟接收方向相反。
首先，應用程序調(diào)用 Socket API（比如 sendmsg）發(fā)送網(wǎng)絡包。由于這是一個系統(tǒng)調(diào)用，所以會陷入到內(nèi)核態(tài)的套接字層中。套接字層會把數(shù)據(jù)包放到 Socket 發(fā)送緩沖區(qū)中。
接下來，網(wǎng)絡協(xié)議棧從 Socket 發(fā)送緩沖區(qū)中，取出數(shù)據(jù)包；再按照 TCP/IP 棧，從上到下逐層處理。比如，傳輸層和網(wǎng)絡層，分別為其增加 TCP 頭和 IP 頭，執(zhí)行路由查找確認下一跳的 IP，并按照 MTU 大小進行分片。
分片后的網(wǎng)絡包，再送到網(wǎng)絡接口層，進行物理地址尋址，以找到下一跳的 MAC 地址。然后添加幀頭和幀尾，放到發(fā)包隊列中。這一切完成后，會有軟中斷通知驅(qū)動程序：發(fā)包隊列中有新的網(wǎng)絡幀需要發(fā)送。
最后，驅(qū)動程序通過 DMA ，從發(fā)包隊列中讀出網(wǎng)絡幀，并通過物理網(wǎng)卡把它發(fā)送出去。
在不同的網(wǎng)絡協(xié)議處理下，給我們的網(wǎng)絡數(shù)據(jù)包加上了各種頭部，這保證了網(wǎng)絡數(shù)據(jù)在各層物理設備的流轉(zhuǎn)下可以正確抵達目的地。
收到處理后的網(wǎng)絡數(shù)據(jù)包后，接受端再通過網(wǎng)絡協(xié)議將頭部字段去除，得到原始的網(wǎng)絡數(shù)據(jù)。
下圖是客戶端與服務器之間用網(wǎng)絡協(xié)議連接通信的過程：
Linux 網(wǎng)絡根據(jù) TCP/IP 模型，構建其網(wǎng)絡協(xié)議棧。TCP/IP 模型由應用層、傳輸層、網(wǎng)絡層、網(wǎng)絡接口層等四層組成，這也是 Linux 網(wǎng)絡棧最核心的構成部分。
應用程序通過套接字接口發(fā)送數(shù)據(jù)包時，先要在網(wǎng)絡協(xié)議棧中從上到下逐層處理，然后才最終送到網(wǎng)卡發(fā)送出去；而接收數(shù)據(jù)包時，也要先經(jīng)過網(wǎng)絡棧從下到上的逐層處理，最后送到應用程序。
了解 Linux 網(wǎng)絡的基本原理和收發(fā)流程后，你肯定迫不及待想知道，如何去觀察網(wǎng)絡的性能情況。具體而言，哪些指標可以用來衡量 Linux 的網(wǎng)絡性能呢？
常用網(wǎng)絡相關命令
分析網(wǎng)絡問題的第一步，通常是查看網(wǎng)絡接口的配置和狀態(tài)。你可以使用 ifconfig 或者 ip 命令，來查看網(wǎng)絡的配置。
ifconfig 和 ip 分別屬于軟件包 net-tools 和 iproute2，iproute2 是 net-tools 的下一代，通常情況下它們會在發(fā)行版中默認安裝。
以網(wǎng)絡接口 ens33 為例，可以運行下面的兩個命令，查看它的配置和狀態(tài)：
[root@dev ~]# ifconfig ens33
ens33: flags=4163 mtu 1500
inet 192.168.2.129 netmask 255.255.255.0 broadcast 192.168.2.255
inet6 fe80::a923:989b:b165:8e3b prefixlen 64 scopeid 0x20
ether 00:0c:29:d9:5e:32 txqueuelen 1000 (Ethernet)
RX packets 249 bytes 22199 (21.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 106 bytes 22636 (22.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@dev ~]#
[root@dev ~]# ip -s addr show ens33
2: ens33: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:d9:5e:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.129/24 brd 192.168.2.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet6 fe80::a923:989b:b165:8e3b/64 scope link noprefixroute
valid_lft forever preferred_lft forever
RX: bytes packets errors dropped overrun mcast
24877 279 0 0 0 0
TX: bytes packets errors dropped carrier collsns
24616 123 0 0 0 0可以看到，ifconfig 和 ip 命令輸出的指標基本相同，只是顯示格式略微不同。比如，它們都包括了網(wǎng)絡接口的狀態(tài)標志、MTU 大小、IP、子網(wǎng)、MAC 地址以及網(wǎng)絡包收發(fā)的統(tǒng)計信息。
有幾個字段可以重點關注下：
第一，網(wǎng)絡接口的狀態(tài)標志。ifconfig 輸出中的 RUNNING ，或 ip 輸出中的 LOWER_UP ，都表示物理網(wǎng)絡是連通的，即網(wǎng)卡已經(jīng)連接到了交換機或者路由器中。如果你看不到它們，通常表示網(wǎng)線被拔掉了。
第二，MTU 的大小。MTU 默認大小是 1500，根據(jù)網(wǎng)絡架構的不同（比如是否使用了 VXLAN 等疊加網(wǎng)絡），你可能需要調(diào)大或者調(diào)小 MTU 的數(shù)值。
第三，網(wǎng)絡接口的 IP 地址、子網(wǎng)以及 MAC 地址。這些都是保障網(wǎng)絡功能正常工作所必需的，你需要確保配置正確。
第四，網(wǎng)絡收發(fā)的字節(jié)數(shù)、包數(shù)、錯誤數(shù)以及丟包情況，特別是 TX （ Transmit發(fā)送 ）和 RX（Receive接收 ） 部分的 errors、dropped、overruns、carrier 以及 collisions 等指標不為 0 時，通常表示出現(xiàn)了網(wǎng)絡問題。其中：
? errors 表示發(fā)生錯誤的數(shù)據(jù)包數(shù)，比如校驗錯誤、幀同步錯誤等；
? dropped 表示丟棄的數(shù)據(jù)包數(shù)，即數(shù)據(jù)包已經(jīng)收到了 Ring Buffer，但因為內(nèi)存不足等原因丟包；
? overruns 表示超限數(shù)據(jù)包數(shù)，即網(wǎng)絡 I/O 速度過快，導致 Ring Buffer 中的數(shù)據(jù)包來不及處理（隊列滿）而導致的丟包；
? carrier 表示發(fā)生 carrirer 錯誤的數(shù)據(jù)包數(shù)，比如雙工模式不匹配、物理電纜出現(xiàn)問題等；
? collisions 表示碰撞數(shù)據(jù)包數(shù)。
套接字信息
套接字接口在網(wǎng)絡程序功能中是內(nèi)核與應用層之間的接口。TCP/IP 協(xié)議棧的所有數(shù)據(jù)和控制功能都來自于套接字接口，與 OSI 網(wǎng)絡分層模型相比，TCP/IP 協(xié)議棧本身在傳輸層以上就不包含任何其他協(xié)議。
在 Linux 操作系統(tǒng)中，替代傳輸層以上協(xié)議實體的標準接口，稱為套接字，它負責實現(xiàn)傳輸層以上所有的功能，可以說套接字是 TCP/IP 協(xié)議棧對外的窗口。
ifconfig 和 ip 只顯示了網(wǎng)絡接口收發(fā)數(shù)據(jù)包的統(tǒng)計信息，但在實際的性能問題中，網(wǎng)絡協(xié)議棧中的統(tǒng)計信息，我們也必須關注，可以用 netstat 或者 ss ，來查看套接字、網(wǎng)絡棧、網(wǎng)絡接口以及路由表的信息。
我個人更推薦，使用 ss 來查詢網(wǎng)絡的連接信息，因為它比 netstat 提供了更好的性能（速度更快）。
比如，你可以執(zhí)行下面的命令，查詢套接字信息：
# head -n 4 表示只顯示前面4行
# -l 表示只顯示監(jiān)聽套接字
# -n 表示顯示數(shù)字地址和端口(而不是名字)
# -p 表示顯示進程信息
[root@dev ~]# netstat -nlp | head -n 4
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 952/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 11/master
# -l 表示只顯示監(jiān)聽套接字
# -t 表示只顯示 TCP 套接字
# -n 表示顯示數(shù)字地址和端口(而不是名字)
# -p 表示顯示進程信息
$ ss -ltnp | head -n 4
netstat 和 ss 的輸出也是類似的，都展示了套接字的狀態(tài)、接收隊列、發(fā)送隊列、本地地址、遠端地址、進程 PID 和進程名稱等。
其中，接收隊列（Recv-Q）和發(fā)送隊列（Send-Q）需要你特別關注，它們通常應該是 0。
當你發(fā)現(xiàn)它們不是 0 時，說明有網(wǎng)絡包的堆積發(fā)生。當然還要注意，在不同套接字狀態(tài)下，它們的含義不同。
當套接字處于連接狀態(tài)（Established）時，
? Recv-Q 表示套接字緩沖還沒有被應用程序取走的字節(jié)數(shù)（即接收隊列長度）。
? Send-Q 表示還沒有被遠端主機確認的字節(jié)數(shù)（即發(fā)送隊列長度）。
當套接字處于監(jiān)聽狀態(tài)（Listening）時，
? Recv-Q 表示全連接隊列的長度。
? Send-Q 表示全連接隊列的最大長度。
所謂全連接，是指服務器收到了客戶端的 ACK，完成了 TCP 三次握手，然后就會把這個連接挪到全連接隊列中。這些全連接中的套接字，還需要被 accept() 系統(tǒng)調(diào)用取走，服務器才可以開始真正處理客戶端的請求。
與全連接隊列相對應的，還有一個半連接隊列。所謂半連接是指還沒有完成 TCP 三次握手的連接，連接只進行了一半。服務器收到了客戶端的 SYN 包后，就會把這個連接放到半連接隊列中，然后再向客戶端發(fā)送 SYN+ACK 包。
連接統(tǒng)計信息
類似的，使用 netstat 或 ss ，也可以查看協(xié)議棧的信息：
[root@dev ~]# netstat -s
...
Tcp:
1898 active connections openings
1502 passive connection openings
24 failed connection attempts
1304 connection resets received
178 connections established
133459 segments received
133428 segments send out
22 segments retransmited
0 bad segments received.
1400 resets sent
...
[root@dev ~]# ss -s
Total: 1700 (kernel 2499)
TCP: 340 (estab 178, closed 144, orphaned 0, synrecv 0, timewait 134/0), ports 0
Transport Total IP IPv6
* 2499 - -
RAW 1 0 1
UDP 5 3 2
TCP 196 179 17
INET 202 182 20
FRAG 0 0 0這些協(xié)議棧的統(tǒng)計信息都很直觀。
ss 只顯示已經(jīng)連接、關閉、孤兒套接字等簡要統(tǒng)計，而 netstat 則提供的是更詳細的網(wǎng)絡協(xié)議棧信息，展示了 TCP 協(xié)議的主動連接、被動連接、失敗重試、發(fā)送和接收的分段數(shù)量等各種信息。
連通性和延時
通常使用 ping ，來測試遠程主機的連通性和延時，而ping基于 ICMP 協(xié)議。
比如，執(zhí)行下面的命令，你就可以測試本機到 192.168.2.129 這個 IP 地址的連通性和延時：
[root@dev ~]# ping -c3 192.168.2.129
PING 192.168.2.129 (192.168.2.129) 56(84) bytes of data.
64 bytes from 192.168.2.129: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from 192.168.2.129: icmp_seq=2 ttl=64 time=0.016 ms
64 bytes from 192.168.2.129: icmp_seq=3 ttl=64 time=0.015 ms
--- 192.168.2.129 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.015/0.019/0.026/0.005 msping 的輸出，可以分為兩部分。
1. 第一部分，是每個 ICMP 請求的信息，包括 ICMP 序列號（icmp_seq）、TTL（生存時間，或者跳數(shù)）以及往返延時。
2. 第二部分，則是三次 ICMP 請求的匯總。
比如上面的示例顯示，發(fā)送了 3 個網(wǎng)絡包，并且接收到 3 個響應，沒有丟包發(fā)生，這說明測試主機到 192.168.2.129是連通的；平均往返延時（RTT）是 0.026 ms，也就是從發(fā)送 ICMP 開始，到接收到主機回復的確認，總共經(jīng)歷的時間。
評論