?

1. 大致過程

當你這樣子回答的時候：

• 用戶輸入 url 地址，瀏覽器查詢 DNS 查找對應的請求 IP 地址

• 建立 TCP 連接

• 瀏覽器向服務器發送 http 請求，如果服務器段返回以 301 之類的重定向，瀏覽器根據相應頭中的 location 再次發送請求

• 服務器端接受請求，處理請求生成 html 代碼，返回給瀏覽器，這時的 html 頁面代碼可能是經過壓縮的

• 瀏覽器接收服務器響應結果，如果有壓縮則首先進行解壓處理，緊接著就是頁面解析渲染

• 解析該過程分為：解析 HTML，構建 DOM 樹，DOM 樹與 CSS 樣式進行附著構造呈現樹，布局、繪制

雖然這大致的過程是對的，但回答不上細節 ！深度不夠！！！

2. 詳細過程

?

2.1 輸入地址

瀏覽器引入了 DNS 預取技術。它是利用現有的 DNS 機制，提前解析網頁中可能的網絡連接。

當我們開始在瀏覽器中輸入網址的時候，瀏覽器其實就已經在智能的匹配可能得 url 了。它會從歷史記錄，書簽等地方，找到已經輸入的字符串可能對應的 url ，找到同輸入的地址很匹配的項，然后給出智能提示，讓你可以補全 url 地址。用戶還沒有按下 enter 鍵， 瀏覽器已經開始使用 DNS 預取技術解析該域名了。

對于 chrome 的瀏覽器，如果有該域名相關的緩存，它會直接從緩存中把網頁展示出來，就是說，你還沒有按下 enter，頁面就出來了。如果沒有緩存，就還是會重新請求資源。

2.2 查詢 DNS 查找對應的請求 IP 地址

假設輸入 www.baidu.com，大概過程：

• 瀏覽器搜索自己的 DNS 緩存。

• 在瀏覽器緩存中沒找到，就在操作系統緩存中查找，這一步中也會查找本機的 hosts 看看有沒有對應的域名映射。

• 在系統中也沒有的話，就到你的路由器來查找，因為路由器一般也會有自己的 DNS 緩存。

• 若沒有，則操作系統將域名發送至 本地域名服務器——遞歸查詢方式，本地域名服務器 查詢自己的 DNS 緩存，查找成功則返回結果，否則，采用迭代查詢方式。本地域名服務器一般都是你的網絡接入服務器商提供，比如中國電信，中國移動。

• 本地域名服務器 將得到的 IP 地址返回給操作系統，同時自己也將 IP 地址緩存起來。

• 操作系統將 IP 地址返回給瀏覽器，同時自己也將 IP 地址緩存起來，以備下次別的用戶查詢時，可以直接返回結果，加快網絡訪問。

• 至此，瀏覽器已經得到了域名對應的 IP 地址。

參考文章：

https://blog.csdn.net/wlk2064819994/article/details/79756669
https://blog.csdn.net/dojiangv/article/details/51794535

2.3 建立 TCP 連接

TCP 是一種面向有連接的傳輸層協議。
它可以保證兩端（發送端和接收端）通信主機之間的通信可達。
它能夠處理在傳輸過程中丟包、傳輸順序亂掉等異常情況；此外它還能有效利用寬帶，緩解網絡擁堵。

三次握手的步驟：（抽象派）

客戶端：hello，你是server么？ 服務端：hello，我是server，你是client么 客戶端：yes，我是client

在 TCP 連接建立完成之后就可以發送 HTTP 請求了。

然后，待到斷開連接時，需要進行四次揮手（因為是全雙工的，所以需要四次揮手）

四次揮手的步驟：（抽象派）

主動方：我已經關閉了向你那邊的主動通道了，只能被動接收了 被動方：收到通道關閉的信息 被動方：那我也告訴你，我這邊向你的主動通道也關閉了 主動方：最后收到數據，之后雙方無法通信

2.4 服務器收到請求并響應 HTTP 請求

在接收和解釋請求消息后，服務器返回一個HTTP響應消息。

HTTP 響應由三個部分組成，分別是：狀態行、消息報頭、響應正文。

狀態代碼：由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：

• 1xx：指示信息--表示請求已接收，繼續處理
• 2xx：成功--表示請求已被成功接收、理解、接受
• 3xx：重定向--要完成請求必須進行更進一步的操作
• 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
• 5xx：服務器端錯誤--服務器未能實現合法的請求

常見狀態代碼、狀態描述、說明：

• 200 OK ：客戶端請求成功
• 400 Bad Request ：客戶端請求有語法錯誤，不能被服務器所理解
• 401 Unauthorized ：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden ：服務器收到請求，但是拒絕提供服務
• 404 Not Found ：請求資源不存在，eg：輸入了錯誤的URL
• 500 Internal Server Error ：服務器發生不可預期的錯誤
• 503 Server Unavailable ：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常

HTTP消息報頭包括：普通報頭、請求報頭、響應報頭、實體報頭。具體不作介紹。

響應正文：就是服務器返回的資源的內容

2.5 瀏覽器接收服務器響應結果并處理

在瀏覽器沒有完整接受全部HTML文檔時，它就已經開始顯示這個頁面了，不同瀏覽器可能解析的過程不太一樣，這里我們只介紹 WebKit 的渲染過程。

渲染步驟大致可以分為以下幾步：

1. 解析HTML，構建 DOM 樹2. 解析 CSS ，生成 CSS 規則樹3. 合并 DOM 樹和 CSS 規則，生成 render 樹4. 布局 render 樹（ Layout / reflow ），負責各元素尺寸、位置的計算5. 繪制 render 樹（ paint ），繪制頁面像素信息6. 瀏覽器會將各層的信息發送給 GPU，GPU 會將各層合成（ composite ），顯示在屏幕上

其中每個解釋的過程中，WebKit 都提供了很多相關的類來一步一步地解釋對應的內部模塊，這里面不做詳細描述。

下面根據上面的大致過程來一步步細解。

2.5.1 構造 DOM 樹

瀏覽器在解析html文件時, 是WebKit 中的 HTML 解釋器的將網絡或者本地磁盤獲取的 HTML 網頁和資源從字節流解釋成 DOM 樹結構。具體過程如下 ：

在 WebKit 中這一過程如下：首先是字節流，經過解碼之后是字符流，然后通過詞法分析器會被解釋成詞語（Tokens），之后經過語法分析器構建成節點，最后這些節點被組建成一棵 DOM 樹。

瀏覽器在解析html文件過程中，會 ”自上而下“ 加載，并在加載過程中進行解析渲染。在解析過程中，如果遇到請求外部資源時，如圖片、外鏈的CSS、iconfont等，請求過程是異步的，并不會影響html文檔進行加載，且統一交由 Browser 進程來處理，這使得資源在不同網頁間的共享變得很容易。

HTML 的解釋、布局和渲染等工作基本上就是工作在渲染線程完成的（這不是絕對的）。因為 DOM 樹只能在渲染線程上創建和訪問，這也就是說構建 DOM 樹的過程只能在渲染線程中進行，但是，從字符到詞語這個階段可以交給另外的單獨的線程來做。

而且因為有 DNS 預取技術，當用戶正在瀏覽當前網頁的時候，Chromium 提取網頁中的超鏈接，將域名抽取出來，利用比較少的 CPU 和網絡帶寬來解析這些域名或者 IP 地址，這樣一來，用戶根本感覺不到這一過程。當用戶單擊這些鏈接的時候，可以節省不少時間，特別在域名解析比較慢的時候，效果特別明顯。

解析過程中，瀏覽器首先會解析 HTML 文件構建 DOM 樹，然后解析 CSS 文件構建 Render樹，等到 Render 樹構建完成后，瀏覽器開始布局 Render 樹并將其繪制到屏幕上。

?

2.5.2 解釋 CSS

CSS 解釋過程是指從 CSS 字符串 經過 CSS 解釋器 處理后變成渲染引擎內部規則的表示過程。

生成樣式規則之后，會進行樣式規則匹配，WebKit 會為其中的一些節點（只限于可視節點）選擇合適的樣式信息，規則的匹配則是由 ElementRuleCollector 類來計算并獲得，它根據元素的屬性等，并從 DocumentRuleSets 類中獲取規則集合，依次按照 ID、類別、標簽等選擇器信息逐次匹配獲得元素的樣式。

最后，WebKit 對這些規則進行排序。對于該元素需要的樣式屬性，WebKit 選擇從高優先級規則中選取，并將樣式屬性值返回。

從整個網頁的加載和渲染過程來看，CSS 解釋和規則匹配處于 DOM 樹建立之后，RenderObject 樹建立之前，CSS 解釋器解釋后的結果會保存起來，然后 RenderObject 樹基于該結果來進行規范匹配和布局計算。當網頁有用戶交互或者動畫等動作的時候，通過 CSSDOM 等技術，JavaScript 代碼同樣可以非常方便地修改 CSS 代碼，WebKit 此時需要重新解釋樣式并重復以上這一過程。

?

2.5.3 渲染過程遇到 JavaScript

當文檔加載過程中遇到 js 文件，html 文檔會掛起渲染（加載解析渲染同步）的線程，不僅要等待文檔中 js 文件加載完畢，還要等待解析執行完畢，才可以恢復 html 文檔的渲染線程。因為 JS 有可能會修改 DOM，最為經典的 document.write，這意味著，在 JS 執行完成前，后續所有資源的下載可能是沒有必要的，這是 js 阻塞后續資源下載的根本原因。所以我們平時的代碼中，js 是放在 html 文檔末尾的。

而且當遇到執行 JavaScript 代碼的時候，WebKit 先暫停當前 JavaScript 代碼的執行，使用預先掃描器 HTMLPreloadScanner 類來掃描后面的詞語。如果 WebKit 發現它們需要使用其他資源，那么使用預資源加載器 HTMLPreloadScanner 類來發送請求，在這之后，才執行 JavaScript 代碼。預先掃描器本身并不創建節點對象，也不會構建 DOM 樹，所以速度比較快。

當 DOM 樹構建完之后，WebKit 觸發 “DOMContentLoaded” 事件，注冊在該事件上的 JavaScript 函數會被調用。當所在資源都被加載完之后，WebKit 觸發 “onload” 事件。

WebKit 將 DOM 樹創建過程中需要執行的 JavaScript 代碼交由 HTMLScriptRunner 類來負責。工作方式很簡單，就是利用 JavaScript 引擎來執行 Node 節點中包含的代碼。

JS 的解析是由瀏覽器中的 JavaScript 引擎完成的。JS是單線程運行，也就是說，在同一個時間內只能做一件事，所有的任務都需要排隊，前一個任務結束，后一個任務才能開始。但是又存在某些任務比較耗時，如 IO 讀寫等，所以需要一種機制可以先執行排在后面的任務，這就是：同步任務(synchronous)和異步任務(asynchronous)。

JS 的執行機制就可以看做是一個主線程加上一個任務隊列(task queue)。同步任務就是放在主線程上執行的任務，異步任務是放在任務隊列中的任務。所有的同步任務在主線程上執行，形成一個執行棧; 異步任務有了運行結果就會在任務隊列中放置一個事件；腳本運行時先依次運行執行棧，然后會從任務隊列里提取事件，運行任務隊列中的任務，這個過程是不斷重復的，所以又叫做事件循環(Event loop)。

?

2.5.4 渲染合成 Render 樹

HTML 經過 WebKit 解釋之后，生成 DOM 樹。在 DOM 樹構建完成之后，WebKit 會為 DOM 樹節點構建 RenderObject 樹，再通過 RenderObject 樹構建出 RenderLayer 樹。

RenderObject 樹是基于 DOM 樹建立起來的一棵新樹，是為了布局計算和渲染等機制而構建的一種新的內部表示。RenderObject 樹節點和 DOM 節點不是一一對應關系，因為有可視節點（常用的 div img 標簽等）與不可視節點（如 head、meta 標簽），不可視節點是不會構成 RenderObject 樹的。

網頁是有層次結構的，可以分層的，一是為了方便設置網頁的層次，二是為了 WebKit 處理上的便利，為了簡化渲染的邏輯。

而且 RenderLayer 節點和 RenderObject 節點不是一一對應關系，而是一對多的關系。

2.5.5 布局

當 WebKit 創建 RenderObject 對象之后，每個對象是不知道自己的位置、大小等信息的，WebKit 根據框模型來計算它們的位置，大小等信息的過程稱為布局計算。

布局計算是一個遞歸的過程，因為一個節點的大小通常需要先計算它的子女節點的位置，大小等信息。

當用戶 網頁的動畫、翻滾網頁、JavaScript 代碼通過 CSSDOM 等操作時還會有重新布局。

?

2.5.6 繪圖

在 WebKit 中，繪圖操作就是繪圖上下文，所有繪圖的操作都是在該上下文中來進行的。

繪圖上下文可以分成兩種類型：

一是 2D 圖形上下文（GraphicsContext），用來繪制 2D 圖形的的上下文；

二是 3D 繪圖上下文，是用來繪制 3D 圖形的上下文。

2D 繪圖上下文具體的作用：提供基本繪圖單元的繪制接口以及設置繪圖的樣式。繪圖接口包括畫點，畫線、畫圖片、畫多邊形、畫文字等，繪圖樣式包括顏色、線寬、字號大小、漸變等。

關于 3D 繪圖上下文，它的主要用處是支持 CSS3D、WebGL 等。

網頁的渲染方式，有三種方式，一是軟件渲染，二是硬件加速渲染，三可以說是混合模式。

如果繪圖操作使用 CPU 來完成，稱之為軟件繪圖。

如果繪圖操作由 GPU 來完成，稱之為 GPU 硬件加速繪圖。

理想情況下，每個層都有個繪制的存儲區域，這個存儲區域用來保存繪圖的結果。最后，需要將這些層的內容合并到同一個圖像之中，可以稱之為合成（Compositing），使用了合成技術的渲染稱之為合成化渲染。

所以，在完成構建 DOM 樹之后，WebKit 會調用繪圖操作、軟件渲染或者硬件加速渲染或者兩者都有，將模型繪制出來，呈現在屏幕上。
至此，瀏覽器渲染完成。

以上轉載自 http://biaochenxuying.cn/articleDetail?article_id=5bf4bb59245730373274df64

?

什么是HTTP？

HTTP（超文本傳輸協議）是應用層上的一種客戶端/服務端模型的通信協議，協議規定了通信雙方必須遵循的數據傳輸格式，這樣通信雙方按照約定的格式才能準確的通信。它由請求和響應構成，且是無狀態的。無狀態是指兩次連接通信之間是沒有任何關系的，每次都是一個新的連接，服務端不會記錄前后的請求信息，就是說你之前的請求并不會被知曉，可以理解為‘活在當下’。

HTTP由五層協議組成：

HTTP(應用層)，TCP(傳輸層)，IP(網絡層)，數據鏈路(鏈路層)，物理介質(物理層)

URL的構成:

例如：http(https)://www.baidu.com/index?firstname=yf&lastname=song#mao 中?http(https)-協議?www.baidu.com-域名，由dns服務器找到hostIP地址 ，?之后為參數，以&分隔，#為錨鏈接，錨鏈接不會發起新請求

協議內容：

請求request：包括請求行、請求頭、請求體

例如：

(如何查看？ 瀏覽器F12->XHR->Headers)

響應response：包括狀態行、響應頭、響應體

狀態碼：

HTTP狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，后兩個數字沒有分類的作用。HTTP狀態碼共分為5種類型：

1**：服務器收到請求，需要請求者繼續操作 2**：操作成功接收并處理 3**：重定向 4**：客戶端錯誤 5**：服務器錯誤

常見的包括：200請求成功，301重定向，400請求語義有誤，401請求需要用戶驗證，403請求被服務器主動拒絕，404請求找不到所需要的資源，500服務器錯誤，502服務器作為網關得到錯誤響應

請求方法：

GET：請求指定的頁面信息，并返回實體主體。
HEAD：類似于get請求，只不過返回的響應中沒有具體的內容，用于獲取報頭
POST：向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。
PUT：從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE：請求服務器刪除指定的頁面。
CONNECT：HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
OPTIONS：允許客戶端查看服務器的性能。
TRACE：回顯服務器收到的請求，主要用于測試或診斷。

最常見的就是GET、POST方法(即RPC風格)，比較古老的基于瀏覽器的客戶端只支持get，post，而在RESTful架構中通過GET，DELETE，PUT和POST實現了表述性狀態轉移，RESTful架構遵循統一接口原則，統一接口包含了一組受限的預定義的操作，不論什么樣的資源，都是通過使用相同的接口進行資源的訪問。避免了URI使用動作來描述，如[GET]localhost:5000/delete?name=zhangsan，而是[DELETE]?localhost:5000/name/zhangsan

HTTP通用頭通用頭域包含請求和響應消息都支持的頭域，通用頭域包含緩存頭部Cache-Control、Pragma及信息性頭部Connection、Date、Transfer-Encoding、Update、Via。1、Cache-ControlCache-Control指定請求和響應遵循的緩存機制。在請求消息或響應消息中設置 Cache-Control并不會修改另一個消息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，響應消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下：no-cache：指示請求或響應消息不能緩存，實際上是可以存儲在本地緩存區中的，只是在與原始服務器進行新鮮度驗證之前，緩存不能將其提供給客戶端使用。　no-store：緩存應該盡快從存儲器中刪除文檔的所有痕跡，因為其中可能會包含敏感信息。max-age：緩存無法返回緩存時間長于max-age規定秒的文檔，若不超規定秒瀏覽器將不會發送對應的請求到服務器，數據由緩存直接返回；超過這一時間段才進一步由服務器決定是返回新數據還是仍由緩存提供。若同時還發送了max-stale指令，則使用期可能會超過其過期時間。min-fresh：至少在未來規定秒內文檔要保持新鮮，接受其新鮮生命期大于其當前 Age 跟 min-fresh 值之和的緩存對象。max-stale：指示客戶端可以接收過期響應消息，如果指定max-stale消息的值，那么客戶端可以接收過期但在指定值之內的響應消息。only-if-cached：只有當緩存中有副本存在時，客戶端才會獲得一份副本。Public：指示響應可被任何緩存區緩存，可以用緩存內容回應任何用戶。Private：指示對于單個用戶的整個或部分響應消息，不能被共享緩存處理，只能用緩存內容回應先前請求該內容的那個用戶。2、PragmaPragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache- Control:no-cache相同。3、ConnectionConnection表示是否需要持久連接。如果Servlet看到這里的值為“Keep-Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久連接），它就可以利用持久連接的優點，當頁面包含多個元素時（例如Applet，圖片），顯著地減少下載所需要的時間。要實現這一點，Servlet需要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入ByteArrayOutputStream，然后在正式寫出內容之前計算它的大小。Close：告訴WEB服務器或者代理服務器，在完成本次請求的響應后，斷開連接，不要等待本次連接的后續請求了。Keepalive：告訴WEB服務器或者代理服務器，在完成本次請求的響應后，保持連接，等待本次連接的后續請求。Keep-Alive：如果瀏覽器請求保持連接，則該頭部表明希望 WEB 服務器保持連接多長時間（秒），如Keep-Alive：300。4、DateDate頭域表示消息發送的時間，服務器響應中要包含這個頭部，因為緩存在評估響應的新鮮度時要用到，其時間的描述格式由RFC822定義。例如，Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。5、Transfer-EncodingWEB 服務器表明自己對本響應消息體（不是消息體里面的對象）作了怎樣的編碼，比如是否分塊（chunked），例如：Transfer-Encoding: chunked6、Upgrade它可以指定另一種可能完全不同的協議，如HTTP/1.1客戶端可以向服務器發送一條HTTP/1.0請求，其中包含值為“HTTP/1.1”的Update頭部，這樣客戶端就可以測試一下服務器是否也使用HTTP/1.1了。7、Via列出從客戶端到 OCS 或者相反方向的響應經過了哪些代理服務器，他們用什么協議（和版本）發送的請求。當客戶端請求到達第一個代理服務器時，該服務器會在自己發出的請求里面添加 Via 頭部，并填上自己的相關信息，當下一個代理服務器 收到第一個代理服務器的請求時，會在自己發出的請求里面復制前一個代理服務器的請求的Via頭部，并把自己的相關信息加到后面，以此類推，當 OCS 收到最后一個代理服務器的請求時，檢查 Via 頭部，就知道該請求所經過的路由。例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)HTTP請求頭請求頭用于說明是誰或什么在發送請求、請求源于何處，或者客戶端的喜好及能力。服務器可以根據請求頭部給出的客戶端信息，試著為客戶端提供更好的響應。請求頭域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通訊雙方都支持，如果存在不支持的請求頭域，一般將會作為實體頭域處理。8、Accept告訴WEB服務器自己接受什么介質類型，*/* 表示任何類型，type/* 表示該類型下的所有子類型，type/sub-type。9、Accept-Charset瀏覽器告訴服務器自己能接收的字符集。10、Accept-Encoding瀏覽器申明自己接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法（gzip，deflate）。11、Accept-Language瀏覽器申明自己接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，比如big5，gb2312，gbk等等。12、Authorization當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時，用該頭部來回應自己的身份驗證信息給WEB服務器。13、If-Match如果對象的 ETag 沒有改變，其實也就意味著對象沒有改變，才執行請求的動作，獲取文檔。14、If-None-Match如果對象的 ETag 改變了，其實也就意味著對象也改變了，才執行請求的動作，獲取文檔。15、If-Modified-Since如果請求的對象在該頭部指定的時間之后修改了，才執行請求的動作（比如返回對象），否則返回代碼304，告訴瀏覽器該對象沒有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT16、If-Unmodified-Since如果請求的對象在該頭部指定的時間之后沒修改過，才執行請求的動作（比如返回對象）。17、If-Range瀏覽器告訴 WEB 服務器，如果我請求的對象沒有改變，就把我缺少的部分給我，如果對象改變了，就把整個對象給我。瀏覽器通過發送請求對象的ETag 或者自己所知道的最后修改時間給 WEB 服務器，讓其判斷對象是否改變了。總是跟 Range 頭部一起使用。18、Range瀏覽器（比如 Flashget 多線程下載時）告訴 WEB 服務器自己想取對象的哪部分。例如：Range: bytes=117354619、Proxy-Authenticate代理服務器響應瀏覽器，要求其提供代理身份驗證信息。20、Proxy-Authorization瀏覽器響應代理服務器的身份驗證請求，提供自己的身份信息。21、Host客戶端指定自己想訪問的WEB服務器的域名/IP 地址和端口號。如Host：rss.sina.com.cn22、Referer瀏覽器向WEB 服務器表明自己是從哪個網頁URL獲得點擊當前請求中的網址/URL，例如：Referer：http://www.jb51.net　　23、User-Agent瀏覽器表明自己的身份（是哪種瀏覽器）。例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
HTTP響應頭響應頭向客戶端提供一些額外信息，比如誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些頭部有助于客戶端處理響應，并在將來發起更好的請求。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支持，如果存在不支持的響應頭域，一般將會作為實體頭域處理。24、Age當代理服務器用自己緩存的實體去響應請求時，用該頭部表明該實體從產生到現在經過多長時間了。25、ServerWEB 服務器表明自己是什么軟件及版本等信息。例如：Server：Apache/2.0.61 (Unix)26、Accept-RangesWEB服務器表明自己是否接受獲取其某個實體的一部分（比如文件的一部分）的請求。bytes：表示接受，none：表示不接受。27、VaryWEB服務器用該頭部的內容告訴 Cache 服務器，在什么條件下才能用本響應所返回的對象響應后續的請求。假如源WEB服務器在接到第一個請求消息時，其響應消息的頭部為：Content-Encoding: gzip; Vary: Content-Encoding，那么Cache服務器會分析后續請求消息的頭部，檢查其Accept-Encoding，是否跟先前響應的Vary頭部值一致，即是否使用相同的內容編碼方法，這樣就可以防止Cache服務器用自己Cache 里面壓縮后的實體響應給不具備解壓能力的瀏覽器。例如：Vary：Accept-Encoding。HTTP實體頭實體頭部提供了有關實體及其內容的大量信息，從有關對象類型的信息，到能夠對資源使用的各種有效的請求方法。總之，實體頭部可以告知接收者它在對什么進行處理。請求消息和響應消息都可以包含實體信息，實體信息一般由實體頭域和實體組成。實體頭域包含關于實體的原信息，實體頭包括信息性頭部Allow、Location，內容頭部Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type，緩存頭部Etag、Expires、Last-Modified、extension-header。28、Allow服務器支持哪些請求方法（如GET、POST等）。29、Location表示客戶應當到哪里去提取文檔，用于將接收端定位到資源的位置（URL）上。Location通常不是直接設置的，而是通過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼為302。30、Content-Base解析主體中的相對URL時使用的基礎URL。31、Content-EncodingWEB服務器表明自己使用了什么壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip32、Content-LanguageWEB 服務器告訴瀏覽器理解主體時最適宜使用的自然語言。33、Content-LengthWEB服務器告訴瀏覽器自己響應的對象的長度或尺寸，例如：Content-Length: 2601234、Content-Location資源實際所處的位置。35、Content-MD5主體的MD5校驗和。36、Content-Range實體頭用于指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的范圍和整個實體長度。一般格式： Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如，傳送頭500個字節次字段的形式：Content-Range:bytes0- 499/1234如果一個http消息包含此節（例如，對范圍請求的響應或對一系列范圍的重疊請求），Content-Range表示傳送的范圍，Content-Length表示實際傳送的字節數。37、Content-TypeWEB 服務器告訴瀏覽器自己響應的對象的類型。例如：Content-Type：application/xml38、Etag就是一個對象（比如URL）的標志值，就一個對象而言，比如一個html文件，如果被修改了，其Etag也會別修改，所以，ETag的作用跟Last-Modified的作用差不多，主要供WEB服務器判斷一個對象是否改變了。比如前一次請求某個html文件時，獲得了其 ETag，當這次又請求這個文件時，瀏覽器就會把先前獲得ETag值發送給WEB服務器，然后WEB服務器會把這個ETag跟該文件的當前ETag進行對比，然后就知道這個文件有沒有改變了。39、ExpiresWEB服務器表明該實體將在什么時候過期，對于過期了的對象，只有在跟WEB服務器驗證了其有效性后，才能用來響應客戶請求。是 HTTP/1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT40、Last-ModifiedWEB服務器認為對象的最后修改時間，比如文件的最后修改時間，動態頁面的最后產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT

?

轉載于:https://www.cnblogs.com/songyifan427/p/10005652.html

總結

以上是生活随笔為你收集整理的从敲入 URL 到浏览器渲染完成、对HTTP协议的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。