web 頁面解析的流程總結

個人博客文章：WEB 頁面解析的流程總結

背景

爲理解 web 頁面解析的過程，總結其中涉及的基礎知識和可能存在的安全問題。

WEB 頁面解析的總體流程

客戶端（瀏覽器）發起頁面請求，主機對 地址中的DNS 域名進行解析，找到對應的 IP 地址，請求發送到 服務端，服務器根據請求內容發送響應給客戶端，客戶端收到響應，將內容渲染成網頁。

DNS 基礎

DNS（Domain Name System），即域名解析系統，用於爲網絡中的主機提供容易記憶、便於閱讀的名字。網絡主機雖然可以通過 IP 地址標識，但是在我們的日常生活中，我們當然更喜歡容易閱讀的域名來標識一個主機，如 www.baidu.com 而不是一連串類似 183.232.231.174 的一串數字，但是域名無法被網絡層的設備如路由器等識別，還需要轉換成相應的 IP 地址，這就需要 DNS 提供這項服務。DNS 包含一個分佈式、分層級的服務器組，用於提供將域名轉換成 IP 地址的服務，另外還提供如何完成這一服務的協議；DNS 協議基於 UDP 進行通信，端口號爲 53。

DNS 服務器的分層結構

DNS 服務器採用分佈式、分層的方式部署在世界各地。按照層級從高到低，DNS 服務器分爲：根域名服務器（Root DNS Servers）、頂級域名服務器（TLD DNS Servers）、權威域名服務器（Authoritative DNS Servers），層級關係如下圖：

• 根域名服務器：世界上有 13 個 根域名服務器，準確來說是 13 組服務器羣組，服務器組中的每一個根域名服務器都有所有頂級域名服務器（com, org, gov …）的 IP 地址。
• 頂級域名服務器：爲頂級域名如 com、org、net 等提供域名解析服務，每一個頂級域名都有相應的 頂級域名服務器，存放其所有子域名的 IP 地址。
• 權威域名服務器：各種組織機構，如企業、學校、政府組織等都需爲其提供網絡服務的主機取一個合適的域名，如 百度公司的 baidu.com，而主機的 IP 地址和域名的對應關係就保存至其權威域名服務器中。一般大公司和學校都會部署自己的權威域名服務器。

域名解析流程

DNS 域名解析服務的總體流程如下圖，查詢主機需要知道 cis.poly.edu 的 IP 地址，按照圖中的順序依次進行域名解析。

以使用瀏覽器訪問 www.baidu.com 爲例，域名解析過程大致如下：

1. 主機上的域名解析：瀏覽器首先查看瀏覽器中的緩存是否緩存了 www.baidu.com 的 IP 地址，如果存在則直接使用，不存在則在主機中的 DNS緩存 和 hosts 文件查找，如果存在則直接使用。
2. 本地域名服務器上的解析：當在主機無法自己完成域名解析時，進一步向 本地域名服務器詢問域名 www.baidu.com 的 IP 地址，本地域名服務器首先會查看服務器上的 DNS 緩存，如果存在相應的緩存則返回給查詢主機，反之則進一步向 根域名服務器發起一個域名解析請求。本地域名服務器一般都是我們接入的網絡的管理機構提供，如我們一般在家裏都是用網絡服務提供商（電信、移動、聯通等）提供的網絡接入服務，相應的本地域名服務器也由各個ISP提供，而當我們接入校園網時，則由學校提供。
3. 根域名服務器上的解析：當根域名接收到本地域名解析服務器發起的域名解析請求後，根域名服務器返回 www.baidu.com 的頂級域名 com 的一個或多個 IP 地址，因爲 根域名服務器 只負頂級域名的解析。
4. 頂級域名服務器上的解析： 當 本地域名服務器 收到頂級域名 com的IP地址後，進一步 com的域名服務器發起一個域名解析請求，頂級域名服務器返回可以解析 www.baidu.com 的一個權威域名服務器地址。
5. 權威域名服務器上的解析： 當 本地域名服務器收到 www.baidu.com 的 權威域名服務器的地址後，進一步向 權威域名服務器發起對 www.baidu.com 的域名解析請求，該權威域名服務器收到請求後，返回 www.baidu.com 的 IP 地址和 有效時間 TTL 給 本地域名服務器。
6. 本地域名服務器上完成解析： 本地域名服務器收到 www.baidu.com 的 IP 地址，放到服務器的 DNS 緩存中，設置緩存的 TTL，標識該 DNS記錄的有效時間，最後返回 www.baidu.com的 IP 地址給查詢主機。

最終主機獲得 www.baidu.com 的 IP 地址，並將本次查詢的 DNS 記錄緩存系統中的 DNS 緩存中，同樣設置相應的TTL。

HTTP 協議基礎

HTTP （HyperText Transfer Protocal，超文本傳輸協議） 是應用層協議，使用 TCP 協議進行數據傳輸，常用端口號爲 80，用於實現 Web 客戶端 和 Web 服務器之間的通信。HTTP 協議規定了客戶端和服務端之間通信的報文格式以及數據交換的流程。

HTTP 報文格式

HTTP 報文分爲客戶端發送的請求報文和服務端發送的響應報文，用於建立通信和數據傳輸。

HTTP 請求報文格式

HTTP 請求報文由三部分組成：

1. 請求行（Request line），聲明請求方法、請求資源的URL路徑、HTTP 版本號
2. 首部行（Header line），聲明額外的信息，
3. 實體主體（Entity Body），存放需要傳輸的數據

請求行和首部行，每行都以 回車（carriage return，cr）和換行符 （line feed，lf）結尾。

首部行和實體主體之間有一空行，同樣以回車和換行符結尾。

一個簡單示例：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

HTTP 響應報文格式

HTTP 響應報文的格式和請求報文格式類似，也由三部分組成：

1. 狀態行（Status line)，聲明 HTTP 的版本號，響應的狀態碼和相應的狀態消息
2. 首部行（Header line），聲明額外信息
3. 實體主體（Entity body），存放需要傳輸的數據

一個簡單示例：

HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

(data data data data data ...)

HTTP 請求方法

現有的 HTTP 請求方法共有 9 種，包括由 HTTP1.0 定義的 GET、HEAD 、POST 三種方法 和在 HTTP1.1 版本中新增的 PUT、DELETE、CONNECT、OPTIONS、TRACE 和 PATCH 6種方法。

序號	方法	描述
1	GET	請求指定的頁面信息，並返回消息主體。
2	HEAD	類似於 GET 請求，只不過返回的響應中沒有消息主體，僅獲取報文的頭部（狀態行+首部行）
3	POST	向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在消息實體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。
4	PUT	從客戶端向服務器傳送的數據取代指定的文檔的內容。
5	DELETE	請求服務器刪除指定的資源。
6	CONNECT	HTTP/1.1 協議中預留給能夠將連接改爲管道方式的代理服務器。
7	OPTIONS	允許客戶端查看服務器的性能。
8	TRACE	回顯服務器收到的請求，主要用於測試或診斷。
9	PATCH	是對 PUT 方法的補充，用來對已知資源進行局部更新 。

HTTP 首部字段

HTTP 首部字段用於定義客戶端和服務端通信的額外信息，按照首部的使用條件可分爲四類：

1. 通用首部，可用於請求和響應報文中，和實體主體無關；
2. 請求首部，僅用於請求報文中，存放請求的詳細信息，如請求資源的要求、請求主機的信息等；
3. 響應首部，僅用於響應報文中，存放響應的信息，如資源的位置，服務器等；
4. 實體首部，僅用於描述所數據的信息，即描述 HTTP 報文中 Entity Body 部分，如數據長度、類型等。

通用首部

常見首部	描述
Date	HTTP 響應創建的時間和日期
Cache-Control	用於控制緩存機制，作用在請求或者響應中，作用是單一方向的，請求和響應中的緩存控制各不相干
Connection	是否建立可持續連接

請求首部

常見首部	描述
Accept	說明客戶端能接收的內容類型，多個類型用逗號隔開，類型格式：type/subtype;parameter=value
Accept-*	說明客戶端能接收的字符集、編碼、語言等。Accept-Charset、Accept-Encoding、Accept-Language
Cookie	存放服務端發送給客戶端的 HTTP Cookie
Host	所請求的服務器的域名
User-Agent	用戶代理，標識客戶端使用的應用、系統等信息
Referer	存放打開當前頁面的源地址，方便服務端識別訪問來源
If-*	條件請求，滿足條件是請求才會成功，如 If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since

響應首部

常見首部	描述
Age	響應在代理緩存中存放的時間，以秒爲單位，值爲代理和通用首部 Date時間之差，爲 0 值說明很有可能從服務器中獲取
Location	說明資源重定向後的地址
Server	原始服務器使用的軟件名稱，如 Server: Apache/2.4.1 (Unix)
Allow	聲明請求資源可以使用的 HTTP 方法，如 Allow: GET, POST, HEAD，當響應的狀態碼爲 405時必須帶這個響應首部

實體首部

常見首部	描述
Content-Length	數據長度，整個 Entity Body 的字節數
Content-Language	數據顯示時使用的語言，如 Content-Language: en,zh
Content-Encoding	數據的壓縮編碼方式，如 Content-Encoding: gzip
Content-Type	數據的 MIME 類型，如 Content-Type: text/html; charset=utf-8
Content-Location	說明資源的一個可用地址，服務器上的資源通常會有多個版本的地址，如一個資源可能存放在 json、text 或者 csv 文件中，根據客戶端能接受的數據類型，返回相應的資源，下次請求時可以直接使用 Content-Location提供的資源路徑，如Content-Location: /documents/foo.json

HTTP 響應的狀態碼

類型	常見狀態碼
1xx：信息	100 Continue 101 Switching Proctocols
2xx：成功	200 OK：請求成功 201 Created：請求成功同時資源在服務器中創建 202 Accepted：請求已接受，但尚未處理完
3xx：重定向	301 Moved Permanently：頁面永久轉移到新 url 302 Moved Temporarily：頁面臨時轉移到新 url
4xx：客戶端錯誤	400 Bad Request：服務器不理解請求 401 Unauthorized：被請求的頁面需要用戶名和密碼。 403 Forbidden：頁面禁止訪問 404 Not Found：沒有找到請求的資源 405 Method Not Allowed：請求方法不被允許
5xx：服務器錯誤	500 Internal Server Error：請求未完成。服務器遇到不可預知的情況。 502 Bad Gateway：請求未完成。服務器從上游服務器收到一個無效的響應。 503 Service Unavailable：請求未完成，服務器臨時過載或宕機。 504 Gateway Timeout：網關超時。

潛在的安全問題

頁面處理：

• 輸入內容不做過濾
• 不檢查地址來源
• 輸出內容不作處理

DNS 解析：

• 域名服務器被劫持（可能性很小）
• DNS 緩存投毒

參考

1. Computer Networking A Top-Down Approach 6th Edition
2. Web頁面的請求歷程
3. HTTP tutorial
4. How browser work
   .net/sun927/article/details/50764837)
5. HTTP tutorial
6. How browser work
7. DNS域名解析過程