看完這篇HTTP国裳，跟面試官扯皮就沒問題了

我是一名程序員，我的主要編程語言是 Java全跨，我更是一名 Web 開發(fā)人員缝左，所以我必須要了解 HTTP，所以本篇文章就來帶你從 HTTP 入門到進階浓若，看完讓你有一種恍然大悟渺杉、醍醐灌頂?shù)母杏X。

最初在有網(wǎng)絡之前挪钓，我們的電腦都是單機的少办，單機系統(tǒng)是孤立的，我還記得 05 年前那會兒家里有個電腦诵原，想打電腦游戲還得兩個人在一個電腦上玩兒英妓，及其不方便。我就想為什么家里人不讓上網(wǎng)绍赛，我的同學 xxx 家里有網(wǎng)蔓纠，每次一提這個就落一通批評：xxx上xxx什xxxx么xxxx網(wǎng)xxxx看xxxx你xxxx考xxxx的xxxx那xxxx點xxxx分。雖然我家里沒有上網(wǎng)吗蚌，但是此時互聯(lián)網(wǎng)已經(jīng)在高速發(fā)展了腿倚，HTTP 就是高速發(fā)展的一個產(chǎn)物。

認識 HTTP

首先你聽的最多的應該就是 HTTP 是一種 超文本傳輸協(xié)議(Hypertext Transfer Protocol)蚯妇，這你一定能說出來敷燎，但是這樣還不夠，假如你是大廠面試官箩言，這不可能是他想要的最終結果硬贯，我們在面試的時候往往把自己知道的盡可能多的說出來，才有和面試官談價錢的資本陨收。那么什么是超文本傳輸協(xié)議饭豹？

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

按照范圍的大小 協(xié)議 > 傳輸 > 超文本它褪。下面就分別對這三個名次做一個解釋候衍。

什么是超文本

在互聯(lián)網(wǎng)早期的時候谎势，我們輸入的信息只能保存在本地桥温，無法和其他電腦進行交互欣尼。我們保存的信息通常都以文本即簡單字符的形式存在，文本是一種能夠被計算機解析的有意義的二進制數(shù)據(jù)包少漆。而隨著互聯(lián)網(wǎng)的高速發(fā)展譬圣，兩臺電腦之間能夠進行數(shù)據(jù)的傳輸后腹纳，人們不滿足只能在兩臺電腦之間傳輸文字源葫，還想要傳輸圖片、音頻砖瞧、視頻息堂，甚至點擊文字或圖片能夠進行超鏈接的跳轉，那么文本的語義就被擴大了块促，這種語義擴大后的文本就被稱為超文本(Hypertext)荣堰。

什么是傳輸

那么我們上面說到，兩臺計算機之間會形成互聯(lián)關系進行通信竭翠，我們存儲的超文本會被解析成為二進制數(shù)據(jù)包振坚，由傳輸載體（例如同軸電纜，電話線斋扰，光纜）負責把二進制數(shù)據(jù)包由計算機終端傳輸?shù)搅硪粋€終端的過程稱為傳輸(transfer)渡八。

通常我們把傳輸數(shù)據(jù)包的一方稱為請求方，把接到二進制數(shù)據(jù)包的一方稱為應答方传货。請求方和應答方可以進行互換屎鳍，請求方也可以作為應答方接受數(shù)據(jù)，應答方也可以作為請求方請求數(shù)據(jù)问裕，它們之間的關系如下

如圖所示逮壁，A 和 B 是兩個不同的端系統(tǒng)，它們之間可以作為信息交換的載體存在粮宛，剛開始的時候是 A 作為請求方請求與 B 交換信息窥淆，B 作為響應的一方提供信息；隨著時間的推移巍杈，B 也可以作為請求方請求 A 交換信息忧饭，那么 A 也可以作為響應方響應 B 請求的信息。

什么是協(xié)議

協(xié)議這個名詞不僅局限于互聯(lián)網(wǎng)范疇筷畦，也體現(xiàn)在日常生活中眷昆，比如情侶雙方約定好在哪個地點吃飯，這個約定也是一種協(xié)議，比如你應聘成功了亚斋，企業(yè)會和你簽訂勞動合同作媚，這種雙方的雇傭關系也是一種 協(xié)議。注意自己一個人對自己的約定不能成為協(xié)議帅刊，協(xié)議的前提條件必須是多人約定纸泡。

那么網(wǎng)絡協(xié)議是什么呢？

網(wǎng)絡協(xié)議就是網(wǎng)絡中(包括互聯(lián)網(wǎng))傳遞赖瞒、管理信息的一些規(guī)范女揭。如同人與人之間相互交流是需要遵循一定的規(guī)矩一樣，計算機之間的相互通信需要共同遵守一定的規(guī)則栏饮，這些規(guī)則就稱為網(wǎng)絡協(xié)議吧兔。

沒有網(wǎng)絡協(xié)議的互聯(lián)網(wǎng)是混亂的，就和人類社會一樣袍嬉，人不能想怎么樣就怎么樣境蔼，你的行為約束是受到法律的約束的；那么互聯(lián)網(wǎng)中的端系統(tǒng)也不能自己想發(fā)什么發(fā)什么伺通，也是需要受到通信協(xié)議約束的箍土。

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

與 HTTP 有關的組件

隨著網(wǎng)絡世界演進沟堡，HTTP 協(xié)議已經(jīng)幾乎成為不可替代的一種協(xié)議，在了解了 HTTP 的基本組成后矢空，下面再來帶你進一步認識一下 HTTP 協(xié)議弦叶。

網(wǎng)絡模型

網(wǎng)絡是一個復雜的系統(tǒng)，不僅包括大量的應用程序妇多、端系統(tǒng)伤哺、通信鏈路、分組交換機等者祖，還有各種各樣的協(xié)議組成立莉，那么現(xiàn)在我們就來聊一下網(wǎng)絡中的協(xié)議層次。

為了給網(wǎng)絡協(xié)議的設計提供一個結構七问，網(wǎng)絡設計者以分層(layer)的方式組織協(xié)議蜓耻，每個協(xié)議屬于層次模型之一。每一層都是向它的上一層提供服務(service)械巡，即所謂的服務模型(service model)刹淌。每個分層中所有的協(xié)議稱為 協(xié)議棧(protocol stack)饶氏。因特網(wǎng)的協(xié)議棧由五個部分組成：物理層、鏈路層有勾、網(wǎng)絡層疹启、運輸層和應用層。我們采用自上而下的方法研究其原理蔼卡，也就是應用層 -> 物理層的方式喊崖。

應用層

應用層是網(wǎng)絡應用程序和網(wǎng)絡協(xié)議存放的分層，因特網(wǎng)的應用層包括許多協(xié)議雇逞，例如我們學 web 離不開的 HTTP荤懂，電子郵件傳送協(xié)議 SMTP、端系統(tǒng)文件上傳協(xié)議 FTP塘砸、還有為我們進行域名解析的 DNS 協(xié)議节仿。應用層協(xié)議分布在多個端系統(tǒng)上，一個端系統(tǒng)應用程序與另外一個端系統(tǒng)應用程序交換信息分組掉蔬，我們把位于應用層的信息分組稱為 報文(message)廊宪。

運輸層

因特網(wǎng)的運輸層在應用程序斷點之間傳送應用程序報文，在這一層主要有兩種傳輸協(xié)議 TCP和 UDP眉踱，利用這兩者中的任何一個都能夠傳輸報文挤忙，不過這兩種協(xié)議有巨大的不同霜威。

TCP 向它的應用程序提供了面向連接的服務谈喳，它能夠控制并確認報文是否到達，并提供了擁塞機制來控制網(wǎng)絡傳輸戈泼，因此當網(wǎng)絡擁塞時婿禽，會抑制其傳輸速率。

UDP 協(xié)議向它的應用程序提供了無連接服務大猛。它不具備可靠性的特征扭倾，沒有流量控制，也沒有擁塞控制挽绩。我們把運輸層的分組稱為 報文段(segment)

網(wǎng)絡層

因特網(wǎng)的網(wǎng)絡層負責將稱為 數(shù)據(jù)報(datagram) 的網(wǎng)絡分層從一臺主機移動到另一臺主機膛壹。網(wǎng)絡層一個非常重要的協(xié)議是 IP 協(xié)議，所有具有網(wǎng)絡層的因特網(wǎng)組件都必須運行 IP 協(xié)議唉堪，IP 協(xié)議是一種網(wǎng)際協(xié)議模聋，除了 IP 協(xié)議外，網(wǎng)絡層還包括一些其他網(wǎng)際協(xié)議和路由選擇協(xié)議唠亚，一般把網(wǎng)絡層就稱為 IP 層链方，由此可知 IP 協(xié)議的重要性。

鏈路層

現(xiàn)在我們有應用程序通信的協(xié)議灶搜，有了給應用程序提供運輸?shù)膮f(xié)議祟蚀，還有了用于約定發(fā)送位置的 IP 協(xié)議工窍，那么如何才能真正的發(fā)送數(shù)據(jù)呢？為了將分組從一個節(jié)點（主機或路由器）運輸?shù)搅硪粋€節(jié)點前酿，網(wǎng)絡層必須依靠鏈路層提供服務患雏。鏈路層的例子包括以太網(wǎng)、WiFi 和電纜接入的 DOCSIS 協(xié)議薪者，因為數(shù)據(jù)從源目的地傳送通常需要經(jīng)過幾條鏈路纵苛，一個數(shù)據(jù)包可能被沿途不同的鏈路層協(xié)議處理，我們把鏈路層的分組稱為 幀(frame)

物理層

雖然鏈路層的作用是將幀從一個端系統(tǒng)運輸?shù)搅硪粋€端系統(tǒng)言津，而物理層的作用是將幀中的一個個 比特 從一個節(jié)點運輸?shù)搅硪粋€節(jié)點攻人，物理層的協(xié)議仍然使用鏈路層協(xié)議，這些協(xié)議與實際的物理傳輸介質有關悬槽，例如怀吻，以太網(wǎng)有很多物理層協(xié)議：關于雙絞銅線、關于同軸電纜初婆、關于光纖等等蓬坡。

五層網(wǎng)絡協(xié)議的示意圖如下

image.png

OSI 模型

我們上面討論的計算網(wǎng)絡協(xié)議模型不是唯一的 協(xié)議棧，ISO（國際標準化組織）提出來計算機網(wǎng)絡應該按照7層來組織磅叛，那么7層網(wǎng)絡協(xié)議棧與5層的區(qū)別在哪里屑咳？

從圖中可以一眼看出，OSI 要比上面的網(wǎng)絡模型多了 表示層 和 會話層弊琴，其他層基本一致兆龙。表示層主要包括數(shù)據(jù)壓縮和數(shù)據(jù)加密以及數(shù)據(jù)描述，數(shù)據(jù)描述使得應用程序不必擔心計算機內(nèi)部存儲格式的問題敲董，而會話層提供了數(shù)據(jù)交換的定界和同步功能紫皇，包括建立檢查點和恢復方案。

瀏覽器

就如同各大郵箱使用電子郵件傳送協(xié)議 SMTP 一樣腋寨，瀏覽器是使用 HTTP 協(xié)議的主要載體聪铺，說到瀏覽器，你能想起來幾種萄窜？是的铃剔，隨著網(wǎng)景大戰(zhàn)結束后，瀏覽器迅速發(fā)展查刻，至今已經(jīng)出現(xiàn)過的瀏覽器主要有

瀏覽器正式的名字叫做 Web Broser键兜，顧名思義，就是檢索赖阻、查看互聯(lián)網(wǎng)上網(wǎng)頁資源的應用程序蝶押，名字里的 Web，實際上指的就是 World Wide Web火欧，也就是萬維網(wǎng)棋电。

我們在地址欄輸入URL（即網(wǎng)址）茎截，瀏覽器會向DNS（域名服務器，后面會說）提供網(wǎng)址赶盔，由它來完成 URL 到 IP 地址的映射企锌。然后將請求你的請求提交給具體的服務器，在由服務器返回我們要的結果（以HTML編碼格式返回給瀏覽器）于未，瀏覽器執(zhí)行HTML編碼撕攒，將結果顯示在瀏覽器的正文。這就是一個瀏覽器發(fā)起請求和接受響應的過程烘浦。

Web 服務器

Web 服務器的正式名稱叫做 Web Server抖坪，Web 服務器一般指的是網(wǎng)站服務器，上面說到瀏覽器是 HTTP 請求的發(fā)起方闷叉，那么 Web 服務器就是 HTTP 請求的應答方擦俐，Web 服務器可以向瀏覽器等 Web 客戶端提供文檔，也可以放置網(wǎng)站文件握侧，讓全世界瀏覽蚯瞧；可以放置數(shù)據(jù)文件，讓全世界下載品擎。目前最主流的三個Web服務器是Apache埋合、 Nginx 、IIS萄传。

CDN

CDN的全稱是Content Delivery Network甚颂，即內(nèi)容分發(fā)網(wǎng)絡，它應用了 HTTP 協(xié)議里的緩存和代理技術盲再，代替源站響應客戶端的請求西设。CDN 是構建在現(xiàn)有網(wǎng)絡基礎之上的網(wǎng)絡瓣铣，它依靠部署在各地的邊緣服務器答朋，通過中心平臺的負載均衡、內(nèi)容分發(fā)棠笑、調度等功能模塊梦碗，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡擁塞蓖救，提高用戶訪問響應速度和命中率洪规。CDN的關鍵技術主要有內(nèi)容存儲和分發(fā)技術。

打比方說你要去亞馬遜上買書循捺，之前你只能通過購物網(wǎng)站購買后從美國發(fā)貨過海關等重重關卡送到你的家里斩例，現(xiàn)在在中國建立一個亞馬遜分基地，你就不用通過美國進行郵寄从橘，從中國就能把書盡快給你送到念赶。

WAF

WAF 是一種 Web 應用程序防護系統(tǒng)（Web Application Firewall础钠，簡稱 WAF），它是一種通過執(zhí)行一系列針對HTTP / HTTPS的安全策略來專門為Web應用提供保護的一款產(chǎn)品叉谜，它是應用層面的防火墻旗吁，專門檢測 HTTP 流量，是防護 Web 應用的安全技術停局。

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

WebService

WebService 是一種 Web 應用程序锭碳，WebService是一種跨編程語言和跨操作系統(tǒng)平臺的遠程調用技術叹洲。

Web Service 是一種由 W3C 定義的應用服務開發(fā)規(guī)范，使用 client-server 主從架構工禾，通常使用 WSDL 定義服務接口运提，使用 HTTP 協(xié)議傳輸 XML 或 SOAP 消息，它是一個基于 Web（HTTP）的服務架構技術闻葵，既可以運行在內(nèi)網(wǎng)民泵，也可以在適當保護后運行在外網(wǎng)。

HTML

HTML 稱為超文本標記語言槽畔，是一種標識性的語言栈妆。它包括一系列標簽．通過這些標簽可以將網(wǎng)絡上的文檔格式統(tǒng)一，使分散的 Internet 資源連接為一個邏輯整體厢钧。HTML 文本是由 HTML 命令組成的描述性文本鳞尔，HTML 命令可以說明文字，圖形早直、動畫寥假、聲音、表格霞扬、鏈接等糕韧。

Web 頁面構成

Web 頁面（Web page）也叫做文檔，是由一個個對象組成的喻圃。一個對象(Objecy) 只是一個文件萤彩，比如一個 HTML 文件、一個 JPEG 圖形斧拍、一個 Java 小程序或一個視頻片段雀扶，它們在網(wǎng)絡中可以通過 URL 地址尋址。多數(shù)的 Web 頁面含有一個 HTML 基本文件 以及幾個引用對象肆汹。

舉個例子愚墓，如果一個 Web 頁面包含 HTML 文件和5個 JPEG 圖形窍侧，那么這個 Web 頁面就有6個對象：一個 HTML 文件和5個 JPEG 圖形。HTML 基本文件通過 URL 地址引用頁面中的其他對象转绷。

與 HTTP 有關的協(xié)議

在互聯(lián)網(wǎng)中伟件，任何協(xié)議都不會單獨的完成信息交換，HTTP 也一樣议经。雖然 HTTP 屬于應用層的協(xié)議斧账，但是它仍然需要其他層次協(xié)議的配合完成信息的交換，那么在完成一次 HTTP 請求和響應的過程中煞肾，需要哪些協(xié)議的配合呢咧织？一起來看一下

TCP/IP

TCP/IP 協(xié)議你一定聽過，TCP/IP 我們一般稱之為協(xié)議簇籍救，什么意思呢习绢？就是 TCP/IP 協(xié)議簇中不僅僅只有 TCP 協(xié)議和 IP 協(xié)議，它是一系列網(wǎng)絡通信協(xié)議的統(tǒng)稱蝙昙。而其中最核心的兩個協(xié)議就是 TCP / IP 協(xié)議闪萄，其他的還有 UDP、ICMP奇颠、ARP 等等败去，共同構成了一個復雜但有層次的協(xié)議棧。

TCP 協(xié)議的全稱是 Transmission Control Protocol 的縮寫烈拒，意思是傳輸控制協(xié)議圆裕，HTTP 使用 TCP 作為通信協(xié)議，這是因為 TCP 是一種可靠的協(xié)議荆几，而可靠能保證數(shù)據(jù)不丟失吓妆。

IP 協(xié)議的全稱是 Internet Protocol 的縮寫，它主要解決的是通信雙方尋址的問題吨铸。IP 協(xié)議使用 IP 地址 來標識互聯(lián)網(wǎng)上的每一臺計算機行拢，可以把 IP 地址想象成為你手機的電話號碼，你要與他人通話必須先要知道他人的手機號碼焊傅，計算機網(wǎng)絡中信息交換必須先要知道對方的 IP 地址剂陡。（關于 TCP 和 IP 更多的討論我們會在后面詳解）

DNS

你有沒有想過為什么你可以通過鍵入 www.google.com 就能夠獲取你想要的網(wǎng)站狈涮？我們上面說到狐胎，計算機網(wǎng)絡中的每個端系統(tǒng)都有一個 IP 地址存在，而把 IP 地址轉換為便于人類記憶的協(xié)議就是 DNS 協(xié)議歌馍。

DNS 的全稱是域名系統(tǒng)（Domain Name System握巢，縮寫：DNS），它作為將域名和 IP 地址相互映射的一個分布式數(shù)據(jù)庫松却，能夠使人更方便地訪問互聯(lián)網(wǎng)暴浦。

URI / URL

我們上面提到溅话，你可以通過輸入 www.google.com 地址來訪問谷歌的官網(wǎng)，那么這個地址有什么規(guī)定嗎歌焦？我怎么輸都可以飞几？AAA.BBB.CCC 是不是也行？當然不是的独撇，你輸入的地址格式必須要滿足 URI 的規(guī)范屑墨。

URI的全稱是（Uniform Resource Identifier），中文名稱是統(tǒng)一資源標識符纷铣，使用它就能夠唯一地標記互聯(lián)網(wǎng)上資源卵史。

URL的全稱是（Uniform Resource Locator），中文名稱是統(tǒng)一資源定位符搜立，也就是我們俗稱的網(wǎng)址以躯，它實際上是 URI 的一個子集。

URI 不僅包括 URL啄踊，還包括 URN（統(tǒng)一資源名稱）忧设，它們之間的關系如下

HTTPS

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

HTTP 請求響應過程

你是不是很好奇淀歇，當你在瀏覽器中輸入網(wǎng)址后量淌，到底發(fā)生了什么事情？你想要的內(nèi)容是如何展現(xiàn)出來的盆均？讓我們通過一個例子來探討一下救恨，我們假設訪問的 URL 地址為 http://www.someSchool.edu/someDepartment/home.index，當我們輸入網(wǎng)址并點擊回車時纳决，瀏覽器內(nèi)部會進行如下操作

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

至此吃警，鍵入網(wǎng)址再按下回車的全過程就結束了。上述過程描述的是一種簡單的請求-響應全過程啄育，真實的請求-響應情況可能要比上面描述的過程復雜很多酌心。

HTTP 請求特征

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

• 支持客戶-服務器模式
• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑挑豌。請求方法常用的有 GET安券、HEAD、POST氓英。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同侯勉。由于 HTTP 協(xié)議簡單，使得 HTTP 服務器的程序規(guī)模小铝阐，因而通信速度很快址貌。
• 靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀?Content-Type 加以標記徘键。
• 無連接：無連接的含義是限制每次連接只處理一個請求练对。服務器處理完客戶的請求，并收到客戶的應答后吹害，即斷開連接螟凭。采用這種方式可以節(jié)省傳輸時間。
• 無狀態(tài)：HTTP 協(xié)議是無狀態(tài)協(xié)議赠制。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力赂摆。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息挟憔，則它必須重傳钟些，這樣可能導致每次連接傳送的數(shù)據(jù)量增大烟号。另一方面，在服務器不需要先前信息時它的應答就較快政恍。

詳解 HTTP 報文

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

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

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

其中起始行和頭部字段并成為 請求頭 或者 響應頭，統(tǒng)稱為 Header详恼；消息正文也叫做實體补君，稱為 body。HTTP 協(xié)議規(guī)定每次發(fā)送的報文必須要有 Header昧互，但是可以沒有 body挽铁，也就是說頭信息是必須的，實體信息可以沒有敞掘。而且在 header 和 body 之間必須要有一個空行（CRLF）屿储，如果用一幅圖來表示一下的話，我覺得應該是下面這樣

image.png

我們使用上面的那個例子來看一下 http 的請求報文

image.png

如圖渐逃，這是 http://www.someSchool.edu/someDepartment/home.index 請求的請求頭够掠，通過觀察這個 HTTP 報文我們就能夠學到很多東西，首先茄菊，我們看到報文是用普通 ASCII 文本書寫的疯潭，這樣保證人能夠可以看懂。然后面殖，我們可以看到每一行和下一行之間都會有換行竖哩，而且最后一行（請求頭部后）再加上一個回車換行符。

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

image.png

HTTP 請求方法

HTTP 請求方法一般分為 8 種遵绰，它們分別是

• GET 獲取資源，GET 方法用來請求訪問已被 URI 識別的資源增淹。指定的資源經(jīng)服務器端解析后返回響應內(nèi)容椿访。也就是說，如果請求的資源是文本虑润，那就保持原樣返回成玫；

• POST 傳輸實體，雖然 GET 方法也可以傳輸主體信息拳喻，但是便于區(qū)分哭当，我們一般不用 GET 傳輸實體信息，反而使用 POST 傳輸實體信息冗澈，

• PUT 傳輸文件钦勘，PUT 方法用來傳輸文件。就像 FTP 協(xié)議的文件上傳一樣亚亲，要求在請求報文的主體中包含文件內(nèi)容彻采，然后保存到請求 URI 指定的位置。

  但是朵栖，鑒于 HTTP 的 PUT 方法自身不帶驗證機制颊亮，任何人都可以上傳文件 , 存在安全性問題，因此一般的 W eb 網(wǎng)站不使用該方法陨溅。若配合 W eb 應用程序的驗證機制终惑，或架構設計采用REST（REpresentational State Transfer，表征狀態(tài)轉移）標準的同類 Web 網(wǎng)站门扇，就可能會開放使用 PUT 方法雹有。

• HEAD 獲得響應首部，HEAD 方法和 GET 方法一樣臼寄，只是不返回報文主體部分霸奕。用于確認 URI 的有效性及資源更新的日期時間等。

• DELETE 刪除文件吉拳，DELETE 方法用來刪除文件质帅，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源留攒。

• OPTIONS 詢問支持的方法煤惩，OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

• TRACE 追蹤路徑炼邀，TRACE 方法是讓 Web 服務器端將之前的請求通信環(huán)回給客戶端的方法魄揉。

• CONNECT 要求用隧道協(xié)議連接代理，CONNECT 方法要求在與代理服務器通信時建立隧道拭宁，實現(xiàn)用隧道協(xié)議進行 TCP 通信洛退。主要使用 SSL（Secure Sockets Layer瓣俯，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加 密后經(jīng)網(wǎng)絡隧道傳輸兵怯。

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

image.png

HTTP 請求 URL

HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源摇零。正是因為 URI 的特定功能推掸，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到桶蝎。URL 帶有請求對象的標識符驻仅。在上面的例子中，瀏覽器正在請求對象 /somedir/page.html 的資源登渣。

我們再通過一個完整的域名解析一下 URL

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

首先出場的是 http

image.png

http://告訴瀏覽器使用何種協(xié)議胜茧。對于大部分 Web 資源粘优，通常使用 HTTP 協(xié)議或其安全版本，HTTPS 協(xié)議呻顽。另外雹顺，瀏覽器也知道如何處理其他協(xié)議。例如廊遍， mailto: 協(xié)議指示瀏覽器打開郵件客戶端嬉愧；ftp:協(xié)議指示瀏覽器處理文件傳輸。

第二個出場的是 主機

image.png

www.example.com 既是一個域名喉前，也代表管理該域名的機構没酣。它指示了需要向網(wǎng)絡上的哪一臺主機發(fā)起請求。當然卵迂，也可以直接向主機的 IP address 地址發(fā)起請求裕便。但直接使用 IP 地址的場景并不常見。

第三個出場的是 端口

image.png

我們前面說到见咒，兩個主機之間要發(fā)起 TCP 連接需要兩個條件偿衰，主機 + 端口。它表示用于訪問 Web 服務器上資源的入口改览。如果訪問的該 Web 服務器使用HTTP協(xié)議的標準端口（HTTP為80下翎，HTTPS為443）授予對其資源的訪問權限，則通常省略此部分恃疯。否則端口就是 URI 必須的部分漏设。

上面是請求 URL 所必須包含的部分，下面就是 URL 具體請求資源路徑

第四個出場的是 路徑

image.png

/path/to/myfile.html 是 Web 服務器上資源的路徑今妄。以端口后面的第一個 / 開始郑口，到 ? 號之前結束鸳碧，中間的 每一個/ 都代表了層級（上下級）關系。這個 URL 的請求資源是一個 html 頁面犬性。

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

image.png

?key1=value1&key2=value2 是提供給 Web 服務器的額外參數(shù)瞻离。如果是 GET 請求，一般帶有請求 URL 參數(shù)乒裆，如果是 POST 請求套利，則不會在路徑后面直接加參數(shù)。這些參數(shù)是用 & 符號分隔的鍵/值對列表鹤耍。key1 = value1 是第一對肉迫，key2 = value2 是第二對參數(shù)

緊跟著參數(shù)的是錨點

image.png

#SomewhereInTheDocument 是資源本身的某一部分的一個錨點。錨點代表資源內(nèi)的一種“書簽”稿黄，它給予瀏覽器顯示位于該“加書簽”點的內(nèi)容的指示喊衫。 例如，在HTML文檔上杆怕，瀏覽器將滾動到定義錨點的那個點上族购；在視頻或音頻文檔上，瀏覽器將轉到錨點代表的那個時間陵珍。值得注意的是 # 號后面的部分寝杖，也稱為片段標識符，永遠不會與請求一起發(fā)送到服務器互纯。

HTTP 版本

表示報文使用的 HTTP 協(xié)議版本瑟幕。

請求頭部

這部分內(nèi)容只是大致介紹一下，內(nèi)容較多伟姐，后面會再以一篇文章詳述

在表述完了起始行之后我們再來看一下請求頭部收苏，現(xiàn)在我們向上找，找到http://www.someSchool.edu/someDepartment/home.index愤兵，來看一下它的請求頭部

Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

這個請求頭信息比較少鹿霸，首先 Host 表示的是對象所在的主機。你也許認為這個 Host 是不需要的秆乳，因為 URL 不是已經(jīng)指明了請求對象的路徑了嗎懦鼠？這個首部行提供的信息是 Web 代理高速緩存所需要的。Connection: close 表示的是瀏覽器需要告訴服務器使用的是非持久連接屹堰。它要求服務器在發(fā)送完響應的對象后就關閉連接肛冶。User-agent: 這是請求頭用來告訴 Web 服務器，瀏覽器使用的類型是 Mozilla/5.0扯键，即 Firefox 瀏覽器睦袖。Accept-language 告訴 Web 服務器，瀏覽器想要得到對象的法語版本荣刑，前提是服務器需要支持法語類型馅笙，否則將會發(fā)送服務器的默認版本伦乔。下面我們針對主要的實體字段進行介紹（具體的可以參考 developer.mozilla.org/zh-CN/docs/… MDN 官網(wǎng)學習）

HTTP 的請求標頭分為四種： 通用標頭、請求標頭董习、響應標頭 和 實體標頭烈和，依次來進行詳解。

通用標頭

通用標頭主要有三個皿淋，分別是 Date招刹、Cache-Control 和 Connection

Date

Date 是一個通用標頭，它可以出現(xiàn)在請求標頭和響應標頭中窝趣，它的基本表示如下

Date: Wed, 21 Oct 2015 07:28:00 GMT 

表示的是格林威治標準時間疯暑，這個時間要比北京時間慢八個小時

image.png

Cache-Control

Cache-Control 是一個通用標頭，他可以出現(xiàn)在請求標頭和響應標頭中高帖，Cache-Control 的種類比較多缰儿，雖然說這是一個通用標頭畦粮，但是又一些特性是請求標頭具有的散址，有一些是響應標頭才有的。主要大類有 可緩存性宣赔、閾值性预麸、 重新驗證并重新加載 和其他特性

可緩存性是唯一響應標頭才具有的特性，我們會在響應標頭中詳述儒将。

閾值性吏祸，這個我翻譯可能不準確，它的原英文是 Expiration钩蚊，我是根據(jù)它的值來翻譯的贡翘，你看到這些值可能會覺得我翻譯的有點道理

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

Connection

Connection 決定當前事務（一次三次握手和四次揮手）完成后菊霜，是否會關閉網(wǎng)絡連接坚冀。Connection 有兩種，一種是持久性連接鉴逞，即一次事務完成后不關閉網(wǎng)絡連接

Connection: keep-alive

另一種是非持久性連接记某，即一次事務完成后關閉網(wǎng)絡連接

Connection: close

HTTP1.1 其他通用標頭如下

image.png

實體標頭

實體標頭是描述消息正文內(nèi)容的 HTTP 標頭联喘。實體標頭用于 HTTP 請求和響應中。頭部Content-Length辙纬、 Content-Language豁遭、 Content-Encoding 是實體頭。

• Content-Length 實體報頭指示實體主體的大小贺拣，以字節(jié)為單位蓖谢，發(fā)送到接收方。
• Content-Language 實體報頭描述了客戶端或者服務端能夠接受的語言譬涡，例如

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA

• Content-Encoding 這又是一個比較麻煩的屬性闪幽，這個實體報頭用來壓縮媒體類型。Content-Encoding 指示對實體應用了何種編碼涡匀。

  常見的內(nèi)容編碼有這幾種： gzip盯腌、compress、deflate陨瘩、identity 腕够，這個屬性可以應用在請求報文和響應報文中

Accept-Encoding: gzip, deflate //請求頭
Content-Encoding: gzip  //響應頭

下面是一些實體標頭字段

image.png

請求標頭

上面給出的例子請求報文的屬性比較少，下面給出一個 MDN 官網(wǎng)的例子

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

Host

Host 請求頭指明了服務器的域名（對于虛擬主機來說）舌劳，以及（可選的）服務器監(jiān)聽的TCP端口號帚湘。如果沒有給定端口號，會自動使用被請求服務的默認端口（比如請求一個 HTTP 的 URL 會自動使用80作為端口）甚淡。

Host: developer.mozilla.org

上面的 Accpet大诸、 Accept-Language、Accept-Encoding 都是屬于內(nèi)容協(xié)商的請求標頭贯卦，我們會在下面說明

Referer

HTTP Referer 屬性是請求標頭的一部分资柔，當瀏覽器向 web 服務器發(fā)送請求的時候，一般會帶上 Referer撵割，告訴服務器該網(wǎng)頁是從哪個頁面鏈接過來的贿堰，服務器因此可以獲得一些信息用于處理。

Referer: https://developer.mozilla.org/testpage.html

Upgrade-Insecure-Requests

Upgrade-Insecure-Requests 是一個請求標頭睁枕，用來向服務器端發(fā)送信號官边，表示客戶端優(yōu)先選擇加密及帶有身份驗證的響應。

Upgrade-Insecure-Requests: 1

If-Modified-Since

HTTP 的 If-Modified-Since 使其成為條件請求：

• 返回200外遇，只有在給定日期的最后一次修改資源后注簿，服務器才會以200狀態(tài)發(fā)送回請求的資源。
• 如果請求從開始以來沒有被修改過跳仿，響應會返回304并且沒有任何響應體

If-Modified-Since 通常會與 If-None-Match 搭配使用诡渴，If-Modified-Since 用于確認代理或客戶端擁有的本地資源的有效性。獲取資源的更新日期時間，可通過確認首部字段 Last-Modified 來確定妄辩。

大白話說就是如果在 Last-Modified 之后更新了服務器資源惑灵，那么服務器會響應200，如果在 Last-Modified 之后沒有更新過資源眼耀，則返回 304英支。

If-Modified-Since: Mon, 18 Jul 2016 02:36:04 GMT

If-None-Match

If-None-Match HTTP請求標頭使請求成為條件請求。 對于 GET 和 HEAD 方法哮伟，僅當服務器沒有與給定資源匹配的 ETag 時干花，服務器才會以200狀態(tài)發(fā)送回請求的資源。 對于其他方法楞黄，僅當最終現(xiàn)有資源的ETag與列出的任何值都不匹配時池凄，才會處理請求。

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"

ETag 屬于響應標頭鬼廓，后面進行介紹肿仑。

內(nèi)容協(xié)商

內(nèi)容協(xié)商機制是指客戶端和服務器端就響應的資源內(nèi)容進行交涉，然后提供給客戶端最為適合的資源碎税。內(nèi)容協(xié)商會以響應資源的語言尤慰、字符集、編碼方式等作為判斷的標準蚣录。

image.png

內(nèi)容協(xié)商主要有以下3種類型：

• 服務器驅動協(xié)商（Server-driven Negotiation）

這種協(xié)商方式是由服務器端進行內(nèi)容協(xié)商割择。服務器端會根據(jù)請求首部字段進行自動處理

• 客戶端驅動協(xié)商（Agent-driven Negotiation）

這種協(xié)商方式是由客戶端來進行內(nèi)容協(xié)商。

• 透明協(xié)商（Transparent Negotiation）

是服務器驅動和客戶端驅動的結合體萎河，是由服務器端和客戶端各自進行內(nèi)容協(xié)商的一種方法。

內(nèi)容協(xié)商的分類有很多種蕉饼，主要的幾種類型是 Accept虐杯、Accept-Charset、Accept-Encoding昧港、Accept-Language擎椰、Content-Language。

Accept

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

那么什么是 MIME 類型呢创肥？在回答這個問題前你應該先了解一下什么是 MIME

MIME: MIME (Multipurpose Internet Mail Extensions) 是描述消息內(nèi)容類型的因特網(wǎng)標準达舒。MIME 消息能包含文本、圖像叹侄、音頻巩搏、視頻以及其他應用程序專用的數(shù)據(jù)。

也就是說趾代，MIME 類型其實就是一系列消息內(nèi)容類型的集合贯底。那么 MIME 類型都有哪些呢？

文本文件： text/html撒强、text/plain禽捆、text/css笙什、application/xhtml+xml、application/xml

圖片文件： image/jpeg胚想、image/gif琐凭、image/png

視頻文件： video/mpeg、video/quicktime

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

比如淘正，如果瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定image/png臼闻，而指定可處理的 image/gif 和 image/jpeg 等圖片類型鸿吆。

一般 MIME 類型也會和 q 這個屬性一起使用，q 是什么述呐？q 表示的是權重惩淳，來看一個例子

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

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

也就是說谭羔，這是一個放置順序，權重高的在前叁温，低的在后江掩，application/xml;q=0.9 是不可分割的整體学辱。

Accept-Charset

accept-charset 屬性規(guī)定服務器處理表單數(shù)據(jù)所接受的字符集。

accept-charset 屬性允許您指定一系列字符集环形，服務器必須支持這些字符集策泣，從而得以正確解釋表單中的數(shù)據(jù)。

該屬性的值是用引號包含字符集名稱列表抬吟。如果可接受字符集與用戶所使用的字符即不相匹配的話萨咕，瀏覽器可以選擇忽略表單或是將該表單區(qū)別對待。

此屬性的默認值是 unknown火本，表示表單的字符集與包含表單的文檔的字符集相同危队。

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

Accept-Language

首部字段 Accept-Language 用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等）钙畔，以及自然語言集的相對優(yōu)先級茫陆。可一次指定多種自然語言集刃鳄。 和 Accept 首部字段一樣盅弛，按權重值 q來表示相對優(yōu)先級。

Accept-Language: en-US,en;q=0.5

請求標頭我們大概就介紹這幾種，后面會有一篇文章詳細深挖所有的響應頭的挪鹏，下面是一個響應頭的匯總见秽，基于 HTTP 1.1

image.png

響應標頭

響應標頭是可以在 HTTP 響應種使用的 HTTP 標頭，這聽起來是像一句廢話讨盒，不過確實是這樣解釋解取。并不是所有出現(xiàn)在響應中的標頭都是響應標頭。還有一些特殊的我們上面說過返顺，有通用標頭和實體標頭也會出現(xiàn)在響應標頭中禀苦，比如 Content-Length 就是一個實體標頭，但是遂鹊，在這種情況下振乏，這些實體請求通常稱為響應頭。下面以一個例子為例和你探討一下響應頭

200 OK
Access-Control-Allow-Origin: *
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Mon, 18 Jul 2016 16:06:00 GMT
Etag: "c561c68d0ba92bbeb8b0f612a9199f722e3a621a"
Keep-Alive: timeout=5, max=997
Last-Modified: Mon, 18 Jul 2016 02:36:04 GMT
Server: Apache
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
x-frame-options: DENY

響應狀態(tài)碼

首先出現(xiàn)的應該就是 200 OK秉扑，這是 HTTP 響應標頭的狀態(tài)碼慧邮，它表示著響應成功完成。HTTP 響應標頭的狀態(tài)碼有很多舟陆，并做了如下規(guī)定

以 2xx 為開頭的都表示請求成功響應误澳。

以 3xx 為開頭的都表示需要進行附加操作以完成請求

以 4xx 的響應結果表明客戶端是發(fā)生錯誤的原因所在芍碧。

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

Access-Control-Allow-Origin

一個返回的 HTTP 標頭可能會具有 Access-Control-Allow-Origin 笨忌，Access-Control-Allow-Origin 指定一個來源，它告訴瀏覽器允許該來源進行資源訪問俱病。 否則-對于沒有憑據(jù)的請求 *通配符官疲，告訴瀏覽器允許任何源訪問資源。例如亮隙，要允許源 https://mozilla.org 的代碼訪問資源途凫，可以指定：

Access-Control-Allow-Origin: https://mozilla.org
Vary: Origin

如果服務器指定單個來源而不是 *通配符的話 ，則服務器還應在 Vary 響應標頭中包含 Origin 溢吻，以向客戶端指示 服務器響應將根據(jù)原始請求標頭的值而有所不同维费。

Keep-Alive

上面我們提到，HTTP 報文標頭會分為四種煤裙，這其實是按著上下文來分類的

還有一種分類是根據(jù)代理進行分類掩完，根據(jù)代理會分為端到端頭 和 逐跳標頭

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

Connection: Keep-Alive
Keep-Alive: timeout=5, max=997

Keep-Alive 有兩個參數(shù)硼砰，它們是以逗號分隔的參數(shù)列表且蓬，每個參數(shù)由一個標識符和一個由等號 = 分隔的值組成。

timeout：指示空閑連接必須保持打開狀態(tài)的最短時間（以秒為單位）题翰。

max：指示在關閉連接之前可以在此連接上發(fā)送的最大請求數(shù)恶阴。

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

Server

服務器標頭包含有關原始服務器用來處理請求的軟件的信息豹障。

應該避免使用過于冗長和詳細的 Server 值冯事，因為它們可能會泄露內(nèi)部實施細節(jié)，這可能會使攻擊者容易地發(fā)現(xiàn)并利用已知的安全漏洞血公。例如下面這種寫法

Server: Apache/2.4.1 (Unix)

Set-Cookie

Cookie 又是另外一個領域的內(nèi)容了昵仅，我們后面文章會說道 Cookie，這里需要記住 Cookie累魔、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段摔笤，它們不是屬于 HTTP 1.1 的首部字段，但是使用率仍然很高垦写。

Transfer-Encoding

首部字段 Transfer-Encoding 規(guī)定了傳輸報文主體時采用的編碼方式吕世。

Transfer-Encoding: chunked

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

X-Frame-Options

HTTP 首部字段是可以自行擴展的梯投。所以在 Web 服務器和瀏覽器的應用上命辖，會出現(xiàn)各種非標準的首部字段况毅。

首部字段 X-Frame-Options 屬于 HTTP 響應首部，用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 Frame 標簽內(nèi)的顯示問題尔艇。其主要目的是為了防止點擊劫持（clickjacking）攻擊尔许。

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

image.png

非 HTTP/1.1 首部字段

在 HTTP 協(xié)議通信交互中使用到的首部字段漓帚，不限于 RFC2616 中定義的 47 種首部字段母债。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段尝抖，它們的使用頻率也很高毡们。 這些非正式的首部字段統(tǒng)一歸納在 RFC4229 HTTP Header Field Registrations 中。

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

HTTP 首部字段將定義成緩存代理和非緩存代理的行為昧辽，分成 2 種類型衙熔。

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

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

這些標頭必須發(fā)送給消息的最終接收者 : 請求的服務器，或響應的客戶端搅荞。中間代理必須重新傳輸未經(jīng)修改的標頭红氯，并且緩存必須存儲這些信息

Hop-by-hop（逐跳） 首部

分在此類別中的首部只對單次轉發(fā)有效，會因通過緩存或代理而不再轉發(fā)咕痛。

下面列舉了 HTTP/1.1 中的逐跳首部字段痢甘。除這 8 個首部字段之外，其他所有字段都屬于端到端首部茉贡。

Connection塞栅、Keep-Alive、Proxy-Authenticate腔丧、Proxy-Authorization放椰、Trailer、TE愉粤、Transfer-Encoding砾医、Upgrade

HTTP 的優(yōu)點和缺點

HTTP 的優(yōu)點

簡單靈活易擴展

HTTP 最重要也是最突出的優(yōu)點是 簡單、靈活衣厘、易于擴展如蚜。

HTTP 的協(xié)議比較簡單，它的主要組成就是 header + body影暴，頭部信息也是簡單的文本格式怖亭，而且 HTTP 的請求報文根據(jù)英文也能猜出來個大概的意思，降低學習門檻坤检，能夠讓更多的人研究和開發(fā) HTTP 應用。

所以期吓，在簡單的基礎上早歇，HTTP 協(xié)議又多了靈活 和 易擴展 的優(yōu)點倾芝。

HTTP 協(xié)議里的請求方法、URI箭跳、狀態(tài)碼晨另、原因短語、頭字段等每一個核心組成要素都沒有被制定死谱姓，允許開發(fā)者任意定制借尿、擴充或解釋，給予了瀏覽器和服務器最大程度的信任和自由屉来。

應用廣泛路翻、環(huán)境成熟

因為過于簡單，普及茄靠，因此應用很廣泛茂契。因為 HTTP 協(xié)議本身不屬于一種語言，它并不限定某種編程語言或者操作系統(tǒng)慨绳，所以天然具有跨語言掉冶、跨平臺的優(yōu)越性。而且脐雪，因為本身的簡單特性很容易實現(xiàn)厌小，所以幾乎所有的編程語言都有 HTTP 調用庫和外圍的開發(fā)測試工具。

隨著移動互聯(lián)網(wǎng)的發(fā)展战秋， HTTP 的觸角已經(jīng)延伸到了世界的每一個角落璧亚，從簡單的 Web 頁面到復雜的 JSON、XML 數(shù)據(jù)获询，從臺式機上的瀏覽器到手機上的各種 APP涨岁、新聞、論壇吉嚣、購物梢薪、手機游戲，你很難找到一個沒有使用 HTTP 的地方尝哆。

無狀態(tài)

無狀態(tài)其實既是優(yōu)點又是缺點秉撇。因為服務器沒有記憶能力，所以就不需要額外的資源來記錄狀態(tài)信息秋泄，不僅實現(xiàn)上會簡單一些琐馆，而且還能減輕服務器的負擔，能夠把更多的 CPU 和內(nèi)存用來對外提供服務恒序。

HTTP 的缺點

無狀態(tài)

既然服務器沒有記憶能力瘦麸，它就無法支持需要連續(xù)多個步驟的事務操作。每次都得問一遍身份信息歧胁，不僅麻煩滋饲，而且還增加了不必要的數(shù)據(jù)傳輸量厉碟。由此出現(xiàn)了 Cookie 技術。

明文

HTTP 協(xié)議里還有一把優(yōu)缺點一體的雙刃劍屠缭，就是明文傳輸箍鼓。明文意思就是協(xié)議里的報文（準確地說是 header 部分）不使用二進制數(shù)據(jù)，而是用簡單可閱讀的文本形式呵曹。

對比 TCP款咖、UDP 這樣的二進制協(xié)議，它的優(yōu)點顯而易見奄喂，不需要借助任何外部工具铐殃，用瀏覽器、Wireshark 或者 tcpdump 抓包后砍聊，直接用肉眼就可以很容易地查看或者修改背稼，為我們的開發(fā)調試工作帶來極大的便利。

當然缺點也是顯而易見的玻蝌，就是不安全蟹肘，可以被監(jiān)聽和被窺探。因為無法判斷通信雙方的身份俯树，不能判斷報文是否被更改過帘腹。

性能

HTTP 的性能不算差，但不完全適應現(xiàn)在的互聯(lián)網(wǎng)许饿，還有很大的提升空間阳欲。