色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

TCP/IP協議棧之ip協議棧詳解

冬至子 ? 來源:周末程序猿 ? 作者:周末程序猿 ? 2023-08-01 17:21 ? 次閱讀

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的頭部結構如下:

1.jpg

重點介紹字段:
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字節+可變頭部):

1.jpg

重點介紹字段:
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的頭部結構

1.jpg

32位的序號:一次tcp通訊過程中某個傳輸方向上字節流的每個字節的編號,初始化階段為一個隨機值,后續的tcp報中的序號設置為初始值+該報文在所攜帶的數據的第一個字節在整個字節流的偏移量;
32位的確認號:是對端的32位的序號+1;
4位頭部長度:標識tcp頭部32個字節的大小,由于只有4位,所以tcp頭部最長位60字節;
6位標識:URG(緊急指針),ACK(確認包),PSH(數據包),SYN(建立連接包),FIN(關閉連接包);
16位窗口大小:指接受通告窗口大小,告訴對端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,窗口大小14480
2^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報文;
聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規問題,請聯系本站處理。 舉報投訴
  • TTL電路
    +關注

    關注

    2

    文章

    65

    瀏覽量

    15071
  • 局域網
    +關注

    關注

    5

    文章

    751

    瀏覽量

    46277
  • TCP
    TCP
    +關注

    關注

    8

    文章

    1353

    瀏覽量

    79055
  • DNS
    DNS
    +關注

    關注

    0

    文章

    218

    瀏覽量

    19828
  • TCPIP協議棧
    +關注

    關注

    0

    文章

    6

    瀏覽量

    5897
  • TCP通信
    +關注

    關注

    0

    文章

    146

    瀏覽量

    4221
收藏 人收藏

    評論

    相關推薦

    全硬件TCP/IP協議學習筆記(第四天:全硬件TCP/IP協議模塊學習)

    /IP協議的不同歸類為兩大類,第一類是傳統的軟件TCP/IP協議
    的頭像 發表于 12-18 10:27 ?8764次閱讀
    全硬件<b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b><b class='flag-5'>協議</b><b class='flag-5'>棧</b>學習筆記(第四天:全硬件<b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b><b class='flag-5'>協議</b>模塊學習)

    協議介紹--TCP/IP

    ,在使用上與一般的協議相同,可能只是在具體的使用細節可能有點不同。3)本協議設計時使用標準UCOS-II操作系統。也可使用其它操作系統下運行。4)本
    發表于 09-03 15:03

    如何去簡化Simplified TCP/IP協議

    Simplified TCP/IP協議的特點是什么?如何去簡化Simplified TCP/IP
    發表于 05-26 07:23

    TCP/IP協議有何功能

    TCP/IP協議是什么?TCP/IP協議
    發表于 10-14 06:39

    UCOS下的TCP-IP-PPP協議

    UCOS下的TCP-IP-PPP協議
    發表于 03-25 16:51 ?61次下載

    TCP/IP協議之路由器簡要分析

    讀完這個系列的第一篇淺談TCP/IP協議(一)入門知識和第二篇淺談TCP/IP
    發表于 10-10 11:46 ?1次下載

    Microchip TCP/IP協議

    的開發人員可以很容易找到許多Microchip產品的商業和非商業的TC P/IP實現方案。本應用筆記詳細說明了Microchip公司自己免費提供的TC P/IP協議。 Microch
    發表于 04-20 16:04 ?4次下載
     Microchip <b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b><b class='flag-5'>協議</b><b class='flag-5'>棧</b>

    介紹tcp_ip協議lwip的特點

    簡介了嵌入式tcp_ip協議lwip的基本信息
    的頭像 發表于 07-03 13:05 ?3653次閱讀

    Microchip TCP/IP精簡協議

    本應用筆記描述 Microchip 傳輸控制協議 / 互聯網協議TCP/IP)精簡協議庫的結
    發表于 04-01 15:36 ?17次下載
    Microchip <b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b>精簡<b class='flag-5'>協議</b><b class='flag-5'>棧</b>

    Microchip TCP/IP協議

    。感興趣的開發人員可以很容易找到許多 Microchip 產品的商業和非商業的TCP/IP 實現方案。本應用筆記詳細說明了 Microchip 公司自己免費提供的 TCP/IP
    發表于 04-02 14:28 ?22次下載
    Microchip <b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b><b class='flag-5'>協議</b><b class='flag-5'>棧</b>

    到底什么是TCP/IP協議,看完這篇你就明白!

    一談到TCP/IP協議,相信不少小白都處于暴躁的邊緣,只懂其一不知其二。沒關系,看完這篇你就知道啦!我們先簡單了解下TCP/
    的頭像 發表于 12-09 15:21 ?1436次閱讀
    到底什么是<b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b><b class='flag-5'>協議</b><b class='flag-5'>棧</b>,看完這篇你就明白!

    Linux高性能網絡編程之TCP/IP協議ip協議詳解

    或者七層,但是便于大家理解,基本上都是用四層模型,如:數據鏈路層,網絡層,傳輸層和應用層。
    發表于 08-08 15:38 ?1056次閱讀
    Linux高性能網絡編程之<b class='flag-5'>TCP</b>/<b class='flag-5'>IP</b><b class='flag-5'>協議</b><b class='flag-5'>棧</b><b class='flag-5'>之</b><b class='flag-5'>ip</b><b class='flag-5'>協議</b><b class='flag-5'>棧</b><b class='flag-5'>詳解</b>

    Microchip TCP/IP 協議應用筆記

    電子發燒友網站提供《Microchip TCP/IP 協議應用筆記.pdf》資料免費下載
    發表于 04-17 14:16 ?1次下載

    TCP/IP協議的設計與實現_中文

    電子發燒友網站提供《TCP/IP協議的設計與實現_中文.pdf》資料免費下載
    發表于 07-03 11:28 ?4次下載

    LwIP協議源碼詳解TCP/IP協議的實現

    電子發燒友網站提供《LwIP協議源碼詳解TCP/IP協議的實現.pdf》資料免費下載
    發表于 07-03 11:22 ?3次下載
    主站蜘蛛池模板: 国产 日韩 欧美 综合 激情| 99久久精品免费看国产免费| 岳扒开让我添| 诱咪视频免费| 99久久综合精品免费| 成人永久免费视频网站在线观看| 国产Av男人的天堂精品良久| 国语对白老女人8av| 久久久久久久久女黄| 欧美色图一区二区三区| 色欲天天婬色婬香影院| 亚洲欧洲免费三级网站| 51久久成人国产精品麻豆| 成人手机在线| 黄色a三级免费看| 男人J进入女人P免费狂躁| 日本一本2017国产| 亚洲国产日韩a精品乱码| 538在线视频一区二区视视频| 岛国片在线看| 久久精品18| 日本女人水多| 一个人在线观看的视频| 哺乳溢出羽月希中文字幕| 国产主播福利一区二区| 男男被强bl高h文| 亚洲人成人77777在线播放| 成年免费三级视频| 国产精品一区第二页| 久久99精品AV99果冻| 欧美丝袜女同| 亚洲欧美无码2017在线| www.av在线| 久久热r在线视频精品| 人人碰国产免费线观看| 亚洲欧洲日产国码中学| 在线日本高清日本免费| 漂亮的av女演员| 国产女合集小岁9三部| 一级毛片皇帝 宫女| 内射人妻骚骚骚|