浅谈HTTP事务的一个过程
一個騰訊在職的朋友問道，當(dāng)我們在瀏覽器的地址欄輸入?www.baidu.com?，然后回車，這一瞬間頁面發(fā)生了什么？下面以谷歌瀏覽器一一解釋．
一.域名解析
首先Chrome瀏覽器會解析www.baidu.com?這個域名對應(yīng)的IP地址。
1 瀏覽器搜索自身的DNS緩存,看是否有www.baidu.com?對應(yīng)的條目，如果有且沒有過期則解析到此結(jié)束。
2 如果沒有找到對應(yīng)的條目，那么Chrome會搜索操作系統(tǒng)自身的DNS緩存,如果找到且沒過期則停止搜索解析到此結(jié)束.
3 如果在Windows系統(tǒng)的DNS緩存也沒有找到，那么嘗試讀取hosts文件，看有沒有該域名對應(yīng)的IP地址，如果有則解析成功。
4 如果在hosts文件中也沒有找到對應(yīng)的條目，瀏覽器就會發(fā)起一個DNS的系統(tǒng)調(diào)用，就會向本地配置的首選DNS服務(wù)器發(fā)起域名解析請求，運營商的DNS服務(wù)器首先查找自身的緩存，找到對應(yīng)的條目，且沒有過期，則解析成功。
二.發(fā)起TCP的3次握手
拿到域名對應(yīng)的IP地址后，User-Agent（一般是指瀏覽器）會以一個隨機(jī)端口（1024 < 端口 < 65535）向服務(wù)器的WEB程序80端口發(fā)起TCP的連接請求。這個連接請求（原始的http請求經(jīng)過TCP/IP4層模型的層層封包）到達(dá)服務(wù)器端后，進(jìn)入到網(wǎng)卡，然后是進(jìn)入到內(nèi)核的TCP/IP協(xié)議棧，還有可能要經(jīng)過Netfilter防火墻的過濾，最終到達(dá)WEB程序，建立了TCP/IP的連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個連接:
第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進(jìn)入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，完成三次握手。
握手過程中傳送的包里不包含數(shù)據(jù)，三次握手完畢后，客戶端與服務(wù)器才正式開始傳送數(shù)據(jù)。理想狀態(tài)下，TCP連接一旦建立，在通信雙方中的任何一方主動關(guān)閉連接之前，TCP 連接都將被一直保持下去。斷開連接時服務(wù)器和客戶端均可以主動發(fā)起斷開TCP連接的請求，斷開過程需要經(jīng)過“第四次握手”，就是服務(wù)器和客戶端交互，最終確定斷開。
三.建立TCP連接后發(fā)起http請求
HTTP協(xié)議即超文本傳送協(xié)議(Hypertext Transfer Protocol )，是Web聯(lián)網(wǎng)的基礎(chǔ)，也是手機(jī)聯(lián)網(wǎng)常用的協(xié)議之一，HTTP協(xié)議是建立在TCP協(xié)議之上的一種應(yīng)用。HTTP連接最顯著的特點是客戶端發(fā)送的每次請求都需要服務(wù)器回送響應(yīng)，在請求結(jié)束后，會主動釋放連接。從建立連接到關(guān)閉連接的過程稱為“一次連接”。
1）在HTTP 1.0中，客戶端的每次請求都要求建立一次單獨的連接，在處理完本次請求后，就自動釋放連接。
2）在HTTP 1.1中則可以在一次連接中處理多個請求，并且多個請求可以重疊進(jìn)行，不需要等待一個請求結(jié)束后再發(fā)送下一個請求。由于HTTP在每次請求結(jié)束后都會主動釋放連接，因此HTTP連接是一種“短連接”，要保持客戶端程序的在線狀態(tài)，需要不斷地向服務(wù)器發(fā)起連接求。通常 的做法是即時不需要獲得任何數(shù)據(jù)，客戶端也保持每隔一段固定的時間向服務(wù)器發(fā)送一次“保持連接”的請求，服務(wù)器在收到該請求后對客戶端進(jìn)行回復(fù)，表明知道客戶端“在線”。若服務(wù)器長時間無法收到客戶端的請求，則認(rèn)為客戶端“下線”，若客戶端長時間無法收到服務(wù)器的回復(fù)，則認(rèn)為網(wǎng)絡(luò)已經(jīng)斷開。
進(jìn)過TCP3次握手之后，瀏覽器發(fā)起了http的請求，使用的http的方法 GET 方法，請求的URL是 / ,協(xié)議是HTTP/1.0。那么HTTP請求報文和響應(yīng)報文會是什么格式呢？
起始行：如 GET / HTTP/1.0 （請求的方法、請求的URL 請求所使用的協(xié)議）
頭部信息：User-Agent? Host等成對出現(xiàn)的值
主體
起始行中的請求方法有以下：
GET
GET是http的默認(rèn)請求方式，一般用來獲取數(shù)據(jù)，傳輸?shù)臄?shù)據(jù)經(jīng)過url編碼后放在路徑?之后，多個鍵值對通過&連接，另外get的傳輸長度一般不推薦超過255個字節(jié)。
GET方法一般被視為安全方法， 因為它僅用來獲取數(shù)據(jù)而不會對服務(wù)器有其他改動。像HEAD、GET、OPTIONS 和 TRACE這幾種http方法是被認(rèn)為是“安全的”，它們只會進(jìn)行獲取數(shù)據(jù)而不會修改服務(wù)器的狀態(tài)，可用于記錄日志、創(chuàng)建緩存或者創(chuàng)建其他統(tǒng)計信息。相反，像POST、PUT、DELETE 和 PATCH 等方法是有可能產(chǎn)生副作用。網(wǎng)絡(luò)爬蟲等一般不會使用這些方式
POST
POST一般用來上傳文件或者提交一個完整的web表單。瀏覽器中提交表單時，這里與get類似，每個鍵值對都是通過&分割, 其他非字母數(shù)字會進(jìn)行url轉(zhuǎn)碼。
為什么一些請求會使用POST提交數(shù)據(jù)?
其他請求方式
HEAD獲取某個URI響應(yīng)頭信息，基本與GET相同但是不返回響應(yīng)主體。
PUT通過提供的URI獲取到特定的內(nèi)容主體，如果存在則修改內(nèi)容，如果不存在則創(chuàng)建。
DELETE通過URI刪除指定內(nèi)容
TRACE返回接受到的請求，用來查看數(shù)據(jù)經(jīng)過中間服務(wù)器時發(fā)生了哪些變動
OPTIONS返回給定URL支持的所有HTTP方法
CONNECT要求使用SSL和TLS進(jìn)行TCP通信
PATCH請求修改局部數(shù)據(jù)
那什么是URL、URI、URN？
URI? Uniform Resource Identifier 統(tǒng)一資源標(biāo)識符
URL? Uniform Resource Locator 統(tǒng)一資源定位符
格式如下：? scheme://[username:password@]HOST:port/path/to/source
? ? ? ? ? ? ? http://www.magedu.com/downloads/nginx-1.5.tar.gz
URN? Uniform Resource Name 統(tǒng)一資源名稱。URL和URN 都屬于 URI。為了方便就把URL和URI暫時都通指一個東西
下面是Chrome發(fā)起的http請求報文頭部信息：
Accept? 就是告訴服務(wù)器端，我接受那些MIME類型
Accept-Encoding? 這個看起來是接受那些壓縮方式的文件
Accept-Lanague?? 告訴服務(wù)器能夠發(fā)送哪些語言
Connection?????? 告訴服務(wù)器支持keep-alive特性
Cookie?????????? 每次請求時都會攜帶上Cookie以方便服務(wù)器端識別是否是同一個客戶端
Host???????????? 用來標(biāo)識請求服務(wù)器上的那個虛擬主機(jī)，比如Nginx里面可以定義很多個虛擬主機(jī)．那這里就是用來標(biāo)識要訪問那個虛擬主機(jī)。
User-Agent?????? 用戶代理，一般情況是瀏覽器，也有其他類型，如：wget curl 搜索引擎的蜘蛛等?
條件請求首部：
If-Modified-Since 是瀏覽器向服務(wù)器端詢問某個資源文件如果自從什么時間修改過，那么重新發(fā)給我，這樣就保證服務(wù)器端資源．文件更新時，瀏覽器再次去請求，而不是使用緩存中的文件
安全請求首部：
Authorization: 客戶端提供給服務(wù)器的認(rèn)證信息；
什么是MIME？
MIME（Multipurpose Internet Mail Extesions 多用途互聯(lián)網(wǎng)郵件擴(kuò)展）是一個互聯(lián)網(wǎng)標(biāo)準(zhǔn)，它擴(kuò)展了電子郵件標(biāo)準(zhǔn)，使其能夠支持非ASCII字符、二進(jìn)制格式附件等多種格式的郵件消息，這個標(biāo)準(zhǔn)被定義在RFC 2045、RFC 2046、RFC 2047、RFC 2048、RFC 2049等RFC中。 由RFC 822轉(zhuǎn)變而來的RFC 2822，規(guī)定電子郵件標(biāo)準(zhǔn)并不允許在郵件消息中使用7位ASCII字符集以外的字符。正因如此，一些非英語字符消息和二進(jìn)制文件，圖像，聲音等非文字消息都不能在電子郵件中傳輸。MIME規(guī)定了用于表示各種各樣的數(shù)據(jù)類型的符號化方法。 此外，在萬維網(wǎng)中使用的HTTP協(xié)議中也使用了MIME的框架，標(biāo)準(zhǔn)被擴(kuò)展為互聯(lián)網(wǎng)媒體類型。
MIME 遵循以下格式：major/minor 主類型/次類型 例如：
image/jpg
image/gif
text/html
video/quicktime
appliation/x-httpd-php
四.服務(wù)器端響應(yīng)http請求，瀏覽器得到html代碼
服務(wù)器端WEB程序接收到http請求以后，就開始處理該請求，處理之后就返回給瀏覽器html文件。
1xx: 信息性狀態(tài)碼
???? 100, 101
2xx: 成功狀態(tài)碼
???? 200：OK
3xx: 重定向狀態(tài)碼
???? 301: 永久重定向, Location響應(yīng)首部的值仍為當(dāng)前URL，因此為隱藏重定向;
???? 302: 臨時重定向，顯式重定向, Location響應(yīng)首部的值為新的URL
???? 304：Not Modified? 未修改，比如本地緩存的資源文件和服務(wù)器上比較時，發(fā)現(xiàn)并沒有修改，服務(wù)器返回一個304狀態(tài)碼，告訴瀏覽器，你不用請求該資源，直接使用本地的資源即可。
4xx: 客戶端錯誤狀態(tài)碼
???? 404: Not Found? 請求的URL資源并不存在
5xx: 服務(wù)器端錯誤狀態(tài)碼
???? 500: Internal Server Error? 服務(wù)器內(nèi)部錯誤
???? 502: Bad Gateway? 前面代理服務(wù)器聯(lián)系不到后端的服務(wù)器時出現(xiàn)
???? 504：Gateway Timeout? 這個是代理能聯(lián)系到后端的服務(wù)器，但是后端的服務(wù)器在規(guī)定的時間內(nèi)沒有給代理服務(wù)器響應(yīng)
用Chrome瀏覽器看到的響應(yīng)頭信息：
Connection??????????? 使用keep-alive特性
Content-Encoding????? 使用gzip方式對資源壓縮
Content-type????????? MIME類型為html類型，字符集是 UTF-8
Date????????????????? 響應(yīng)的日期
Server??????????????? 使用的WEB服務(wù)器
Transfer-Encoding:chunked?? 分塊傳輸編碼 是http中的一種數(shù)據(jù)傳輸機(jī)制，允許HTTP由網(wǎng)頁服務(wù)器發(fā)送給客戶端應(yīng)用（通常是網(wǎng)頁瀏覽器）的數(shù)據(jù)可以分成多個部分，分塊傳輸編碼只在HTTP協(xié)議1.1版本（HTTP/1.1）中提供
五. 瀏覽器解析html代碼，并請求html代碼中的資源
瀏覽器拿到index.html文件后，就開始解析其中的html代碼，遇到j(luò)s/css/image等靜態(tài)資源時，就向服務(wù)器端去請求下載（會使用多線程下載，每個瀏覽器的線程數(shù)不一樣），這個時候就用上keep-alive特性了，建立一次HTTP連接，可以請求多個資源，下載資源的順序就是按照代碼里的順序，但是由于每個資源大小不一樣，而瀏覽器又多線程請求請求資源，順序并不一定是代碼里面的順序。
瀏覽器在請求靜態(tài)資源時（在未過期的情況下），向服務(wù)器端發(fā)起一個http請求（詢問自從上一次修改時間到現(xiàn)在有沒有對資源進(jìn)行修改），如果服務(wù)器端返回304狀態(tài)碼（告訴瀏覽器服務(wù)器端沒有修改），那么瀏覽器會直接讀取本地的該資源的緩存文件。
六.瀏覽器對頁面進(jìn)行渲染呈現(xiàn)給用戶
最后，瀏覽器把請求到的靜態(tài)資源和html代碼進(jìn)行渲染，呈現(xiàn)給用戶。
總結(jié)
域名解析 --> 發(fā)起TCP的3次握手 --> 建立TCP連接后發(fā)起http請求 --> 服務(wù)器響應(yīng)http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進(jìn)行渲染呈現(xiàn)給用戶
轉(zhuǎn)載于:https://www.cnblogs.com/LIUYANZUO/p/5428185.html
總結(jié)
以上是生活随笔為你收集整理的浅谈HTTP事务的一个过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [android] 新闻客户端实现左侧导
- 下一篇： 关于Win7 内存变小处理方法