摘要：服務器處理請求返回報文響應報文由相響應行響應頭響應主體三個部分組成，如下圖響應行包含協(xié)議版本狀態(tài)碼狀態(tài)碼描述協(xié)議版本狀態(tài)碼請求成功以創(chuàng)建，成功請求并創(chuàng)建了新的資源非授權信息。

DNS解析

TCP連接

發(fā)送http請求

服務器處理請求

瀏覽器解析渲染頁面

連接結束

什么是DNS?

DNS是一種組織成域層次結構的計算機和網絡服務命名系統(tǒng)，他用于TCP/IP網絡，它所提供的服務是用來將主機名和域名轉換成IP地址的工作。DNS就是這樣的一位"翻譯官"，它的基本工作原理可以用下圖來表示。

DNS解析過程

檢查瀏覽器緩存中是否緩存過該域名對應的ip地址

如果在瀏覽器緩存中沒有找到ip，那么將繼續(xù)查找本機系統(tǒng)是否緩存過ip

向本地域名解析服務發(fā)起域名解析的請求

向根域名解析服務器發(fā)起域名解析請求

根域名服務器返回gTLD(通用頂級域)域名解析服務器地址

向gTLD服務器發(fā)起解析請求

gTLD服務器接收請求病返回Name Server服務器

Name Server 服務器返回ip地址給本地服務器

本地域名服務器緩存解析結果

返回解析結果給用戶

DNS負載均衡

DNS負載均衡技術的實現原理是在DNS服務器中為同一個主機名配置多個IP地址，在應答NDS查詢時，DNS服務器對每個查詢將以DNS文件中主機記錄的IP地址按順序返回不同的解析結果，將客戶端的訪問引導到不同的機器上去，使得不同的客戶端訪問不同的服務器，從而達到負載均衡的目的。

三次握手的目的

目的是為了防止已經失效的連接請求報文段突然有傳送到了服務端，因而產生錯誤

三次握手的過程

客戶端發(fā)送一個帶SYN=1，Seq=X 的數據包到服務器端(第一次握手，由瀏覽器發(fā)起，告訴服務器我要發(fā)送請求了)

服務器發(fā)揮一個帶SUN=1,ACK=Y的響應包以示傳達確認信息(第二次握手，由服務器發(fā)起，告訴瀏覽器我準備接收了，可以發(fā)送了)

客戶端再傳回一個帶ACK=Y+1,Seq=Z的數據報，代表握手結束(第三次握手，由瀏覽器發(fā)送，告訴服務器，我準備發(fā)送了)

(°ー°〃)我們用大白話解釋下三次握手

快遞小哥：你好，你的快遞到了，你在家沒？
小明：在家呢，送過來吧。
快遞小哥：好的，馬上送到。

請求報文由請求行，請求頭，空行，請求體四個部分組成。

請求方法包括：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

URL即請求地址

協(xié)議版本即http版本號

GET /js/count.js HTTP/1.1

上面代碼中GET代表請求方法，/js/count.js表示URL，HTTP/1.1代表http版本

請求頭部通知服務器關于客戶端請求的信息。它包含許多有關的客戶端環(huán)境和請求正文的有用信息。比如：

Host:主機名，虛擬主機

Connection：HTTP/1.1增加的，使用keeoalive,即持久連接，一個連接可以發(fā)多個請求

User-Agent:客戶端程序的信息，就是我發(fā)送請求的瀏覽器信息

Accept:瀏覽器可以接收的媒體數據類型

Accept-Encoding：是瀏覽器用來告知服務器它能夠支持的內容編碼及內容編碼的優(yōu)先級順序，可一次性指定多種內容編碼

Accept-Language:高hi服務器瀏覽器能夠處理的自然語言集

Cookie：瀏覽器記錄的用戶相關信息

響應報文由相響應行、響應頭、響應主體三個部分組成，如下圖

HTTP/1.1 200 OK

協(xié)議版本：HTTP/1.1

狀態(tài)碼：200

200：請求成功

201：以創(chuàng)建，成功請求并創(chuàng)建了新的資源

203：非授權信息。請求成功，但返回的meta信息不在原始的服務器，而是一個副本

204：無內容。服務器處理成功，但未返回內容。在未更新網頁的情況下，可確保瀏覽器繼續(xù)顯示當前文檔

301：永久重定向

302：臨時重定向

307：臨時重定向。與302類似。使用GET請求重定向

400：客戶端請求的語法錯誤，服務器無法理解(給服務端傳的參數和服務端指定接受的字段不同)

404：服務器無法根據客戶端的請求找到資源

405：客戶端請求中的方法被禁止(請求方法不對，比如服務端設置GET請求，客戶端使用POST請求)

500：服務端內部錯誤

狀態(tài)碼描述：ok

響應頭為客戶端提供了額外的信息，使得客戶端可以做出更好的響應。

Server：服務器告訴客戶端當前服務器上安裝得HTTP服務應用程序的信息，可能包含服務器上的軟件應用名稱，版本號

Content-Type：表明了服務器返回給瀏覽器的實體內容的類型

Transfer-Encoding: chunked 表示輸出的長度不能確定，普通的靜態(tài)頁面、圖片之類的基本上都用不到這個。動態(tài)頁面可能會用到。

Cache-Control：緩存控制，默認值為private,表示內容只緩存到私有緩存中(僅客戶端可以緩存，代理服務器不可緩存)

Expires：告知客戶端資源失效日期

服務端給客戶端返回的文本信息

關鍵渲染路徑是指瀏覽器從最初接收請求來的HTML、CSS、JS等資源，然后解析，構建樹、渲染布局、繪制，最后呈現給客戶能看到的界面的整個過程

主要包括以下幾步

解析HTML生成DOM樹

解析CSS生成CSSOM規(guī)則樹

將DOM樹與CSSOM規(guī)則樹合并在一起生成渲染樹

遍歷渲染樹開始布局，計算每個節(jié)點的位置大小信息

將渲染樹每個節(jié)點繪制到屏幕

構建DOM樹

當瀏覽器接收到服務器響應來的HTML文檔后，會遍歷文檔節(jié)點，生成DOM樹。需要注意的是，DOM樹生成過程中可能會被CSS和JS的加載執(zhí)行阻塞。

構建CSSOM規(guī)則書

瀏覽器解析CSS文件并生成CSS規(guī)則樹，每個CSS文件都被解析成一個StyleSheet對象，每個對象都包含CSS規(guī)則。CSS規(guī)則對象包含對應于CSS語法的選擇器和聲明對象以及其他對象

渲染阻塞

當瀏覽器遇到一個script標記時，DOM構建將暫停，直至腳本完成執(zhí)行，然后繼續(xù)構建DOM。每次去執(zhí)行Js腳本都會嚴重阻塞DOM樹的構建，如果js腳本還操作的CSSOM,而正好這個CSSOM還沒有下載和構建，瀏覽器甚至會延遲腳本執(zhí)行和構建DOM，直至完成其CSSOM的下載和構建。

所以script標簽的位置很重要。實際使用時，可以遵循下面兩個原則：

CSS優(yōu)先：引入順序上，CSS資源先于JS資源。

JS置后：通常我們把JS代碼放到頁面底部，且JS應盡量少影響DOM構建

構建渲染樹

通過DOM樹和CSS規(guī)則樹我們便可以構建渲染樹。瀏覽器會先從DOM樹的根節(jié)點開始遍歷每個可見節(jié)點。對每個可見節(jié)點，找到其適配的CSS樣式規(guī)則并應用。

渲染樹構建完成后，每個節(jié)點都是可見節(jié)點并且都含有其內容和對應的規(guī)則的樣式。這也是渲染樹與DOM樹最大的區(qū)別。渲染樹是用于顯示，那些不可見的元素當然就不會在這棵樹中出現了，除此之外，display等于none的也不會被顯示在這棵樹里頭，但是visibility等于hidden的元素是會顯示在這棵樹里頭的。

渲染樹布局

布局階段會從渲染樹的根節(jié)點開始遍歷，然后確定每個接待你對象在頁面上的確切大小與位置，布局階段的輸出是一個盒子模型，他會精確的捕獲每個元素在屏幕內的確切位置與大小。

渲染樹繪制

在繪制階段，遍歷渲染樹，調用渲染器的paint()方法在屏幕上顯示其內容。渲染樹的繪制工作是由瀏覽器的UI后端組件完成

回流與重繪

根據選安然樹布局，計算CSS樣式，即每個節(jié)點在頁面中的帶線啊哦和位置等幾何信息。HTML默認是流式布局的，CSS和JS會打破這種布局，改變DOM的外觀樣式以及大小和位置。這時就會觸發(fā)回流和重繪

重繪

屏幕的一部分重繪，不影響整體布局，比如某個CSS的背景色變了，但元素的幾何尺寸和位置不變。

常見引起重回的屬性

color

border-style

box-shadow

background

background-size

border-radius

background-position

回流

當元素的大小位置改變，需要重新驗證并計算渲染樹。是渲染樹的一部分或全部發(fā)生了變化。

常見引起回流的屬性和方法

添加或者刪除可見的DOM元素

元素尺寸改變--邊距、填充、邊框、寬度和高度

內容變化，比如用戶在input中輸入文字

瀏覽器窗口尺寸改變

計算offsetWidth和offsetHeight

從上面可以看出：回流必將引起重繪，而重繪不一定會引起回流。

思考下面代碼會觸發(fā)幾次渲染？

div.style.left = "10px";
div.style.top = "10px";
div.style.width = "20px";
div.style.height = "20px";

這段代碼理論上會觸發(fā)4次重繪和回流，因為每次都改變了元素的集合屬性，實際上最后支出法了一次回流，這都得益于

當瀏覽器發(fā)現某一行代碼是改變元素樣式時，瀏覽器不會立即進行渲染，而是緩那么一哆嗦，看你下一行代碼是不是在改樣式，如果下一行還是改樣式，在緩一哆嗦，如果連續(xù)發(fā)現幾行代碼都是在改樣式，瀏覽器會等待這幾行代碼全部執(zhí)行完，才會進行渲染，這就是瀏覽器的渲染隊列機制

動畫效果應用position屬性為absolute或fixed元素上(脫離文檔流)

這種方法也會引發(fā)回流，但是會對其他元素沒有影響，可以提升性能

硬件加速會自動規(guī)避回流和重繪
css中又一下幾個屬性能觸發(fā)硬件加速

transform

opacity

filter

will-change

如果有一些元素不需要用到上述屬性，但是需要觸發(fā)硬件加速效果，可以使用一些小技巧來誘導瀏覽器開啟硬件加速。

    -webkit-transform: translateZ(0);
    -moz-transform: translateZ(0);
    -ms-transform: translateZ(0);
    -o-transform: translateZ(0);
    transform: translateZ(0); 
    /**或者**/
    transform: rotateZ(360deg);
    transform: translate3d(0, 0, 0);

要注意的問題

過多的開啟硬件加速可能會耗費較多的內存。

GPU 渲染會影響字體的抗鋸齒效果。這是因為 GPU 和 CPU 具有不同的渲染機制，即使最終硬件加速停止了，文本還是會在動畫期間顯示得很模糊。

現在的頁面為了優(yōu)化請求的耗時，默認都會開啟持久連接（keep-alive），那么一個TCP連接確切關閉的時機，是這個tab標簽頁關閉的時候。這個關閉的過程就是四次揮手.由于TCP連接時全雙工的，因此，每個方向都必須要多帶帶進行關閉，這一原則是當一方完成數據發(fā)送任務后，發(fā)送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數據流動了，即不會再收到數據了，但是在這個TCP連接上仍然能夠發(fā)送數據，直到這一方向也發(fā)送了FIN。首先進行關閉的一方將執(zhí)行主動關閉，而另一方則執(zhí)行被動關閉

client發(fā)送一個FIN，用來關閉client到server的數據傳送，cliient進入FIN_WAIT_1狀態(tài)

server收到FIN后，發(fā)送一個ack給client，確認序列號為收到序列號+1（與SYN相同，一個FIN占用一個序號），server進入CLOSE_WAIT狀態(tài)

server發(fā)送一個FIN，用來關閉server到client的數據傳送，server進入LAST_ACK狀態(tài)

client收到FIN后，client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ack給server，確認序列號為收到序列號+1，server進入CLOSED狀態(tài)，完成四次揮手