淺談HTTP事務的一個過程

一個騰訊在職的朋友問道，當咱們在瀏覽器的地址欄輸入 www.baidu.com ，而後回車，這一瞬間頁面發生了什麼？下面以谷歌瀏覽器一一解釋．

一.域名解析

首先Chrome瀏覽器會解析www.baidu.com 這個域名對應的IP地址。

1 瀏覽器搜索自身的DNS緩存,看是否有www.baidu.com 對應的條目，若是有且沒有過時則解析到此結束。

2 若是沒有找到對應的條目，那麼Chrome會搜索操做系統自身的DNS緩存,若是找到且沒過時則中止搜索解析到此結束.

3 若是在Windows系統的DNS緩存也沒有找到，那麼嘗試讀取hosts文件，看有沒有該域名對應的IP地址，若是有則解析成功。

4 若是在hosts文件中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS服務器發起域名解析請求，運營商的DNS服務器首先查找自身的緩存，找到對應的條目，且沒有過時，則解析成功。

二.發起TCP的3次握手

拿到域名對應的IP地址後，User-Agent（通常是指瀏覽器）會以一個隨機端口（1024 < 端口 < 65535）向服務器的WEB程序80端口發起TCP的鏈接請求。這個鏈接請求（原始的http請求通過TCP/IP4層模型的層層封包）到達服務器端後，進入到網卡，而後是進入到內核的TCP/IP協議棧，還有可能要通過Netfilter防火牆的過濾，最終到達WEB程序，創建了TCP/IP的鏈接。在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接:

第一次握手：客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；

第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

握手過程當中傳送的包裏不包含數據，三次握手完畢後，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP鏈接一旦創建，在通訊雙方中的任何一方主動關閉鏈接以前，TCP 鏈接都將被一直保持下去。斷開鏈接時服務器和客戶端都可以主動發起斷開TCP鏈接的請求，斷開過程須要通過「第四次握手」，就是服務器和客戶端交互，最終肯定斷開。

三.創建TCP鏈接後發起http請求

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網經常使用的協議之一，HTTP協議是創建在TCP協議之上的一種應用。HTTP鏈接最顯著的特色是客戶端發送的每次請求都須要服務器回送響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

1）在HTTP 1.0中，客戶端的每次請求都要求創建一次單獨的鏈接，在處理完本次請求後，就自動釋放鏈接。
2）在HTTP 1.1中則能夠在一次鏈接中處理多個請求，而且多個請求能夠重疊進行，不須要等待一個請求結束後再發送下一個請求。因爲HTTP在每次請求結束後都會主動釋放鏈接，所以HTTP鏈接是一種「短鏈接」，要保持客戶端程序的在線狀態，須要不斷地向服務器發起鏈接求。一般 的作法是即時不須要得到任何數據，客戶端也保持每隔一段固定的時間向服務器發送一次「保持鏈接」的請求，服務器在收到該請求後對客戶端進行回覆，代表知道客戶端「在線」。若服務器長時間沒法收到客戶端的請求，則認爲客戶端「下線」，若客戶端長時間沒法收到服務器的回覆，則認爲網絡已經斷開。

進過TCP3次握手以後，瀏覽器發起了http的請求，使用的http的方法 GET 方法，請求的URL是 / ,協議是HTTP/1.0。那麼HTTP請求報文和響應報文會是什麼格式呢？

起始行：如 GET / HTTP/1.0 （請求的方法、請求的URL 請求所使用的協議）

頭部信息：User-Agent  Host等成對出現的值

主體

起始行中的請求方法有如下：

GET

GET是http的默認請求方式，通常用來獲取數據，傳輸的數據通過url編碼後放在路徑?以後，多個鍵值對經過&鏈接，另外get的傳輸長度通常不推薦超過255個字節。

GET方法通常被視爲安全方法， 由於它僅用來獲取數據而不會對服務器有其餘改動。像HEAD、GET、OPTIONS 和 TRACE這幾種http方法是被認爲是「安全的」，它們只會進行獲取數據而不會修改服務器的狀態，可用於記錄日誌、建立緩存或者建立其餘統計信息。相反，像POST、PUT、DELETE 和 PATCH 等方法是有可能產生反作用。網絡爬蟲等通常不會使用這些方式

POST

POST通常用來上傳文件或者提交一個完整的web表單。瀏覽器中提交表單時，這裏與get相似，每一個鍵值對都是經過&分割, 其餘非字母數字會進行url轉碼。

爲何一些請求會使用POST提交數據?

1. GET請求數據均可以在URL中看到
2. GET提交的數據都會有長度限制
3. 通常規範，POST用來修改數據，GET用來獲取數據
4. GET請求提交的數據放置在HTTP請求協議頭中，而POST提交的數據放在實體數據中

其餘請求方式

HEAD獲取某個URI響應頭信息，基本與GET相同可是不返回響應主體。

PUT經過提供的URI獲取到特定的內容主體，若是存在則修改內容，若是不存在則建立。

DELETE經過URI刪除指定內容

TRACE返回接受到的請求，用來查看數據通過中間服務器時發生了哪些變更

OPTIONS返回給定URL支持的全部HTTP方法

CONNECT要求使用SSL和TLS進行TCP通訊

PATCH請求修改局部數據

那什麼是URL、URI、URN？

URI  Uniform Resource Identifier 統一資源標識符

URL  Uniform Resource Locator 統一資源定位符

格式以下：  scheme://[username:password@]HOST:port/path/to/source

             　http://www.magedu.com/downloads/nginx-1.5.tar.gz

URN  Uniform Resource Name 統一資源名稱。URL和URN 都屬於 URI。爲了方便就把URL和URI暫時都通指一個東西

下面是Chrome發起的http請求報文頭部信息：

Accept  就是告訴服務器端，我接受那些MIME類型

Accept-Encoding  這個看起來是接受那些壓縮方式的文件

Accept-Lanague   告訴服務器可以發送哪些語言

Connection       告訴服務器支持keep-alive特性

Cookie           每次請求時都會攜帶上Cookie以方便服務器端識別是不是同一個客戶端

Host             用來標識請求服務器上的那個虛擬主機，好比Nginx裏面能夠定義不少個虛擬主機．那這裏就是用來標識要訪問那個虛擬主機。

User-Agent       用戶代理，通常狀況是瀏覽器，也有其餘類型，如：wget curl 搜索引擎的蜘蛛等 

條件請求首部：

If-Modified-Since 是瀏覽器向服務器端詢問某個資源文件若是自從什麼時間修改過，那麼從新發給我，這樣就保證服務器端資源．文件更新時，瀏覽器再次去請求，而不是使用緩存中的文件

安全請求首部：

Authorization: 客戶端提供給服務器的認證信息；

什麼是MIME？

MIME（Multipurpose Internet Mail Extesions 多用途互聯網郵件擴展）是一個互聯網標準，它擴展了電子郵件標準，使其可以支持非ASCII字符、二進制格式附件等多種格式的郵件消息，這個標準被定義在RFC 204五、RFC 204六、RFC 204七、RFC 204八、RFC 2049等RFC中。 由RFC 822轉變而來的RFC 2822，規定電子郵件標準並不容許在郵件消息中使用7位ASCII字符集之外的字符。正因如此，一些非英語字符消息和二進制文件，圖像，聲音等非文字消息都不能在電子郵件中傳輸。MIME規定了用於表示各類各樣的數據類型的符號化方法。 此外，在萬維網中使用的HTTP協議中也使用了MIME的框架，標準被擴展爲互聯網媒體類型。

MIME 遵循如下格式：major/minor 主類型/次類型 例如：

image/jpg

image/gif

text/html

video/quicktime

appliation/x-httpd-php

四.服務器端響應http請求，瀏覽器獲得html代碼

服務器端WEB程序接收到http請求之後，就開始處理該請求，處理以後就返回給瀏覽器html文件。

1xx: 信息性狀態碼

     100, 101

2xx: 成功狀態碼

     200：OK

3xx: 重定向狀態碼

     301: 永久重定向, Location響應首部的值仍爲當前URL，所以爲隱藏重定向;

     302: 臨時重定向，顯式重定向, Location響應首部的值爲新的URL

     304：Not Modified  未修改，好比本地緩存的資源文件和服務器上比較時，發現並無修改，服務器返回一個304狀態碼，告訴瀏覽器，你不用請求該資源，直接使用本地的資源便可。

4xx: 客戶端錯誤狀態碼

     404: Not Found  請求的URL資源並不存在

5xx: 服務器端錯誤狀態碼

     500: Internal Server Error  服務器內部錯誤

     502: Bad Gateway  前面代理服務器聯繫不到後端的服務器時出現

     504：Gateway Timeout  這個是代理能聯繫到後端的服務器，可是後端的服務器在規定的時間內沒有給代理服務器響應

用Chrome瀏覽器看到的響應頭信息：

Connection            使用keep-alive特性

Content-Encoding      使用gzip方式對資源壓縮

Content-type          MIME類型爲html類型，字符集是 UTF-8

Date                  響應的日期

Server                使用的WEB服務器

Transfer-Encoding:chunked   分塊傳輸編碼 是http中的一種數據傳輸機制，容許HTTP由網頁服務器發送給客戶端應用（一般是網頁瀏覽器）的數據能夠分紅多個部分，分塊傳輸編碼只在HTTP協議1.1版本（HTTP/1.1）中提供

五. 瀏覽器解析html代碼，並請求html代碼中的資源

瀏覽器拿到index.html文件後，就開始解析其中的html代碼，遇到js/css/image等靜態資源時，就向服務器端去請求下載（會使用多線程下載，每一個瀏覽器的線程數不同），這個時候就用上keep-alive特性了，創建一次HTTP鏈接，能夠請求多個資源，下載資源的順序就是按照代碼裏的順序，可是因爲每一個資源大小不同，而瀏覽器又多線程請求請求資源，順序並不必定是代碼裏面的順序。

瀏覽器在請求靜態資源時（在未過時的狀況下），向服務器端發起一個http請求（詢問自從上一次修改時間到如今有沒有對資源進行修改），若是服務器端返回304狀態碼（告訴瀏覽器服務器端沒有修改），那麼瀏覽器會直接讀取本地的該資源的緩存文件。

六.瀏覽器對頁面進行渲染呈現給用戶

最後，瀏覽器把請求到的靜態資源和html代碼進行渲染，呈現給用戶。

總結

域名解析 --> 發起TCP的3次握手 --> 創建TCP鏈接後發起http請求 --> 服務器響應http請求，瀏覽器獲得html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶