前言

有人說，如果你懂得瀏覽器的工作原理，你就能解決80%的前端難題。

是的，了解瀏覽器的工作原理，有助于你的工作；而了解TCP/IP 、HTTP等網(wǎng)絡(luò)協(xié)議，更是對你未來的職業(yè)發(fā)展大有裨益。

下面，我總結(jié)了4個(gè)面試?？嫉年P(guān)于瀏覽器和網(wǎng)絡(luò)通信的問題，為你重新梳理瀏覽器，網(wǎng)絡(luò)通信、頁面渲染、JavaScript、瀏覽器安全等知識，從而讓你對整個(gè)前端后端體系有全新的認(rèn)識。

第一問：Chrome為什么打開一個(gè)頁面，會(huì)有4個(gè)進(jìn)程？

學(xué)習(xí)掌握：瀏覽器中的網(wǎng)絡(luò)流程，頁面渲染過程，JavaScript執(zhí)行流程，以及Web安全理論。下面展開問題了解多進(jìn)程架構(gòu)：

多進(jìn)程架構(gòu)的學(xué)習(xí)

進(jìn)程和線程的概念混淆

從計(jì)算的角度來說，單線程就是一個(gè)接一個(gè)的計(jì)算，多線程就是同時(shí)處理多個(gè)計(jì)算。多線程是指程序中包含多個(gè)執(zhí)行流，即在一個(gè)程序中可以同時(shí)運(yùn)行多個(gè)不同的線程來執(zhí)行不同的任務(wù)，就是說允許單個(gè)程序創(chuàng)建多個(gè)并行執(zhí)行。

單線程是程序中的一個(gè)執(zhí)行流，每個(gè)線程都有自己的專有寄存器(棧指針、程序計(jì)數(shù)器等)，但代碼區(qū)是共享的，即不同的線程可以執(zhí)行同樣的函數(shù)。

多線程也是程序，所以線程需要占用內(nèi)存，線程越多占用內(nèi)存也越多，多線程需要協(xié)調(diào)和管理，所以需要CPU時(shí)間跟蹤線程；線程之間對共享資源的訪問會(huì)相互影響，必須解決爭用共享資源的問題；線程太多會(huì)導(dǎo)致控制太復(fù)雜。

單線程在程序執(zhí)行時(shí)，所走的程序都是按照連續(xù)順序下來的，前面的必須處理好，才會(huì)執(zhí)行后面的。多線程運(yùn)行就是一個(gè)進(jìn)程內(nèi)有多個(gè)相對獨(dú)立的并且實(shí)現(xiàn)特定的任務(wù)以競爭CPU的方式執(zhí)行，宏觀上是并發(fā)，實(shí)際上是分時(shí)執(zhí)行，只是執(zhí)行的時(shí)間片較短。

每個(gè)正在運(yùn)行的程序即是進(jìn)程，至少包含一個(gè)線程，這個(gè)線程叫主線程，它在程序啟動(dòng)時(shí)被創(chuàng)建，用于執(zhí)行main函數(shù)。只有一個(gè)主線程的程序，稱為單線程程序。擁有多個(gè)線程的程序，稱為多線程程序。

進(jìn)程是當(dāng)一個(gè)程序開始運(yùn)行時(shí)，它就是一個(gè)進(jìn)程，進(jìn)程包括運(yùn)行中的程序和程序所使用到的內(nèi)存和系統(tǒng)資源（一個(gè)進(jìn)程又是由多個(gè)線程所組成的）

多線程的好處就是可以提高CPU的利用率，在多線程程序中，如果一個(gè)線程必須等待的時(shí)候，CPU可以運(yùn)行其它的線程而不是等待，這樣可以大大地提高程序的效率。

所以，線程是不能單獨(dú)存在的，它是由進(jìn)程來啟動(dòng)和管理的，一個(gè)進(jìn)程就是一個(gè)程序的運(yùn)行實(shí)例。線程是依附于進(jìn)程的，而進(jìn)程中使用多線程并行處理能提升運(yùn)算效率。線程之間共享進(jìn)程中的數(shù)據(jù)。當(dāng)一個(gè)進(jìn)程關(guān)閉后，操作系統(tǒng)會(huì)回收進(jìn)程所占用的內(nèi)存。

目前的多進(jìn)程架構(gòu)瀏覽器Chrome包括，1個(gè)瀏覽器主進(jìn)程，1個(gè)GPU進(jìn)程，1個(gè)網(wǎng)絡(luò)進(jìn)程，多個(gè)渲染進(jìn)程和多個(gè)插件進(jìn)程。

so，打開一個(gè)頁面，為啥有4個(gè)進(jìn)程？因?yàn)榇蜷_1個(gè)頁面：至少需要1個(gè)網(wǎng)絡(luò)進(jìn)程，1個(gè)瀏覽器進(jìn)程，1個(gè)GPU進(jìn)程以及1個(gè)渲染進(jìn)程。

雖然多進(jìn)程模型提升了瀏覽器的穩(wěn)定性、流暢性和安全性，但是帶來了更高的資源占用，更復(fù)雜的體系架構(gòu)。so，Chrome官方要構(gòu)建一個(gè)更內(nèi)聚，松耦合，易于維護(hù)和擴(kuò)展的系統(tǒng)。

第二問：TCP協(xié)議是如何保證頁面文件能被完整送達(dá)瀏覽器的？

對于在網(wǎng)絡(luò)中，我們知道一個(gè)文件通常會(huì)被拆分為很多數(shù)據(jù)包來進(jìn)行傳輸，而數(shù)據(jù)包在傳輸過程中又有很大的可能會(huì)丟失或者出錯(cuò)，保證頁面文件完整地送達(dá)瀏覽器是有必要的。

下面就這三方面展開描述：

1. 數(shù)據(jù)包如何送達(dá)到主機(jī)
2. 主機(jī)如何將數(shù)據(jù)包轉(zhuǎn)交給應(yīng)用
3. 數(shù)據(jù)是如何被完整地送達(dá)到應(yīng)用程序

數(shù)據(jù)包從主機(jī)A送到主機(jī)B，數(shù)據(jù)包上會(huì)附加上主機(jī)B的IP地址信息，主機(jī)A本身的IP地址，這些附加的信息會(huì)被裝進(jìn)一個(gè)IP頭的數(shù)據(jù)結(jié)構(gòu)里（包含IP版本，源IP地址，目標(biāo)IP地址，生存時(shí)間等）

這些一般我們都了解，下面主要說明TCP（Transmission Control Protocol），傳輸控制協(xié)議是一種面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議，在簡化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能。

用戶數(shù)據(jù)報(bào)協(xié)議（UDP）是同一層內(nèi)另一個(gè)重要的傳輸協(xié)議。

在因特網(wǎng)協(xié)議族中，TCP層是位于IP層之上的，TCP->IP，應(yīng)用層之下的中間層，應(yīng)用層->中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的，像管道一樣的連接，但是IP層不提供這樣的流機(jī)制，而是提供不可靠的包進(jìn)行交換。

TCP為了保證不發(fā)生丟包的情況，就給每個(gè)包一個(gè)序號，同時(shí)序號也保證了傳送到接收端實(shí)體的包的按序接收。接收端實(shí)體對已成功收到的包發(fā)回一個(gè)相應(yīng)的確認(rèn)信息（ACK），如果發(fā)送端實(shí)體在合理的往返時(shí)延（RTT）內(nèi)未收到確認(rèn)，那么對應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失并進(jìn)行重傳。

• 數(shù)據(jù)在TCP層稱為流
• 數(shù)據(jù)分組稱為分段

TCP協(xié)議的運(yùn)作：連接創(chuàng)建，數(shù)據(jù)傳送，連接終止。

那你了解什么是TCP嗎？這一點(diǎn)大部分人應(yīng)該只會(huì)說它是一種協(xié)議。

TCP傳輸控制協(xié)議是TCP/IP，傳輸控制協(xié)議Internet協(xié)議中的主要協(xié)議之一，TCP/IP是一套通信協(xié)議，用于連接Internet以及大多數(shù)其他計(jì)算機(jī)網(wǎng)絡(luò)上的主機(jī)。

協(xié)議是一種共同商定的用于執(zhí)行某件事的格式。對于計(jì)算機(jī)，最常用于指一組規(guī)則，使計(jì)算機(jī)能夠相互連接并傳輸數(shù)據(jù)，稱為通信協(xié)議。

TCP是一種面向連接的協(xié)議，它在主機(jī)之間建立并維護(hù)虛擬連接，直到交換了一條消息或要在其上運(yùn)行的應(yīng)用程序交換的消息為止。數(shù)據(jù)包是TCP/IP網(wǎng)絡(luò)上數(shù)據(jù)傳輸?shù)淖罨締挝弧?/p>

TCP在傳輸層上運(yùn)行，負(fù)責(zé)維護(hù)整個(gè)網(wǎng)絡(luò)上可靠的端到端通信，IP是網(wǎng)絡(luò)層協(xié)議，它是傳輸層正下方的層，在傳輸層運(yùn)行的有：UDP(用戶數(shù)據(jù)報(bào)協(xié)議)，RTP(實(shí)時(shí)傳輸協(xié)議)，SCTP(流控制傳輸協(xié)議)。

連接創(chuàng)建

TCP用三次握手過程創(chuàng)建一個(gè)連接

三次握手協(xié)議的過程：

a.客戶端 向 服務(wù)器端 發(fā)送一個(gè) SYN 包，請求一個(gè)主動(dòng)打開。該包攜帶客戶端為這個(gè)連接請求設(shè)定的隨機(jī)數(shù)A作為消息列號。

b.服務(wù)器端接收到一個(gè)SYN包后，把該包放入SYN隊(duì)列中；回送一個(gè)SYN/ACK。ACK的確認(rèn)碼應(yīng)為A+1，SYN/ACK包本身攜帶一個(gè)隨機(jī)產(chǎn)生的序號B。

c.客戶端收到SYN/ACK包后，發(fā)送一個(gè)ACK的包，該包的序號被設(shè)定為A+1，而ACK的確認(rèn)碼為B+1。當(dāng)服務(wù)器端收到這個(gè)ACK包的時(shí)候，把請求幀從SYN隊(duì)列中移出，放置ACCEPT隊(duì)列中。

場景：當(dāng)服務(wù)器端接收到客戶端發(fā)送過來的SYN后， 回了SYN-ACK后，客戶端掉線了，服務(wù)器端沒有收到客戶端回來的ACK，那這個(gè)連接 就 處于 一個(gè)中間狀態(tài)，沒成功也沒失敗。

但是，服務(wù)器端如果在一定時(shí)間內(nèi)沒有收到TCP會(huì)重新發(fā)SYN-ACK。

• 主機(jī)收到一個(gè)TCP包時(shí)，用兩端的IP地址與端口號來標(biāo)識這個(gè)TCP包屬于哪個(gè)session。
  使用一張表來存儲(chǔ)所有的session，表中的每條稱作TCB（Transmit Control? Block ）。
• TCB結(jié)構(gòu)的定義包含：連接使用的源端口， 目的端口，目的ip， 序號， 應(yīng)答序號， 對方窗口大小， 已方窗口大小， tcp狀態(tài)， tcp輸入/輸出隊(duì)列， 應(yīng)用層輸出隊(duì)列， tcp的重傳有關(guān)變量等。
• 服務(wù)器端的連接數(shù)量是無限的，只受內(nèi)存的限制。

數(shù)據(jù)傳送

在每個(gè)TCP報(bào)文段中都有一對序號和確認(rèn)號。

TCP報(bào)文發(fā)送者稱自己的字節(jié)流的編號為序號，稱接收到對方的字節(jié)流編號為確認(rèn)號。通過使用序號和確認(rèn)號，TCP層可以把收到的報(bào)文段中的字節(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)號碼，校驗(yàn)和，緊急指針等。

• 來源連接端口，16位長，識別發(fā)送連接端口
• 目的連接端口，16位長，識別接收連接端口
• 序列號（seq,32位長）
• 確認(rèn)號（ack,32位長），期望收到的數(shù)據(jù)的開始序列號，也即已經(jīng)收到的數(shù)據(jù)的字節(jié)長度加1
• 資料偏移（4位長），以4字節(jié)為單位計(jì)算出的數(shù)據(jù)段開始地址的偏移值。
• 保留，需置0
• ACK—為1表示確認(rèn)號字段有效
• SYN—為1表示這是連接請求或是連接接受請求，用于創(chuàng)建連接和使順序號同步
• FIN—為1表示發(fā)送方?jīng)]有數(shù)據(jù)要傳輸了，要求釋放連接
• RST—為1表示出現(xiàn)嚴(yán)重差錯(cuò)?？赡苄枰匦聞?chuàng)建TCP連接。還可以用于拒絕非法的報(bào)文段和拒絕連接請求
• 緊急指針（16位長）—本報(bào)文段中的緊急數(shù)據(jù)的最后一個(gè)字節(jié)的序號
• 窗口（WIN，16位長）—表示從確認(rèn)號開始，本報(bào)文的發(fā)送方可以接收的字節(jié)數(shù)，即接收窗口大小。用于流量控制
• 校驗(yàn)和（Checksum，16位長）—對整個(gè)的TCP報(bào)文段，包括TCP頭部和TCP數(shù)據(jù)，以16位字進(jìn)行計(jì)算所得。這是一個(gè)強(qiáng)制性的字段

記住其中IP是把數(shù)據(jù)包送達(dá)目的主機(jī)的，數(shù)據(jù)包送達(dá)到主機(jī)。那么如何將數(shù)據(jù)包轉(zhuǎn)交給應(yīng)用的呢？

UDP是把數(shù)據(jù)包送達(dá)應(yīng)用程序的。

UDP是基于IP之上開發(fā)能和應(yīng)用打交道的協(xié)議，用戶數(shù)據(jù)包協(xié)議，是決定把數(shù)據(jù)包交給哪個(gè)程序的，IP只負(fù)責(zé)把數(shù)據(jù)包傳送到對方電腦。

看完位置，那么下面我們來簡單對比一下UDP和TCP：

UDP: 無連接；支持一對一，一對多，多對一和多對多交互通信；對應(yīng)用層交付的報(bào)文直接打包；盡最大努力交付，也就是不可靠；不使用流量控制和擁塞控制；首部開銷小，僅8字節(jié)。

TCP：面向連接；每一條TCP連接只能有兩個(gè)端點(diǎn)EP，只能是一對一通信；面向字節(jié)流；可靠傳輸，使用流量控制和擁塞控制；首部最小20字節(jié)，最大60字節(jié)。

UDP最重要的一點(diǎn)就是端口號，因?yàn)閁DP是通過端口號把數(shù)據(jù)包分發(fā)給正確的程序，UDP不能保證數(shù)據(jù)的可靠性，但傳輸速度快。

重要的講解是：數(shù)據(jù)是如何被完整地送達(dá)到應(yīng)用程序？

TCP就是把數(shù)據(jù)完整地送達(dá)應(yīng)用程序。

TCP是一種面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議，提供重傳機(jī)制，引入了數(shù)據(jù)包排序機(jī)制（TCP頭，提供了排序的序列號，用來通過序號重排數(shù)據(jù)包）。

說到TCP連接，就要說說常面試的TCP/IP的三次握手，建立連接；四次揮手，斷開連接。

三次握手圖：

完成了三次TCP握手：

女朋友發(fā)給男朋友：“在嗎？”男朋友回復(fù)女朋友：“我在！”女朋友回復(fù)男朋友：“我知道了！”

此時(shí)男朋友知道了。

四次揮手圖：

完成四次揮手：

女朋友發(fā)給男朋友：“分手吧！”男朋友回復(fù)女朋友：“額？”男朋友回復(fù)女朋友：“認(rèn)真的嗎？”女朋友回復(fù)男朋友：“認(rèn)真的！”

此時(shí)女朋友刪除了男朋友的微信。

按照我描述的三次握手和四次揮手，我相信你懂了，哈哈！

第三問：HTTP請求流程，為什么很多站點(diǎn)第二次打開速度會(huì)很快呢？

說到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ù)階段來實(shí)現(xiàn)的)。

• 域名和IP地址-映射關(guān)系，域名映射為IP的系統(tǒng)叫作“域名系統(tǒng)”，簡 稱DNS。

域名系統(tǒng)DNS是互聯(lián)網(wǎng)的一項(xiàng)服務(wù)。它作為將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫，能夠使人更方便地訪問互聯(lián)網(wǎng)。

域名如：dadaqianduan.cn (URL地址)

IP地址為：xx.233.xxs.12 (訪問)

首先，第一步瀏覽器會(huì)請求DNS返回域名對應(yīng)的IP，瀏覽器還提供了DNS數(shù)據(jù)緩存服務(wù)，如果某個(gè)域名已經(jīng)被解析過了，瀏覽器就會(huì)緩存解析的結(jié)構(gòu)，下次查詢時(shí)直接使用，減少一次網(wǎng)絡(luò)請求。拿到IP后，就需要獲取端口號，如果url沒有明確指出端口號，HTTP協(xié)議默認(rèn)是80端口。

到這一步明白的清清楚楚了，IP和端口號。那么讓我說說HTTP協(xié)議的描述，這里補(bǔ)充是為了更好的了解：

HTTP是一個(gè)客戶端和服務(wù)器端之間請求和應(yīng)答的標(biāo)準(zhǔn)，通常使用TCP協(xié)議，通過使用網(wǎng)頁瀏覽器，網(wǎng)絡(luò)爬蟲或者其它的工具，客戶端發(fā)起一個(gè)HTTP請求到服務(wù)器上指定端口，默認(rèn)端口為80。

應(yīng)答的服務(wù)器上存儲(chǔ)著一些資源，如HTML文件和圖像等，源服務(wù)器；（客戶端稱為用戶代理程序），用戶代理和源服務(wù)器中間可能存在多個(gè)"中間層"，比如代理服務(wù)器，網(wǎng)關(guān)，隧道等。

so，HTTP服務(wù)器在端口監(jiān)聽客戶端的請求，一旦收到請求，服務(wù)器會(huì)向客戶端返回一個(gè)狀態(tài)，如："HTTP/1.1 200 OK",以及返回的內(nèi)容，如請求的文件，錯(cuò)誤消息，或者其它消息。

到這里我先回答一下：瀏覽器發(fā)起HTTP請求流程：1.構(gòu)建請求(構(gòu)建請求行信息)；2.查找緩存（瀏覽器緩存是一種在本地保存資源副本，以供下次請求時(shí)直接使用的技術(shù)）；3.準(zhǔn)備IP地址和端口；4.等待TCP隊(duì)列；5.建立TCP連接；6.發(fā)送HTTP請求。

然后服務(wù)器處理請求，服務(wù)器返回請求，斷開連接。

其實(shí)端口和IP地址準(zhǔn)備好后，不一定直接建立TCP連接的，因?yàn)樵贑hrome中有個(gè)機(jī)制，就是同一個(gè)域名同時(shí)最多只能建立6個(gè)TCP連接，如果在同一個(gè)域名下同時(shí)有10個(gè)請求發(fā)生，那么其中就有4個(gè)請求進(jìn)入排隊(duì)等待狀態(tài)。

如果請求數(shù)量少于6個(gè)，就直接進(jìn)入建立TCP連接。

發(fā)送HTTP請求

上面都講好了初步，那么瀏覽器是如何發(fā)送請求信息給服務(wù)器的呢？

來一張post請求抓包圖：

來張瀏覽器發(fā)送請求到服務(wù)器端接收返回的過程：

描述：用戶在瀏覽器輸入請求的url地址，瀏覽器內(nèi)部的核心代碼會(huì)將這個(gè)url進(jìn)行拆分解析，最終將domain發(fā)送到DNS服務(wù)器上，DNS服務(wù)器會(huì)根據(jù)domain去查詢相關(guān)的對應(yīng)的ip地址，從而將IP地址返回給瀏覽器。

瀏覽器有了ip地址后就會(huì)知道這個(gè)請求是發(fā)送到哪里的。經(jīng)過（局域網(wǎng)，交換機(jī)，路由器，主干網(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請求流程：

1. 返回請求；
2. 斷開連接；
3. 重定向。

查看返回請求數(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ù)同一個(gè)TCP連接發(fā)送請求，可以省下次請求時(shí)需要建立連接的時(shí)間。

其實(shí)一般返回請求，斷開連接就沒了，但有一種就是你在瀏覽器中打開的url，發(fā)現(xiàn)最終的頁面地址不一樣，那是因?yàn)橛幸粋€(gè)重定向操作。

如圖：-I表示只需要獲取響應(yīng)頭和響應(yīng)行數(shù)據(jù)

• location字段時(shí)重定向的地址；

狀態(tài)碼301和302的區(qū)別

301 Moved Permanently 被請求的資源已永久移動(dòng)到新位置，并且將來任何對此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個(gè)URI之一。如果可能，擁有鏈接編輯功能的客戶端應(yīng)當(dāng)自動(dòng)把請求的地址修改為從服務(wù)器反饋回來的地址。除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。

302 Found 請求的資源現(xiàn)在臨時(shí)從不同的URI響應(yīng)請求。由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存的。

字面上的區(qū)別：301是永久重定向，而302是臨時(shí)重定向

302重定向是暫時(shí)的重定向，搜索引擎會(huì)抓取新的內(nèi)容而保留舊的地址，因?yàn)榉?wù)器返回302，所以搜索搜索引擎認(rèn)為新的網(wǎng)址是暫時(shí)的。

301重定向是永久的重定向，搜索引擎在抓取新的內(nèi)容的同時(shí)也將舊的網(wǎng)址替換為了重定向之后的網(wǎng)址。

接下來，讓我們梳理一下HTTP版本號，這一點(diǎn)，我相信在學(xué)習(xí)的過程中，大家也是想知道的。

HTTP/0.9：

已過時(shí)。僅支持請求方式GET，并且僅能請求訪問HTML格式的資源，沒有在通訊中指定版本號，且不支持請求頭。

HTTP/1.0：

這是第一個(gè)在通訊中指定版本號的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ā)送一個(gè)請求，當(dāng)服務(wù)器響應(yīng)后就會(huì)關(guān)閉這次連接，下一個(gè)請求需要再次建立TCP連接.

HTTP/1.1：

默認(rèn)采用持續(xù)連接(TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請求復(fù)用，不用聲明Connection: keep-alive)，能很好地配合代理服務(wù)器工作。

一個(gè)TCP連接可以允許多個(gè)HTTP請求

增加了管道機(jī)制，在同一個(gè)TCP連接里，允許多個(gè)請求同時(shí)發(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ù)傳輸機(jī)制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端應(yīng)用的數(shù)據(jù)可以分成多個(gè)部分，分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供。

同一個(gè)TCP連接里，所有的數(shù)據(jù)通信是按次序進(jìn)行的?；貞?yīng)慢，會(huì)有許多請求排隊(duì)，造成"隊(duì)頭堵塞"。

HTTP/2：

于2015年5月作為互聯(lián)網(wǎng)標(biāo)準(zhǔn)正式發(fā)布。加了雙工模式，即不僅客戶端能夠同時(shí)發(fā)送多個(gè)請求，服務(wù)端也能同時(shí)處理多個(gè)請求，解決了隊(duì)頭堵塞的問題。

使用了多路復(fù)用的技術(shù)，做到同一個(gè)連接并發(fā)處理多個(gè)請求，而且并發(fā)請求的數(shù)量比HTTP1.1大了好幾個(gè)數(shù)量級。

增加服務(wù)器推送的功能，不經(jīng)請求服務(wù)端主動(dòng)向客戶端發(fā)送數(shù)據(jù)。

HTTP1.1相較于HTTP1.0協(xié)議區(qū)別：

1. 緩存處理
2. 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用
3. 錯(cuò)誤通知的管理
4. 消息在網(wǎng)絡(luò)中的發(fā)送
5. 互聯(lián)網(wǎng)地址的維護(hù)
6. 安全性及完整性

最后的最后，說第二次站點(diǎn)的打開為啥速度快？

原因是第一次加載頁面過程中，緩存了一些耗時(shí)的數(shù)據(jù)，主要緩存有 DNS緩存 和 頁面資源緩存 兩個(gè)方面。

• 瀏覽器緩存

當(dāng)?shù)谝淮伟l(fā)送請求，服務(wù)器返回HTTP響應(yīng)頭給瀏覽器時(shí)，瀏覽器會(huì)通過響應(yīng)頭中CacheControl字段來設(shè)置是否緩存資源。通常還需設(shè)置一個(gè)緩存時(shí)間，Cache-Control:Max-age=2000，在緩存沒有過期的情況下，在發(fā)送請求請求該資源，會(huì)直接返回緩存中的資源給瀏覽器。如果緩存過期，瀏覽器則會(huì)繼續(xù)發(fā)起網(wǎng)絡(luò)請求。

第四問：輸入U(xiǎn)RL到頁面展示發(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é)束，加載完畢

分步驟簡單說一下就是：

1. 首先是域名解析
2. 建立TCP鏈接
3. 建立Http請求
4. 服務(wù)器處理Http請求
5. 關(guān)閉TCP連接
6. 瀏覽器解析資源
7. 瀏覽器渲染頁面

在我的GitHub上也講過：從瀏覽器地址欄輸入url到顯示頁面的步驟https://github.com/webVueBlog/interview-answe/issues/27

本篇文章的最后，留給你一個(gè)面試題，就是上面說到的：“從輸入U(xiǎn)RL到頁面展示，這中間發(fā)送了什么？”這個(gè)問題，如果面試你，你又如何回答呢？

如果你作為面試官，又該考哪些點(diǎn)呢？

閱讀資料

瀏覽器工作原理與實(shí)踐

https://time.geekbang.org/column/intro/100033601

總結(jié)

以上就是今天要講的內(nèi)容，本文簡單介紹了Chrome流程，梳理了TCP與HTTP協(xié)議，了解三次握手，四次揮手流程，感謝閱讀，如果你覺得這篇文章對你有幫助的話，也歡迎把它分享給更多的朋友。

—————END—————

喜歡本文的朋友，歡迎關(guān)注公眾號?程序員小灰，收看更多精彩內(nèi)容

       

        

         

          

           

            

             

              
             
             

              點(diǎn)個(gè)[在看]，是對小灰最大的支持！