Linux高性能網(wǎng)絡(luò)編程之TCP/IP協(xié)議棧之ip協(xié)議棧詳解

1、tcp/ip協(xié)議棧分為四層

或者七層，但是便于大家理解，基本上都是用四層模型，如：數(shù)據(jù)鏈路層，網(wǎng)絡(luò)層，傳輸層和應(yīng)用層。
其中封包的流程是：

應(yīng)用層數(shù)據(jù) --- >  
tcp/udp頭部(20字節(jié)) + 應(yīng)用層數(shù)據(jù) --- >  
ip頭部(20字節(jié)) + tcp/udp頭部(20字節(jié)) + 應(yīng)用層數(shù)據(jù) --- >  
以太網(wǎng)頭部(18字節(jié)) + ip頭部(20字節(jié)) + tcp/udp頭部(20字節(jié)) + 應(yīng)用層數(shù)據(jù)

這些數(shù)據(jù)每一個頭部都有自己的協(xié)議，并發(fā)送到對端模塊進行解析，其中對于發(fā)送數(shù)據(jù)大小的要求是有相應(yīng)的限制，在以太網(wǎng)這一層數(shù)據(jù)必須46字節(jié)-1500字節(jié)之間，不足的情況下填充數(shù)據(jù)，超過的情況下拆分ip包數(shù)據(jù)；

2、arp協(xié)議工作原理

主機向自己所在的網(wǎng)絡(luò)廣播一個arp請求，請求獲取目標ip地址的物理地址，請求發(fā)出后所在的網(wǎng)絡(luò)(局域網(wǎng))都會收到這個請求，當匹配該ip請求的機器就主動回包含自己物理地址；

3、dns解析原理

tcpdump抓包(tcpdump -i eth0 -nt -s 500 port domain):  
08:41:28.266682 IP 192.168.1.100.51468 > 202.96.134.33.53: 42940+ A? www.google.com.hk. (35)  
08:41:28.271805 IP 202.96.134.33.53 > 192.168.1.100.51468: 42940 1/0/0 A 93.46.8.89 (51)  
08:41:29.827625 IP 192.168.1.100.13671 > 202.96.134.33.53: 14422+ A? sp0.baidu.com. (31)  
08:41:29.827843 IP 192.168.1.100.29083 > 202.96.134.33.53: 4498+ A? ss1.baidu.com. (31)  
08:41:29.828060 IP 192.168.1.100.38240 > 202.96.134.33.53: 35663+ A? ss2.baidu.com. (31)  
08:41:29.828341 IP 192.168.1.100.11330 > 202.96.134.33.53: 42502+ A? www.baidu.com. (31)  
08:41:29.828513 IP 192.168.1.100.21489 > 202.96.134.33.53: 20283+ A? ss0.baidu.com. (31)  
08:41:29.828710 IP 192.168.1.100.37763 > 202.96.134.33.53: 6612+ A? ss1.bdstatic.com. (34)  
08:41:29.838009 IP 202.96.134.33.53 > 192.168.1.100.11330: 42502 2/0/0 A 14.215.177.38, A 14.215.177.37 (63) 
08:41:29.839022 IP 202.96.134.33.53 > 192.168.1.100.13671: 14422 2/0/0 A 14.215.177.37, A 14.215.177.38 (63)

dns是udp協(xié)議，192.168.1.100發(fā)送dns解析，42940是dns查詢標示，+是采用遞歸查詢，A?是使用A類查詢（A方式是查找ip，CNAME方式是查詢主機別名，PTR是反向查詢）。
202.96.134.33.53回包解析42940是發(fā)送dns解析的標示，1/0/0是1個應(yīng)答資源，0個授權(quán)資源記錄和0個額外信息記錄，A是A類查詢返回，93.46.8.89是返回www.google.com.hk域名的ip地址；

4、ip協(xié)議

ip是無連接，無狀態(tài)，不可靠的協(xié)議，是tcp/udp的動力，決定了路由和轉(zhuǎn)發(fā)的功能，ipv4的頭部結(jié)構(gòu)如下：

重點介紹字段:
TOS字段分別表示最小延時，最大吞吐量，最高可靠性和最小費用；
16位總長度指整個ip數(shù)據(jù)的長度；
8位的TTL生存時間指數(shù)據(jù)包到目的地之前允許經(jīng)過的路由跳數(shù)，數(shù)據(jù)報在轉(zhuǎn)發(fā)的過程中每次經(jīng)過一個路由都會-1，當TTL為0時，路由器將其丟棄，并向源端發(fā)送icmp的差錯報文；

5、ip分片和轉(zhuǎn)發(fā)

當ip數(shù)據(jù)報的長度超過幀的MTU時，將會被分片，其中分片可能會發(fā)生在發(fā)送端，也可能是路由轉(zhuǎn)發(fā)階段；
一個ip數(shù)據(jù)報每個分片具有自己的ip頭部，相同的標識值，但是具有不同偏移量，并且除了最后一個分片不帶有MF標志，其他的分片都帶有MF標志。
下面看一個抓包的例子，ping的數(shù)據(jù)包，協(xié)議是icmp，命令ping www.baidu.com -s 1473[發(fā)送1473個數(shù)據(jù)信息]：

IP (tos 0x0, ttl 64, id 4454, offset 0, flags [+], proto ICMP (1), length 1500)
    192.168.1.100  ?> 14.215.177.37: ICMP echo request, id 51842, seq 2, length 1480
IP (tos 0x0, ttl 64, id 4454, offset 1480, flags [none], proto ICMP (1), length 21)
    192.168.1.100  ?> 14.215.177.37: ip-proto-1

從以上包可以分析：tos：最小延時；
ttl：64跳；
id：4454標識相同；
offset：偏移量分別是0和1480，將icmp分片1500(20個ip報頭，8個icmp報頭，1472數(shù)據(jù))和21(20個ip報頭，1個icmp數(shù)據(jù)，由于下一個數(shù)據(jù)報不需要攜帶icmp的數(shù)據(jù)報頭)；
本小節(jié)還有一個知識點是ip數(shù)據(jù)報在主機上的轉(zhuǎn)發(fā)，主機一般都不轉(zhuǎn)發(fā)，不過可以設(shè)置echo 1 > /proc/sys/net/ipv4/ip_forward，那么轉(zhuǎn)發(fā)邏輯如下：

• 1、檢查數(shù)據(jù)報頭部的ttl，如果為0則丟棄該數(shù)據(jù)包；
• 2、查看數(shù)據(jù)報頭部的嚴格路由選擇項，如果該項被設(shè)置，則檢測數(shù)據(jù)報的目標地址是否為本機的ip，如果不是，則發(fā)送icmp源站選路失敗報文給發(fā)送端；
• 3、如果有必要，則給源端發(fā)送icmp的重定向報文，告訴下一跳ip路由器；
• 4、將ttl值減1，同時處理其他ip頭部選項；
• 5、如果包超過當前路由器的MTU，則進行ip分片操作；

6、ipv6頭部結(jié)構(gòu)

ipv6協(xié)議是為了解決ipv4不夠用的情況，同時增加很多功能，如多播和流功能等，ipv6的頭部結(jié)構(gòu)如下（40字節(jié)+可變頭部）：

重點介紹字段：
20位流標簽是ipv6新增字段，用于對于某些對連接服務(wù)質(zhì)量有特殊要求的通信；
ipv6提供了多種擴展數(shù)據(jù)，如認證頭部和加密頭部等；

第二部分：tcp／ip協(xié)議棧之tcp協(xié)議棧詳解

tcp協(xié)議在我們的應(yīng)用中非常重要，本小節(jié)主要從四方面討論tcp協(xié)議：

• 1）tcp的頭部協(xié)議，每個tcp報文都包含20字節(jié)的頭部字節(jié)，指定四元組（目的ip，目的端口，源ip，源端口）；
• 2）tcp的狀態(tài)轉(zhuǎn)移，tcp從三次握手到四次揮手過程中狀態(tài)跳變，如深入理解有助于排查網(wǎng)絡(luò)問題；
• 3）tcp的數(shù)據(jù)流，包括交互數(shù)據(jù)流，成塊數(shù)據(jù)和緊急數(shù)據(jù)；
• 4）tcp數(shù)據(jù)流的控制，為了保障可靠傳輸和網(wǎng)絡(luò)質(zhì)量，內(nèi)核對tcp數(shù)據(jù)進行控制，包括超時重傳和擁塞控制；

1、tcp數(shù)據(jù)特點

tcp傳輸是可靠的，首先協(xié)議采用應(yīng)答機制，即對發(fā)送端的每個數(shù)據(jù)報都必須得到對端的應(yīng)答確認，才認為本次報文傳輸成功；
其次tcp采用超時重傳，發(fā)送端在發(fā)送數(shù)據(jù)后就啟動定時器，如果在定時時間內(nèi)未收到應(yīng)答，將重發(fā)該數(shù)據(jù)報；
最后tcp報文最終以ip數(shù)據(jù)報發(fā)送，而ip數(shù)據(jù)報是無序或重復的，那么tcp協(xié)議需要對ip層來的數(shù)據(jù)進行重排和丟棄等操作；

2、tcp的頭部結(jié)構(gòu)

32位的序號：一次tcp通訊過程中某個傳輸方向上字節(jié)流的每個字節(jié)的編號，初始化階段為一個隨機值，后續(xù)的tcp報中的序號設(shè)置為初始值+該報文在所攜帶的數(shù)據(jù)的第一個字節(jié)在整個字節(jié)流的偏移量；
32位的確認號：是對端的32位的序號+1；
4位頭部長度：標識tcp頭部32個字節(jié)的大小，由于只有4位，所以tcp頭部最長位60字節(jié)；
6位標識：URG(緊急指針)，ACK(確認包)，PSH(數(shù)據(jù)包)，SYN(建立連接包)，F(xiàn)IN(關(guān)閉連接包)；
16位窗口大?。褐附邮芡ǜ娲翱诖笮。嬖V對端tcp本端接受緩沖區(qū)的數(shù)據(jù)大小，讓對端控制發(fā)送速度；
16位校驗和：tcp的報文crc校驗；
16位緊急指針：序號字段的值+該值的下一個字節(jié)表示緊急數(shù)據(jù)的偏移量；
選項數(shù)據(jù)：在后續(xù)的博客中再詳細介紹；

具體的數(shù)據(jù)報樣例：

19:23:14.767712 IP 192.168.1.100.61976  ?> 139.129.212.166.http: Flags [S], seq 2580028945, win 65535, options [mss 1460,nop,wscale 5,nop,nop,TS val 1032935471 ecr 0,sackOK,eol], length 0
19:23:14.823856 IP 139.129.212.166.http  ?> 192.168.1.100.61976: Flags [S.], seq 3491427708, ack 2580028946, win 14480, options [mss 1360,sackOK,TS val 3615337495 ecr 1032935471,nop,wscale 7], length 0
19:23:14.823905 IP 192.168.1.100.61976  ?> 139.129.212.166.http: Flags [.], ack 1, win 4128, options [nop,nop,TS val 1032935521 ecr 3615337495], length 0
19:23:20.376906 IP 192.168.1.100.61976  ?> 139.129.212.166.http: Flags [P.], seq 1:14, ack 1, win 4128, options [nop,nop,TS val 1032940499 ecr 3615337495], length 13: HTTP

說明：
上面的報文的第一條請求中看出Flags [S]表示syn包，seq序號2580028945，窗口大小655352^5（需要計算options中的wscale 5擴大因子選項），options是選項字段；
第二條請求是回包數(shù)據(jù)，F(xiàn)lags [S.]表示syn，ack包，seq序號3491427708，ack確認序號2580028945+1，窗口大小144802^7（需要計算options中的wscale 7擴大因子選項），options是選項字段；

3、tcp的狀態(tài)轉(zhuǎn)移

tcp在建立連接和斷開連接分別要經(jīng)過三次握手和四次揮手，那么都會有相應(yīng)的服務(wù)器端口狀態(tài)，只描述三次握手和四次揮手雙端的狀態(tài)，如圖：

server狀態(tài)轉(zhuǎn)移語意：
a.服務(wù)器在listen調(diào)用進入LISTEN狀態(tài)，等待客戶端連接；
b.服務(wù)器監(jiān)聽到客戶端連接，就將該連接放入內(nèi)核的等待隊列，并向客戶端發(fā)送SYN，ACK報文，進入SYN_RECVD狀態(tài)，此時客戶端處于SYN_SENT階段；
c.服務(wù)器收到客戶端的ACK報文，進入ESTABLISHED狀態(tài)；
d.客戶端主動關(guān)閉連接（通過close和shutdown發(fā)送FIN包），服務(wù)器返回ACK報文后進入CLOSE_WAIT狀態(tài)；
e.在服務(wù)端發(fā)送完所有數(shù)據(jù)給客戶端以后（客戶端此時只讀不寫，處于半關(guān)閉狀態(tài)），發(fā)送FIN，ACK到客戶端，進入LAST_ACK狀態(tài)；
f.最后服務(wù)端收到客戶端發(fā)送ACK包后，進入CLOSED狀態(tài)，關(guān)閉連接句柄；

client狀態(tài)轉(zhuǎn)移語意：
a.客戶端通過connect連接服務(wù)器，connect失敗后直接進入CLOSED狀態(tài)，連接成功進入ESTABLISHED狀態(tài)；
b.客戶端向服務(wù)端發(fā)送FIN包，進入FIN_WAIT_1狀態(tài)，收到服務(wù)端的確認包進入FIN_WAIT_2狀態(tài)；
c.客戶端處于FIN_WAIT_2狀態(tài)，服務(wù)端處于CLOSE_WAIT狀態(tài)，此時可能處于半關(guān)閉，此時服務(wù)端可以發(fā)送和接收數(shù)據(jù)，但是客戶端只能接受數(shù)據(jù)；
d.客戶端收到服務(wù)端的FIN，ACK包后，進入TIME_WAIT，此時客戶端要等待2MSL（報文最大生存時間的2倍，一般是2min） ，可能大家比較疑惑，為什么需要TIME_WAIT狀態(tài)，而且需要等2MSL呢？
TIME_WAIT狀態(tài)存在原因有兩點：
其一是可靠的中止tcp連接；
其二是保證讓延遲的tcp報文有足夠的時間被識別；
客戶端在關(guān)閉連接階段需要處理收到重復的結(jié)束報文，然后回復最后的ACK給服務(wù)端，否則客戶端在收到服務(wù)端的FIN就直接回復ACK，這樣后續(xù)服務(wù)端重傳的FIN包都會被回復RESET報文，這時服務(wù)端認為是錯誤報文，這就是第一點存在的原因；
那么第二點是為了不讓同一個tcp端口被多次打開或者是斷開以后馬上被一個新的連接接管，這樣存在數(shù)據(jù)安全和處理異常等問題，讓tcp最大時間堅持2MSL也是為了確保重發(fā)和延時的tcp包在這段時間內(nèi)被丟棄(使用端口復用采用socket選項SO_REUSEADDR)；

3、tcp的數(shù)據(jù)流

往往按照正常的tcp模型，一個數(shù)據(jù)包回復一個確認包可能不適應(yīng)某些生產(chǎn)環(huán)境，為了更好的優(yōu)化tcp模型，下面討論兩種數(shù)據(jù)交互模型：

• 1、交互數(shù)據(jù)流：對于實時性比較高的應(yīng)用（如telnet，ssh），每次發(fā)送一個都需要進行數(shù)據(jù)確認，但是在網(wǎng)絡(luò)不好的情況下，很多微小的數(shù)據(jù)包會導致?lián)砣l(fā)送，因此采用Nagle算法（在后續(xù)章節(jié)介紹）和延時確認（即收到對端的數(shù)據(jù)包的時候，先不立即發(fā)送數(shù)據(jù)包，等到需要發(fā)送數(shù)據(jù)時候同時發(fā)出ACK包，當然這個控制在一定時間范圍內(nèi)）；
• 2、成塊數(shù)據(jù)流：對于類似ftp協(xié)議，多次發(fā)送大量的數(shù)據(jù)，接受端為了加快ACK確認包的順序，針對多個數(shù)據(jù)包進行一次確認或者開啟SACK(針對需要重傳的數(shù)據(jù)，回復對應(yīng)的偏移指針)，其中對端發(fā)送數(shù)據(jù)多次發(fā)送數(shù)據(jù)是根據(jù)接受端的窗口大小限制的，如果接受端參數(shù)win 30084，scale 6，表示還能接收3008464個字節(jié)，其中一次發(fā)送16384字節(jié)，那么接受端還能同時處理(3008464)/16384=106個數(shù)據(jù)包(一般不會發(fā)送這么多)；

4、tcp超時重傳和擁塞控制

tcp服務(wù)必須能夠重傳超時時間內(nèi)未收到的tcp報文段。
為此，tcp模塊為每一個tcp報文都維護一個重傳定時器，linux兩個重傳相關(guān)的內(nèi)核參數(shù)：
/proc/sys/net/ipv4/tcp_retries1和/proc/sys/net/ipv4/tcp_retries2
前者表示tcp最少執(zhí)行重傳次數(shù)，默認為3；
后者表示tcp最多執(zhí)行重傳次數(shù)，默認為15；
tcp服務(wù)有重傳必然就會導致?lián)砣?，那么接下來介紹網(wǎng)絡(luò)底層如何進行擁塞控制？
擁塞控制包括四個部分：慢啟動，擁塞避免，快速重傳和快速恢復；
在此之前還需要介紹窗口概念：RNWD(接收窗口，指前面tcp報文中的對端發(fā)送的win窗口)，CWND(擁塞窗口，是系統(tǒng)定義的一個狀態(tài)變量大小)，SWND(發(fā)送窗口，是RNWD和CWND之間的較小值)；
在tcp模塊剛開始發(fā)送數(shù)據(jù)階段并不知道網(wǎng)絡(luò)的實際情況，需要試探性地增加CWND，這一過程稱為慢啟動，CWND初始值設(shè)置為2-4個MSS；然后發(fā)送端每次收到接受端的一個確認，就按照公式：

CWND += min(N, MSS)

其中N是此次確認中包含的之前未確認的字節(jié)數(shù)；
如果隨著CWND不斷累加，不加控制會造成網(wǎng)絡(luò)擁塞，那么需要進行擁塞避免算法，界定慢啟動和擁塞避免過程通過慢啟動門限(ssthresh)控制，當CWND超過ssthresh則進入擁塞避免階段；
擁塞避免階段控制CWND是每個RTT時間都計算(如果RTT時間內(nèi)收到多少確認包)，公式：

CWND += SMSS*SMSS/CWND

這樣就保障了CWND緩慢增長，直到傳輸超時或者tcp重傳定時器溢出，就需要重新調(diào)整ssthresh，再次進入慢啟動階段，那么ssthresh計算公式：

ssthresh = max(FlightSize/2, 2MSS)

其中FlightSize已經(jīng)發(fā)送但是還未收到確認的字節(jié)數(shù)；
另外一種情況：在接受端接收到重復的確認報文段的時候，tcp模塊如何處理？
如果發(fā)送端收到3個重復的確認報文，認為擁塞發(fā)生，啟動快速重傳和快速恢復，先計算ssthresh；
然后通過CWND = ssthresh + 3 * SMSS計算出CWND，再次每收到1個重復確認時，設(shè)置CWND += SMSS，最后當收到新數(shù)據(jù)的確認時，直接設(shè)置CWND = ssthresh，這樣快速重傳和快速恢復完成，又再次進入擁塞避免階段。

5、補充知識

復位報文產(chǎn)生條件：

• 1、訪問不存在的端口；
• 2、異常中止連接，當發(fā)送端回復一個RST報文給接受端，接受端所有的排隊等待發(fā)送的數(shù)據(jù)都將被丟棄；
• 3、處于半連接狀態(tài)寫入數(shù)據(jù)時候，也會回復一個RST報文；