DP例題

阿新 • • 發佈：2020-07-15

從一個經典的面試題說起

從輸入URL到頁面展現的過程:

輸入URL後，會先進行域名解析。優先查詢本地host檔案有無對應的IP地址，沒有的話去本地DNS伺服器查詢，還不行的話，本地DNS伺服器會去找根DNS伺服器要一個域伺服器的地址進行查詢，域伺服器將要查詢的域名的解析伺服器地址返回給本地DNS，本地DNS去這裡查詢就OK了。
瀏覽器拿到伺服器的IP地址後，會向它傳送HTTP請求。HTTP請求經由一層層的處理、封裝、發出之後，最終經由網路到達伺服器，建立TCP/IP連線，伺服器接收到請求並開始處理。
伺服器構建響應，再經由一層層的處理、封裝、發出後，到達客戶端，瀏覽器處理請求。
瀏覽器開始渲染頁面，解析HTML，構建render樹，根據render樹的節點和CSS的對應關係，進行佈局，繪製頁面。

這4個步驟包含了一個HTTP請求的完整生命週期，文章著重介紹第2步和第3步，也就是請求是如何在兩個物理端點之間進行通訊的。資料的發出和接收必然會經歷一些處理、解析的過程，這些過程在系統的不同層次進行。

分層

一個HTTP請求從源端發出到在終端接收的處理過程都是要經過以下四層。其中每一層都有各自的協議。

我們先來理解一下協議是什麼，協議是經過約定，雙方共同承認，並且需要共同遵守的規則。上面的每一層，都有各自的協議，協議的執行者是通訊鏈路兩端內的對應層。每一層通過協議來理解資料，並進行處理。

上圖中只舉例出了最常見的協議，實際上每一層都有細分的協議：

應用層：應用程式負責將資料以相應規則（協議）進行包裝，發給傳輸層
- HTTP：超文字傳輸協議
- FTP：檔案傳輸協議
- SMTP：簡單郵件傳送協議
- SNMP：簡單網路管理協議
傳輸層：負責將應用層傳過來的資料進行分組，為確保終端接收資料的順序和完整性，會對每個分組進行標記，交給網路層
- TCP：傳輸控制協議
- UDP：使用者資料協議
網路層：負責將傳輸層發來的資料分組傳送到目標終端
- IP：網際協議
- ICMP：Internet網際網路控制報文協議
- IGMP：Internet組管理協議
鏈路層：為網路層傳送和接收資料單元
- ARP：地址解析協議
- RARP：逆地址解析協議

封裝和分用

資料在經過每一層的時候都要被對應的協議包裝，到達終端的時候，要一層一層的解包。這兩個過程叫封裝和分用。

傳送時，使用者資料被HTTP封裝為報文，每一層會將上層傳過來的報文作為本層的資料塊，並新增自己的首部，其中包含了協議標識，這一整體作為本層報文向下傳遞。

接收時，資料自下而上流動，經過每一層時被去掉報文首部，根據報文標識確定正確的上層協議，最終到應用層被應用程式處理。

封裝

源端傳送HTTP報文時，報文會以資料流的形式通過一條已經開啟的TCP連線按序傳輸，TCP收到資料流後會將其分割成小的資料塊，每個小塊被新增的TCP首部與資料塊共同組成了TCP分組，分組經由網路層傳送，網路層遵循IP協議，當收到分組傳送請求後，會將分組其放入IP資料報，填充報頭，將資料報發經由鏈路層傳送出去。

這一過程經過每層的時候都會被增加一些首部資訊，有時還需要增加尾部資訊，每一層都會把資料封裝到各自的報文中，並在報文首部新增協議標識，這個過程叫封裝。

分用

終端接收到一個乙太網資料幀時，資料自底層向上流動，去掉髮送時各層協議加上的報文首部，每層協議都要檢查報文首部的協議標識，從而確定上層協議，保證資料被正確處理，這個過程叫分用。

終端從鏈路層接收到資料請求後，進入網路層對資料進行解析，交給給傳輸層，校驗分組順序和完整性，從資料塊中取出資料，得到HTTP報文，交給應用層進行處理。這個過程會逐層剝離報頭還原資料。

逐層分析

我們已經知道，資料是從源端自上而下到終端自下而上被一層層處理的，現在就來看一下每層都做了什麼事情。

HTTP

HTTP屬於應用層，使用者觸發互動所產生的行為資料和服務端對此的響應都由它封裝成HTTP報文，再交由下層協議進行處理。報文的作用是客戶端與服務端溝通的載體，雙方都要遵循統一規則對資訊進行處理，這一規則稱為HTTP。

客戶端與服務端的互動往往非常複雜，為了使雙方都能高效、明確、安全地通訊（例如傳遞意圖與狀態、承載資料、攜帶認證資訊、控制連線行為與快取），需要依賴報文中的結構來實現，下面先從結構開始看。

報文結構

HTTP報文的結構分為請求和響應兩種，請求報文封裝使用者操作產生的動作，告知伺服器應採取什麼行為，響應報文來告知客戶端請求的結果。
請求報文格式：

<method> <request-url> <version> // 起始行格式
<headers> // 首部
<body> // 實體

響應報文格式：

<method> <status> <reason-phrase> // 起始行格式
<headers> // 首部
<body> // 實體

起始行

報文的起始行表明了報文的開始，請求和響應各自的起始行的格式也不相同。

請求報文的起始行說明要做什麼，結構為方法 + 請求URL + 協議版本，中間用空格做分隔：

GET /api/nht/blog/example HTTP/1.1

響應報頭的起始行說明發生了什麼，結構為協議版本 + 狀態碼 + 描述文字，中間用空格做分隔：

HTTP/1.1 200 OK

方法與狀態碼

方法來告訴服務端請求報文要做的事情，狀態碼來通知客戶端服務端依據請求報文完成動作之後的大致結果。常見的HTTP方法如下：

| 方法 | 含義 | 有無主體 | | ------- | ---------------------------------------------- | -------- | | GET | 從服務端獲取資源 | 無 | | HEAD | 只獲取資源頭部 | 無 | | POST | 向服務端傳送資料 | 有 | | PUT | 將客戶端傳送的資料存到服務端，應用場景多為修改 | 有 | | OPTIONS | 對服務端進行預檢，例如服務端支援哪些方法 | 無 | | DELETE | 從服務端刪除資源 | 無 |

請求完成時，響應報文中會有一個狀態碼，用來表示此次請求的狀態，是成功了還是失敗了，或者時需要重定向。狀態碼的範圍從100到599， 其中有部分是已經定義的。不同的範圍表示的含義也不同：

| 範圍 | 已定義範圍 | 含義 | | ------- | ---------------------------------------------- | ---------- | | 100~199 | 100~101 | 資訊提示 | | 200~299 | 200~206 | 成功 | | 300~399 | 300~305 | 重定向 | | 400~499 | 400~415 | 客戶端錯誤 | | 500~599 | 500~505 | 服務端錯誤 |

首部

首部是請求和響應報文中的一些資訊，形式為鍵值對，每對鍵值結尾是CRLF換行符，它決定了請求或者響應報文的屬性，比如Content-Type表明了請求主體的資料型別，Date說明了請求的建立時間。客戶端與服務端通過首部來協商具體行為。可以根據請求、響應、結構等，將首部分為五種。

請求首部：是放在請求報文中的首部，它被用來告訴服務端一些資訊。
響應首部：為客戶端提供一些可能用到的資訊。
通用首部：請求與響應報文都包含的首部，例如Date首部
實體首部：對於報文實體主體部分的描述，比如Content-Type，表明其資料型別。
擴充套件首部：開發者自己新增的首部欄位，用來滿足定製化需求。

實體

HTTP/1.0 200 OK
Server: xxxxxxx
Date: Sun,17 Sep 2019 02:01:16 GMT
--------------------------------實體首部
Content-Type: text/plain
Content-length: 18
--------------------------------實體主體

Hi! I"m a message!
--------------------------------

實體部分是可選的，它被用來運送請求或者響應的資料，實體由實體首部 + 實體主體組成，實體首部對實體主體做描述。HTTP/1.1定義了以下的基本實體首部欄位：

Content-Type: 實體主體中的資料型別。
Content-Length: 實體主體的長度或者大小。
Content-Language: 和傳輸的資料最匹配的語言。
Content-Encoding: 來標識服務端編碼時所用的編碼方式。
Content-Location: 要返回的資料的地址。
Content-Range: 如果是部分實體，用來標記它是實體的哪個部分。
Content-MD5: 實體主體內容的校驗和。
Last-Modified: 所傳輸內容在伺服器上建立或者最後修改的日期時間。
Expires: 實體資料試下的日期時間。
Allow: 所請求資源允許的請求方法。
ETag: 資源的特定版本的識別符號。可以讓快取更高效，並節省頻寬。
Cache-Control: 控制快取機制的指令。

以上是HTTP報文包含的主要結構，當請求報文到達伺服器時，伺服器會對報文中的內容解析出來，根據方法、資源路徑、首部、和主體來處理請求，然後通過對請求資源的訪問結果，來構建響應，回送給客戶端。

傳輸層-TCP

HTTP連線是建立在TCP連線的基礎之上的，TCP提供可靠的資料連線。當要傳輸一個HTTP報文時，報文資料會以流的形式通過一條已經開啟的TCP連線按順序傳輸，TCP會將收到的資料分成小塊，每塊是一個TCP分組。

由於資料是分成小塊傳送的，所以完整可靠的資料傳輸主要體現在：分組是否完整、分組順序是否正常、分組是否損壞、分組資料是否重複。這些可以通過TCP的檢驗和、序列號、確認應答、重發控制、連線管理和視窗機制來控制。

TCP是傳輸控制協議，傳輸控制主要依賴首部包含的6個標誌，它們控制報文的傳輸狀態，以及傳送端和接收端應對資料採取的動作。當它們的值為1時，標誌對應的各自功能才允許被執行，比如當URG為1時，報文首部的緊急指標部分才有效。

URG 緊急指標
ACK 確認序號有效
PSH 接收方應該儘快將這個報文段交給應用層。
RST 重建連線
SYN 同步序號用來發起一個連線
FIN 發端完成傳送任務

源埠和目的埠：標識傳送方和接收方的埠號，一個TCP連線通過4個值確認：源IP、源埠、目的IP、目的埠，其中源IP和目的IP包含在IP分組內。

首部長度：表示TCP首部的位元組長度，也能標記出從多少個位元組開始，才是需要傳輸的資料。

TCP段序號：本段報文傳送的資料第一個位元組的序號，每段報文中的資料的每個位元組都有序號，第一個位元組的序號從0開始，依次加1，加到2的32次方減1後再次從0開始。

TCP段確認序號：當首部標誌ACK為1時，確認序號有效。TCP段被接收端接收後，會回送給傳送端一個確認號，為上次接受的最後一個位元組序號加1。

檢驗和：由傳送端計算，接收端驗證，如果接收方檢測到檢驗和不正確，表明該TCP段可能有損壞，會被丟棄，同時接收端向回送一個重複的確認號（與最近的一次正確的報文傳輸的確認號重複），表明接收到的TCP段是錯誤的，並告知自己希望收到的序號。這時傳送端需要立即重傳出錯的TCP段。

緊急指標：當首部標誌URG為1時，緊急指標有效，表示傳送端向接收端要傳送緊急資料。緊急指標是一個正偏移量，它和TCP段序號相加，計算出緊急資料的最後一個位元組的序號。比如接收方接收到資料，從序號為1000的位元組開始讀取，緊急指標為1000，那麼緊急資料就是序號從1000到2000之間的位元組。這些資料由接收方決定如何處理。

視窗尺寸：決定了TCP一次成塊資料流的吞吐量。需要注意的是，它表示的是傳送一方的允許對方傳送的資料量，比如傳送方首部中的視窗大小為1000，就表示傳送方最多可以接受對方發來的1000個位元組的資料量。這與傳送方的資料快取空間有關，會影響TCP的效能。

首部標誌PSH：如果需要告訴接收方將資料立即全部提交給接收程序，傳送方需要將PSH置為1，這裡的資料是和PSH一起傳送的資料以及之前接收到的全部資料。如果接收方收到了PSH為1的標誌，需要立即將資料提交給接收程序，不用再等待有沒有其他資料進來。

復位標誌RST：當RST為1時，表示連接出現了異常情況，接收方將終止連線，通知應用層重新建立連線。

同步序號SYN：用來建立連線，涉及到TCP的三次握手。

開始建立連線時，客戶端向伺服器傳送一個TCP分組，分組首部的SYN為1，並攜帶一個初始序號，表明這是一個連線請求。
如果伺服器接受了連線，會向客戶端傳送一個TCP分組，分組中會包含SYN和ACK，都為1，同時包含一個確認序號，值為來自客戶端的初始序號 + 1，表示連線已經被接受。
客戶端收到上一步發來的分組後，會再向伺服器傳送一段確認報文分組，ACK為1，會再次攜帶確認序號，值是第二步來自客戶端的確認序號 +1。服務端收到確認資訊後，進入已經連線的狀態。
在第三步的確認分組中，是可以攜帶要傳送的資料的。

連線終止標誌FIN：用來關閉連線，當一端完成資料傳送任務後會傳送一個FIN標誌來終止連線，但因為TCP在兩個方向（C-S,S-C）上會有資料傳遞，每個方向有各自的傳送FIN & 確認關閉流程，所以會有四次互動，也稱為四次揮手。

如果客戶端應用層的資料傳送完畢，會導致客戶端的TCP報文傳送一個FIN，告知伺服器準備關閉資料傳送。
伺服器接收到這個標誌後，它發回一個ACK，確認序號為收到的序號加1，同時TCP還要嚮應用程式發一個檔案結束符。
此時伺服器關閉這個方向的連線，導致它的TCP也會發送一個FIN。
客戶端接收到之後發回一個確認ACK，序號為收到的序號 + 1，連線完全關閉。

TCP段序號與確認序號保證了資料的順序，檢驗和確保資料的完整性，緊急指標保證緊急資料可被及時處理。另外，TCP還有一些超時重傳、擁塞避免、慢啟動的機制，都可以保證分組資料按照順序完整的傳到目標端。

網路層-IP

如果說TCP分組是包裝貨物的集裝箱，那麼IP就是運送集裝箱的卡車。IP協議提供了兩個節點之間的連線，保證將TCP資料儘可能快地從源端送到終端，但卻不能保證傳輸的可靠性。

IP層會將上層傳過來的TCP分組封裝，帶上自己的首部，再進行選路、是否分片以及重組的工作，最終到達目的地，這個過程中，IP首部起了重要的作用，下面讓我們看一下首部的結構。

版本：表示當前IP協議的版本，目前版本號是4，還有一種是6，也就是IPV4和IPV6，如果傳送和接收這兩端的版本不一致，那麼當前IP資料報會被丟棄。

首部長度：整個首部的長度，最長為60位元組。

服務型別（TOS）：用來區分服務的型別，但其實IP層在工作的時候一直沒有實際使用過，現有的TOS只有4bit的子欄位，和1bit的未用位。未用位必須置為0。TOS的4個bit中只能將一個置成1，用來表示當前服務型別。4bit對應的4個服務型別分別為：最小時延、最大吞吐量、最高可靠性和最小費用。

總長度：表示當前的資料報報文的總長度，單位為位元組，可以結合首部長度計算出報文內資料的大小以及起始位置。

下面這三個首部欄位涉及到IP資料報的分片與重組過程，由於網路層一般會限制每個資料幀的最大長度，IP層傳送資料報會在選路的同時查詢當前裝置網路層的每個資料幀的最大傳輸長度，一旦超出，資料報就會被進行分片，到達目的地之後再進行重組，此時就會用以下三個欄位作為重組依據。需要注意的是：因為存在選路的過程，資料報經過的每層路由裝置對於資料幀的最大傳輸長度都不同，所以分片可能發生在任意一次選路的過程中。

分組標識：這個標識相當於ID，每成功傳送一個分片，IP層就會把這個分組ID加1。

標誌：共佔用三位，分別是R、D、M，R目前還沒有被使用，有用的是D、和M。這個欄位表示了資料報的分片行為。D如果為1的話，表示資料無需分片，一次傳輸完；M如果為1，表示資料是分片的，後邊還有資料，當它為0時，就表示當前資料報是最後一個分片，或者只有這一個分片。

片偏移：標識了當前分片距離原始資料報開始處的位置，分片之後，每一片的總長度會改成這一片的長度值，而不是整個資料報的長度。

生存時間：（TTL）可以決定資料報是否被丟棄。因為IP傳送資料是逐跳的，資料有可能在被設定了路由功能的不同的IP層之間轉發，所以生存時間表示了資料報最多個可以經過多少個處理過它的路由，每經過一層路由，值減去1，當值為0時資料報就被丟棄，並且傳送一個帶有錯誤訊息的報文（ICMP，IP層的組成部分，被用來傳遞一些錯誤資訊）給源端。生存時間可以有效解決資料報在一個路由環路中一直轉發的問題。

首部檢驗和：校驗資料報的完整性，傳送端對首部進行求和，將結果存在檢驗和中，接收端再計算一遍，如果計算結果與存在檢驗和中的結果一致，則說明傳輸過程是OK的，否則這個資料報就會被丟棄。
上層協議：決定了接收端在分用的時候將資料交給哪個上層協議去處理，例如TCP或者UDP。

源IP：記錄了傳送端的IP，在回送錯誤訊息時用到。

目的IP：表示目的IP，每一次選路都要以它來做決策。

路由選擇

因為IP首部只包含了目的IP地址，並不體現完整的路徑，當向外傳送資料時，IP層會根據目的IP在本機路由表中的查詢結果來做出選路決策，資料報會逐跳地被運送到目的地，這裡的每一跳，就是一次路由選擇。

IP層既可配置成路由器，也可以配置成主機。當配置成路由功能時，可以對資料報進行轉發，配置成主機時，如果目的IP不是本機IP，資料報會被丟棄。

具有路由功能的IP層在當目標IP不是本機地址的時候是根據什麼判斷轉發到哪一站呢？要理解這個問題，需要先明白路由表的結構，以下是IP層維護的路由表，（windows系統可以在控制檯輸入netstat -r來檢視路由表）


| Destination | Gateway | Flags| Refcnt| Use | Interface| | ------------------ | --------------- | -----|------ |---- | ---------| | 140.252.13.65

Destination（目的IP）：表示IP資料報最終要到達或者經過的網路地址或者主機地址。
Gateway（下一跳地址）：當前維護路由表裝置的相鄰路由器的地址
Flags（標誌）：表示當前這一條路由記錄的屬性，具體用五個不同的標誌來表示：
- U：該路由可以使用
- G：如果有這個標誌，表示是下一跳是一個閘道器，如果沒有，表示下一跳是和當前裝置在一個網段，也就是可以直接把資料報發過去
- H: 下一跳是一個主機還是一個網路，有這個標誌，表示主機，沒有，則表示下一跳的路由是一個網路
- D：該路由是由重定向報文建立的
- M：該路由已被重定向報文修改
- Interface：當前路由項的物理埠

每收到一個數據報時候，IP層就會根據目的IP在路由表裡查詢，根據查詢狀態會導向三種結果：

找到了與目的IP完全匹配的路由項，將報文發給該路由項的下一站路由（Gateway）或者網路介面（Interface）
找到了與目的IP的網路號匹配的路由項，將報文發給該路由項的下一站路由（Gateway）或者網路介面（Interface）
前兩者都沒有找到，就看路由表裡有沒有預設路由項（default），有的話發給它指定的下一站路由（Gateway）

要是上邊三個都沒有結果，那麼資料報就不能被髮送。IP資料報就是這樣一跳一跳地被送往目的主機的，但資料報有固有的長度，一旦超出了目的主機的MTU，就會被分片。

資料報分片的概念

TCP在進行握手的時候，會根據目的端IP層的最大傳輸單元（MTU）來決定TCP資料每次能傳輸的最大資料量（MSS），之後TCP會對資料依照MSS來進行分組，每個分組會被包裝進一個IP資料報內。當IP資料報經過選路過程中的任意一層路由時，有可能被MTU限制住從而被分片，這時IP首部的3bit標誌中的M標誌被置為1，表示需要分片。每個分片的首部基本一樣，只是片偏移有所不同。依據片偏移，這些分片在目的端被重組成一個完整的IP資料報（一個TCP分組）。IP傳輸是無序的，所以得到的資料報也是無序的，但如果資料完整，TCP會根據首部中的欄位對其進行排序。一旦IP分片丟失，IP層無法組成完整的資料報，就會告訴TCP層，TCP進行重傳。

當IP層將資料封裝好之後，只有目標主機的IP地址。光有IP地址並不能直接把資料報傳送過去，因為每一臺硬體裝置都有自己的MAC地址，是一個48bit的值。現在知道目標IP的地址，需要找到這個IP對應的MAC地址。這個過程要通過查詢路由表，再結合鏈路層的ARP協議，最終獲得目標IP對應的MAC地址。

地址解析協議：ARP

IP只能讓資料在邏輯端點之間流動，但是IP之下還有網路介面層，這一層也有自己的地址（MAC地址：用於在網路中唯一標識一個網絡卡），從IP地址到MAC地址需要一個轉換的過程，ARP就是提供這一服務的。

ARP協議實現了從IP地址到MAC地址的對映。一開始，起點並不知道目標的MAC地址，只有目標IP，要獲取這個地址就涉及到了ARP的請求和應答。同樣，ARP也有自己的分組，先看一下分組格式。

ARP分組格式

乙太網目的地址：目的端的MAC地址，當ARP快取表中沒有的時候，這裡為廣播地址。

乙太網源地址：傳送端的MAC地址。

幀型別：不同的幀型別有不同的格式和MTU值，不同的型別有不同的編號，這裡ARP對應的編號是0x0806。

硬體型別：指鏈路層網路型別，1為乙太網。

協議型別：指的是要轉換的地址型別，0x0800為IP地址。比如將乙太網地址轉換為IP地址。

op（操作型別）：有四種，分別是ARP請求（1），ARP應答（2），RARP請求（3），RARP應答（4）。

源MAC地址：表示傳送端MAC地址。

源IP地址：表示傳送端IP地址。

目的乙太網地址：表示目標裝置的MAC實體地址。

目的IP地址：表示目標裝置的IP地址。

當兩臺裝置傳送報文之前，源端的鏈路層會用ARP協議去詢問目的端的MAC地址，ARP會將一個請求廣播出去，乙太網上的每一個主機都會收到這份廣播，廣播的目的是詢問目標IP的MAC地址，內容主要是先介紹自己的IP和MAC地址，再詢問如果你有目標IP，請回復你的硬體地址。如果一個主機收到廣播後看到自己有這個IP，並且請求內有源IP和MAC地址，那麼就會向源主機迴應一個ARP應答。如果沒有目標IP，就會丟棄這個請求。可以看出請求是向外廣播的，而應答是單獨迴應的。

但不能每次通訊之前都去經歷一次請求-應答過程，在成功地接收到應答之後，IP和MAC地址的對映關係就會快取在ARP快取表中，有效期一般為20分鐘，便於網路層下次直接進行封裝，所以，完整的過程應該是：
IP層接收到TCP分組後，傳送或者封裝之前，通過查詢路由表：

當目標IP和自己在同一個網段時，先去ARP快取表裡找有沒有目標IP對應的MAC地址，有的話交給鏈路層進行封裝傳送出去。如果快取表內沒有，進行廣播，獲得MAC地址後快取起來，IP層再對TCP進行封裝，然後交給鏈路層再封裝傳送出去。
當目標IP和自己不在同一個網段，需要將報文發給預設的閘道器。如果ARP快取表中有閘道器IP對應的MAC地址，那麼交給鏈路層進行封裝傳送出去。如果沒有，進行廣播，獲得地址後快取起來，IP層再對TCP進行封裝，然後交給鏈路層再封裝傳送出去。

乙太網資料幀

上面所有東西都準備好了，封裝傳送的其實是乙太網資料幀。乙太網目的地址、乙太網源地址、幀型別這三者組成了幀首部。在首部之前還會插入前同步碼和幀開始定界符，告知接收端做一些準備工作。幀檢驗序列 FCS被新增進尾部，用來檢測幀是否出錯。

結構

前同步碼：協調終端接收介面卡的時鐘頻率，讓它與傳送端頻率相同。

幀開始定界符：幀開始的標誌，表示幀資訊要來了，準備接收。

目的地址：接收幀的網路介面卡的MAC地址，接收端收到幀時，會首先檢查目的地址與本機地址是否相符，不是的話就會丟棄。

源地址：傳送端裝置的MAC地址。

型別：決定接收到幀之後將資料交由那種協議處理。

資料：交給上層的資料。在本文的場景中指IP資料報。

幀檢驗序列：檢測這一幀是否出錯，傳送方計算幀的迴圈冗餘碼校驗（CRC）值，把這個值寫到幀裡。接收方計算機重新計算 CRC，與 FCS 欄位的值進行比較。如果兩個值不相同，則表示傳輸過程中發生了資料丟失或改變。這時，就需要重新傳輸這一幀。
傳輸和接收

接收到上層傳過來的資料報之後，根據MTU以及資料報大小來決定是否分割成小塊，也就是IP資料報被分片的過程。
把資料報（塊）封裝成一幀，傳給底層元件，底層元件將幀轉換為位元流，併發送出去。
乙太網上的裝置接收到幀，檢查幀裡邊的目標地址，如果與本機地址匹配，幀就會被處理，一層一層向上傳遞（分用過程）。

最後

一個網路請求從源端一層層封裝，再到終端一層層拆分，最後的所有過程基本梳理清楚，文章只是簡單梳理了一下大概流程，並且只以HTTP報文通過TCP協議經過IP傳送這一過程為例，實際還有很多概念沒有覆蓋，比如鏈路層的尾部封裝、 IP的動態選路、逆地址解析協議RARP、UDP協議相關的概念，建議大家可以閱讀下面列出的參考資料，相信會有更多收穫。