1、tcp/ip協議棧分為四層

或者七層，但是便于大家理解，基本上都是用四層模型，如：數據鏈路層，網絡層，傳輸層和應用層。
其中封包的流程是：

應用層數據 --- >  
tcp/udp頭部(20字節) + 應用層數據 --- >  
ip頭部(20字節) + tcp/udp頭部(20字節) + 應用層數據 --- >  
以太網頭部(18字節) + ip頭部(20字節) + tcp/udp頭部(20字節) + 應用層數據

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

2、arp協議工作原理

主機向自己所在的網絡廣播一個arp請求，請求獲取目標ip地址的物理地址，請求發出后所在的網絡(局域網)都會收到這個請求，當匹配該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協議，192.168.1.100發送dns解析，42940是dns查詢標示，+是采用遞歸查詢，A?是使用A類查詢（A方式是查找ip，CNAME方式是查詢主機別名，PTR是反向查詢）。
202.96.134.33.53回包解析42940是發送dns解析的標示，1/0/0是1個應答資源，0個授權資源記錄和0個額外信息記錄，A是A類查詢返回，93.46.8.89是返回www.google.com.hk域名的ip地址；

4、ip協議

ip是無連接，無狀態，不可靠的協議，是tcp/udp的動力，決定了路由和轉發的功能，ipv4的頭部結構如下：

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

5、ip分片和轉發

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

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數據)和21(20個ip報頭，1個icmp數據，由于下一個數據報不需要攜帶icmp的數據報頭)；
本小節還有一個知識點是ip數據報在主機上的轉發，主機一般都不轉發，不過可以設置echo 1 > /proc/sys/net/ipv4/ip_forward，那么轉發邏輯如下：

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

6、ipv6頭部結構

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

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

第二部分：tcp／ip協議棧之tcp協議棧詳解

tcp協議在我們的應用中非常重要，本小節主要從四方面討論tcp協議：

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

1、tcp數據特點

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

2、tcp的頭部結構

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

具體的數據報樣例：

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是選項字段；
第二條請求是回包數據，Flags [S.]表示syn，ack包，seq序號3491427708，ack確認序號2580028945+1，窗口大小144802^7（需要計算options中的wscale 7擴大因子選項），options是選項字段；

3、tcp的狀態轉移

tcp在建立連接和斷開連接分別要經過三次握手和四次揮手，那么都會有相應的服務器端口狀態，只描述三次握手和四次揮手雙端的狀態，如圖：

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

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

3、tcp的數據流

往往按照正常的tcp模型，一個數據包回復一個確認包可能不適應某些生產環境，為了更好的優化tcp模型，下面討論兩種數據交互模型：

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

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

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

CWND += min(N, MSS)

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

CWND += SMSS*SMSS/CWND

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

ssthresh = max(FlightSize/2, 2MSS)

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

5、補充知識

復位報文產生條件：

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