本(ben)篇文章帶你(ni)從 HTTP 入(ru)門到(dao)進階，看完讓你(ni)有一種恍然大悟、醍醐灌(guan)頂的感(gan)覺。

最(zui)初在(zai)有(you)(you)網(wang)絡之前，我(wo)(wo)(wo)(wo)們的(de)(de)電(dian)腦都是單機(ji)的(de)(de)，單機(ji)系統是孤立的(de)(de)，我(wo)(wo)(wo)(wo)還記得 05 年(nian)前那會兒家(jia)里有(you)(you)個電(dian)腦，想打電(dian)腦游戲(xi)還得兩個人在(zai)一(yi)個電(dian)腦上(shang)(shang)玩兒，及其(qi)不方便。我(wo)(wo)(wo)(wo)就想為什(shen)么(me)(me)家(jia)里人不讓上(shang)(shang)網(wang)，我(wo)(wo)(wo)(wo)的(de)(de)同學 xxx 家(jia)里有(you)(you)網(wang)，每次一(yi)提(ti)這個就落一(yi)通(tong)批評：xxx上(shang)(shang)xxx什(shen)xxxx么(me)(me)xxxx網(wang)xxxx看xxxx你xxxx考xxxx的(de)(de)xxxx那xxxx點xxxx分。雖然我(wo)(wo)(wo)(wo)家(jia)里沒有(you)(you)上(shang)(shang)網(wang)，但是此時互(hu)聯(lian)網(wang)已經在(zai)高速(su)發展(zhan)了，HTTP 就是高速(su)發展(zhan)的(de)(de)一(yi)個產物。

認識 HTTP

首先你聽的(de)最多的(de)應該就是(shi)(shi) HTTP 是(shi)(shi)一種 超文(wen)本傳(chuan)(chuan)輸協議(yi)(yi)(Hypertext Transfer Protocol)，這你一定能(neng)說出來，但是(shi)(shi)這樣(yang)還不(bu)夠，假(jia)如你是(shi)(shi)大廠面試(shi)官，這不(bu)可能(neng)是(shi)(shi)他(ta)想要的(de)最終結果，我們(men)在面試(shi)的(de)時候往往把自己知道的(de)盡可能(neng)多的(de)說出來，才(cai)有(you)和面試(shi)官談價錢的(de)資本。那么(me)什么(me)是(shi)(shi)超文(wen)本傳(chuan)(chuan)輸協議(yi)(yi)？

超文本傳輸協議可以進行文字分割：超文本（Hypertext）、傳輸（Transfer）、協議（Protocol），它們之間的關系(xi)如下

按(an)照范圍的大小 協議 > 傳輸 > 超文本。下面就分(fen)別(bie)對這三(san)個名次做一個解釋。

什么是超文本

在互聯網(wang)早期(qi)的(de)時候，我(wo)們(men)輸入的(de)信息(xi)只能(neng)(neng)保存在本(ben)(ben)地，無法(fa)和(he)其他電(dian)腦進(jin)(jin)行交互。我(wo)們(men)保存的(de)信息(xi)通常(chang)都以文(wen)(wen)本(ben)(ben)即簡單字符的(de)形式存在，文(wen)(wen)本(ben)(ben)是一種能(neng)(neng)夠(gou)被計(ji)算(suan)機解析的(de)有意義的(de)二進(jin)(jin)制數(shu)據包。而隨著互聯網(wang)的(de)高速發展，兩臺電(dian)腦之(zhi)間能(neng)(neng)夠(gou)進(jin)(jin)行數(shu)據的(de)傳(chuan)輸后(hou)(hou)，人們(men)不滿足只能(neng)(neng)在兩臺電(dian)腦之(zhi)間傳(chuan)輸文(wen)(wen)字，還想要(yao)傳(chuan)輸圖片、音頻、視頻，甚至點擊文(wen)(wen)字或(huo)圖片能(neng)(neng)夠(gou)進(jin)(jin)行超鏈接的(de)跳轉(zhuan)，那么文(wen)(wen)本(ben)(ben)的(de)語義就被擴(kuo)大了，這種語義擴(kuo)大后(hou)(hou)的(de)文(wen)(wen)本(ben)(ben)就被稱為超文(wen)(wen)本(ben)(ben)(Hypertext)。

什么是傳輸

那么我們上面說到，兩臺計(ji)算(suan)機之間會形成(cheng)互(hu)聯關(guan)系進行通信，我們存儲的(de)(de)超文本(ben)會被解析成(cheng)為(wei)二(er)進制數(shu)據(ju)包，由(you)傳輸載體（例如同軸電纜，電話線，光纜）負責把(ba)二(er)進制數(shu)據(ju)包由(you)計(ji)算(suan)機終(zhong)端傳輸到另一個終(zhong)端的(de)(de)過(guo)程（對終(zhong)端的(de)(de)詳細解釋可以(yi)參(can)考(kao) 你說你懂(dong)互(hu)聯網，那這些你知(zhi)道么？這篇文章）稱為(wei)傳輸(transfer)。

通常我們(men)把傳輸(shu)數(shu)據(ju)包(bao)的一方(fang)稱(cheng)為請(qing)求(qiu)(qiu)方(fang)，把接到二進制數(shu)據(ju)包(bao)的一方(fang)稱(cheng)為應答方(fang)。請(qing)求(qiu)(qiu)方(fang)和應答方(fang)可以進行(xing)互(hu)換，請(qing)求(qiu)(qiu)方(fang)也可以作(zuo)為應答方(fang)接受數(shu)據(ju)，應答方(fang)也可以作(zuo)為請(qing)求(qiu)(qiu)方(fang)請(qing)求(qiu)(qiu)數(shu)據(ju)，它們(men)之間的關(guan)系如下

如圖所示(shi)，A 和 B 是兩個(ge)不同的(de)端系統(tong)，它們(men)之間可以作(zuo)(zuo)為信息交(jiao)(jiao)換(huan)的(de)載體存在，剛開始的(de)時(shi)候是 A 作(zuo)(zuo)為請求方請求與 B 交(jiao)(jiao)換(huan)信息，B 作(zuo)(zuo)為響(xiang)應(ying)的(de)一方提(ti)供信息；隨著(zhu)時(shi)間的(de)推移，B 也可以作(zuo)(zuo)為請求方請求 A 交(jiao)(jiao)換(huan)信息，那么(me) A 也可以作(zuo)(zuo)為響(xiang)應(ying)方響(xiang)應(ying) B 請求的(de)信息。

什么是協議

協(xie)議這(zhe)(zhe)個(ge)名詞不僅局限于(yu)互(hu)聯網范疇，也(ye)體現在(zai)日常生活中(zhong)，比(bi)如情侶雙(shuang)方(fang)約(yue)定好在(zai)哪個(ge)地點吃飯，這(zhe)(zhe)個(ge)約(yue)定也(ye)是(shi)一(yi)種協(xie)議，比(bi)如你應聘成功了，企業會和你簽訂勞動合(he)同(tong)，這(zhe)(zhe)種雙(shuang)方(fang)的(de)雇傭關系也(ye)是(shi)一(yi)種 協(xie)議。注(zhu)意自(zi)(zi)己一(yi)個(ge)人對自(zi)(zi)己的(de)約(yue)定不能成為協(xie)議，協(xie)議的(de)前提條件必須是(shi)多人約(yue)定。

那(nei)么(me)(me)網絡協議是什么(me)(me)呢？

網絡(luo)協議就是(shi)網絡(luo)中(zhong)(包括互聯網)傳遞、管理信息的一(yi)些規(gui)(gui)范。如(ru)同(tong)人與(yu)人之間相互交流(liu)是(shi)需要遵(zun)(zun)循一(yi)定的規(gui)(gui)矩一(yi)樣，計(ji)算機之間的相互通信需要共(gong)同(tong)遵(zun)(zun)守一(yi)定的規(gui)(gui)則，這些規(gui)(gui)則就稱為網絡(luo)協議。

沒有網(wang)絡協議(yi)的(de)互聯(lian)網(wang)是混亂的(de)，就和人(ren)類社會一樣，人(ren)不(bu)能想怎么(me)(me)(me)樣就怎么(me)(me)(me)樣，你的(de)行為約束(shu)是受(shou)到法律的(de)約束(shu)的(de)；那么(me)(me)(me)互聯(lian)網(wang)中的(de)端系統也不(bu)能自己想發(fa)(fa)什么(me)(me)(me)發(fa)(fa)什么(me)(me)(me)，也是需(xu)要受(shou)到通信協議(yi)約束(shu)的(de)。

那么我們就可以總結一下，什么是 HTTP？可以用下面這個經典的總結回答一下： HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規范

與 HTTP 有關的組件

隨著網(wang)絡世界演進(jin)，HTTP 協(xie)議(yi)已(yi)經幾乎(hu)成為不(bu)可替(ti)代的(de)一種協(xie)議(yi)，在(zai)了解了 HTTP 的(de)基本組(zu)成后，下面再來帶你進(jin)一步(bu)認識一下 HTTP 協(xie)議(yi)。

網絡模型

網絡是一個復雜的(de)系統，不僅包(bao)括大量的(de)應用程序、端系統、通信鏈路、分組交換機等(deng)，還有各(ge)種各(ge)樣的(de)協議組成，那么現(xian)在我們就來聊一下(xia)網絡中(zhong)的(de)協議層次。

為(wei)了給網(wang)絡(luo)協議的(de)(de)(de)設計(ji)提供一個(ge)結構(gou)，網(wang)絡(luo)設計(ji)者以分層(ceng)(ceng)(layer)的(de)(de)(de)方(fang)式(shi)組織協議，每個(ge)協議屬于層(ceng)(ceng)次模(mo)型之一。每一層(ceng)(ceng)都是向它(ta)的(de)(de)(de)上(shang)(shang)一層(ceng)(ceng)提供服務(service)，即(ji)所謂的(de)(de)(de)服務模(mo)型(service model)。每個(ge)分層(ceng)(ceng)中所有的(de)(de)(de)協議稱為(wei) 協議棧(protocol stack)。因特網(wang)的(de)(de)(de)協議棧由五個(ge)部分組成：物(wu)理層(ceng)(ceng)、鏈路層(ceng)(ceng)、網(wang)絡(luo)層(ceng)(ceng)、運輸層(ceng)(ceng)和應(ying)用層(ceng)(ceng)。我們采(cai)用自上(shang)(shang)而下(xia)的(de)(de)(de)方(fang)法研(yan)究其原理，也就是應(ying)用層(ceng)(ceng) -> 物(wu)理層(ceng)(ceng)的(de)(de)(de)方(fang)式(shi)。

應用層

應(ying)(ying)(ying)用(yong)(yong)(yong)層(ceng)(ceng)是網(wang)(wang)絡(luo)(luo)應(ying)(ying)(ying)用(yong)(yong)(yong)程(cheng)序和網(wang)(wang)絡(luo)(luo)協議(yi)存放(fang)的分層(ceng)(ceng)，因特網(wang)(wang)的應(ying)(ying)(ying)用(yong)(yong)(yong)層(ceng)(ceng)包括許多(duo)協議(yi)，例(li)如我們學 web 離(li)不開的 HTTP，電子郵件(jian)傳送協議(yi) SMTP、端系(xi)統(tong)(tong)文(wen)件(jian)上(shang)傳協議(yi) FTP、還有為(wei)我們進行域(yu)名解析的 DNS 協議(yi)。應(ying)(ying)(ying)用(yong)(yong)(yong)層(ceng)(ceng)協議(yi)分布在多(duo)個端系(xi)統(tong)(tong)上(shang)，一個端系(xi)統(tong)(tong)應(ying)(ying)(ying)用(yong)(yong)(yong)程(cheng)序與另(ling)外一個端系(xi)統(tong)(tong)應(ying)(ying)(ying)用(yong)(yong)(yong)程(cheng)序交換信息分組，我們把位于應(ying)(ying)(ying)用(yong)(yong)(yong)層(ceng)(ceng)的信息分組稱為(wei) 報文(wen)(message)。

運輸層

因特(te)網的(de)運輸層在應用程(cheng)(cheng)序斷點之間傳(chuan)送應用程(cheng)(cheng)序報(bao)文，在這一層主要(yao)有兩(liang)(liang)種傳(chuan)輸協議 TCP和 UDP，利用這兩(liang)(liang)者中的(de)任何一個都能夠(gou)傳(chuan)輸報(bao)文，不過(guo)這兩(liang)(liang)種協議有巨大的(de)不同。

TCP 向它的應用程序提供(gong)了面(mian)向連接的服務，它能夠控(kong)制(zhi)并確(que)認報(bao)文是(shi)否到達，并提供(gong)了擁(yong)塞機(ji)制(zhi)來(lai)控(kong)制(zhi)網絡傳輸，因此當網絡擁(yong)塞時，會抑(yi)制(zhi)其傳輸速率(lv)。

UDP 協議(yi)向它(ta)的應用程序提供了無連(lian)接服務。它(ta)不具備可靠性的特(te)征，沒有(you)流量控制，也沒有(you)擁(yong)塞控制。我們(men)把運輸層的分組稱為(wei) 報文段(segment)

網絡層

因特(te)網(wang)(wang)的(de)(de)網(wang)(wang)絡(luo)(luo)(luo)層(ceng)(ceng)負責將稱(cheng)為(wei) 數(shu)據報(datagram) 的(de)(de)網(wang)(wang)絡(luo)(luo)(luo)分層(ceng)(ceng)從一(yi)(yi)臺(tai)主(zhu)機移動(dong)到另一(yi)(yi)臺(tai)主(zhu)機。網(wang)(wang)絡(luo)(luo)(luo)層(ceng)(ceng)一(yi)(yi)個非(fei)常重(zhong)要的(de)(de)協(xie)(xie)(xie)議(yi)(yi)(yi)是 IP 協(xie)(xie)(xie)議(yi)(yi)(yi)，所有具有網(wang)(wang)絡(luo)(luo)(luo)層(ceng)(ceng)的(de)(de)因特(te)網(wang)(wang)組件都必須運行 IP 協(xie)(xie)(xie)議(yi)(yi)(yi)，IP 協(xie)(xie)(xie)議(yi)(yi)(yi)是一(yi)(yi)種網(wang)(wang)際(ji)協(xie)(xie)(xie)議(yi)(yi)(yi)，除了 IP 協(xie)(xie)(xie)議(yi)(yi)(yi)外，網(wang)(wang)絡(luo)(luo)(luo)層(ceng)(ceng)還包括一(yi)(yi)些其他網(wang)(wang)際(ji)協(xie)(xie)(xie)議(yi)(yi)(yi)和(he)路由選擇(ze)協(xie)(xie)(xie)議(yi)(yi)(yi)，一(yi)(yi)般(ban)把網(wang)(wang)絡(luo)(luo)(luo)層(ceng)(ceng)就(jiu)稱(cheng)為(wei) IP 層(ceng)(ceng)，由此可知(zhi) IP 協(xie)(xie)(xie)議(yi)(yi)(yi)的(de)(de)重(zhong)要性。

鏈路層

現在我們(men)有應用(yong)(yong)程序通信的(de)協(xie)議(yi)(yi)，有了(le)給應用(yong)(yong)程序提(ti)供運(yun)輸的(de)協(xie)議(yi)(yi)，還有了(le)用(yong)(yong)于(yu)約(yue)定(ding)發送(song)(song)位置的(de) IP 協(xie)議(yi)(yi)，那么如何(he)才能(neng)真(zhen)正的(de)發送(song)(song)數據(ju)呢？為了(le)將分組從一(yi)(yi)個(ge)節點（主(zhu)機或路由(you)器(qi)）運(yun)輸到另一(yi)(yi)個(ge)節點，網絡(luo)層(ceng)(ceng)必須依靠(kao)鏈(lian)(lian)路層(ceng)(ceng)提(ti)供服務(wu)。鏈(lian)(lian)路層(ceng)(ceng)的(de)例子包括以太(tai)網、WiFi 和電纜接入的(de) DOCSIS 協(xie)議(yi)(yi)，因為數據(ju)從源目的(de)地傳送(song)(song)通常需要經過幾條鏈(lian)(lian)路，一(yi)(yi)個(ge)數據(ju)包可(ke)能(neng)被沿途不同的(de)鏈(lian)(lian)路層(ceng)(ceng)協(xie)議(yi)(yi)處理，我們(men)把鏈(lian)(lian)路層(ceng)(ceng)的(de)分組稱為 幀(frame)

物理層

雖(sui)然(ran)鏈路層的(de)(de)(de)作(zuo)用(yong)是(shi)將幀從一(yi)個端系統運輸到另一(yi)個端系統，而物理(li)層的(de)(de)(de)作(zuo)用(yong)是(shi)將幀中(zhong)的(de)(de)(de)一(yi)個個 比特 從一(yi)個節(jie)點(dian)運輸到另一(yi)個節(jie)點(dian)，物理(li)層的(de)(de)(de)協議(yi)仍然(ran)使用(yong)鏈路層協議(yi)，這些協議(yi)與(yu)實際的(de)(de)(de)物理(li)傳輸介(jie)質有關，例如，以太網有很多物理(li)層協議(yi)：關于(yu)(yu)雙絞銅(tong)線、關于(yu)(yu)同(tong)軸電纜(lan)、關于(yu)(yu)光(guang)纖等等。

五層網絡協議的(de)示意圖(tu)如下

OSI 模型

我們(men)上面討(tao)論(lun)的(de)計(ji)算網(wang)絡協(xie)(xie)議模型不是唯一的(de) 協(xie)(xie)議棧，ISO（國際標準化組織(zhi)）提出來(lai)計(ji)算機(ji)網(wang)絡應該(gai)按照7層來(lai)組織(zhi)，那(nei)么7層網(wang)絡協(xie)(xie)議棧與5層的(de)區別在(zai)哪里？

從(cong)圖(tu)中可以(yi)一眼看出，OSI 要(yao)比上面的網(wang)絡模型多了 表示層(ceng) 和(he)(he)(he) 會話層(ceng)，其他層(ceng)基(ji)本(ben)一致。表示層(ceng)主要(yao)包括數據(ju)壓縮和(he)(he)(he)數據(ju)加密以(yi)及(ji)數據(ju)描述，數據(ju)描述使得應用程序不必(bi)擔心(xin)計算機內部存儲格式的問題，而會話層(ceng)提供了數據(ju)交換的定界和(he)(he)(he)同步功(gong)能，包括建立(li)檢查(cha)點和(he)(he)(he)恢復方案。

瀏覽器

就(jiu)如同(tong)各大(da)郵箱使(shi)(shi)用電子郵件傳送協(xie)議 SMTP 一樣，瀏(liu)覽器(qi)是使(shi)(shi)用 HTTP 協(xie)議的主要(yao)載體，說到瀏(liu)覽器(qi)，你(ni)能想起來(lai)幾種？是的，隨(sui)著網景(jing)大(da)戰結(jie)束后，瀏(liu)覽器(qi)迅(xun)速(su)發展，至(zhi)今已經(jing)出現過的瀏(liu)覽器(qi)主要(yao)有

瀏覽器正(zheng)式(shi)的名字叫做 Web Broser，顧名思義，就是檢索、查(cha)看互聯網上網頁資源的應用程序，名字里(li)的 Web，實(shi)際上指的就是 World Wide Web，也(ye)就是萬維網。

我們在(zai)地(di)址(zhi)欄(lan)輸入URL（即(ji)網址(zhi)），瀏(liu)覽(lan)器(qi)(qi)會向DNS（域名服(fu)務(wu)器(qi)(qi)，后面會說）提(ti)供網址(zhi)，由(you)它來完成 URL 到 IP 地(di)址(zhi)的映射(she)。然后將請求(qiu)你的請求(qiu)提(ti)交給(gei)具體的服(fu)務(wu)器(qi)(qi)，在(zai)由(you)服(fu)務(wu)器(qi)(qi)返回我們要的結果（以HTML編碼格式返回給(gei)瀏(liu)覽(lan)器(qi)(qi)），瀏(liu)覽(lan)器(qi)(qi)執行HTML編碼，將結果顯示(shi)在(zai)瀏(liu)覽(lan)器(qi)(qi)的正文。這就(jiu)是一(yi)個瀏(liu)覽(lan)器(qi)(qi)發起請求(qiu)和(he)接(jie)受響應的過程。

Web 服務器

Web 服務器(qi)的(de)(de)正(zheng)式名稱(cheng)叫做(zuo) Web Server，Web 服務器(qi)一般指的(de)(de)是網站(zhan)服務器(qi)，上面說到(dao)瀏覽(lan)器(qi)是 HTTP 請求的(de)(de)發起方(fang)(fang)，那么 Web 服務器(qi)就是 HTTP 請求的(de)(de)應答方(fang)(fang)，Web 服務器(qi)可(ke)以向瀏覽(lan)器(qi)等 Web 客戶端提供文檔，也(ye)可(ke)以放(fang)置網站(zhan)文件，讓全世界瀏覽(lan)；可(ke)以放(fang)置數據(ju)文件，讓全世界下載。目前最主流的(de)(de)三個(ge)Web服務器(qi)是Apache、 Nginx 、IIS。

CDN

CDN的(de)全稱是(shi)Content Delivery Network，即內(nei)容分(fen)發(fa)網(wang)(wang)絡(luo)，它(ta)應用了 HTTP 協議里(li)的(de)緩(huan)存(cun)和代理技術(shu)(shu)(shu)，代替(ti)源站響(xiang)應客(ke)戶端的(de)請求。CDN 是(shi)構建(jian)在現有網(wang)(wang)絡(luo)基礎之上的(de)網(wang)(wang)絡(luo)，它(ta)依靠部署在各地的(de)邊(bian)緣服務器，通(tong)過中心平臺(tai)的(de)負載均衡、內(nei)容分(fen)發(fa)、調(diao)度(du)等(deng)功能模塊，使用戶就近獲取所(suo)需內(nei)容，降低網(wang)(wang)絡(luo)擁塞，提高用戶訪問(wen)響(xiang)應速度(du)和命中率。CDN的(de)關鍵技術(shu)(shu)(shu)主(zhu)要有內(nei)容存(cun)儲和分(fen)發(fa)技術(shu)(shu)(shu)。

打比方(fang)說你要去亞馬(ma)遜上買書，之(zhi)前你只能通過購物網站購買后從美(mei)國發貨過海關等重重關卡送到(dao)(dao)你的家里，現在在中國建立一個亞馬(ma)遜分(fen)基地，你就不(bu)用通過美(mei)國進行郵寄(ji)，從中國就能把書盡快給你送到(dao)(dao)。

WAF

WAF 是一種(zhong) Web 應(ying)用程(cheng)序防(fang)護系統（Web Application Firewall，簡稱(cheng) WAF），它是一種(zhong)通(tong)過(guo)執行一系列針對HTTP / HTTPS的安全策略來專門為Web應(ying)用提(ti)供保(bao)護的一款產品(pin)，它是應(ying)用層面的防(fang)火墻，專門檢(jian)測 HTTP 流量，是防(fang)護 Web 應(ying)用的安全技術。

WAF 通常(chang)位于 Web 服務器之前，可(ke)以阻止如 SQL 注入、跨站(zhan)腳本(ben)等攻(gong)擊，目前應用較多的一個開源項目是 ModSecurity，它能夠完全集成進 Apache 或 Nginx。

WebService

WebService 是一種 Web 應用程序，WebService是一種跨編程語言和跨操作系統平臺的遠程調用技術。

Web Service 是一種由 W3C 定義的應用服務開發規范，使用 client-server 主從架構，通常使用 WSDL 定義服務接口，使用 HTTP 協議傳輸 XML 或 SOAP 消息，它是一個基于 Web（HTTP）的服務架構技術，既可(ke)(ke)以運行(xing)在(zai)(zai)內網(wang)，也(ye)可(ke)(ke)以在(zai)(zai)適(shi)當保護后(hou)運行(xing)在(zai)(zai)外網(wang)。

HTML

HTML 稱為超文本(ben)標(biao)(biao)記語(yu)言(yan)，是(shi)一(yi)種標(biao)(biao)識性的(de)語(yu)言(yan)。它包括一(yi)系列標(biao)(biao)簽(qian)．通過這些標(biao)(biao)簽(qian)可(ke)以將網絡上的(de)文檔格式統一(yi)，使分(fen)散(san)的(de) Internet 資源(yuan)連接為一(yi)個(ge)邏輯整(zheng)體。HTML 文本(ben)是(shi)由 HTML 命令組(zu)成的(de)描述性文本(ben)，HTML 命令可(ke)以說(shuo)明文字，圖(tu)形、動畫、聲音、表格、鏈(lian)接等。

Web 頁面構成

Web 頁(ye)面（Web page）也叫(jiao)做文(wen)檔，是(shi)由一個(ge)(ge)(ge)(ge)(ge)個(ge)(ge)(ge)(ge)(ge)對象組(zu)成的。一個(ge)(ge)(ge)(ge)(ge)對象(Objecy) 只是(shi)一個(ge)(ge)(ge)(ge)(ge)文(wen)件(jian)，比如(ru)一個(ge)(ge)(ge)(ge)(ge) HTML 文(wen)件(jian)、一個(ge)(ge)(ge)(ge)(ge) JPEG 圖形、一個(ge)(ge)(ge)(ge)(ge) Java 小(xiao)程(cheng)序或(huo)一個(ge)(ge)(ge)(ge)(ge)視頻(pin)片(pian)段，它們在(zai)網絡中可以(yi)通過 URL 地址尋址。多數的 Web 頁(ye)面含(han)有一個(ge)(ge)(ge)(ge)(ge) HTML 基本文(wen)件(jian) 以(yi)及幾個(ge)(ge)(ge)(ge)(ge)引用(yong)對象。

舉(ju)個(ge)(ge)例(li)子，如果一個(ge)(ge) Web 頁面包(bao)含(han) HTML 文件(jian)(jian)和(he)5個(ge)(ge) JPEG 圖(tu)形，那么這個(ge)(ge) Web 頁面就有6個(ge)(ge)對象(xiang)：一個(ge)(ge) HTML 文件(jian)(jian)和(he)5個(ge)(ge) JPEG 圖(tu)形。HTML 基本(ben)文件(jian)(jian)通過(guo) URL 地址引用(yong)頁面中的其(qi)他(ta)對象(xiang)。

與 HTTP 有關的協議

在互聯網中，任何協議都不會單獨的(de)(de)完成信息交換，HTTP 也一樣(yang)。雖然(ran) HTTP 屬于應用層(ceng)(ceng)的(de)(de)協議，但是(shi)它(ta)仍然(ran)需要其他層(ceng)(ceng)次(ci)協議的(de)(de)配合完成信息的(de)(de)交換，那么在完成一次(ci) HTTP 請求和響(xiang)應的(de)(de)過程中，需要哪些(xie)協議的(de)(de)配合呢？一起(qi)來看一下

TCP/IP

TCP/IP 協議(yi)(yi)(yi)你一定(ding)聽過，TCP/IP 我們一般稱(cheng)之為協議(yi)(yi)(yi)簇，什么意思呢？就(jiu)是(shi) TCP/IP 協議(yi)(yi)(yi)簇中(zhong)不僅僅只有 TCP 協議(yi)(yi)(yi)和 IP 協議(yi)(yi)(yi)，它(ta)是(shi)一系列網絡通信協議(yi)(yi)(yi)的統稱(cheng)。而其中(zhong)最(zui)核心(xin)的兩個(ge)協議(yi)(yi)(yi)就(jiu)是(shi) TCP / IP 協議(yi)(yi)(yi)，其他的還有 UDP、ICMP、ARP 等(deng)等(deng)，共(gong)同構成了一個(ge)復(fu)雜但有層次的協議(yi)(yi)(yi)棧。

TCP 協(xie)(xie)議的全稱是(shi) Transmission Control Protocol 的縮寫，意思是(shi)傳輸控制協(xie)(xie)議，HTTP 使用 TCP 作為通(tong)信(xin)協(xie)(xie)議，這是(shi)因為 TCP 是(shi)一(yi)種可靠(kao)的協(xie)(xie)議，而可靠(kao)能保證數(shu)據(ju)不丟(diu)失。

IP 協(xie)議的(de)(de)全(quan)稱是(shi) Internet Protocol 的(de)(de)縮寫，它主要解(jie)決的(de)(de)是(shi)通(tong)(tong)信(xin)雙方尋址(zhi)(zhi)的(de)(de)問題。IP 協(xie)議使用 IP 地址(zhi)(zhi) 來標識互聯(lian)網上的(de)(de)每一(yi)臺計算機，可以把 IP 地址(zhi)(zhi)想象成為你手機的(de)(de)電話(hua)號碼，你要與他人通(tong)(tong)話(hua)必(bi)須(xu)先要知道他人的(de)(de)手機號碼，計算機網絡中信(xin)息交(jiao)換必(bi)須(xu)先要知道對(dui)方的(de)(de) IP 地址(zhi)(zhi)。（關于 TCP 和 IP 更多的(de)(de)討論我(wo)們會在后面詳(xiang)解(jie)）

DNS

你有沒(mei)有想過為什么你可以通過鍵(jian)入 www.google.com 就能(neng)夠(gou)獲取你想要的網(wang)(wang)站？我們上面說(shuo)到，計算機網(wang)(wang)絡中的每個端系統都有一個 IP 地(di)址(zhi)存在，而把(ba) IP 地(di)址(zhi)轉換為便于人類記憶(yi)的協議就是(shi) DNS 協議。

DNS 的(de)全稱是域(yu)名系統(tong)（Domain Name System，縮寫：DNS），它作為將域(yu)名和 IP 地址相互映射的(de)一個分布(bu)式數(shu)據庫(ku)，能夠(gou)使人(ren)更方便地訪問(wen)互聯(lian)網。

URI / URL

我們上面提到，你(ni)可(ke)以(yi)通過輸(shu)入(ru) www.google.com 地址(zhi)來(lai)訪問谷(gu)歌的(de)官網(wang)，那(nei)么(me)(me)這(zhe)個地址(zhi)有(you)什么(me)(me)規(gui)定嗎？我怎(zen)么(me)(me)輸(shu)都可(ke)以(yi)？AAA.BBB.CCC 是不是也行？當然不是的(de)，你(ni)輸(shu)入(ru)的(de)地址(zhi)格(ge)式必須要滿足 URI 的(de)規(gui)范。

URI的全(quan)稱是(shi)（Uniform Resource Identifier），中(zhong)文名稱是(shi)統一資源標識符(fu)，使用它就能夠唯一地標記互聯網上(shang)資源。

URL的全稱(cheng)(cheng)是（Uniform Resource Locator），中文名稱(cheng)(cheng)是統一資(zi)源(yuan)定位符，也(ye)就是我們俗稱(cheng)(cheng)的網址，它(ta)實際上是 URI 的一個(ge)子(zi)集。

URI 不僅包(bao)括 URL，還(huan)包(bao)括 URN（統一資(zi)源(yuan)名稱），它們之(zhi)間的關系如下

HTTPS

HTTP 一般是明文傳輸，很容易被攻擊者竊取重要信息，鑒于此，HTTPS 應運而生。HTTPS 的全稱為 （Hyper Text Transfer Protocol over SecureSocket Layer），全稱有點長，HTTPS 和 HTTP 有很大的不同在于 HTTPS 是以安全為目標的 HTTP 通道，在 HTTP 的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性。HTTPS 在 HTTP 的基礎上增加了 SSL 層，也就是說 HTTPS = HTTP + SSL。（這塊我(wo)們后面(mian)也(ye)會(hui)詳談(tan) HTTPS）

HTTP 請求響應過程

你是(shi)不(bu)是(shi)很好奇，當你在瀏覽器中輸(shu)入網(wang)址(zhi)后，到底發(fa)生了什么事情(qing)？你想要的內容是(shi)如何展現出來(lai)的？讓我(wo)們通過一個例子來(lai)探討一下，我(wo)們假設訪問的 URL 地址(zhi)為 //www.someSchool.edu/someDepartment/home.index，當我(wo)們輸(shu)入網(wang)址(zhi)并點(dian)擊回車時，瀏覽器內部會進(jin)行(xing)如下操作

• DNS服務器會首先進行域名的映射，找到訪問www.someSchool.edu所在的地址，然后HTTP 客戶端進程在 80 端口發起一個到服務器 www.someSchool.edu 的 TCP 連接（80 端口是 HTTP 的默認端口）。在客戶和服務器進程中都會有一個套接字與其相連。
• HTTP 客戶端通過它的套接字向服務器發送一個 HTTP 請求報文。該報文中包含了路徑 someDepartment/home.index 的資源，我們后面會詳細討論 HTTP 請求報文。
• HTTP 服務器通過它的套接字接受該報文，進行請求的解析工作，并從其存儲器(RAM 或磁盤)中檢索出對象 www.someSchool.edu/someDepartment/home.index，然后把檢索出來的對象進行封裝，封裝到 HTTP 響應報文中，并通過套接字向客戶進行發送。
• HTTP 服務器隨即通知 TCP 斷開 TCP 連接，實際上是需要等到客戶接受完響應報文后才會斷開 TCP 連接。
• HTTP 客戶端接受完響應報文后，TCP 連接會關閉。HTTP 客戶端從響應中提取出報文中是一個 HTML 響應文件，并檢查該 HTML 文件，然后循環檢查報文中其他內部對象。
• 檢查完成后，HTTP 客戶端會把對應的資源通過顯示器呈現給用戶。

至此，鍵入網址再按下回(hui)車(che)的(de)(de)(de)全過程(cheng)就結束了。上述(shu)過程(cheng)描述(shu)的(de)(de)(de)是一種(zhong)簡單的(de)(de)(de)請求-響應全過程(cheng)，真實的(de)(de)(de)請求-響應情況可能(neng)要比上面描述(shu)的(de)(de)(de)過程(cheng)復雜很(hen)多。

HTTP 請求特征

從上面整個過程中我們可以(yi)總結(jie)出 HTTP 進行分組(zu)傳輸是具(ju)有以(yi)下特征(zheng)

• 支持客戶-服務器模式
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有 GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于 HTTP 協議簡單，使得 HTTP 服務器的程序規模小，因而通信速度很快。
• 靈活：HTTP 允許傳輸任意類型的數據對象。正在傳輸的類型由 Content-Type 加以標記。
• 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
• 無狀態：HTTP 協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

詳解 HTTP 報文

我們上面描述了一下 HTTP 的請求響應過程，流程比較簡單，但是凡事就怕認真，你這一認真，就能拓展出很多東西，比如 HTTP 報文是什么樣的，它的組成格式是什么？ 下面就來探討一下

HTTP 協議主要由三大部分組成(cheng)：

• 起始行（start line）：描述請求或響應的基本信息；
• 頭部字段（header）：使用 key-value 形式更詳細地說明報文；
• 消息正文（entity）：實際傳輸的數據，它不一定是純文本，可以是圖片、視頻等二進制數據。

其中起始行(xing)和(he)頭(tou)部字(zi)段并成為(wei) 請求(qiu)頭(tou) 或者 響(xiang)應頭(tou)，統稱(cheng)為(wei) Header；消(xiao)息(xi)正文(wen)也叫做實體(ti)，稱(cheng)為(wei) body。HTTP 協議規定每次發送的(de)報文(wen)必(bi)須要有(you)(you) Header，但是(shi)可(ke)以沒有(you)(you) body，也就是(shi)說頭(tou)信息(xi)是(shi)必(bi)須的(de)，實體(ti)信息(xi)可(ke)以沒有(you)(you)。而且在 header 和(he) body 之間必(bi)須要有(you)(you)一(yi)(yi)個空行(xing)（CRLF），如果用一(yi)(yi)幅圖來表示一(yi)(yi)下(xia)的(de)話，我覺得應該是(shi)下(xia)面這(zhe)樣

我們使用上(shang)面的那(nei)個例子來看(kan)一(yi)下(xia) http 的請(qing)求(qiu)報文

如圖，這是(shi) //www.someSchool.edu/someDepartment/home.index 請(qing)求(qiu)的(de)請(qing)求(qiu)頭，通(tong)過觀察(cha)這個 HTTP 報(bao)文我(wo)們就能夠(gou)學到(dao)(dao)很多(duo)東西(xi)，首先，我(wo)們看到(dao)(dao)報(bao)文是(shi)用普通(tong) ASCII 文本(ben)書(shu)寫(xie)的(de)，這樣保證人能夠(gou)可以看懂。然后(hou)，我(wo)們可以看到(dao)(dao)每一行(xing)和下一行(xing)之間都(dou)會有換(huan)行(xing)，而且最后(hou)一行(xing)（請(qing)求(qiu)頭部后(hou)）再加(jia)上一個回(hui)車換(huan)行(xing)符。

每個報文的起始行都是由三個字段組成：方法、URL 字段和 HTTP 版本字段。

HTTP 請求方法

HTTP 請(qing)求(qiu)方法一般分(fen)為 8 種，它們分(fen)別是(shi)

• GET 獲取資源，GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析后返回響應內容。也就是說，如果請求的資源是文本，那就保持原樣返回；
• POST 傳輸實體，雖然 GET 方法也可以傳輸主體信息，但是便于區分，我們一般不用 GET 傳輸實體信息，反而使用 POST 傳輸實體信息，
• PUT 傳輸文件，PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求 URI 指定的位置。 但是，鑒于 HTTP 的 PUT 方法自身不帶驗證機制，任何人都可以上傳文件 , 存在安全性問題，因此一般的 W eb 網站不使用該方法。若配合 W eb 應用程序的驗證機制，或架構設計采用REST（REpresentational State Transfer，表征狀態轉移）標準的同類 Web 網站，就可能會開放使用 PUT 方法。
• HEAD 獲得響應首部，HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用于確認 URI 的有效性及資源更新的日期時間等。
• DELETE 刪除文件，DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。
• OPTIONS 詢問支持的方法，OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。
• TRACE 追蹤路徑，TRACE 方法是讓 Web 服務器端將之前的請求通信環回給客戶端的方法。
• CONNECT 要求用隧道協議連接代理，CONNECT 方法要求在與代理服務器通信時建立隧道，實現用隧道協議進行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容加 密后經網絡隧道傳輸。

我們一(yi)般最常用(yong)的(de)方(fang)法(fa)也就是 GET 方(fang)法(fa)和 POST 方(fang)法(fa)，其他方(fang)法(fa)暫時了解即可。下面是 HTTP1.0 和 HTTP1.1 支持的(de)方(fang)法(fa)清單

HTTP 請求 URL

HTTP 協議使用 URI 定位(wei)互(hu)聯網上(shang)的(de)(de)資源(yuan)(yuan)。正(zheng)(zheng)是因(yin)為 URI 的(de)(de)特(te)定功能，在(zai)互(hu)聯網上(shang)任(ren)意位(wei)置的(de)(de)資源(yuan)(yuan)都能訪問到(dao)。URL 帶有(you)請(qing)求對(dui)象的(de)(de)標識符。在(zai)上(shang)面的(de)(de)例子中，瀏覽器(qi)正(zheng)(zheng)在(zai)請(qing)求對(dui)象 /somedir/page.html 的(de)(de)資源(yuan)(yuan)。

我(wo)們再通過(guo)一(yi)(yi)個(ge)完整(zheng)的(de)域名(ming)解(jie)析一(yi)(yi)下 URL

比如 //www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 這個 URL 比較繁瑣了吧，你把這個 URL 搞(gao)懂了其他的 URL 也就不成問題了。

首先出(chu)場的(de)是 http

//告訴(su)瀏(liu)覽器使(shi)(shi)用(yong)何種協議(yi)。對(dui)于(yu)大部分(fen) Web 資源，通常使(shi)(shi)用(yong) HTTP 協議(yi)或其安全版(ban)本(ben)，HTTPS 協議(yi)。另(ling)外(wai)，瀏(liu)覽器也(ye)知道如(ru)何處理(li)其他協議(yi)。例(li)如(ru)， mailto: 協議(yi)指示(shi)瀏(liu)覽器打開郵(you)件客戶(hu)端；ftp:協議(yi)指示(shi)瀏(liu)覽器處理(li)文(wen)件傳輸(shu)。

第二(er)個出(chu)場的(de)是 主機

www.example.com 既(ji)是一(yi)個域名，也(ye)代表管理該(gai)域名的機構。它指示了需要(yao)向網絡上(shang)的哪一(yi)臺主機發起請(qing)求。當然(ran)，也(ye)可以直接(jie)向主機的 IP address 地址發起請(qing)求。但(dan)直接(jie)使用 IP 地址的場(chang)景并不常(chang)見。

第(di)三個出(chu)場的是 端(duan)口

我們前面說到(dao)，兩個(ge)主(zhu)機之(zhi)間(jian)要(yao)發起 TCP 連(lian)接需要(yao)兩個(ge)條件，主(zhu)機 + 端口。它表示用于訪(fang)問 Web 服務器(qi)上資(zi)源的(de)入口。如果訪(fang)問的(de)該 Web 服務器(qi)使(shi)用HTTP協議的(de)標準端口（HTTP為80，HTTPS為443）授予(yu)對其資(zi)源的(de)訪(fang)問權限，則通(tong)常省略此部(bu)(bu)分。否則端口就是 URI 必須的(de)部(bu)(bu)分。

上面(mian)是請(qing)求 URL 所必(bi)須包含的(de)部分，下面(mian)就是 URL 具體請(qing)求資源(yuan)路徑

第四個出場的是 路徑

/path/to/myfile.html 是 Web 服(fu)務(wu)器(qi)上(shang)資源的路徑(jing)。以端口后(hou)面的第一個(ge) / 開(kai)始(shi)，到 ? 號之前結束，中(zhong)間的 每一個(ge)/ 都代表了層級（上(shang)下級）關(guan)系。這個(ge) URL 的請求資源是一個(ge) html 頁(ye)面。

緊跟著路徑后面的是 查(cha)詢參數

?key1=value1&key2=value2 是(shi)(shi)(shi)(shi)提供給(gei) Web 服務(wu)器(qi)的額外參數。如果(guo)是(shi)(shi)(shi)(shi) GET 請求，一般帶有(you)請求 URL 參數，如果(guo)是(shi)(shi)(shi)(shi) POST 請求，則不(bu)會在(zai)路徑后(hou)面直接加參數。這些參數是(shi)(shi)(shi)(shi)用 & 符號(hao)分隔的鍵/值對列表(biao)。key1 = value1 是(shi)(shi)(shi)(shi)第(di)一對，key2 = value2 是(shi)(shi)(shi)(shi)第(di)二對參數

緊跟著參數的是錨點

#SomewhereInTheDocument 是(shi)資源本身(shen)的(de)某一部(bu)分的(de)一個(ge)錨(mao)點(dian)。錨(mao)點(dian)代(dai)表(biao)資源內(nei)的(de)一種(zhong)“書(shu)簽”，它給予瀏覽(lan)器(qi)顯示位于該“加書(shu)簽”點(dian)的(de)內(nei)容的(de)指示。 例如，在(zai)HTML文檔上，瀏覽(lan)器(qi)將滾動到定義(yi)錨(mao)點(dian)的(de)那(nei)個(ge)點(dian)上；在(zai)視頻或音頻文檔上，瀏覽(lan)器(qi)將轉到錨(mao)點(dian)代(dai)表(biao)的(de)那(nei)個(ge)時間。值(zhi)得注意的(de)是(shi) # 號(hao)后面的(de)部(bu)分，也稱(cheng)為片(pian)段標識(shi)符，永遠不(bu)會(hui)與請求一起(qi)發(fa)送(song)到服務器(qi)。

HTTP 版本

表示(shi)報文使用(yong)的 HTTP 協(xie)議版本。

請求頭部

這部分內容只是大致介紹一下，內容較多，后面會再以一篇文章詳述

在表述完了起始行之后我(wo)們(men)再(zai)來(lai)看一(yi)下(xia)請求(qiu)頭部(bu)，現在我(wo)們(men)向上找(zhao)，找(zhao)到//www.someSchool.edu/someDepartment/home.index，來(lai)看一(yi)下(xia)它的請求(qiu)頭部(bu)

Host: www.someschool.eduConnection: closeUser-agent: Mozilla/5.0Accept-language: fr復制代碼

這個請求(qiu)頭(tou)信息(xi)比較(jiao)少，首先 Host 表示的(de)(de)是(shi)對(dui)象(xiang)所在的(de)(de)主機。你也許認(ren)為這個 Host 是(shi)不需(xu)要(yao)(yao)的(de)(de)，因為 URL 不是(shi)已經指(zhi)明(ming)了(le)請求(qiu)對(dui)象(xiang)的(de)(de)路徑了(le)嗎？這個首部行(xing)提供(gong)的(de)(de)信息(xi)是(shi) Web 代(dai)理(li)高速緩存所需(xu)要(yao)(yao)的(de)(de)。Connection: close 表示的(de)(de)是(shi)瀏(liu)(liu)覽器(qi)需(xu)要(yao)(yao)告(gao)訴(su)服(fu)務器(qi)使(shi)用的(de)(de)是(shi)非持久(jiu)連接(jie)(jie)。它要(yao)(yao)求(qiu)服(fu)務器(qi)在發送完響應的(de)(de)對(dui)象(xiang)后就關閉連接(jie)(jie)。User-agent: 這是(shi)請求(qiu)頭(tou)用來告(gao)訴(su) Web 服(fu)務器(qi)，瀏(liu)(liu)覽器(qi)使(shi)用的(de)(de)類型(xing)是(shi) Mozilla/5.0，即 Firefox 瀏(liu)(liu)覽器(qi)。Accept-language 告(gao)訴(su) Web 服(fu)務器(qi)，瀏(liu)(liu)覽器(qi)想要(yao)(yao)得到對(dui)象(xiang)的(de)(de)法語版本，前提是(shi)服(fu)務器(qi)需(xu)要(yao)(yao)支持法語類型(xing)，否則將會發送服(fu)務器(qi)的(de)(de)默認(ren)版本。下面(mian)我們針對(dui)主要(yao)(yao)的(de)(de)實體字段進行(xing)介紹（具體的(de)(de)可以參考(kao) developer.mozilla.org/zh-CN/docs/… MDN 官(guan)網學習）

HTTP 的請求(qiu)標頭(tou)分為四(si)種： 通用標頭(tou)、請求(qiu)標頭(tou)、響應標頭(tou) 和 實體(ti)標頭(tou)，依次來進行詳解。

通用標頭

通用標頭主(zhu)要有三個(ge)，分別是 Date、Cache-Control 和 Connection

Date

Date 是一個通(tong)用標頭，它(ta)可以出(chu)現在(zai)請求標頭和(he)響(xiang)應標頭中，它(ta)的基(ji)本(ben)表示如下

Date: Wed, 21 Oct 2015 07:28:00 GMT 復制代碼

表示的是(shi)格林威(wei)治標準時間，這個(ge)時間要比北京時間慢八個(ge)小時

Cache-Control

Cache-Control 是(shi)(shi)一個通用標(biao)頭(tou)，他(ta)可以出現在請求標(biao)頭(tou)和(he)響應標(biao)頭(tou)中，Cache-Control 的(de)種類(lei)(lei)比(bi)較多，雖(sui)然說這是(shi)(shi)一個通用標(biao)頭(tou)，但是(shi)(shi)又一些特性是(shi)(shi)請求標(biao)頭(tou)具有的(de)，有一些是(shi)(shi)響應標(biao)頭(tou)才有的(de)。主(zhu)要大類(lei)(lei)有 可緩存性、閾值(zhi)性、 重新驗證(zheng)并重新加載 和(he)其他(ta)特性

可緩(huan)存性是(shi)唯一響(xiang)(xiang)應(ying)標頭才(cai)具有的特性，我們(men)會在響(xiang)(xiang)應(ying)標頭中詳述。

閾值(zhi)性，這個(ge)我翻(fan)譯可能(neng)不準確，它(ta)的(de)原英文是 Expiration，我是根(gen)據它(ta)的(de)值(zhi)來翻(fan)譯的(de)，你看到這些值(zhi)可能(neng)會覺(jue)得我翻(fan)譯的(de)有(you)點(dian)道理

• max-age: 資源被認為仍然有效的最長時間，與 Expires 不同，這個請求是相對于 request標頭的時間，而 Expires 是相對于響應標頭。（請求標頭）
• s-maxage: 重寫了 max-age 和 Expires 請求頭，僅僅適用于共享緩存，被私有緩存所忽略（這塊不理解，看完響應頭的 Cache-Control 再進行理解）（請求標頭）
• max-stale：表示客戶端將接受的最大響應時間，以秒為單位。（響應標頭）
• min-fresh: 表示客戶端希望響應在指定的最小時間內有效。（響應標頭）

Connection

Connection 決定當前事務（一(yi)次三次握手和四次揮手）完成(cheng)后，是(shi)(shi)否(fou)會關閉網絡連(lian)接。Connection 有兩種(zhong)，一(yi)種(zhong)是(shi)(shi)持久性連(lian)接，即一(yi)次事務完成(cheng)后不關閉網絡連(lian)接

Connection: keep-alive復制代碼

另一種是非持(chi)久(jiu)性連接(jie)，即一次事務(wu)完成(cheng)后關(guan)閉網絡連接(jie)

Connection: close復制代碼

HTTP1.1 其(qi)他通(tong)用標頭如(ru)下

實體標頭

實(shi)體(ti)(ti)標頭是描述(shu)消息正(zheng)文(wen)內容的 HTTP 標頭。實(shi)體(ti)(ti)標頭用于 HTTP 請求和(he)響應中。頭部Content-Length、 Content-Language、 Content-Encoding 是實(shi)體(ti)(ti)頭。

• Content-Length 實體報頭指示實體主體的大小，以字節為單位，發送到接收方。
• Content-Language 實體報頭描述了客戶端或者服務端能夠接受的語言，例如

Content-Language: de-DEContent-Language: en-USContent-Language: de-DE, en-CA復制代碼

• Content-Encoding 這又是一個比較麻煩的屬性，這個實體報頭用來壓縮媒體類型。Content-Encoding 指示對實體應用了何種編碼。 常見的內容編碼有這幾種： gzip、compress、deflate、identity ，這個屬性可以應用在請求報文和響應報文中

Accept-Encoding: gzip, deflate //請求頭Content-Encoding: gzip  //響應頭復制代碼

下面(mian)是一些實體標(biao)頭字段

請求標頭

上面給出的例子(zi)請求報文的屬性(xing)比較少，下面給出一(yi)個 MDN 官(guan)網的例子(zi)

GET /home.html HTTP/1.1Host: developer.mozilla.orgUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflate, brReferer: //developer.mozilla.org/testpage.htmlConnection: keep-aliveUpgrade-Insecure-Requests: 1If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMTIf-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"Cache-Control: max-age=0 復制代碼

Host

Host 請(qing)求(qiu)頭指明了(le)服(fu)(fu)務(wu)(wu)器(qi)的(de)域名（對(dui)于虛擬(ni)主機來說），以及（可選的(de)）服(fu)(fu)務(wu)(wu)器(qi)監聽(ting)的(de)TCP端(duan)(duan)口號。如果沒有給定端(duan)(duan)口號，會自動(dong)使(shi)用被請(qing)求(qiu)服(fu)(fu)務(wu)(wu)的(de)默認端(duan)(duan)口（比如請(qing)求(qiu)一(yi)個 HTTP 的(de) URL 會自動(dong)使(shi)用80作為(wei)端(duan)(duan)口）。

Host: developer.mozilla.org復制代碼

上(shang)面的 Accpet、 Accept-Language、Accept-Encoding 都是屬于內容協商(shang)的請求標頭，我們(men)會在下面說明(ming)

Referer

HTTP Referer 屬性是請(qing)(qing)求(qiu)標(biao)頭(tou)的(de)一(yi)(yi)部分，當瀏覽(lan)器(qi)(qi)(qi)向(xiang) web 服務器(qi)(qi)(qi)發送請(qing)(qing)求(qiu)的(de)時(shi)候(hou)，一(yi)(yi)般會帶上 Referer，告(gao)訴(su)服務器(qi)(qi)(qi)該網(wang)頁是從哪個頁面鏈接(jie)過來的(de)，服務器(qi)(qi)(qi)因此可以獲得一(yi)(yi)些信息用(yong)于處理。

Referer: //developer.mozilla.org/testpage.html復制代碼

Upgrade-Insecure-Requests

Upgrade-Insecure-Requests 是一個請求標頭，用來向(xiang)服(fu)務器端發送信號，表示(shi)客戶端優先選(xuan)擇加密及帶有身份驗證的響應(ying)。

Upgrade-Insecure-Requests: 1復制代碼

If-Modified-Since

HTTP 的 If-Modified-Since 使其成為條(tiao)件(jian)請求：

• 返回200，只有在給定日期的最后一次修改資源后，服務器才會以200狀態發送回請求的資源。
• 如果請求從開始以來沒有被修改過，響應會返回304并且沒有任何響應體

If-Modified-Since 通常會與 If-None-Match 搭配使用，If-Modified-Since 用于(yu)確(que)認代理或客(ke)戶(hu)端擁(yong)有的本(ben)地資源的有效性。獲取資源的更新(xin)日(ri)期時間，可通過確(que)認首(shou)部字段(duan) Last-Modified 來確(que)定。

大白話說就是如(ru)(ru)果(guo)(guo)在 Last-Modified 之后更(geng)(geng)新了服務器資源(yuan)，那么服務器會響應200，如(ru)(ru)果(guo)(guo)在 Last-Modified 之后沒有更(geng)(geng)新過資源(yuan)，則返回(hui) 304。

If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT復制代碼

If-None-Match

If-None-Match HTTP請(qing)(qing)求(qiu)標頭使請(qing)(qing)求(qiu)成為條(tiao)件請(qing)(qing)求(qiu)。 對于 GET 和 HEAD 方法，僅當(dang)服務器沒有與給定資源匹(pi)配的(de) ETag 時(shi)，服務器才(cai)(cai)會(hui)(hui)以200狀態發(fa)送回(hui)請(qing)(qing)求(qiu)的(de)資源。 對于其他方法，僅當(dang)最(zui)終(zhong)現有資源的(de)ETag與列(lie)出的(de)任何值都不匹(pi)配時(shi)，才(cai)(cai)會(hui)(hui)處理(li)請(qing)(qing)求(qiu)。

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"復制代碼

ETag 屬于響應標(biao)頭(tou)，后面進(jin)行介紹。

內容協商

內(nei)容(rong)協商機制(zhi)是指(zhi)客(ke)戶端和服務器端就(jiu)響應的(de)資(zi)(zi)源(yuan)內(nei)容(rong)進行交涉，然后(hou)提供給客(ke)戶端最為(wei)適合的(de)資(zi)(zi)源(yuan)。內(nei)容(rong)協商會以響應資(zi)(zi)源(yuan)的(de)語言、字符集、編(bian)碼(ma)方式(shi)等作為(wei)判(pan)斷(duan)的(de)標準。

內容協商主(zhu)要(yao)有以下3種(zhong)類(lei)型：

• 服務器驅動協商（Server-driven Negotiation）

這種協商(shang)方式是由服務器(qi)端進行內容協商(shang)。服務器(qi)端會根據(ju)請求首(shou)部(bu)字段進行自動(dong)處理

• 客戶端驅動協商（Agent-driven Negotiation）

這種協商方(fang)式是由(you)客戶端(duan)來(lai)進(jin)行內容協商。

• 透明協商（Transparent Negotiation）

是服(fu)務器驅動(dong)和客戶端(duan)驅動(dong)的(de)結(jie)合(he)體，是由服(fu)務器端(duan)和客戶端(duan)各自進行內容協(xie)商(shang)的(de)一種(zhong)方(fang)法。

內容協商的分類有很多種，主要的幾種類型是 Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。

Accept

接受請求 HTTP 標頭會通告(gao)客戶端其能夠理解的 MIME 類(lei)型

那么什么是 MIME 類型呢？在回答這(zhe)個問題(ti)前你應該先了解(jie)一(yi)下什么是 MIME

MIME: MIME (Multipurpose Internet Mail Extensions) 是(shi)描述(shu)消息內容類型的(de)因特網標(biao)準。MIME 消息能包含文(wen)本、圖(tu)像、音頻、視頻以及(ji)其他應用程序專用的(de)數(shu)據。

也(ye)就(jiu)是說，MIME 類型其實(shi)就(jiu)是一系列(lie)消息內(nei)容類型的集合。那么 MIME 類型都有哪些呢？

文本文件(jian)： text/html、text/plain、text/css、application/xhtml+xml、application/xml

圖片文件： image/jpeg、image/gif、image/png

視頻文(wen)件： video/mpeg、video/quicktime

應用程序二進制文件： application/octet-stream、application/zip

比如，如果(guo)瀏(liu)覽器不(bu)支持 PNG 圖片的顯示，那 Accept 就不(bu)指(zhi)定(ding)image/png，而指(zhi)定(ding)可處理的 image/gif 和 image/jpeg 等圖片類型。

一般 MIME 類型也會和 q 這個屬性(xing)一起使用(yong)，q 是什么？q 表(biao)示的是權重，來看一個例子

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8復制代碼

這是什么意思呢？若想要給顯示的媒體類型增加優先級，則使用 q= 來額外表(biao)示(shi)(shi)權重值，沒有顯示(shi)(shi)權重的時候默認值是(shi)1.0 ，我(wo)給(gei)你列個表(biao)格你就明白了(le)

q MIME 1.0 text/html 1.0 application/xhtml+xml 0.9 application/xml 0.8 * / *

也就是說(shuo)，這是一個放置順序，權(quan)重高(gao)的在前，低的在后，application/xml;q=0.9 是不(bu)可分割的整體。

Accept-Charset

accept-charset 屬性規定(ding)服務(wu)器處(chu)理(li)表(biao)單數據所接受的(de)字符集。

accept-charset 屬性允許您指定(ding)一系(xi)列(lie)字符集，服(fu)務(wu)器必須(xu)支持這些字符集，從而(er)得(de)以正確解釋表單中的數據。

該(gai)屬性(xing)的(de)值是用(yong)引號(hao)包含字符(fu)集名稱列(lie)表(biao)。如果可接受(shou)字符(fu)集與用(yong)戶所使用(yong)的(de)字符(fu)即不相匹配的(de)話，瀏覽器可以(yi)選擇忽略表(biao)單或是將該(gai)表(biao)單區(qu)別對待。

此屬性的默認值(zhi)是 unknown，表(biao)示表(biao)單(dan)的字符(fu)集(ji)與包(bao)含表(biao)單(dan)的文檔的字符(fu)集(ji)相同(tong)。

常用(yong)的字符(fu)(fu)集有： UTF-8 - Unicode 字符(fu)(fu)編碼(ma) ； ISO-8859-1 - 拉丁字母表的字符(fu)(fu)編碼(ma)

Accept-Language

首(shou)部(bu)字段 Accept-Language 用(yong)來(lai)告(gao)知服務器用(yong)戶代理能(neng)夠處理的(de)(de)自(zi)(zi)然語(yu)(yu)言(yan)集（指中文或英文等），以及(ji)自(zi)(zi)然語(yu)(yu)言(yan)集的(de)(de)相對優先級(ji)。可一次指定(ding)多種自(zi)(zi)然語(yu)(yu)言(yan)集。 和(he) Accept 首(shou)部(bu)字段一樣(yang)，按權重值 q來(lai)表(biao)示相對優先級(ji)。

Accept-Language: en-US,en;q=0.5復制代碼

請求標頭(tou)我們大概就介紹這幾種(zhong)，后面會有一(yi)(yi)篇文章(zhang)詳細深(shen)挖(wa)所有的(de)響應(ying)頭(tou)的(de)，下面是一(yi)(yi)個響應(ying)頭(tou)的(de)匯總，基于 HTTP 1.1

響應標頭

響(xiang)應標頭(tou)(tou)是(shi)(shi)可(ke)以(yi)(yi)在(zai) HTTP 響(xiang)應種使用(yong)(yong)的 HTTP 標頭(tou)(tou)，這聽(ting)起(qi)來是(shi)(shi)像(xiang)一(yi)句(ju)廢話(hua)，不過(guo)確實(shi)是(shi)(shi)這樣解(jie)釋。并不是(shi)(shi)所有(you)出(chu)(chu)現(xian)在(zai)響(xiang)應中(zhong)的標頭(tou)(tou)都是(shi)(shi)響(xiang)應標頭(tou)(tou)。還有(you)一(yi)些特(te)殊的我們上面(mian)說過(guo)，有(you)通用(yong)(yong)標頭(tou)(tou)和實(shi)體(ti)標頭(tou)(tou)也會出(chu)(chu)現(xian)在(zai)響(xiang)應標頭(tou)(tou)中(zhong)，比如 Content-Length 就是(shi)(shi)一(yi)個(ge)實(shi)體(ti)標頭(tou)(tou)，但是(shi)(shi)，在(zai)這種情況下(xia)，這些實(shi)體(ti)請求通常稱為響(xiang)應頭(tou)(tou)。下(xia)面(mian)以(yi)(yi)一(yi)個(ge)例子為例和你探討一(yi)下(xia)響(xiang)應頭(tou)(tou)

200 OKAccess-Control-Allow-Origin: *Connection: Keep-AliveContent-Encoding: gzipContent-Type: text/html; charset=utf-8Date: Mon, 18 Jul 2016 16:06:00 GMTEtag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"Keep-Alive: timeout=5, max=997Last-Modified: Mon, 18 Jul 2016 02:36:04 GMTServer: ApacheSet-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secureTransfer-Encoding: chunkedVary: Cookie, Accept-Encodingx-frame-options: DENY復制代碼

響應狀態碼

首先出現的(de)(de)應(ying)(ying)該(gai)就(jiu)是 200 OK，這是 HTTP 響應(ying)(ying)標(biao)頭的(de)(de)狀(zhuang)態(tai)(tai)碼，它表示著響應(ying)(ying)成功完(wan)成。HTTP 響應(ying)(ying)標(biao)頭的(de)(de)狀(zhuang)態(tai)(tai)碼有(you)很多，并做了如(ru)下(xia)規定

以 2xx 為開頭的(de)都(dou)表示請求成功響(xiang)應。

狀(zhuang)態(tai)碼 含義 200 成(cheng)功(gong)響應(ying) 204 請求處理(li)成(cheng)功(gong)，但是沒有資源可(ke)以返回 206 對資源某一(yi)部分進行(xing)響應(ying)，由Content-Range 指定范圍(wei)的實體(ti)內容(rong)。

以(yi) 3xx 為開頭的都表示(shi)需要進行附加操(cao)作以(yi)完(wan)成(cheng)請求

狀態(tai)(tai)碼 含義 301 永(yong)久性重定(ding)向(xiang)(xiang)，該狀態(tai)(tai)碼表(biao)示請(qing)求(qiu)(qiu)(qiu)的(de)(de)資(zi)源已經(jing)重新分(fen)配(pei) URI，以后(hou)應該使(shi)用(yong)(yong)(yong)資(zi)源現有(you)的(de)(de) URI 302 臨(lin)時性重定(ding)向(xiang)(xiang)。該狀態(tai)(tai)碼表(biao)示請(qing)求(qiu)(qiu)(qiu)的(de)(de)資(zi)源已被分(fen)配(pei)了新的(de)(de) URI，希(xi)望(wang)用(yong)(yong)(yong)戶（本(ben)次）能使(shi)用(yong)(yong)(yong)新的(de)(de) URI 訪(fang)問。 303 該狀態(tai)(tai)碼表(biao)示由于請(qing)求(qiu)(qiu)(qiu)對應的(de)(de)資(zi)源存在著(zhu)另一個 URI，應使(shi)用(yong)(yong)(yong) GET 方(fang)法定(ding)向(xiang)(xiang)獲取請(qing)求(qiu)(qiu)(qiu)的(de)(de)資(zi)源。 304 該狀態(tai)(tai)碼表(biao)示客戶端發送(song)附帶條件的(de)(de)請(qing)求(qiu)(qiu)(qiu)時，服務器端允許請(qing)求(qiu)(qiu)(qiu)訪(fang)問資(zi)源，但未滿足(zu)條件的(de)(de)情況。 307 臨(lin)時重定(ding)向(xiang)(xiang)。該狀態(tai)(tai)碼與(yu) 302 Found 有(you)著(zhu)相同的(de)(de)含義。

以(yi) 4xx 的響應結(jie)果表(biao)明客(ke)戶端是發生錯誤的原因所在。

狀(zhuang)態碼(ma)(ma) 含義 400 該狀(zhuang)態碼(ma)(ma)表(biao)示請(qing)求(qiu)(qiu)報文中存在(zai)語法錯誤。當錯誤發生時，需修(xiu)改(gai)請(qing)求(qiu)(qiu)的(de)內容(rong)后再次發送(song)請(qing)求(qiu)(qiu)。 401 該狀(zhuang)態碼(ma)(ma)表(biao)示發送(song)的(de)請(qing)求(qiu)(qiu)需要有通過 HTTP 認(ren)證(zheng)（BASIC 認(ren)證(zheng)、DIGEST 認(ren)證(zheng)）的(de)認(ren)證(zheng)信息。 403 該狀(zhuang)態碼(ma)(ma)表(biao)明對請(qing)求(qiu)(qiu)資源的(de)訪問被服務器拒絕了。 404 該狀(zhuang)態碼(ma)(ma)表(biao)明服務器上無法找(zhao)到請(qing)求(qiu)(qiu)的(de)資源。

以 5xx 為開頭的(de)響應標頭都表示服務(wu)器本身發(fa)生錯誤(wu)

狀態碼(ma) 含義(yi) 500 該(gai)狀態碼(ma)表明(ming)服(fu)務器(qi)(qi)端在執行請(qing)求(qiu)時發生了(le)錯(cuo)誤。 503 該(gai)狀態碼(ma)表明(ming)服(fu)務器(qi)(qi)暫時處于超負載或正(zheng)在進行停機(ji)維護，現在無法處理請(qing)求(qiu)。

Access-Control-Allow-Origin

一個(ge)返(fan)回(hui)的 HTTP 標頭可(ke)能會具有 Access-Control-Allow-Origin ，Access-Control-Allow-Origin 指定一個(ge)來源(yuan)，它告訴瀏(liu)覽器(qi)允許該來源(yuan)進行資源(yuan)訪(fang)(fang)問。 否則-對于沒有憑據的請(qing)求(qiu) *通(tong)配符，告訴瀏(liu)覽器(qi)允許任何源(yuan)訪(fang)(fang)問資源(yuan)。例如，要(yao)允許源(yuan) //mozilla.org 的代碼訪(fang)(fang)問資源(yuan)，可(ke)以(yi)指定：

Access-Control-Allow-Origin: //mozilla.orgVary: Origin復制代碼

如果服(fu)務器指定單個來源而(er)不是 *通配符(fu)的話 ，則服(fu)務器還應(ying)在(zai) Vary 響(xiang)(xiang)應(ying)標(biao)頭(tou)中包含 Origin ，以向客戶(hu)端(duan)指示 服(fu)務器響(xiang)(xiang)應(ying)將根據原始請求標(biao)頭(tou)的值而(er)有所不同。

Keep-Alive

上(shang)(shang)面我們提(ti)到，HTTP 報文(wen)標(biao)頭會分為(wei)四種(zhong)，這其實是按著(zhu)上(shang)(shang)下文(wen)來分類(lei)的(de)

還有一(yi)種(zhong)分類是(shi)根(gen)據代(dai)理進行分類，根(gen)據代(dai)理會(hui)分為(wei)端到端頭(tou) 和 逐跳標頭(tou)

而 Keep-Alive 表(biao)示的(de)是 Connection 非持續連接的(de)存活時間(jian)，如下

Connection: Keep-AliveKeep-Alive: timeout=5, max=997復制代碼

Keep-Alive 有兩個(ge)(ge)參數，它們(men)是(shi)以逗號分隔的參數列表(biao)，每個(ge)(ge)參數由一(yi)個(ge)(ge)標識符和一(yi)個(ge)(ge)由等號 = 分隔的值組(zu)成。

timeout：指示空閑(xian)連接必(bi)須(xu)保持打開(kai)狀態的(de)最短時間（以秒為(wei)單位(wei)）。

max：指(zhi)示在關閉連接之前(qian)可(ke)以在此連接上(shang)發送的最大(da)請求數。

上述 HTTP 代碼的(de)意思就(jiu)是限制最(zui)大的(de)超時時間是 5s 和 最(zui)大的(de)連(lian)接請求是 997 個。

Server

服務器標(biao)頭包含有(you)關原(yuan)始服務器用來處理(li)請求的(de)軟件的(de)信息。

應該避免使用(yong)(yong)過于(yu)冗(rong)長和(he)詳細(xi)的 Server 值，因為它們可(ke)能會(hui)(hui)泄露內部實(shi)施細(xi)節，這可(ke)能會(hui)(hui)使攻擊者(zhe)容易地發現并利用(yong)(yong)已知的安全漏洞。例如下面(mian)這種寫法

Server: Apache/2.4.1 (Unix)復制代碼

Set-Cookie

Cookie 又是(shi)另外一個領域(yu)的內容(rong)了，我們(men)后面文章會說道 Cookie，這里需(xu)要記住 Cookie、Set-Cookie 和 Content-Disposition 等在其(qi)他(ta) RFC 中定義的首部(bu)字段，它(ta)們(men)不是(shi)屬于 HTTP 1.1 的首部(bu)字段，但是(shi)使用(yong)率仍然(ran)很高。

Transfer-Encoding

首部字段(duan) Transfer-Encoding 規定了(le)傳輸(shu)報文主體時(shi)采用的編碼方(fang)式。

Transfer-Encoding: chunked復制代碼

HTTP /1.1 的傳輸(shu)編碼方式(shi)僅對分塊傳輸(shu)編碼有效。

X-Frame-Options

HTTP 首部(bu)字(zi)(zi)段是可以(yi)自行擴展的(de)。所以(yi)在 Web 服務器和瀏覽器的(de)應用上，會出(chu)現各種非標準的(de)首部(bu)字(zi)(zi)段。

首部(bu)字(zi)段(duan) X-Frame-Options 屬于(yu) HTTP 響應首部(bu)，用于(yu)控制網(wang)站內容在其他 Web 網(wang)站的 Frame 標簽內的顯(xian)示問題。其主要(yao)目的是為了防止點擊劫持(chi)（clickjacking）攻擊。

下面是一個響應(ying)頭的匯總(zong)，基于 HTTP 1.1

非 HTTP/1.1 首部字段

在 HTTP 協議通信交互中(zhong)使用(yong)(yong)到的(de)首部(bu)字(zi)段，不限于 RFC2616 中(zhong)定義(yi)(yi)的(de) 47 種首部(bu)字(zi)段。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其他(ta) RFC 中(zhong)定義(yi)(yi)的(de)首部(bu)字(zi)段，它們的(de)使用(yong)(yong)頻率也(ye)很高。 這些非正式的(de)首部(bu)字(zi)段統一歸納在 RFC4229 HTTP Header Field Registrations 中(zhong)。

End-to-end 首部和 Hop-by-hop 首部

HTTP 首(shou)部字段(duan)將定義成緩存代理(li)和非緩存代理(li)的行為(wei)，分成 2 種類型。

一種是 End-to-end 首部(bu) 和 Hop-by-hop 首部(bu)

End-to-end（端到端） 首部

這些標頭必(bi)(bi)須發送給消息的(de)最(zui)終接收者 : 請求的(de)服(fu)務器，或響應的(de)客戶端(duan)。中間(jian)代理必(bi)(bi)須重新傳輸未(wei)經(jing)修改(gai)的(de)標頭，并且緩存必(bi)(bi)須存儲這些信息

Hop-by-hop（逐跳） 首部

分(fen)在(zai)此類別中(zhong)的首部只對單次(ci)轉發(fa)有效，會因通過緩存或代(dai)理而不再轉發(fa)。

下面列舉了 HTTP/1.1 中(zhong)的逐(zhu)跳首部字(zi)(zi)段。除這 8 個首部字(zi)(zi)段之外，其(qi)他(ta)所有字(zi)(zi)段都屬于(yu)端(duan)到端(duan)首部。

Connection、Keep-Alive、Proxy-Authenticate、Proxy-Authorization、Trailer、TE、Transfer-Encoding、Upgrade

HTTP 的優點和缺點

HTTP 的優點

簡單靈活易擴展

HTTP 最重要也是最突出的優點是 簡單、靈活、易于擴展。

HTTP 的(de)(de)協(xie)議比(bi)較簡單(dan)，它的(de)(de)主要組成就是 header + body，頭(tou)部(bu)信息也是簡單(dan)的(de)(de)文(wen)本格(ge)式，而且 HTTP 的(de)(de)請求報文(wen)根據英文(wen)也能(neng)猜出來個(ge)大概(gai)的(de)(de)意(yi)思，降低(di)學習門檻，能(neng)夠讓更多(duo)的(de)(de)人研(yan)究和開發(fa) HTTP 應用(yong)。

所以(yi)，在簡單的基礎上，HTTP 協議又多了靈活(huo) 和 易擴展 的優點。

HTTP 協(xie)議(yi)里(li)的(de)請求方法、URI、狀態(tai)碼、原因短(duan)語(yu)、頭(tou)字段等(deng)每一(yi)個(ge)核心組(zu)成要(yao)素(su)都沒有被(bei)制(zhi)定(ding)死，允許開發者任(ren)意定(ding)制(zhi)、擴充(chong)或(huo)解釋，給(gei)予(yu)了瀏覽器和(he)(he)服(fu)務器最大程(cheng)度(du)的(de)信任(ren)和(he)(he)自由。

應用廣泛、環境成熟

因為過于簡單，普及，因此應用很廣泛。因為 HTTP 協議本身不屬于一種語言，它并不限定某種編程語言或者操作系統，所以天然具有跨語言、跨平臺的(de)優越性。而且(qie)，因為本身的(de)簡單特性很(hen)容(rong)易(yi)實(shi)現，所以幾乎所有(you)的(de)編程語言都有(you) HTTP 調(diao)用(yong)庫(ku)和外圍(wei)的(de)開發測試(shi)工具。

隨著移動(dong)互聯網的(de)(de)發展， HTTP 的(de)(de)觸角已經(jing)延伸到(dao)了世界的(de)(de)每一個(ge)角落，從(cong)簡單的(de)(de) Web 頁(ye)面到(dao)復(fu)雜的(de)(de) JSON、XML 數據，從(cong)臺式(shi)機(ji)上的(de)(de)瀏覽器到(dao)手機(ji)上的(de)(de)各(ge)種 APP、新聞、論壇、購物、手機(ji)游戲，你很難(nan)找到(dao)一個(ge)沒有使用 HTTP 的(de)(de)地(di)方。

無狀態

無(wu)狀(zhuang)態(tai)其實(shi)既是優點又是缺點。因(yin)為服務器(qi)沒有記(ji)憶能(neng)力，所以(yi)就不需要額外(wai)的資源來記(ji)錄狀(zhuang)態(tai)信息，不僅實(shi)現上會簡單一些，而且還能(neng)減輕(qing)服務器(qi)的負(fu)擔，能(neng)夠把更多的 CPU 和內存用來對外(wai)提供服務。

HTTP 的缺點

無狀態

既然服務器沒有記憶能力(li)，它就無法(fa)支持需要(yao)連續多個(ge)步驟的事(shi)務操作。每次都得問(wen)一遍(bian)身份(fen)信息，不僅麻煩，而(er)且還增加了(le)(le)不必要(yao)的數據(ju)傳輸量。由此出(chu)現了(le)(le) Cookie 技術。

明文

HTTP 協議里還有一把優缺點一體的雙刃劍，就是明文傳輸。明文(wen)意(yi)思就是(shi)協(xie)議里的報文(wen)（準確(que)地說是(shi) header 部(bu)分）不使用(yong)二進制數(shu)據，而是(shi)用(yong)簡(jian)單可閱讀的文(wen)本形式。

對比(bi) TCP、UDP 這樣(yang)的(de)(de)二(er)進(jin)制協議，它的(de)(de)優點(dian)顯而易(yi)見，不(bu)需要借助任何外部(bu)工具(ju)，用(yong)瀏覽器、Wireshark 或者 tcpdump 抓(zhua)包后，直接用(yong)肉眼就可以(yi)很容易(yi)地(di)查看或者修(xiu)改(gai)，為我們(men)的(de)(de)開發調試工作帶來極(ji)大的(de)(de)便利。

當然缺點也是顯而易(yi)見的，就(jiu)是不安全(quan)，可以被(bei)監(jian)聽和被(bei)窺探(tan)。因(yin)為無法判斷通信雙方的身份，不能判斷報文是否(fou)被(bei)更改過。

性能

HTTP 的性(xing)能不(bu)(bu)算差，但不(bu)(bu)完(wan)全適應現在(zai)的互聯(lian)網，還有很大的提升空間