Tcp和IP協議承載了整個互聯網的生命線，這一章算是本書核心部分，掌握這兩個協議也是學好網絡編程的基礎。

套接字鍊接在表面上看就是建立連接，交換數據，斷開連接，雖然實際上細節肯定沒有那麼簡單，但是大體上的思路基本不變。

協議棧建立連接

這裡記住一個前提：向操作系統内部的協議棧發出委托時，需要按照指定的順序來調用 Socket 庫中的程序組件。

建立Socket的協議大部分情況都是Tcp/ip協議，Socket收發數據類似在兩個主機之間建立一個無形的管道，Socket建立的關鍵是要按照指定順序調用Socket程序組件，大緻的構建順序如下：

1. 創建Socket（Socket類似管道兩邊的出入口）
2. 綁定客戶端的套接字到服務端（類似接管道）
3. 交換數據。
4. 斷開Socket連接，解除綁定。

轉化為具體的流程圖如下：

創建Socket

過程大緻為應用程序會把控制流程會轉移到 socket 内部并執行創建套接字的操作，完成之後控制流程又會被移交回應用程序。

創建完套接字之後，協議棧需要返回标識符号也就是描述符用于标識是哪一個套接字在進行傳數據，因為我們可能打開很多套接字連接訪問不同的網站，具體的效果是我們浏覽器會打開很多個頁面，這時候每一個頁面都可能需要創建套接字，此時就需要識别和區分這些套接字依賴描述符。

綁定客戶端的套接字到服務端

​ 連接操作核心是調用Socket的CONNECT連接方法，此方法需要指定描述符、 服務器 IP 地址和端口号這 3 個參數。

​ connect看上去挺複雜，其實本質上就是完成連接動作而已，連接成功會把IP地址和端口号記錄到套接字上面。

描述符在創建Socket的時候已經拿到了，IP地址則是在DNS解析的步驟完成，拿到IP之後會放入到應用程序的某個位置替換保存，而端口号則是需要應用程序事先提供。

端口可以簡單看作應用程序的入口，DNS解析的IP隻能知道主機在哪但是本身發往哪個應用程序是不清楚的，我們可以想象DNS解析類似地圖上告訴我們高速的收費站坐标，但是他并不知道對應數據送往那個閘口）。

這裡可以理解為端口就是收費站過站口，計算機會要求程序對待應用程序預設明确的端口參與網絡交互。

傳遞消息

接下來的操作是調用read和write函數完成消息傳遞動作，這一步就是底層的流讀寫操作。

斷開連接

​ 這一步需要簡單理解為需要一方主動發起斷開申請浏覽器調用read收發數據同時會收到關閉請求，此時客戶端确認請求之後将會停止請求并且開始釋放Socket連接。

為什麼不能用描述符标識應用程序的入口？

描述符是和委托創建套接字的 應用程序進行交互時使用的，并不是用來告訴網絡連接的另一方。

客戶端也無法知道服務器上的描述符，客戶端也無法通過服務器端的描述符去确定位于服務器上的某 一個套接字。〉

Socket連接中大緻介紹了協議棧是如何通過網卡完成和目标服務器的連接、斷開、收發數據的過程下面按照順序講述各個步驟的細節。

下面我們根據上面所講的各個步驟按順序進行詳細介紹。

創建套接字

首先來看一下創建套接字的情況，下面是協議棧的内容。

​ 委托分發被拆分為好幾個部分，最上面可以看作浏覽器，協議棧中主要有兩張協議 TCP和UDP， TCP主要是用于和服務器交互收發數據的，UDP則用于較短的控制數據。

​ IP協議主要控制網絡收發操作，主要工作是把一個個拆分的網絡包發給通信的目标對象，IP協議包括 ICMP和 ARP協議，前者告知傳輸過程的錯誤和控制信息，後者傳遞以太網MAC地址。

MAC 地址：符合 IEEE 規格的局域網設備都使用同一格式的地址，這種地址被稱為 MAC 地址

驅動部分是為了讓操作系統能正常使用硬件進行網絡收發的一個“适配器”，而所有的電信号最終要通過網卡完成。

套接字和協議棧

協議棧實際上是根據套接字傳遞的信息來決定做什麼操作的，比如發數據要看IP和端口号。

以Windows的套接字為例，直接在CMD中使用 netstat操作即可：

複制代碼 隐藏代碼 C:\Users\Xander>netstat -ano 協議 本地地址 外部地址 狀态 PID TCP 0.0.0.0:49666 0.0.0.0:0 LISTENING 604 TCP 0.0.0.0:49667 0.0.0.0:0 LISTENING 1892 TCP 0.0.0.0:49668 0.0.0.0:0 LISTENING 4508 TCP 0.0.0.0:57621 0.0.0.0:0 LISTENING 22748 TCP 127.0.0.1:1001 0.0.0.0:0 LISTENING 4 TCP 127.0.0.1:1043 127.0.0.1:1061 ESTABLISHED 8452 TCP 127.0.0.1:1043 127.0.0.1:1063 ESTABLISHED 8452 UDP 192.168.159.1:1900 *:* 3060 UDP 192.168.159.1:5353 *:* 5248 UDP 192.168.159.1:58085 *:* 3060

netstat 命令 的 ano 三個參數主要用于擴展IP地址端口以及PID的顯示，以及一些隐式的可能存在的通信也會被記錄。

LISTENING：表示等待對方連接ESTABLISHED ：表示完成連接并且進行數據通信操作

套接字和協議棧和應用程序的交互流程如下：

1. 協議棧在操作套接字之前，需要事先開辟一塊空間來存放用于操作套接字的必要信息。
2. 協議棧需要向應用程序返回描述符表示當前連接的是哪一個“管道”。
3. 之後應用程序需要和協議棧交互就必須要攜帶描述符，不過這樣也節省了協議棧了解應用程序要和哪一個套接字交互。

連接服務器

連接的目的是為了讓兩台不在同一個地方的主機能夠相互認識對方，這時候不可避免地需要互相提供自己的信息，這樣才能正确的建立連接然後使用套接字傳輸數據。

連接的含義

人和人之間的溝通有時候可以不使用一個語言，隻要雙方都聽懂就行，但是對于計算機是行不通的。

所以連接操作的控制信息要根據通信規則确定，協議棧在通信之前需要依靠一塊空間來存放必要數據，這塊内存空間稱為緩沖區。

連接需要雙方各自告知自己的信息，所以連接最開始的時候是沒有任何數據交互的，由于是TCP是全雙工的協議客戶端和服務器都需要建立套接字，不過雙方不知道和誰連接，所以需要在客戶端和服務端各自開辟一塊空間來存放對方的IP和端口等必要的傳輸信息。

為了讓雙方既可以正常通信，又可以根據自己的系統設計協議棧和套接字的控制信息處理方式，網絡通信設計采用了 控制信息的方式讓不同的計算機和系統能相互認識。

所謂的控制信息可以認為是一種 通用語言，隻要是符合這個控制信息規範的頭部信息就可以被其他的計算機認識。

控制信息分為兩類：

1. 客戶端和服務器的交換的控制信息，主要用于整個通信過程，這些内容在TCP協議進行規定。生活的例子理解是我們和别人通話之前，兩邊都得知道對方的電話号碼和基本身份。
2. 保存在套接字中用來控制協議棧操作的信息，這些信息主要用來傳輸數據，通常需要包括控制信息和數據塊，套接字需要通過控制信息了解到發來的是什麼類型的數據，然後協議棧才能配合處理數據。

由于在一開始傳輸的時候是沒有具體數據的，通常是一個空的報文頭，所以這個控制信息也被叫做 協議頭部， 比如下面提到的TCP頭部，IP頭部。

第一類：TCP 頭部格式

第二類：套接字中的信息

連接的實際操作

連接的實際操作主要是調用CONNECT函數，協議首先會傳遞給TCP模塊，通過TCP模塊交換獲取控制信息的頭部，以此了解具體要連接的套接字信息，然後把頭部的SYN比特設置為1，表示可以連接。

TCP 模塊處創建表示連接控制信息的頭部，接着便把信息傳遞給IP模塊進行委托發送。

三次握手

交換頭部信息之後，接着便是常見的TCP三次握手的過程：

• 第一步：客戶端主動打開TCB端口，服務器被動打開TCB端口。發起方攜帶一個SYN标志，并且攜帶一個ISN序号Seq=x，但是需要注意的是第一步的過程這個ISN序号是隐藏傳遞的（因為沒有傳遞數據），因為如果請求不存在數據的交換則不會被顯示。客戶端發送SYN命令之後進入設置SYN=1，并且設置SYN-SENT（同步-已發送狀态）。
• 第二步：服務器收到客戶端TCP報文之後，也将SYN=1，并且回送一個新的ISN序号ack=x 1，并且将ACK=1表示自己收到了，然後在返回參數回送自己新的序列号表示自己的确認請求Seq=y，将狀态設置為SYN-RCVD（同步收到）狀态，（表示希望收到的序号為xxxx1522），最後也是指定MSS。
• 第三步：客戶端收到服務器的确認報文之後，還需要向服務端返回确認報文，确認報文的ACK=1，并且回傳服務器傳遞的ISN序号 1（ack = y 1），以及自己的ISN序号 1（Seq = x 1），此時TCP連接進入已連接狀态，ACK是可以攜帶數據的，但是如果不攜帶數據則不消耗序列号。
• 最後一步：當服務器收到客戶端的确認，也進入已連接狀态。

經過三次握手連接建立，直到斷開連接之前都可以傳遞數據。

收發數據

收發數據有兩個重點：

• 第一點是收發數據并不關心數據的格式，而是根據頭部信息來辨别是什麼類型的數據，對于協議棧來說接收的的内容都是二進制的數據。
• 第二點是利用緩沖區減少頻繁的數據傳輸提高傳輸效率。

緩沖區的大小如何控制？

• 每個數據包的數據長度，協議棧會根據一個叫作 MTU的參數來進行判斷，但是MTU指的是總長度，除開頭部信息之後獲得真實的數據長度MSS。
• 時間，這個時間指的是固定的時間内容不管緩沖區有有沒有達到MSS長度必須發送數據的時間，目的是防止等待時間過長造成請求延遲。

名詞解釋：

MTU：一個網絡包的最大長度，以太網中一般為 1500 字節。MSS：除去頭部之後，一個網絡包所能容納的 TCP 數據的最大長度。

但這兩個因素實際上并不能完全決定收發數據的效率平衡，TCP協議沒有規定協議棧如何平衡，具體需要看操作系統如何決定。

實際上協議棧收發數據是有所保留的，并不是強制按照協議的規定處理，而是給了應用程序一些可控選項，比如浏覽器這種要求實時性的應用程序通常不使用緩沖區。Http請求拆分

通常情況http的請求響應内容可以通過一個網絡包完成，但是針對POST請求等大表單的數據提交則通常會觸發TCP拆包操作。

拆包是根據MSS的參數确定的，發送緩沖區會根據這個參數把一個超過一次請求長度的數據拆分為多個包，但是因為實際上同屬一份數據，拆分之後所有的數據包都需要添加相同的頭部。

注意：TCP是面向字節流的協議，就是沒有界限的一串數據，本沒有“包”的概念，“粘包”和“拆包”一說是為了有助于形象地理解這兩種現象。

TCP粘包

TCP除了拆包動作之外還包含粘包的操作，所謂粘包是指TCP協議中發送方發送的若幹包數據到接收方接收時粘成一個包，從接收緩沖區角度來看後一個數據的頭緊接着前一包數據的尾部。

解決粘包、拆包問題策略？

​ 粘包和拆包需要解決容易造成半包讀寫的根本問題，解決辦法也有很多種，主要的策略基本很多網上資料都有講到，這裡直接搬運結論了：

• 請求消息定長，如果緩沖區不滿，則通過補0的方式達到長度，防止粘包和拆包。
• 在包尾增加回車換行符進行分割，例如FTP協議；
• 将消息分為頭部和消息體，頭部中保存整個消息的長度，隻有讀取到足夠長度的消息之後才算是讀到了一個完整的消息；
• 通過自定義協議進行粘包和拆包的處理。（幾乎不用）

ACK号确認網絡包收發

ACK号碼除了在三次握手的過程中确認對方是否有收到請求之外，還能作為判斷接收的數據包是否完整的依據，在進行數據傳輸的時候，接收方會将到目前為止接收到的數據長度加起來，計算出一共已經收到了多少個字節，然後将這個數值寫入 TCP頭部的 ACK 号中發送給發送方，以表示自己到底受到了多少數據，如果中間存在缺少數據則服務端重新傳輸即可。

當然僅靠ACK号不能完全作為參考依據，并且隻使用ACK号是隻考慮 單向傳輸的情況，但是TCP是全雙工協議，無法确定數據接收方來自哪一方。

解決這個問題也很簡單，實際在進行雙向數據傳輸的時候雙方各自會額外計算一個序号，序号其實就是一組随機數，在接收方收到數據之後每次都需要把序号 1回傳給發送方表示自己接收到哪一個序号之前的所有數據。

通過ACK 序号的方式确保數據正确傳輸，這樣可以使得其他網絡通信組件不需要額外的失敗補償機制，如果發現丢包或者數據不完整的情況，直接根據序号進行重傳重發的操作即可。

影響數據傳輸的因素

主要影響因素是返回ACK号的等待時間。

如果ACK号遲遲沒有響應給對方服務器，勢必會影響整個網絡傳輸的效率，如果下一個數據已經準備好上一個返回包卻沒有發回去，很容易造成網絡的堵塞，對方遲遲拿不到正确結果。

網絡環境的複雜多變，這個等待時間不可能是固定的，所以TCP使用了動态時間的方法進行調整，具體的調整方法就是使用滑動窗口。

滑動窗口

滑動窗口：指的是在不等待ACK返回結果的情況下直接雙方互相不間斷的發送數據。

雙方需要通過各自的緩沖區順序返回ACK信息，但是如果無限制的發送數據會導緻數據無法處理出現丢包，所以滑動窗口的關鍵是接收方需要告訴發送方自己最多能接收多少數據。

滑動窗口的細節通過一張圖更好理解：

關于接收方的接收量，最大能承受處理多少數據是通過緩沖區大小确定的。另外需要注意下面的圖隻有單向的部分，實際上對于雙向來說都是類似的處理。

影響數據傳輸的次要因素：返回 ACK号和更新窗口的時機。

關于這一點直接記住一個結論，接收方在發送 ACK 号和窗口更新時，并不會馬上把包發送出去，而是會等待一段時間，等到其他的通知合并到一起處理，因為ACK号體現的是已經收到的包的數據量，使用這樣延遲發送的方式也可以防止過多的更新數據包出現。

最終協議棧收發數據的細節如下：

1. 協議棧會根據收到的數據塊和TCP或者IP頭部解析内容，如果确認收到數據則返回ACK 序号。
2. 協議棧會把數據塊放到緩沖區進行存儲，利用滑動窗口的特性按照順序處理數據交給應用程序處理。
3. 協議棧會将接收到的數據複制到應用程序指定的内存地址中，然後将控制流程交回應用程序

斷開連接

斷開連接的部分包含斷開連接和删除套接字的操作，斷開連接也就是經典的四次揮手的操作，而删除套接字則需要注意在協議棧中并沒有規定關閉的時間，但是通常情況下過幾分鐘之後會删除套接字。

四次揮手端口tcp連接

• 第一步（客戶端）：TCP發送釋放連接的報文，停止發送數據，釋放報文首部，把FIN=1，同時發送序列号，根據上一次傳送的序列号 1傳送Seq = t 1（由于下圖是在連接之後立馬進行四次揮手，所以序列号沒有變），此時客戶端進行終止等待1的狀态。注意FIN不攜帶數據也需要消耗序列号。
• 第二步（服務端）：服務器回送确認報文，發出确認報文，ACK=1，并且把回傳序列号 1回傳（ack = t 1），然後再帶上自己的序列号Seq = y，此時服務端進入CLOSE-WAIT狀态（關閉等待狀态），TCP服務器此時需要停止上層應用客戶端向服務端請求釋放，處于 半關閉 階段，此時服務端依然可以向客戶端發數據并且客戶端需要接收并處理，關閉等待狀态意味着整個狀态還需要持續一段時間。
• 第三步（客戶端）：客戶端接收到服務端确認請求，此時客戶端進入到FIN-WAIT-2終止等待2的階段，等待服務器的釋放報文。（還有一部分服務器沒有發送完的數據需要處理）
• 第四步（服務端）：服務器把最後的數據處理完畢，向客戶端發送釋放報文，FIN=1，ack=t 1，由于需要把剩下的數據發送完成，假設處理完成之後需要帶上自己的序列号Seq=w，服務器進入最後确認狀态，等待客戶端确認。
• 第五步（客戶端）：客戶端收到報文之後，發出确認 ACK=1，ack=w 1，自己的序列号為Seq = t 1，此時客戶端進入到了TIME-WAIT（時間等待狀态），此時客戶端還是沒有釋放，必須經過**2 * MSL（最長報文壽命）**之後，客戶端撤掉TCB之後才進入CLOSED狀态。
• 第六步（服務端）：服務器收到客戶端的請求立馬進入CLOSE狀态，同時撤銷TCB，結束此次TCP的連接。（服務端結束TCP連接要比客戶端早一些）

套接字和協議棧和對方服務器的交互流程細節還是比較多的，這裡可以發現實際上三次握手和四次揮手實際上隻是網絡連接當中很小的一部分，最後是從連接服務到數據收發到斷開連接的一張簡單總結圖，建議當作一個大概的流程參考：

IP和以太網的收發操作

上面的部分比較貼近TCP協議的相關操作，TCP完成連接收發的同時其實都需要IP模塊的配合，在了解這兩個模塊如何配合工作之前需要了解完整的網絡包是如何組成的。

包的組成

對于任何一個網絡包，都有最外層的抽象概念，那就是頭部和數據 兩個部分

上面的部分有一個這樣的圖，裡面套接字中的TCP數據，這裡需要注意在TCP控制信息的前面就是以太網和IP的控制信息，對于隻傳輸控制信息的網絡包雖然沒有數據的部分，但是可以把協議的頭部信息作為數據部分。

通過下面的圖也可以發現，所有的網絡包必須要委托以太網和IP控制信息才能完成傳輸。

把存放數據的網絡包進行拆分，可以看到下面的TCP/IP 包結構：

我們可以簡單把頭部和數據看做是平時的快遞，頭部是面單，指示從哪裡到哪裡，然後這個“快遞”會通過網絡轉發設備的查表操作判斷傳輸到那個方向。

轉發設備是什麼？這裡建議看看第一章的關于認識網絡傳輸的基本概念，這裡簡單提一下：

• 路由器根據目标地址判斷下一個路由器的位置
• 集線器在子網中将網絡包傳輸到下一個路由

但是實際上集線器和路由器各自有不同分工，集線器負責管理以太網規則傳輸包設備，路由器管理IP轉發規則，所以上面兩個步驟也可以做下面的理解：

• IP協議根據層級規則判斷下一個IP轉發設備。
• 子網的以太網協議轉發給下一個轉發設備。

實際上頭部部分應該分為 MAC 頭部 和 IP頭部。為什麼要把頭部拆分為兩個協議？實際上是為了讓協議之間可以實現替換，比如MAC可以替換為局域網、ADSL、FTTH。同時因為互聯網這樣龐大的網絡架構，需要更加細化的分工。

小結

實際上網絡包的封裝應該範圍三個部分：

第一部分是TCP模塊組織頭部信息和數據包（當然也可能沒有數據隻有控制信息）。

第二部分是把整個TCP模塊塞到IP模塊的後面，然後經過網卡發送出去。

第三部分是在IP模塊前面加上Mac信息。

關鍵：無論要收發的包是控制包還是數據包，IP 對各種類型的包的收發操作都是相同的。

名詞解釋ADSL：可以理解為以前寬帶使用撥号連接互聯網上網的方式。

非對稱數字用戶線路（英語：Asymmetric Digital Subscriber Line）又稱非對稱數字用戶環路（Asymmetric Digital Subscriber Loop），簡稱ADSL。ADSL是一個依靠銅質電話線的數據傳輸技術比傳統的調制器更快。

FTTH：其實就是現在的光纖通信。

光纖到戶（英語：Fiber To The Home，縮寫：FTTH）是一種光纖通信的傳輸方法。是直接把光纖接到用戶的家中（用戶所需的地方）。

這種光纖通信方式及策略與FTTN、FTTC、HFC（Hybrid Fiber Coaxial）等也不同，它們都是需要依賴傳統的金屬電線，包括雙絞線及同軸電纜等，作“最後一哩”的信息傳輸。

IP 協議頭部

IP類似快遞上的單号，所以實際上IP模塊是無法決定自己選擇正确的地址了，哪怕應用程序通過TCP告訴IP發的地址式是一個錯誤地址，IP也無法自行修正隻能照做。

從這樣的特點可以看出IP頭部又有點類似快遞員，和網上買東西商家發錯地址或者我們填錯地址一樣，不能把責任賴在快遞員上。

IP協議頭部的組成類似下面的結構，注意IP地址的長度固定需要32Bit的空間占用。

這裡需要注意“發送方的IP”地址不是指計算機的IP，而是指網卡對應的IP，因為IP不是分配和計算機而是網卡的，當一個計算機有多個網卡就會存在多個IP。

那麼應該如何判斷包發送給哪一個網卡？這裡涉及到IP協議規則，無論是路由器的轉發還是協議棧的處理都需要按照IP協議轉給下一個用戶。

查詢分配給哪一個網卡在不同操作系統中的查詢方式不同，查詢發送端需要查詢是哪個網卡把包發給了路由器，這個動作隻需要簡單的根據路由器IP地址和網卡的IP進行比對。

在windows中可以通過命令route print查看路由信息。

獲取IP和網卡之後，還需要知道包所屬的協議，委托内容是固定的，比如TCP模塊就是06，UDP就是17，大部分請求都是HTTP，使用TCP的方式傳輸。

以太網Mac頭部

TCP/IP模塊隻能在傳輸層上互相了解，但是往下的鍊路層以太網用同樣的規則是行不通的，所以頭部加上TCP/IP的頭部之後，還需要在頭部加上Mac頭部，Mac頭部包含了發送方和接收方的Mac信息，這裡可以簡單理解為Mac和IP的作用類似，不過Mac頭部是48Bit，而IP頭部是32Bit。

需要注意以太類型就是Mac包裝的後面的真實數據的類型， 如果是IP就是IP協議。另外需要注意在發送Mac包給接收方之前，由于不知道對方的Mac地址，所以還需要一步查詢操作。

注意IP 模塊根據路由表 Gateway 欄的内容判斷應該把包發送給誰。

下面是Mac頭部的組成：

查詢Mac地址

查詢對方的Mac地址需要用到ARP（ Address Resolution Protocol，地址解析協議），ARP通過廣播的方法查找到目标地址，所謂廣播就是字面意思把消息發給所有的其他互聯網用戶，等待對方應答。

為了防止每次查詢都要帶ARP的數據，所以有一塊ARP的緩存專門緩存這個地址，但是需要注意這個緩存和IP模塊的IP地址一樣，過一段時間會被ARP緩存淘汰掉，但是如果IP剛剛變化可能會導緻ARP緩存未及時更新導緻網絡異常。

實際整個工作都是由IP模塊完成的，雖然Mac地址是以太網數據傳輸的必要内容，但是實際上讓IP模塊負責這些工作是有利的。

為什麼需要以太網？

# 有了 IP 地址，為什麼還要用 MAC 地址？

以太網基本知識

首先來看看以太網的基本發展，雖然設計結構越來越精細，但是本質上幹的活卻沒有發生變化。

以太網早期原型本質上可以看作是一根網線以及一個用于收發的設備，網絡信号發送之後通過廣播最終到達所有設備，在開頭的收發信息讓其他人可以知道信息最終要發給誰，在Mac頭部就包含了“收貨地址”，而具體發送了什麼類型的可以通過上面的“以太類型”進行判斷。

以太網在後續的發展中将主幹網線替 換成了一個中繼式集線器，收發器變成雙絞線，雖然形式變了，但是本質的工作沒有變。

以太網到了現代最終由交換式集線器完成所有的操作，并且網絡請求隻有請求方和接收方可以互通，集成度增加以及網絡傳輸安全性能增加。

但是以太網無論怎麼發展性質始終沒有任何變動：

MAC 地址代表的目的地，用發送方 MAC 地址識别發送方，用以太類型識别包的内容。

IP模塊轉光（或電）信号

網絡信号發送依賴網卡，但是網卡并不是插上電就可以使用的，還需要依賴初始化以及驅動程序才能完成操作，驅動程序和初始化操作在其他很多電腦硬件中比較常見，但是以太網有比較獨特的驅動操作，那就是控制以太網收發操作的MAC當中收發MAC地址。

另外網卡還有一個特性是網卡的 ROM 中保存着全世界唯一的 MAC 地址，這是在生産網卡的時候就已經決定。

所以可以看到最終完成IP數據轉化的關鍵是驅動程序，網卡中保存的 MAC 地址會依賴網卡驅動程序讀取并分配給 MAC模塊。

網絡包的控制信息

MAC模塊工作在網卡調用MAC包發送請求命令之後，MAC模塊的工作是劃分網絡包的“邊界”。

為了劃分邊界，MAC模塊會加上三個控制信息：

1. 報頭：是一串像 10101010…這樣 1 和 0 交替出現的比特序列，長度為** 56 比特**，它的作用是确定包的讀取時機。
2. 起始幀分界符（SFD）：确定幀的起始位置，主要是輔助電信号切分報文頭部和真實的網絡包邊界，并且判斷出每個比特的界限。
3. FCS：檢查包傳輸過程中因噪聲導緻的波形紊亂、數據錯誤，它是一串 32 比特的序列，是通過一個公式對包中從頭到尾 的所有内容進行計算而得出來的

響應内容傳輸從IP給TCP

當服務器接收到網絡包之後，首先協議棧會判斷以太網頭部的以太類型，發現是0800為TCP/IP協議，接下來是IP模塊工作，首先是檢查IP頭部是否正确，IP地址是否正确。

如果接收方是window客戶端，因為不會對包進行轉發，如果發現包不是發給自己的，會調用ICMP消息回傳給請求發送方，IMCP的消息格式如下：

另外接收到的網絡請求可能會因為數據包過大出現IP分片，分片的包會在 IP 頭部的标志字段中進行标記，IP模塊會把分片過的包暫存内部内存空間，等相同ID的包全部接收到緩沖區之後再拼接。

怎麼保證拼接的順序正确呢？可以查看前文IP 頭部還有一個分片偏移量（fragment offset）字段，它 表示當前分片在整個包中所處的位置。

IP模塊完成數據分片重組之後，數據包交給TCP模塊操作，TCP還會再次檢查一遍請求方和接收方的IP信息，以及獲取端口号找到對應的套接字，找到套接字之後根據應用程序的類型進行不同的操作，這個過程可能是建立連接，也可能是完成應用程序數據的讀寫操作。

這裡可能會覺得IP檢查不是IP模塊的操作麼，TCP去看IP模塊的信息是不是“越權”了？實際上這是一種性能開銷都考慮而違反“迪米特法則（Law of Demeter）”的一種特例。因為TCP模塊需要頻繁使用IP模塊的信息，如果老是需要數據之間的交互傳輸非常影響性能。

UDP協議收發操作

TCP/IP為了保證數據準确收發需要使用一系列複雜的模塊和過程配合保證數據的完整傳輸，但是有時候有些應用程序為了保證高效會舍棄使用TCP這種複雜的機制。

UDP協議的要點是盡可能将所有的數據通過一個包解決，UDP 沒有 TCP 的接收确認、窗口等機制，因此在收發數據之前也不 需要交換控制信息。UDP的實現非常簡單隻需要應用程序加入頭部，直接交給IP模塊完成即可，接收方也隻需要檢查IP頭部的發送方和接收方的IP地址信息，然後再從UDP找到端口号，最後再找到套接字信息把數據給應用程序。

因為UDP不保證傳輸的穩定性所以無論包是否接收到都無關緊要，隻要對方沒有回應直接把包進行重發即可。這種不需要保證傳輸穩定性的場景還是有不少的，比如聊天數據、音頻和視頻信息，即使丢失一點點也沒有關系，最多是卡頓一下而已。

關鍵：UDP 可發送的數據最大長度為 IP 包的最大長度減去 IP 頭部和 UDP 頭部 的長度。一般來說 IP 頭部為 20 字節，UDP 頭部為 8 字節，因此 UDP 的最大數據長度為 65507 字節。

下面是UDP的頭部信息：

小結

在第二章我們了解Socket鍊接的步驟和大緻細節，另外介紹了整個互聯網比較重要的兩個協議TCP協議和IP協議，在兩個協議中需要重點掌握頭部設計，IP模塊完成TCP模塊的數據，TCP數據封裝應用程序數據，之後還需要配合Mac以太網模塊完成網絡包的最後封裝，等一切準備工作完成之後，由網卡以及驅動程序把整個包發送出去，所以其實可以看到決定你能不能上網等實際上是網卡和驅動（這不是廢話），但是這些内容屬于不同層級的内容，需要一一消化。

介紹了TCP之後，在在第二章最後部分簡單提到了UDP協議，UDP是一種簡單暴力的協議，設計的目的是讓所有的數據盡可能通過一個包完成，所以他不需要鍊接也不需要保證數據安全傳輸，數據丢了直接傳輸即可，UDP的應用也是十分廣泛的，比如遊戲，視頻，音樂等等數據的傳輸，很多時候丢一點根本無關緊要，因為即使找回來這些數據也沒有意義。

TCP/IP連接也隻是互聯網數據傳輸的一小部分，但是确實最為核心的部分，雖然往下還有以太網和網卡以及網絡通信如何上網等細節，但是隻有深刻了解TCP/IP協議才能了解整個互聯網是如何交互和數據傳輸的。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部