面試官不講武德,一上來就問我Chrome底層原理和HTTP協(xié)議(萬字長文)
前言
有人說,如果你懂得瀏覽器的工作原理,你就能解決80%的前端難題。
是的,了解瀏覽器的工作原理,有助于你的工作;而了解TCP/IP 、HTTP等網(wǎng)絡(luò)協(xié)議,更是對你未來的職業(yè)發(fā)展大有裨益。
下面,我總結(jié)了4個面試??嫉年P(guān)于瀏覽器和網(wǎng)絡(luò)通信的問題,為你重新梳理瀏覽器,網(wǎng)絡(luò)通信、頁面渲染、JavaScript、瀏覽器安全等知識,從而讓你對整個前端后端體系有全新的認(rèn)識。
第一問:Chrome為什么打開一個頁面,會有4個進(jìn)程?
學(xué)習(xí)掌握:瀏覽器中的網(wǎng)絡(luò)流程,頁面渲染過程,JavaScript執(zhí)行流程,以及Web安全理論。下面展開問題了解多進(jìn)程架構(gòu):
多進(jìn)程架構(gòu)的學(xué)習(xí)
進(jìn)程和線程的概念混淆
從計算的角度來說,單線程就是一個接一個的計算,多線程就是同時處理多個計算。多線程是指程序中包含多個執(zhí)行流,即在一個程序中可以同時運行多個不同的線程來執(zhí)行不同的任務(wù),就是說允許單個程序創(chuàng)建多個并行執(zhí)行。
單線程是程序中的一個執(zhí)行流,每個線程都有自己的專有寄存器(棧指針、程序計數(shù)器等),但代碼區(qū)是共享的,即不同的線程可以執(zhí)行同樣的函數(shù)。
多線程也是程序,所以線程需要占用內(nèi)存,線程越多占用內(nèi)存也越多,多線程需要協(xié)調(diào)和管理,所以需要CPU時間跟蹤線程;線程之間對共享資源的訪問會相互影響,必須解決爭用共享資源的問題;線程太多會導(dǎo)致控制太復(fù)雜。
單線程在程序執(zhí)行時,所走的程序都是按照連續(xù)順序下來的,前面的必須處理好,才會執(zhí)行后面的。多線程運行就是一個進(jìn)程內(nèi)有多個相對獨立的并且實現(xiàn)特定的任務(wù)以競爭CPU的方式執(zhí)行,宏觀上是并發(fā),實際上是分時執(zhí)行,只是執(zhí)行的時間片較短。
每個正在運行的程序即是進(jìn)程,至少包含一個線程,這個線程叫主線程,它在程序啟動時被創(chuàng)建,用于執(zhí)行main函數(shù)。只有一個主線程的程序,稱為單線程程序。擁有多個線程的程序,稱為多線程程序。
進(jìn)程是當(dāng)一個程序開始運行時,它就是一個進(jìn)程,進(jìn)程包括運行中的程序和程序所使用到的內(nèi)存和系統(tǒng)資源(一個進(jìn)程又是由多個線程所組成的)
多線程的好處就是可以提高CPU的利用率,在多線程程序中,如果一個線程必須等待的時候,CPU可以運行其它的線程而不是等待,這樣可以大大地提高程序的效率。
所以,線程是不能單獨存在的,它是由進(jìn)程來啟動和管理的,一個進(jìn)程就是一個程序的運行實例。線程是依附于進(jìn)程的,而進(jìn)程中使用多線程并行處理能提升運算效率。線程之間共享進(jìn)程中的數(shù)據(jù)。當(dāng)一個進(jìn)程關(guān)閉后,操作系統(tǒng)會回收進(jìn)程所占用的內(nèi)存。
目前的多進(jìn)程架構(gòu)瀏覽器Chrome包括,1個瀏覽器主進(jìn)程,1個GPU進(jìn)程,1個網(wǎng)絡(luò)進(jìn)程,多個渲染進(jìn)程和多個插件進(jìn)程。
so,打開一個頁面,為啥有4個進(jìn)程?因為打開1個頁面:至少需要1個網(wǎng)絡(luò)進(jìn)程,1個瀏覽器進(jìn)程,1個GPU進(jìn)程以及1個渲染進(jìn)程。
雖然多進(jìn)程模型提升了瀏覽器的穩(wěn)定性、流暢性和安全性,但是帶來了更高的資源占用,更復(fù)雜的體系架構(gòu)。so,Chrome官方要構(gòu)建一個更內(nèi)聚,松耦合,易于維護(hù)和擴(kuò)展的系統(tǒng)。
第二問:TCP協(xié)議是如何保證頁面文件能被完整送達(dá)瀏覽器的?
對于在網(wǎng)絡(luò)中,我們知道一個文件通常會被拆分為很多數(shù)據(jù)包來進(jìn)行傳輸,而數(shù)據(jù)包在傳輸過程中又有很大的可能會丟失或者出錯,保證頁面文件完整地送達(dá)瀏覽器是有必要的。
下面就這三方面展開描述:
-
數(shù)據(jù)包如何送達(dá)到主機 -
主機如何將數(shù)據(jù)包轉(zhuǎn)交給應(yīng)用 -
數(shù)據(jù)是如何被完整地送達(dá)到應(yīng)用程序
數(shù)據(jù)包從主機A送到主機B,數(shù)據(jù)包上會附加上主機B的IP地址信息,主機A本身的IP地址,這些附加的信息會被裝進(jìn)一個IP頭的數(shù)據(jù)結(jié)構(gòu)里(包含IP版本,源IP地址,目標(biāo)IP地址,生存時間等)
這些一般我們都了解,下面主要說明TCP(Transmission Control Protocol),傳輸控制協(xié)議是一種面向連接的,可靠的,基于字節(jié)流的傳輸層通信協(xié)議,在簡化的計算機網(wǎng)絡(luò)OSI模型中,它完成第四層傳輸層所指定的功能。
用戶數(shù)據(jù)報協(xié)議(UDP)是同一層內(nèi)另一個重要的傳輸協(xié)議。
在因特網(wǎng)協(xié)議族中,TCP層是位于IP層之上的,TCP->IP,應(yīng)用層之下的中間層,應(yīng)用層->中間層。不同主機的應(yīng)用層之間經(jīng)常需要可靠的,像管道一樣的連接,但是IP層不提供這樣的流機制,而是提供不可靠的包進(jìn)行交換。
TCP為了保證不發(fā)生丟包的情況,就給每個包一個序號,同時序號也保證了傳送到接收端實體的包的按序接收。接收端實體對已成功收到的包發(fā)回一個相應(yīng)的確認(rèn)信息(ACK),如果發(fā)送端實體在合理的往返時延(RTT)內(nèi)未收到確認(rèn),那么對應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失并進(jìn)行重傳。
-
數(shù)據(jù)在TCP層稱為流 -
數(shù)據(jù)分組稱為分段
TCP協(xié)議的運作:連接創(chuàng)建,數(shù)據(jù)傳送,連接終止。
那你了解什么是TCP嗎?這一點大部分人應(yīng)該只會說它是一種協(xié)議。
TCP傳輸控制協(xié)議是TCP/IP,傳輸控制協(xié)議Internet協(xié)議中的主要協(xié)議之一,TCP/IP是一套通信協(xié)議,用于連接Internet以及大多數(shù)其他計算機網(wǎng)絡(luò)上的主機。
協(xié)議是一種共同商定的用于執(zhí)行某件事的格式。對于計算機,最常用于指一組規(guī)則,使計算機能夠相互連接并傳輸數(shù)據(jù),稱為通信協(xié)議。
TCP是一種面向連接的協(xié)議,它在主機之間建立并維護(hù)虛擬連接,直到交換了一條消息或要在其上運行的應(yīng)用程序交換的消息為止。數(shù)據(jù)包是TCP/IP網(wǎng)絡(luò)上數(shù)據(jù)傳輸?shù)淖罨締挝弧?/p>
TCP在傳輸層上運行,負(fù)責(zé)維護(hù)整個網(wǎng)絡(luò)上可靠的端到端通信,IP是網(wǎng)絡(luò)層協(xié)議,它是傳輸層正下方的層,在傳輸層運行的有:UDP(用戶數(shù)據(jù)報協(xié)議),RTP(實時傳輸協(xié)議),SCTP(流控制傳輸協(xié)議)。
連接創(chuàng)建
TCP用三次握手過程創(chuàng)建一個連接
三次握手協(xié)議的過程:
a.客戶端 向 服務(wù)器端 發(fā)送一個 SYN 包,請求一個主動打開。該包攜帶客戶端為這個連接請求設(shè)定的隨機數(shù)A作為消息列號。
b.服務(wù)器端接收到一個SYN包后,把該包放入SYN隊列中;回送一個SYN/ACK。ACK的確認(rèn)碼應(yīng)為A+1,SYN/ACK包本身攜帶一個隨機產(chǎn)生的序號B。
c.客戶端收到SYN/ACK包后,發(fā)送一個ACK的包,該包的序號被設(shè)定為A+1,而ACK的確認(rèn)碼為B+1。當(dāng)服務(wù)器端收到這個ACK包的時候,把請求幀從SYN隊列中移出,放置ACCEPT隊列中。
場景:當(dāng)服務(wù)器端接收到客戶端發(fā)送過來的SYN后, 回了SYN-ACK后,客戶端掉線了,服務(wù)器端沒有收到客戶端回來的ACK,那這個連接 就 處于 一個中間狀態(tài),沒成功也沒失敗。
但是,服務(wù)器端如果在一定時間內(nèi)沒有收到TCP會重新發(fā)SYN-ACK。
-
主機收到一個TCP包時,用兩端的IP地址與端口號來標(biāo)識這個TCP包屬于哪個session。 使用一張表來存儲所有的session,表中的每條稱作TCB(Transmit Control? Block )。 -
TCB結(jié)構(gòu)的定義包含:連接使用的源端口, 目的端口,目的ip, 序號, 應(yīng)答序號, 對方窗口大小, 已方窗口大小, tcp狀態(tài), tcp輸入/輸出隊列, 應(yīng)用層輸出隊列, tcp的重傳有關(guān)變量等。 -
服務(wù)器端的連接數(shù)量是無限的,只受內(nèi)存的限制。
數(shù)據(jù)傳送
在每個TCP報文段中都有一對序號和確認(rèn)號。
TCP報文發(fā)送者稱自己的字節(jié)流的編號為序號,稱接收到對方的字節(jié)流編號為確認(rèn)號。通過使用序號和確認(rèn)號,TCP層可以把收到的報文段中的字節(jié)按正確的順序交付給應(yīng)用層。
TCP協(xié)議使用序號標(biāo)識每端發(fā)出的字節(jié)順序,從另一端接收數(shù)據(jù)可以重建順序,無懼傳輸?shù)陌膩y序交付或丟包。
發(fā)送確認(rèn)包acks,攜帶接收對方發(fā)來的字節(jié)流的編號(確認(rèn)號),告訴對方已經(jīng)成功接收的數(shù)據(jù)流的字節(jié)位置。
數(shù)據(jù)包結(jié)構(gòu)
下面讓我們來看看數(shù)據(jù)包結(jié)構(gòu)圖:
包含:偏移字節(jié),來源連接端口,目的連接端口,序列號碼,確認(rèn)號碼,校驗和,緊急指針等。
-
來源連接端口,16位長,識別發(fā)送連接端口 -
目的連接端口,16位長,識別接收連接端口 -
序列號(seq,32位長) -
確認(rèn)號(ack,32位長),期望收到的數(shù)據(jù)的開始序列號,也即已經(jīng)收到的數(shù)據(jù)的字節(jié)長度加1 -
資料偏移(4位長),以4字節(jié)為單位計算出的數(shù)據(jù)段開始地址的偏移值。 -
保留,需置0 -
ACK—為1表示確認(rèn)號字段有效 -
SYN—為1表示這是連接請求或是連接接受請求,用于創(chuàng)建連接和使順序號同步 -
FIN—為1表示發(fā)送方?jīng)]有數(shù)據(jù)要傳輸了,要求釋放連接 -
RST—為1表示出現(xiàn)嚴(yán)重差錯??赡苄枰匦聞?chuàng)建TCP連接。還可以用于拒絕非法的報文段和拒絕連接請求 -
緊急指針(16位長)—本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號 -
窗口(WIN,16位長)—表示從確認(rèn)號開始,本報文的發(fā)送方可以接收的字節(jié)數(shù),即接收窗口大小。用于流量控制 -
校驗和(Checksum,16位長)—對整個的TCP報文段,包括TCP頭部和TCP數(shù)據(jù),以16位字進(jìn)行計算所得。這是一個強制性的字段
記住其中IP是把數(shù)據(jù)包送達(dá)目的主機的,數(shù)據(jù)包送達(dá)到主機。那么如何將數(shù)據(jù)包轉(zhuǎn)交給應(yīng)用的呢?
UDP是把數(shù)據(jù)包送達(dá)應(yīng)用程序的。
UDP是基于IP之上開發(fā)能和應(yīng)用打交道的協(xié)議,用戶數(shù)據(jù)包協(xié)議,是決定把數(shù)據(jù)包交給哪個程序的,IP只負(fù)責(zé)把數(shù)據(jù)包傳送到對方電腦。
看完位置,那么下面我們來簡單對比一下UDP和TCP:
UDP: 無連接;支持一對一,一對多,多對一和多對多交互通信;對應(yīng)用層交付的報文直接打包;盡最大努力交付,也就是不可靠;不使用流量控制和擁塞控制;首部開銷小,僅8字節(jié)。
TCP:面向連接;每一條TCP連接只能有兩個端點EP,只能是一對一通信;面向字節(jié)流;可靠傳輸,使用流量控制和擁塞控制;首部最小20字節(jié),最大60字節(jié)。
UDP最重要的一點就是端口號,因為UDP是通過端口號把數(shù)據(jù)包分發(fā)給正確的程序,UDP不能保證數(shù)據(jù)的可靠性,但傳輸速度快。
重要的講解是:數(shù)據(jù)是如何被完整地送達(dá)到應(yīng)用程序?
TCP就是把數(shù)據(jù)完整地送達(dá)應(yīng)用程序。
TCP是一種面向連接的,可靠的,基于字節(jié)流的傳輸層通信協(xié)議,提供重傳機制,引入了數(shù)據(jù)包排序機制(TCP頭,提供了排序的序列號,用來通過序號重排數(shù)據(jù)包)。
說到TCP連接,就要說說常面試的TCP/IP的三次握手,建立連接;四次揮手,斷開連接。
三次握手圖:
完成了三次TCP握手:
女朋友發(fā)給男朋友:“在嗎?”男朋友回復(fù)女朋友:“我在!”女朋友回復(fù)男朋友:“我知道了!”
此時男朋友知道了。
四次揮手圖:
完成四次揮手:
女朋友發(fā)給男朋友:“分手吧!”男朋友回復(fù)女朋友:“額?”男朋友回復(fù)女朋友:“認(rèn)真的嗎?”女朋友回復(fù)男朋友:“認(rèn)真的!”
此時女朋友刪除了男朋友的微信。
按照我描述的三次握手和四次揮手,我相信你懂了,哈哈!
第三問:HTTP請求流程,為什么很多站點第二次打開速度會很快呢?
說到HTTP協(xié)議,它是建立在TCP連接基礎(chǔ)之上的,超文本傳輸協(xié)議,HTTP是一種用于分布式,協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議,HTTP是萬維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)。
某人說:要想學(xué)好瀏覽器,就要深入了解HTTP。
瀏覽器是使用HTTP協(xié)議作為應(yīng)用層協(xié)議,用來封裝請求的文本信息,使用TCP/IP作傳輸層協(xié)議將它發(fā)到網(wǎng)絡(luò)上(http的內(nèi)容是通過TCP的傳輸數(shù)據(jù)階段來實現(xiàn)的)。
-
域名和IP地址-映射關(guān)系,域名映射為IP的系統(tǒng)叫作“域名系統(tǒng)”,簡 稱DNS。
域名系統(tǒng)DNS是互聯(lián)網(wǎng)的一項服務(wù)。它作為將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫,能夠使人更方便地訪問互聯(lián)網(wǎng)。
域名如:dadaqianduan.cn (URL地址)
IP地址為:xx.233.xxs.12 (訪問)
首先,第一步瀏覽器會請求DNS返回域名對應(yīng)的IP,瀏覽器還提供了DNS數(shù)據(jù)緩存服務(wù),如果某個域名已經(jīng)被解析過了,瀏覽器就會緩存解析的結(jié)構(gòu),下次查詢時直接使用,減少一次網(wǎng)絡(luò)請求。拿到IP后,就需要獲取端口號,如果url沒有明確指出端口號,HTTP協(xié)議默認(rèn)是80端口。
到這一步明白的清清楚楚了,IP和端口號。那么讓我說說HTTP協(xié)議的描述,這里補充是為了更好的了解:
HTTP是一個客戶端和服務(wù)器端之間請求和應(yīng)答的標(biāo)準(zhǔn),通常使用TCP協(xié)議,通過使用網(wǎng)頁瀏覽器,網(wǎng)絡(luò)爬蟲或者其它的工具,客戶端發(fā)起一個HTTP請求到服務(wù)器上指定端口,默認(rèn)端口為80。
應(yīng)答的服務(wù)器上存儲著一些資源,如HTML文件和圖像等,源服務(wù)器;(客戶端稱為用戶代理程序),用戶代理和源服務(wù)器中間可能存在多個"中間層",比如代理服務(wù)器,網(wǎng)關(guān),隧道等。
so,HTTP服務(wù)器在端口監(jiān)聽客戶端的請求,一旦收到請求,服務(wù)器會向客戶端返回一個狀態(tài),如:"HTTP/1.1 200 OK",以及返回的內(nèi)容,如請求的文件,錯誤消息,或者其它消息。
到這里我先回答一下:瀏覽器發(fā)起HTTP請求流程:1.構(gòu)建請求(構(gòu)建請求行信息);2.查找緩存(瀏覽器緩存是一種在本地保存資源副本,以供下次請求時直接使用的技術(shù));3.準(zhǔn)備IP地址和端口;4.等待TCP隊列;5.建立TCP連接;6.發(fā)送HTTP請求。
然后服務(wù)器處理請求,服務(wù)器返回請求,斷開連接。
其實端口和IP地址準(zhǔn)備好后,不一定直接建立TCP連接的,因為在Chrome中有個機制,就是同一個域名同時最多只能建立6個TCP連接,如果在同一個域名下同時有10個請求發(fā)生,那么其中就有4個請求進(jìn)入排隊等待狀態(tài)。
如果請求數(shù)量少于6個,就直接進(jìn)入建立TCP連接。
發(fā)送HTTP請求
上面都講好了初步,那么瀏覽器是如何發(fā)送請求信息給服務(wù)器的呢?
來一張post請求抓包圖:
來張瀏覽器發(fā)送請求到服務(wù)器端接收返回的過程:
描述:用戶在瀏覽器輸入請求的url地址,瀏覽器內(nèi)部的核心代碼會將這個url進(jìn)行拆分解析,最終將domain發(fā)送到DNS服務(wù)器上,DNS服務(wù)器會根據(jù)domain去查詢相關(guān)的對應(yīng)的ip地址,從而將IP地址返回給瀏覽器。
瀏覽器有了ip地址后就會知道這個請求是發(fā)送到哪里的。經(jīng)過(局域網(wǎng),交換機,路由器,主干網(wǎng)咯)到達(dá)服務(wù)器。
對于經(jīng)常了解HTTP的朋友應(yīng)該了解上述表達(dá),那接下來看看HTTP請求數(shù)據(jù)格式(可看上圖->來一張post請求抓包圖):
HTTP請求數(shù)據(jù)格式:
瀏覽器首先向服務(wù)器發(fā)送請求行(請求方法;請求URI;HTTP協(xié)議版本)-來告訴服務(wù)器瀏覽器需要什么資源,常用請求方法為GET,請求頭(用來告訴一些瀏覽器的基礎(chǔ)信息-瀏覽器所使用的操作系統(tǒng)、瀏覽器內(nèi)核等信息,以及當(dāng)前請求的域名信息、瀏覽器端的Cookie信息等),請求體(如常用的POST,用于發(fā)送一些數(shù)據(jù)給服務(wù)器,準(zhǔn)備的數(shù)據(jù)是通過請求體來發(fā)送的)。
服務(wù)器處理HTTP請求流程:
-
返回請求; -
斷開連接; -
重定向。
查看返回請求數(shù)據(jù),-i,獲取返回響應(yīng)行(包含協(xié)議版本和狀態(tài)碼),響應(yīng)頭,響應(yīng)體數(shù)據(jù)。
一般情況下,服務(wù)器向客戶端返回了請求數(shù)據(jù),就要關(guān)閉TCP連接。但其頭信息中加入了該字段:Connection: Keep-Alive,讓TCP連接仍然保持連接,可以繼續(xù)同一個TCP連接發(fā)送請求,可以省下次請求時需要建立連接的時間。
其實一般返回請求,斷開連接就沒了,但有一種就是你在瀏覽器中打開的url,發(fā)現(xiàn)最終的頁面地址不一樣,那是因為有一個重定向操作。
如圖:-I表示只需要獲取響應(yīng)頭和響應(yīng)行數(shù)據(jù)
-
location字段時重定向的地址;
狀態(tài)碼301和302的區(qū)別
301 Moved Permanently 被請求的資源已永久移動到新位置,并且將來任何對此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個URI之一。如果可能,擁有鏈接編輯功能的客戶端應(yīng)當(dāng)自動把請求的地址修改為從服務(wù)器反饋回來的地址。除非額外指定,否則這個響應(yīng)也是可緩存的。
302 Found 請求的資源現(xiàn)在臨時從不同的URI響應(yīng)請求。由于這樣的重定向是臨時的,客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下,這個響應(yīng)才是可緩存的。
字面上的區(qū)別:301是永久重定向,而302是臨時重定向
302重定向是暫時的重定向,搜索引擎會抓取新的內(nèi)容而保留舊的地址,因為服務(wù)器返回302,所以搜索搜索引擎認(rèn)為新的網(wǎng)址是暫時的。
301重定向是永久的重定向,搜索引擎在抓取新的內(nèi)容的同時也將舊的網(wǎng)址替換為了重定向之后的網(wǎng)址。
接下來,讓我們梳理一下HTTP版本號,這一點,我相信在學(xué)習(xí)的過程中,大家也是想知道的。
HTTP/0.9:
已過時。僅支持請求方式GET,并且僅能請求訪問HTML格式的資源,沒有在通訊中指定版本號,且不支持請求頭。
HTTP/1.0:
這是第一個在通訊中指定版本號的HTTP協(xié)議版本,增加了請求方式POST和HEAD;不再局限于0.9版本的HTML格式,根據(jù)Content-Type可以支持多種數(shù)據(jù)格式;包括狀態(tài)碼(status code)、多字符集支持、多部分發(fā)送(multi-part type)、權(quán)限(authorization)、緩存(cache)、內(nèi)容編碼(content encoding)等。
1.0版本:每次TCP連接只能發(fā)送一個請求,當(dāng)服務(wù)器響應(yīng)后就會關(guān)閉這次連接,下一個請求需要再次建立TCP連接.
HTTP/1.1:
默認(rèn)采用持續(xù)連接(TCP連接默認(rèn)不關(guān)閉,可以被多個請求復(fù)用,不用聲明Connection: keep-alive),能很好地配合代理服務(wù)器工作。
一個TCP連接可以允許多個HTTP請求
增加了管道機制,在同一個TCP連接里,允許多個請求同時發(fā)送,增加了并發(fā)性,進(jìn)一步改善了HTTP協(xié)議的效率
1.1版規(guī)定可以不使用Content-Length字段,而使用"分塊傳輸編碼"-只要請求或回應(yīng)的頭信息有Transfer-Encoding字段,就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成。Transfer-Encoding: chunked
新增了請求方式PUT、PATCH、OPTIONS、DELETE等
-
分塊傳輸編碼:是超文本傳輸協(xié)議中的一種數(shù)據(jù)傳輸機制,允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端應(yīng)用的數(shù)據(jù)可以分成多個部分,分塊傳輸編碼只在HTTP協(xié)議1.1版本(HTTP/1.1)中提供。
同一個TCP連接里,所有的數(shù)據(jù)通信是按次序進(jìn)行的?;貞?yīng)慢,會有許多請求排隊,造成"隊頭堵塞"。
HTTP/2:
于2015年5月作為互聯(lián)網(wǎng)標(biāo)準(zhǔn)正式發(fā)布。加了雙工模式,即不僅客戶端能夠同時發(fā)送多個請求,服務(wù)端也能同時處理多個請求,解決了隊頭堵塞的問題。
使用了多路復(fù)用的技術(shù),做到同一個連接并發(fā)處理多個請求,而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個數(shù)量級。
增加服務(wù)器推送的功能,不經(jīng)請求服務(wù)端主動向客戶端發(fā)送數(shù)據(jù)。
HTTP1.1相較于HTTP1.0協(xié)議區(qū)別:
-
緩存處理 -
帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用 -
錯誤通知的管理 -
消息在網(wǎng)絡(luò)中的發(fā)送 -
互聯(lián)網(wǎng)地址的維護(hù) -
安全性及完整性
最后的最后,說第二次站點的打開為啥速度快?
原因是第一次加載頁面過程中,緩存了一些耗時的數(shù)據(jù),主要緩存有 DNS緩存 和 頁面資源緩存 兩個方面。
-
瀏覽器緩存
當(dāng)?shù)谝淮伟l(fā)送請求,服務(wù)器返回HTTP響應(yīng)頭給瀏覽器時,瀏覽器會通過響應(yīng)頭中CacheControl字段來設(shè)置是否緩存資源。通常還需設(shè)置一個緩存時間,Cache-Control:Max-age=2000,在緩存沒有過期的情況下,在發(fā)送請求請求該資源,會直接返回緩存中的資源給瀏覽器。如果緩存過期,瀏覽器則會繼續(xù)發(fā)起網(wǎng)絡(luò)請求。
第四問:輸入URL到頁面展示發(fā)生了什么?
簡單地說一下就是:
-
瀏覽器主進(jìn)程提交url給網(wǎng)絡(luò)進(jìn)程 -
網(wǎng)絡(luò)進(jìn)程請求服務(wù)器,返回響應(yīng)頭行體,判斷是否需要重定向 -
網(wǎng)絡(luò)進(jìn)程將頁面類型的響應(yīng)資源提交給渲染進(jìn)程 -
渲染進(jìn)程渲染結(jié)束,加載完畢
分步驟簡單說一下就是:
-
首先是域名解析 -
建立TCP鏈接 -
建立Http請求 -
服務(wù)器處理Http請求 -
關(guān)閉TCP連接 -
瀏覽器解析資源 -
瀏覽器渲染頁面
在我的GitHub上也講過:從瀏覽器地址欄輸入url到顯示頁面的步驟https://github.com/webVueBlog/interview-answe/issues/27
本篇文章的最后,留給你一個面試題,就是上面說到的:“從輸入URL到頁面展示,這中間發(fā)送了什么?”這個問題,如果面試你,你又如何回答呢?
如果你作為面試官,又該考哪些點呢?
閱讀資料
瀏覽器工作原理與實踐
https://time.geekbang.org/column/intro/100033601
總結(jié)
以上就是今天要講的內(nèi)容,本文簡單介紹了Chrome流程,梳理了TCP與HTTP協(xié)議,了解三次握手,四次揮手流程,感謝閱讀,如果你覺得這篇文章對你有幫助的話,也歡迎把它分享給更多的朋友。
—————END—————
喜歡本文的朋友,歡迎關(guān)注公眾號?程序員小灰,收看更多精彩內(nèi)容
點個[在看],是對小灰最大的支持!
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!