從輸入U(xiǎn)RL到頁面展現(xiàn)的過程
輸入U(xiǎn)RL后,會(huì)先進(jìn)行域名解析。優(yōu)先查找本地host文件有無對(duì)應(yīng)的IP地址,沒有的話去本地DNS服務(wù)器查找,還不行的話,本地DNS服務(wù)器會(huì)去找根DNS服務(wù)器要一個(gè)域服務(wù)器的地址進(jìn)行查詢,域服務(wù)器將要查詢的域名的解析服務(wù)器地址返回給本地DNS,本地DNS去這里查詢就OK了。
瀏覽器拿到服務(wù)器的IP地址后,會(huì)向它發(fā)送HTTP請(qǐng)求。HTTP請(qǐng)求經(jīng)由一層層的處理、封裝、發(fā)出之后,最終經(jīng)由網(wǎng)絡(luò)到達(dá)服務(wù)器,建立TCP/IP連接,服務(wù)器接收到請(qǐng)求并開始處理。
服務(wù)器構(gòu)建響應(yīng),再經(jīng)由一層層的處理、封裝、發(fā)出后,到達(dá)客戶端,瀏覽器處理請(qǐng)求。
瀏覽器開始渲染頁面,解析HTML,構(gòu)建render樹,根據(jù)render樹的節(jié)點(diǎn)和CSS的對(duì)應(yīng)關(guān)系,進(jìn)行布局,繪制頁面。
這4個(gè)步驟包含了一個(gè)HTTP請(qǐng)求的完整生命周期,文章著重介紹第2步和第3步,也就是請(qǐng)求是如何在兩個(gè)物理端點(diǎn)之間進(jìn)行通信的。數(shù)據(jù)的發(fā)出和接收必然會(huì)經(jīng)歷一些處理、解析的過程,這些過程在系統(tǒng)的不同層次進(jìn)行。
個(gè)HTTP請(qǐng)求從源端發(fā)出到在終端接收的處理過程都是要經(jīng)過以下四層。其中每一層都有各自的協(xié)議。

上圖中只舉例出了最常見的協(xié)議,實(shí)際上每一層都有細(xì)分的協(xié)議:
應(yīng)用層:應(yīng)用程序負(fù)責(zé)將數(shù)據(jù)以相應(yīng)規(guī)則(協(xié)議)進(jìn)行包裝,發(fā)給傳輸層
HTTP:超文本傳輸協(xié)議
FTP:文件傳輸協(xié)議
SMTP:簡單郵件傳送協(xié)議
SNMP:簡單網(wǎng)絡(luò)管理協(xié)議
傳輸層:負(fù)責(zé)將應(yīng)用層傳過來的數(shù)據(jù)進(jìn)行分組,為確保終端接收數(shù)據(jù)的順序和完整性,會(huì)對(duì)每個(gè)分組進(jìn)行標(biāo)記,交給網(wǎng)絡(luò)層
TCP:傳輸控制協(xié)議
UDP:用戶數(shù)據(jù)協(xié)議
網(wǎng)絡(luò)層:負(fù)責(zé)將傳輸層發(fā)來的數(shù)據(jù)分組發(fā)送到目標(biāo)終端
ICMP:Internet互聯(lián)網(wǎng)控制報(bào)文協(xié)議
IGMP:Internet組管理協(xié)議
IP:網(wǎng)際協(xié)議
鏈路層:為網(wǎng)絡(luò)層發(fā)送和接收數(shù)據(jù)單元
ARP:地址解析協(xié)議
RARP:逆地址解析協(xié)議
封裝
源端發(fā)送HTTP報(bào)文時(shí),報(bào)文會(huì)以數(shù)據(jù)流的形式通過一條已經(jīng)打開的TCP連接按序傳輸,TCP收到數(shù)據(jù)流后會(huì)將其分割成小的數(shù)據(jù)塊,每個(gè)小塊被添加的TCP首部與數(shù)據(jù)塊共同組成了TCP分組,分組經(jīng)由網(wǎng)絡(luò)層發(fā)送,網(wǎng)絡(luò)層遵循IP協(xié)議,當(dāng)收到分組發(fā)送請(qǐng)求后,會(huì)將分組其放入IP數(shù)據(jù)報(bào),填充報(bào)頭,將數(shù)據(jù)報(bào)發(fā)經(jīng)由鏈路層發(fā)送出去。

分用
終端接收到一個(gè)以太網(wǎng)數(shù)據(jù)幀時(shí),數(shù)據(jù)自底層向上流動(dòng),去掉發(fā)送時(shí)各層協(xié)議加上的報(bào)文首部,每層協(xié)議都要檢查報(bào)文首部的協(xié)議標(biāo)識(shí),從而確定上層協(xié)議,保證數(shù)據(jù)被正確處理,這個(gè)過程叫分用。
HTTP
HTTP屬于應(yīng)用層,用戶觸發(fā)交互所產(chǎn)生的行為數(shù)據(jù)和服務(wù)端對(duì)此的響應(yīng)都由它封裝成HTTP報(bào)文,再交由下層協(xié)議進(jìn)行處理。報(bào)文的作用是客戶端與服務(wù)端溝通的載體,雙方都要遵循統(tǒng)一規(guī)則對(duì)信息進(jìn)行處理,這一規(guī)則稱為HTTP。
客戶端與服務(wù)端的交互往往非常復(fù)雜,為了使雙方都能高效、明確、安全地通信(例如傳遞意圖與狀態(tài)、承載數(shù)據(jù)、攜帶認(rèn)證信息、控制連接行為與緩存),需要依賴報(bào)文中的結(jié)構(gòu)來實(shí)現(xiàn),下面先從結(jié)構(gòu)開始看。
地址解析協(xié)議:ARP
IP只能讓數(shù)據(jù)在邏輯端點(diǎn)之間流動(dòng),但是IP之下還有網(wǎng)絡(luò)接口層,這一層也有自己的地址(MAC地址:用于在網(wǎng)絡(luò)中唯一標(biāo)識(shí)一個(gè)網(wǎng)卡),從IP地址到MAC地址需要一個(gè)轉(zhuǎn)換的過程,ARP就是提供這一服務(wù)的。
ARP協(xié)議實(shí)現(xiàn)了從IP地址到MAC地址的映射。一開始,起點(diǎn)并不知道目標(biāo)的MAC地址,只有目標(biāo)IP,要獲取這個(gè)地址就涉及到了ARP的請(qǐng)求和應(yīng)答。同樣,ARP也有自己的分組,先看一下分組格式。
以太網(wǎng)數(shù)據(jù)幀
上面所有東西都準(zhǔn)備好了,封裝發(fā)送的其實(shí)是以太網(wǎng)數(shù)據(jù)幀。以太網(wǎng)目的地址、以太網(wǎng)源地址、幀類型這三者組成了幀首部。在首部之前還會(huì)插入前同步碼和幀開始定界符,告知接收端做一些準(zhǔn)備工作。幀檢驗(yàn)序列 FCS被添加進(jìn)尾部,用來檢測(cè)幀是否出錯(cuò)。.
傳輸和接收
接收到上層傳過來的數(shù)據(jù)報(bào)之后,根據(jù)MTU以及數(shù)據(jù)報(bào)大小來決定是否分割成小塊,也就是IP數(shù)據(jù)報(bào)被分片的過程。
把數(shù)據(jù)報(bào)(塊)封裝成一幀,傳給底層組件,底層組件將幀轉(zhuǎn)換為比特流,并發(fā)送出去。
以太網(wǎng)上的設(shè)備接收到幀,檢查幀里邊的目標(biāo)地址,如果與本機(jī)地址匹配,幀就會(huì)被處理,一層一層向上傳遞(分用過程)。
一個(gè)網(wǎng)絡(luò)請(qǐng)求從源端一層層封裝,再到終端一層層拆分,最后的所有過程基本梳理清楚,文章只是簡單梳理了一下大概流程,并且只以HTTP報(bào)文通過TCP協(xié)議經(jīng)過IP傳送這一過程為例,實(shí)際還有很多概念沒有覆蓋,比如鏈路層的尾部封裝、IP的動(dòng)態(tài)選路、逆地址解析協(xié)議RARP、UDP協(xié)議相關(guān)的概念,建議大家可以閱讀下面列出的參考資料,相信會(huì)有更多收獲。lw
電子發(fā)燒友App





















































評(píng)論