一次網路請求的完整生命週期

從客戶端發起請求的時候，網路資料流是從上而下的：

訪問**，瀏覽器位址列輸入**，這只是**網域名稱，瀏覽器並不知道要去**訪問資源，這個時候用到dns協議對網域名稱進行解析，在網域名稱註冊商那裡繫結了網域名稱對應的ip位址，ip位址就相當於網際網路世界的門牌號。

知道了目標ip後，瀏覽器打包本次請求，根據傳輸資料是否機密與否分為http和https請求，分別使用http協議和https協議。

dns、http、https所在的層是應用層，經過應用層封裝，瀏覽器將應用層的包交給下一層完成，這個過程通過socket程式設計來實現。

下一層是傳輸層，傳輸層有兩種協議，一種是無連線的udp協議，和面向連線的tcp協議，upd無需建立連線即可通訊，不可靠，可能丟包，tcp需要三次握手建立連線，能保證資料報到達目的地，但是效能不如upd。

對於http/https來說都是基於tcp的可靠連線，tcp協議有兩個埠，乙個瀏覽器監聽的埠（監聽伺服器），另乙個伺服器監聽的埠（http請求通常為80，https為443）。作業系統會根據埠將包**給不同的程序：

傳輸層封裝完成，瀏覽器將包交給網路層，網路層的協議是ip協議，在這一層，會給資料報加上ip頭，其中包含源ip位址（瀏覽器所在機器），目標ip（伺服器所在機器）等資訊：

作業系統知道目標機器ip位址後，就開始更具他尋找目標機器，如果是區域網內的機器，可以直接通過ip位址判斷出來，如果是區域網外的機器需要通過閘道器出外面的世界查詢。

作業系統啟動的時候，會通過dhcp協議配置ip位址，以及預設閘道器的ip位址：192.168.1.1.作業系統同會通過arp協議通過ip位址獲取閘道器的mac位址，並將本地閘道器和計算機的mac位址新增到mac頭中：

這樣作業系統就將ip包交給了下一層——鏈路層，再經由網絡卡傳送出去。（客戶端機器與閘道器之間還有物理層的線路連線。）

使用網絡卡（nic）的情況下，mac位址會燒到rom中，任何一張網絡卡的mac位址都是全球唯一的。

閘道器收到包以後，會根據自己的知識判斷下一步怎麼走，閘道器往往是乙個路由器，到某個目標ip怎麼走，有乙個路由表。網路請求包往往需要經過多個閘道器的跳轉，才能到達目標機器。

假設網路包經過多個閘道器之後，最終到達了目標服務所在的閘道器，通過arp協議，目標伺服器根據目標ip位址返回乙個mac位址，表示目標伺服器在此，然後網路包通過這個mac位址找到目標伺服器所在區域網的目標機器。

服務端接收請求的時候，與客戶端傳送請求相反，網路流是自下而上的。

目標伺服器發現與網路請求包的mac位址對上了，取下mac頭，將包傳遞給上一層網路層，發現ip也對上了，就取下ip頭，然後交給傳輸層，在傳輸層裡，對於收到的每乙個包，都要回覆包收到了，這個回覆不是此次請求的響應，僅是回覆包收到了。

如果過了一段時間還是沒有收到伺服器的回覆，客戶端會重新傳送這個包，直到回覆為止。這個重發也不是重新傳送上邊那個客戶端請求，而是傳輸層將同乙個請求反覆重試，對於使用者來說，只有一次請求。

回到目標伺服器，當網路包到達傳輸層後，tcp頭中有乙個伺服器監聽埠號，通過這個埠號可以識別將資料報交給哪個應用處理。

當後台處理完成後，就會返回乙個響應包，告知使用者請求成功，並返回響應內容。