從敲入 URL 到瀏覽器渲染完成、對HTTP協議的理解

 

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-Control

　　Cache-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、Pragma

　　Pragma頭域用來包含實現特定的指令，最經常使用的是Pragma:no-cache。在HTTP/1.1協議中，它的含義和Cache- Control:no-cache相同。

　　3、Connection

　　Connection表示是否須要持久鏈接。若是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、Date

　　Date頭域表示消息發送的時間，服務器響應中要包含這個頭部，由於緩存在評估響應的新鮮度時要用到，其時間的描述格式由RFC822定義。例如，Date:Mon, 31 Dec 2001 04:25:57 GMT。Date描述的時間表示世界標準時，換算成本地時間，須要知道用戶所在的時區。

　　5、Transfer-Encoding

　　WEB 服務器代表本身對本響應消息體（不是消息體裏面的對象）做了怎樣的編碼，好比是否分塊（chunked），例如：Transfer-Encoding: chunked

　　6、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。

　　九、Accept-Charset

　　瀏覽器告訴服務器本身能接收的字符集。

　　十、Accept-Encoding

　　瀏覽器申明本身接收的編碼方法，一般指定壓縮方法，是否支持壓縮，支持什麼壓縮方法（gzip，deflate）。

　　十一、Accept-Language

　　瀏覽器申明本身接收的語言。語言跟字符集的區別：中文是語言，中文有多種字符集，好比big5，gb2312，gbk等等。

　　十二、Authorization

　　當客戶端接收到來自WEB服務器的 WWW-Authenticate 響應時，用該頭部來回應本身的身份驗證信息給WEB服務器。

　　1三、If-Match

　　若是對象的 ETag 沒有改變，其實也就意味著對象沒有改變，才執行請求的動做，獲取文檔。

　　1四、If-None-Match

　　若是對象的 ETag 改變了，其實也就意味著對象也改變了，才執行請求的動做，獲取文檔。

　　1五、If-Modified-Since

　　若是請求的對象在該頭部指定的時間以後修改了，才執行請求的動做（好比返回對象），不然返回代碼304，告訴瀏覽器該對象沒有修改。例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT

　　1六、If-Unmodified-Since

　　若是請求的對象在該頭部指定的時間以後沒修改過，才執行請求的動做（好比返回對象）。

　　1七、If-Range

　　瀏覽器告訴 WEB 服務器，若是我請求的對象沒有改變，就把我缺乏的部分給我，若是對象改變了，就把整個對象給我。瀏覽器經過發送請求對象的ETag 或者本身所知道的最後修改時間給 WEB 服務器，讓其判斷對象是否改變了。老是跟 Range 頭部一塊兒使用。

　　1八、Range

　　瀏覽器（好比 Flashget 多線程下載時）告訴 WEB 服務器本身想取對象的哪部分。例如：Range: bytes=1173546

　　1九、Proxy-Authenticate

　　代理服務器響應瀏覽器，要求其提供代理身份驗證信息。

　　20、Proxy-Authorization

　　瀏覽器響應代理服務器的身份驗證請求，提供本身的身份信息。

　　2一、Host

　　客戶端指定本身想訪問的WEB服務器的域名/IP 地址和端口號。如Host：rss.sina.com.cn

　　2二、Referer

　　瀏覽器向WEB 服務器代表本身是從哪一個網頁URL得到點擊當前請求中的網址/URL，例如：Referer：http://www.jb51.net　　

        2三、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。對響應頭域的擴展要求通信雙方都支持，若是存在不支持的響應頭域，通常將會做爲實體頭域處理。

　　2四、Age

　　當代理服務器用本身緩存的實體去響應請求時，用該頭部代表該實體從產生到如今通過多長時間了。

　　2五、Server

　　WEB 服務器代表本身是什麼軟件及版本等信息。例如：Server：Apache/2.0.61 (Unix)

　　2六、Accept-Ranges

　　WEB服務器代表本身是否接受獲取其某個實體的一部分（好比文件的一部分）的請求。bytes：表示接受，none：表示不接受。

　　2七、Vary

　　WEB服務器用該頭部的內容告訴 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-MD五、Content-Range、Content-Type，緩存頭部Etag、Expires、Last-Modified、extension-header。

　　2八、Allow

　　服務器支持哪些請求方法（如GET、POST等）。

　　2九、Location

　　表示客戶應當到哪裏去提取文檔，用於將接收端定位到資源的位置（URL）上。Location一般不是直接設置的，而是經過HttpServletResponse的sendRedirect方法，該方法同時設置狀態代碼爲302。

　　30、Content-Base

　　解析主體中的相對URL時使用的基礎URL。

　　3一、Content-Encoding

　　WEB服務器代表本身使用了什麼壓縮方法（gzip，deflate）壓縮響應中的對象。例如：Content-Encoding：gzip

　　3二、Content-Language

　　WEB 服務器告訴瀏覽器理解主體時最適宜使用的天然語言。

　　3三、Content-Length

　　WEB服務器告訴瀏覽器本身響應的對象的長度或尺寸，例如：Content-Length: 26012

　　3四、Content-Location

　　資源實際所處的位置。

　　3五、Content-MD5

　　主體的MD5校驗和。

　　3六、Content-Range

　　實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。通常格式： Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth。例如，傳送頭500個字節次字段的形式：Content-Range:bytes0- 499/1234若是一個http消息包含此節（例如，對範圍請求的響應或對一系列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。

　　3七、Content-Type

　　WEB 服務器告訴瀏覽器本身響應的對象的類型。例如：Content-Type：application/xml

　　3八、Etag

　　就是一個對象（好比URL）的標誌值，就一個對象而言，好比一個html文件，若是被修改了，其Etag也會別修改，因此，ETag的做用跟Last-Modified的做用差很少，主要供WEB服務器判斷一個對象是否改變了。好比前一次請求某個html文件時，得到了其 ETag，當此次又請求這個文件時，瀏覽器就會把先前得到ETag值發送給WEB服務器，而後WEB服務器會把這個ETag跟該文件的當前ETag進行對比，而後就知道這個文件有沒有改變了。

　　3九、Expires

　　WEB服務器代表該實體將在何時過時，對於過時了的對象，只有在跟WEB服務器驗證了其有效性後，才能用來響應客戶請求。是 HTTP/1.0 的頭部。例如：Expires：Sat, 23 May 2009 10:02:12 GMT

　　40、Last-Modified

　　WEB服務器認爲對象的最後修改時間，好比文件的最後修改時間，動態頁面的最後產生時間等等。例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT