就像在招待客人一樣得遵守一定禮節，瀏覽器與web服務器一問一答的交互過程也得遵守一定的規則——HTTP協議（HyperText Transfer Protocol）。現代B/S架構都是基於統一的HTTP協議，基於此協議的服務器有Apache、IIS、Nginx、Tomcat、JBoss等。目前被廣泛使用的是HTTP1.1（主要討論此版本），與上個版本最大的區別是支持持續連接。B/S固定不變的原則：URL、HTTP、瀏覽器。
當瀏覽器向服務器發出一次請求，web服務器返回HTML文檔給瀏覽器後，兩者不再有任何關係。上一次請求的響應結果不影響下次請求的響應結果，如用戶網線接觸不良，重新插好網線後，再次發送請求，web服務器是感知不到的，只要瀏覽器發出的請求內容一樣，它的處理過程就完全一樣。所以說HTTP協議是無狀態的。
代理服務器（可有效減少服務器的訪問負載）的工作流程：
①當瀏覽器發出請求後，若本地緩存有請求的資源，直接取出保存的副本進行響應；
②若本地沒有請求的資源，代理服務器就向web服務器請求該資源並返回給用戶，同時將資源保持在本地緩存。
HTTP協議採用無狀態短連接的通信方式。因爲web應用每天都要處理大量的請求，不可能每個用戶訪問都保持住這個連接。HTTP1.1支持持久連接，在一個TCP連接上可以傳送多個HTTP請求和響應。eg.一個網頁中的css、JavaScript、圖片文件（HTTP1.0都要單獨建立TCP連接，非常耗時）。一個頁面的css文件經常要發送多個HTTP請求，但每個單獨的頁面還是需要使用各自的TCP連接，所以稱爲短連接。
在瀏覽器輸入http://www.sina.com.cn/：
①首先請求DNS把該域名映射成IP地址；
②根據IP地址在互聯網找到對應的服務器；
③向該服務器發送一個get請求；
④服務器返回數據資源。
發起請求
一個完整的請求消息包括：一個請求行、若干消息頭、以及實體內容。
一個完整的響應消息包括：一個狀態行、若干消息頭、以及實體內容。
消息頭和實體內容要用空行隔開（即回車和換行兩個字符）
若HTTP消息包括實體內容，且沒采用chunked傳輸編碼方式，則消息頭必須包含實體內容的長度的字段，否則客戶端和服務程序無法知道實體內容何時結束。
1.請求行
格式：請求方式 資源路徑 HTTP版本號<CRLF>
舉例：GET/test.html HTTP/1.1
請求方式：POST,HEAD,OPTIONS,DELETE,TRACE,PUT
2.狀態行
格式：HTTP版本號 狀態號 原因描述<CRLF>
舉例：HTTP/1.1 200 OK
實例：telnet localhost 8080（“ctr+]”，組合鍵打開本地回顯）
我們來解析一下在瀏覽器輸入http://www.sina.com.cn/的url後，各請求頭和響應頭的部分：
請求頭：
Host: www.sina.com.cn（指定被請求資源）
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0（客戶端的操作系統、瀏覽器和其他屬性）
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8（指出瀏覽器能夠處理的MIME類型）
Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3（指定一種自然語言）
Accept-Encoding: gzip, deflate（指定可接受的內容編碼）
DNT: 1
Connection: keep-alive（當前連接是否保持）
If-Modified-Since: Thu, 21 Apr 2016 14:22:29 GMT（緩存文檔最後更新時間）
補充：Referer：
①如果從瀏覽器地址輸入URL發出，則不應發送Referer請求頭；
②使用指定的超鏈接的URL發出，發送Referer請求頭。（這樣可以追蹤和了解發出本次請求的起源URL地址）
響應頭：
Age: 51（可在客戶機或代理服務器中緩存的有效時間，單位秒）
Cache-Control: max-age=60（緩存的內容將在60秒後失效）
Content-Encoding: gzip（指定實體內容的壓縮編碼方式）
Content-Length: 120981（指明實體內容長度）
Content-Type: text/html（發送給接受者實體正文類型）
Date: Thu, 21 Apr 2016 15:42:42 GMT
Expires: Thu, 21 Apr 2016 15:43:42 GMT（指定當前文檔什麼時候過期，不能繼續使用本地緩存）
Last-Modified: Thu, 21 Apr 2016 15:42:12 GMT（緩存文檔最後更新時間）
Server: nginx（指定服務器軟件的產品名稱）
Vary: Accept-Encoding（指定影響了服務器所生成的響應內容的那些請求頭字段名）
X-Cache: HIT from cmnet.xxg.18a4.31.spool.sina.com.cn
X-Powered-By: shci_v1.03
補充：
|
Cache-directive |
說明 |
|
public |
所有內容都將被緩存 |
|
private |
內容只緩存到私有緩存中 |
|
no-cache |
必須先與服務器確認返回的響應是否被更改，然後才能使用該響應來滿足後續對同一個網址的請求。因此，如果存在合適的驗證令牌 (ETag)，no-cache會發起往返通信來驗證緩存的響應，如果資源未被更改，可以避免下載。 |
|
no-store |
所有內容都不會被緩存到緩存或 Internet 臨時文件中 |
|
must-revalidation/proxy-revalidation |
如果緩存的內容失效，請求必須發送到服務器/代理以進行重新驗證 |
|
max-age=xxx (xxx is numeric) |
緩存的內容將在 xxx 秒後失效,這個選項只在HTTP 1.1可用,並如果和Last-Modified一起使用時,優先級較高 |
Ctrl+F5可以繞過本地緩存和遠程緩存，通過增加請求頭：Pragma： no-cache、Cache-Control： no-cache，重新發送請求響應新內容。
CDN工作機制：
CDN（Content Delivery Network，內容分佈網絡），是一種先進的流量分配網絡，使用戶就近取得所需內容，提高訪問網站的速度。
可近似認爲CDN=鏡像（mirror）+緩存（cache）+整體負載均衡（GSLB）。可明顯提高Internet中信息流動效率。CDN以緩存靜態數據爲主，eg.CSS、JS、圖片和靜態頁面。淘寶有90%以上的數據都是由CDN來提供的。
作者： @nanphonfy
Email: nanphonfy
(Nfzone) gmail.com 請將(Nfzone)換成@
