帶你從HTTP入門到進階

前言css

我是一名程序員，個人主要編程語言是 Java，我更是一名 Web 開發人員，因此我必需要了解 HTTP，因此本篇文章就來帶你從 HTTP 入門到進階，看完讓你有一種恍然大悟、醍醐灌頂的感受。html

1、認識 HTTP

首先你聽的最多的應該就是 HTTP 是一種 超文本傳輸協議(Hypertext Transfer Protocol)，這你必定能說出來，可是這樣還不夠，假如你是大廠面試官，這不多是他想要的最終結果，咱們在面試的時候每每把本身知道的儘量多的說出來，纔有和麪試官談價錢的資本。那麼什麼是超文本傳輸協議？java

超文本傳輸協議能夠進行文字分割：超文本（Hypertext）、傳輸（Transfer）、協議（Protocol），它們之間的關係以下程序員

按照範圍的大小 協議 > 傳輸 > 超文本。下面就分別對這三個名次作一個解釋。web

一、什麼是超文本

在互聯網早期的時候，咱們輸入的信息只能保存在本地，沒法和其餘電腦進行交互。咱們保存的信息一般都以文本即簡單字符的形式存在，文本是一種可以被計算機解析的有意義的二進制數據包。而隨着互聯網的高速發展，兩臺電腦之間可以進行數據的傳輸後，人們不知足只能在兩臺電腦之間傳輸文字，還想要傳輸圖片、音頻、視頻，甚至點擊文字或圖片可以進行超連接的跳轉，那麼文本的語義就被擴大了，這種語義擴大後的文本就被稱爲超文本(Hypertext)。面試

二、什麼是傳輸

那麼咱們上面說到，兩臺計算機之間會造成互聯關係進行通訊，咱們存儲的超文本會被解析成爲二進制數據包，由傳輸載體（例如同軸電纜，電話線，光纜）負責把二進制數據包由計算機終端傳輸到另外一個終端的過程（對終端的詳細解釋能夠參考 你說你懂互聯網，那這些你知道麼？這篇文章）稱爲傳輸(transfer)。數據庫

一般咱們把傳輸數據包的一方稱爲請求方，把接到二進制數據包的一方稱爲應答方。請求方和應答方能夠進行互換，請求方也能夠做爲應答方接受數據，應答方也能夠做爲請求方請求數據，它們之間的關係以下編程

如圖所示，A 和 B 是兩個不一樣的端系統，它們之間能夠做爲信息交換的載體存在，剛開始的時候是 A 做爲請求方請求與 B 交換信息，B 做爲響應的一方提供信息；隨着時間的推移，B 也能夠做爲請求方請求 A 交換信息，那麼 A 也能夠做爲響應方響應 B 請求的信息。小程序

三、什麼是協議

協議這個名詞不只侷限於互聯網範疇，也體如今平常生活中，好比情侶雙方約定好在哪一個地點吃飯，這個約定也是一種協議，好比你應聘成功了，企業會和你簽定勞動合同，這種雙方的僱傭關係也是一種 協議。注意本身一我的對本身的約定不能成爲協議，協議的前提條件必須是多人約定。瀏覽器

那麼網絡協議是什麼呢？

網絡協議就是網絡中(包括互聯網)傳遞、管理信息的一些規範。如同人與人之間相互交流是須要遵循必定的規矩同樣，計算機之間的相互通訊須要共同遵照必定的規則，這些規則就稱爲網絡協議。

沒有網絡協議的互聯網是混亂的，就和人類社會同樣，人不能想怎麼樣就怎麼樣，你的行爲約束是受到法律的約束的；那麼互聯網中的端系統也不能本身想發什麼發什麼，也是須要受到通訊協議約束的。

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

 

2、與 HTTP 有關的組件

隨着網絡世界演進，HTTP 協議已經幾乎成爲不可替代的一種協議，在瞭解了 HTTP 的基本組成後，下面再來帶你進一步認識一下 HTTP 協議。

一、網絡模型

網絡是一個複雜的系統，不只包括大量的應用程序、端系統、通訊鏈路、分組交換機等，還有各類各樣的協議組成，那麼如今咱們就來聊一下網絡中的協議層次。

爲了給網絡協議的設計提供一個結構，網絡設計者以分層(layer)的方式組織協議，每一個協議屬於層次模型之一。每一層都是向它的上一層提供服務(service)，即所謂的服務模型(service model)。每一個分層中全部的協議稱爲 協議棧(protocol stack)。因特網的協議棧由五個部分組成：物理層、鏈路層、網絡層、運輸層和應用層。咱們採用自上而下的方法研究其原理，也就是應用層 -> 物理層的方式。

二、應用層

應用層是網絡應用程序和網絡協議存放的分層，因特網的應用層包括許多協議，例如咱們學 web 離不開的 HTTP，電子郵件傳送協議 SMTP、端系統文件上傳協議 FTP、還有爲咱們進行域名解析的 DNS 協議。應用層協議分佈在多個端系統上，一個端系統應用程序與另一個端系統應用程序交換信息分組，咱們把位於應用層的信息分組稱爲 報文(message)。

三、運輸層

因特網的運輸層在應用程序斷點之間傳送應用程序報文，在這一層主要有兩種傳輸協議 TCP和 UDP，利用這二者中的任何一個都可以傳輸報文，不過這兩種協議有巨大的不一樣。

TCP 向它的應用程序提供了面向鏈接的服務，它可以控制並確認報文是否到達，並提供了擁塞機制來控制網絡傳輸，所以當網絡擁塞時，會抑制其傳輸速率。

UDP 協議向它的應用程序提供了無鏈接服務。它不具有可靠性的特徵，沒有流量控制，也沒有擁塞控制。咱們把運輸層的分組稱爲 報文段(segment)

四、網絡層

因特網的網絡層負責將稱爲 數據報(datagram) 的網絡分層從一臺主機移動到另外一臺主機。網絡層一個很是重要的協議是 IP 協議，全部具備網絡層的因特網組件都必須運行 IP 協議，IP 協議是一種網際協議，除了 IP 協議外，網絡層還包括一些其餘網際協議和路由選擇協議，通常把網絡層就稱爲 IP 層，由此可知 IP 協議的重要性。

五、鏈路層

如今咱們有應用程序通訊的協議，有了給應用程序提供運輸的協議，還有了用於約定發送位置的 IP 協議，那麼如何才能真正的發送數據呢？爲了將分組從一個節點（主機或路由器）運輸到另外一個節點，網絡層必須依靠鏈路層提供服務。鏈路層的例子包括以太網、WiFi 和電纜接入的 DOCSIS 協議，由於數據從源目的地傳送一般須要通過幾條鏈路，一個數據包可能被沿途不一樣的鏈路層協議處理，咱們把鏈路層的分組稱爲 幀(frame)

六、物理層

雖然鏈路層的做用是將幀從一個端系統運輸到另外一個端系統，而物理層的做用是將幀中的一個個 比特 從一個節點運輸到另外一個節點，物理層的協議仍然使用鏈路層協議，這些協議與實際的物理傳輸介質有關，例如，以太網有不少物理層協議：關於雙絞銅線、關於同軸電纜、關於光纖等等。

五層網絡協議的示意圖以下

七、OSI 模型

咱們上面討論的計算網絡協議模型不是惟一的 協議棧，ISO（國際標準化組織）提出來計算機網絡應該按照7層來組織，那麼7層網絡協議棧與5層的區別在哪裏？

從圖中能夠一眼看出，OSI 要比上面的網絡模型多了 表示層 和 會話層，其餘層基本一致。表示層主要包括數據壓縮和數據加密以及數據描述，數據描述使得應用程序沒必要擔憂計算機內部存儲格式的問題，而會話層提供了數據交換的定界和同步功能，包括創建檢查點和恢復方案。

八、瀏覽器

就如同各大郵箱使用電子郵件傳送協議 SMTP 同樣，瀏覽器是使用 HTTP 協議的主要載體，說到瀏覽器，你能想起來幾種？是的，隨着網景大戰結束後，瀏覽器迅速發展，至今已經出現過的瀏覽器主要有

瀏覽器正式的名字叫作 Web Broser，顧名思義，就是檢索、查看互聯網上網頁資源的應用程序，名字裏的 Web，實際上指的就是 World Wide Web，也就是萬維網。

咱們在地址欄輸入URL（即網址），瀏覽器會向DNS（域名服務器，後面會說）提供網址，由它來完成 URL 到 IP 地址的映射。而後將請求你的請求提交給具體的服務器，在由服務器返回咱們要的結果（以HTML編碼格式返回給瀏覽器），瀏覽器執行HTML編碼，將結果顯示在瀏覽器的正文。這就是一個瀏覽器發起請求和接受響應的過程。

九、Web 服務器

Web 服務器的正式名稱叫作 Web Server，Web 服務器通常指的是網站服務器，上面說到瀏覽器是 HTTP 請求的發起方，那麼 Web 服務器就是 HTTP 請求的應答方，Web 服務器能夠向瀏覽器等 Web 客戶端提供文檔，也能夠放置網站文件，讓全世界瀏覽；能夠放置數據文件，讓全世界下載。目前最主流的三個Web服務器是Apache、 Nginx 、IIS。

十、CDN

CDN的全稱是Content Delivery Network，即內容分發網絡，它應用了 HTTP 協議裏的緩存和代理技術，代替源站響應客戶端的請求。CDN 是構建在現有網絡基礎之上的網絡，它依靠部署在各地的邊緣服務器，經過中心平臺的負載均衡、內容分發、調度等功能模塊，使用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。

打比方說你要去亞馬遜上買書，以前你只能經過購物網站購買後從美國發貨過海關等重重關卡送到你的家裏，如今在中國創建一個亞馬遜分基地，你就不用經過美國進行郵寄，從中國就能把書儘快給你送到。

十一、WAF

WAF 是一種 Web 應用程序防禦系統（Web Application Firewall，簡稱 WAF），它是一種經過執行一系列針對HTTP / HTTPS的安全策略來專門爲Web應用提供保護的一款產品，它是應用層面的防火牆，專門檢測 HTTP 流量，是防禦 Web 應用的安全技術。

WAF 一般位於 Web 服務器以前，能夠阻止如 SQL 注入、跨站腳本等攻擊，目前應用較多的一個開源項目是 ModSecurity，它可以徹底集成進 Apache 或 Nginx。

十二、WebService

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

Web Service 是一種由 W3C 定義的應用服務開發規範，使用 client-server 主從架構，一般使用 WSDL 定義服務接口，使用 HTTP 協議傳輸 XML 或 SOAP 消息，它是一個基於 Web（HTTP）的服務架構技術，既能夠運行在內網，也能夠在適當保護後運行在外網。

1三、HTML

HTML 稱爲超文本標記語言，是一種標識性的語言。它包括一系列標籤．經過這些標籤能夠將網絡上的文檔格式統一，使分散的 Internet 資源鏈接爲一個邏輯總體。HTML 文本是由 HTML 命令組成的描述性文本，HTML 命令能夠說明文字，圖形、動畫、聲音、表格、連接等。

1四、Web 頁面構成

Web 頁面（Web page）也叫作文檔，是由一個個對象組成的。一個對象(Objecy) 只是一個文件，好比一個 HTML 文件、一個 JPEG 圖形、一個 Java 小程序或一個視頻片斷，它們在網絡中能夠經過 URL 地址尋址。多數的 Web 頁面含有一個 HTML 基本文件 以及幾個引用對象。

舉個例子，若是一個 Web 頁面包含 HTML 文件和5個 JPEG 圖形，那麼這個 Web 頁面就有6個對象：一個 HTML 文件和5個 JPEG 圖形。HTML 基本文件經過 URL 地址引用頁面中的其餘對象。

 

3、與 HTTP 有關的協議

在互聯網中，任何協議都不會單獨的完成信息交換，HTTP 也同樣。雖然 HTTP 屬於應用層的協議，可是它仍然須要其餘層次協議的配合完成信息的交換，那麼在完成一次 HTTP 請求和響應的過程當中，須要哪些協議的配合呢？一塊兒來看一下

一、TCP/IP

TCP/IP 協議你必定聽過，TCP/IP 咱們通常稱之爲協議簇，什麼意思呢？就是 TCP/IP 協議簇中不只僅只有 TCP 協議和 IP 協議，它是一系列網絡通訊協議的統稱。而其中最核心的兩個協議就是 TCP / IP 協議，其餘的還有 UDP、ICMP、ARP 等等，共同構成了一個複雜但有層次的協議棧。

TCP 協議的全稱是 Transmission Control Protocol 的縮寫，意思是傳輸控制協議，HTTP 使用 TCP 做爲通訊協議，這是由於 TCP 是一種可靠的協議，而可靠能保證數據不丟失。

IP 協議的全稱是 Internet Protocol 的縮寫，它主要解決的是通訊雙方尋址的問題。IP 協議使用 IP 地址 來標識互聯網上的每一臺計算機，能夠把 IP 地址想象成爲你手機的電話號碼，你要與他人通話必須先要知道他人的手機號碼，計算機網絡中信息交換必須先要知道對方的 IP 地址。（關於 TCP 和 IP 更多的討論咱們會在後面詳解）

二、DNS

你有沒有想過爲何你能夠經過鍵入 www.google.com 就可以獲取你想要的網站？咱們上面說到，計算機網絡中的每一個端系統都有一個 IP 地址存在，而把 IP 地址轉換爲便於人類記憶的協議就是 DNS 協議。

DNS 的全稱是域名系統（Domain Name System，縮寫：DNS），它做爲將域名和 IP 地址相互映射的一個分佈式數據庫，可以令人更方便地訪問互聯網。

三、URI / URL

咱們上面提到，你能夠經過輸入 www.google.com 地址來訪問谷歌的官網，那麼這個地址有什麼規定嗎？我怎麼輸均可以？AAA.BBB.CCC 是否是也行？固然不是的，你輸入的地址格式必需要知足 URI 的規範。

URI的全稱是（Uniform Resource Identifier），中文名稱是統一資源標識符，使用它就可以惟一地標記互聯網上資源。

URL的全稱是（Uniform Resource Locator），中文名稱是統一資源定位符，也就是咱們俗稱的網址，它其實是 URI 的一個子集。

URI 不只包括 URL，還包括 URN（統一資源名稱），它們之間的關係以下

四、HTTPS

HTTP 通常是明文傳輸，很容易被攻擊者竊取重要信息，鑑於此，HTTPS 應運而生。HTTPS 的全稱爲 （Hyper Text Transfer Protocol over SecureSocket Layer），全稱有點長，HTTPS 和 HTTP 有很大的不一樣在於 HTTPS 是以安全爲目標的 HTTP 通道，在 HTTP 的基礎上經過傳輸加密和身份認證保證了傳輸過程的安全性。HTTPS 在 HTTP 的基礎上增長了 SSL 層，也就是說 HTTPS = HTTP + SSL。（這塊咱們後面也會詳談 HTTPS）

 

4、HTTP 請求響應過程

你是否是很好奇，當你在瀏覽器中輸入網址後，到底發生了什麼事情？你想要的內容是如何展示出來的？讓咱們經過一個例子來探討一下，咱們假設訪問的 URL 地址爲 http://www.someSchool.edu/someDepartment/home.index，當咱們輸入網址並點擊回車時，瀏覽器內部會進行以下操做

• 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 客戶端會把對應的資源經過顯示器呈現給用戶。

至此，鍵入網址再按下回車的全過程就結束了。上述過程描述的是一種簡單的請求-響應全過程，真實的請求-響應狀況可能要比上面描述的過程複雜不少。

 

5、HTTP 請求特徵

從上面整個過程當中咱們能夠總結出 HTTP 進行分組傳輸是具備如下特徵

• 支持客戶-服務器模式

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有 GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲 HTTP 協議簡單，使得 HTTP 服務器的程序規模小，於是通訊速度很快。

• 靈活：HTTP 容許傳輸任意類型的數據對象。正在傳輸的類型由 Content-Type 加以標記。

• 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

• 無狀態：HTTP 協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

 

6、詳解 HTTP 報文

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

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

• 起始行（start line）：描述請求或響應的基本信息；

• 頭部字段（header）：使用 key-value 形式更詳細地說明報文；

• 消息正文（entity）：實際傳輸的數據，它不必定是純文本，能夠是圖片、視頻等二進制數據。

其中起始行和頭部字段併成爲 請求頭 或者 響應頭，統稱爲 Header；消息正文也叫作實體，稱爲 body。HTTP 協議規定每次發送的報文必需要有 Header，可是能夠沒有 body，也就是說頭信息是必須的，實體信息能夠沒有。並且在 header 和 body 之間必需要有一個空行（CRLF），若是用一幅圖來表示一下的話，我以爲應該是下面這樣

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

如圖，這是 http://www.someSchool.edu/someDepartment/home.index 請求的請求頭，經過觀察這個 HTTP 報文咱們就可以學到不少東西，首先，咱們看到報文是用普通 ASCII 文本書寫的，這樣保證人可以能夠看懂。而後，咱們能夠看到每一行和下一行之間都會有換行，並且最後一行（請求頭部後）再加上一個回車換行符。

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

一、HTTP 請求方法

HTTP 請求方法通常分爲 8 種，它們分別是

• 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，傳輸層安全）協議把通訊內容加 密後經網絡隧道傳輸。

咱們通常最經常使用的方法也就是 GET 方法和 POST 方法，其餘方法暫時瞭解便可。下面是 HTTP1.0 和 HTTP1.1 支持的方法清單

二、HTTP 請求 URL

HTTP 協議使用 URI 定位互聯網上的資源。正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。URL 帶有請求對象的標識符。在上面的例子中，瀏覽器正在請求對象 /somedir/page.html 的資源。

咱們再經過一個完整的域名解析一下 URL

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

首先出場的是 http

http://告訴瀏覽器使用何種協議。對於大部分 Web 資源，一般使用 HTTP 協議或其安全版本，HTTPS 協議。另外，瀏覽器也知道如何處理其餘協議。例如， mailto: 協議指示瀏覽器打開郵件客戶端；ftp:協議指示瀏覽器處理文件傳輸。

第二個出場的是 主機

www.example.com 既是一個域名，也表明管理該域名的機構。它指示了須要向網絡上的哪一臺主機發起請求。固然，也能夠直接向主機的 IP address 地址發起請求。但直接使用 IP 地址的場景並不常見。

第三個出場的是 端口

咱們前面說到，兩個主機之間要發起 TCP 鏈接須要兩個條件，主機 + 端口。它表示用於訪問 Web 服務器上資源的入口。若是訪問的該 Web 服務器使用HTTP協議的標準端口（HTTP爲80，HTTPS爲443）授予對其資源的訪問權限，則一般省略此部分。不然端口就是 URI 必須的部分。

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

第四個出場的是 路徑

/path/to/myfile.html 是 Web 服務器上資源的路徑。以端口後面的第一個 / 開始，到 ? 號以前結束，中間的 每個/ 都表明了層級（上下級）關係。這個 URL 的請求資源是一個 html 頁面。

緊跟着路徑後面的是 查詢參數

?key1=value1&key2=value2 是提供給 Web 服務器的額外參數。若是是 GET 請求，通常帶有請求 URL 參數，若是是 POST 請求，則不會在路徑後面直接加參數。這些參數是用 & 符號分隔的鍵/值對列表。key1 = value1 是第一對，key2 = value2 是第二對參數

緊跟着參數的是錨點

#SomewhereInTheDocument 是資源自己的某一部分的一個錨點。錨點表明資源內的一種「書籤」，它給予瀏覽器顯示位於該「加書籤」點的內容的指示。例如，在HTML文檔上，瀏覽器將滾動到定義錨點的那個點上；在視頻或音頻文檔上，瀏覽器將轉到錨點表明的那個時間。值得注意的是 # 號後面的部分，也稱爲片斷標識符，永遠不會與請求一塊兒發送到服務器。

三、HTTP 版本

表示報文使用的 HTTP 協議版本。

四、請求頭部

這部份內容只是大體介紹一下，內容較多，後面會再以一篇文章詳述

在表述完了起始行以後咱們再來看一下請求頭部，如今咱們向上找，找到http://www.someSchool.edu/someDepartment/home.index，來看一下它的請求頭部

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

這個請求頭信息比較少，首先 Host 表示的是對象所在的主機。你也許認爲這個 Host 是不須要的，由於 URL 不是已經指明瞭請求對象的路徑了嗎？這個首部行提供的信息是 Web 代理高速緩存所須要的。Connection: close 表示的是瀏覽器須要告訴服務器使用的是非持久鏈接。它要求服務器在發送完響應的對象後就關閉鏈接。User-agent: 這是請求頭用來告訴 Web 服務器，瀏覽器使用的類型是 Mozilla/5.0，即 Firefox 瀏覽器。Accept-language 告訴 Web 服務器，瀏覽器想要獲得對象的法語版本，前提是服務器須要支持法語類型，不然將會發送服務器的默認版本。下面咱們針對主要的實體字段進行介紹（具體的能夠參考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers MDN 官網學習）

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

通用標頭

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

Date

Date 是一個通用標頭，它能夠出如今請求標頭和響應標頭中，它的基本表示以下

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

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

Cache-Control

Cache-Control 是一個通用標頭，他能夠出如今請求標頭和響應標頭中，Cache-Control 的種類比較多，雖說這是一個通用標頭，可是有一些特性是請求標頭具備的，有一些是響應標頭纔有的。主要大類有 可緩存性、閾值性、 從新驗證並從新加載 和其餘特性

可緩存性是惟一響應標頭才具備的特性，咱們會在響應標頭中詳述。

閾值性，這個我翻譯可能不許確，它的原英文是 Expiration，我是根據它的值來翻譯的，你看到這些值可能會以爲我翻譯的有點道理

• max-age: 資源被認爲仍然有效的最長時間，與 Expires 不一樣，這個請求是相對於 request標頭的時間，而 Expires 是相對於響應標頭。（請求標頭）

• s-maxage: 重寫了 max-age 和 Expires 請求頭，僅僅適用於共享緩存，被私有緩存所忽略（這塊不理解，看完響應頭的 Cache-Control 再進行理解）（請求標頭）

• max-stale：表示客戶端將接受的最大響應時間，以秒爲單位。（響應標頭）

• min-fresh:  表示客戶端但願響應在指定的最小時間內有效。（響應標頭）

Connection

Connection 決定當前事務（一次三次握手和四次揮手）完成後，是否會關閉網絡鏈接。Connection 有兩種，一種是持久性鏈接，即一次事務完成後不關閉網絡鏈接

Connection: keep-alive

另外一種是非持久性鏈接，即一次事務完成後關閉網絡鏈接

Connection: close

HTTP1.1 其餘通用標頭以下

實體標頭

實體標頭是描述消息正文內容的 HTTP 標頭。實體標頭用於 HTTP 請求和響應中。頭部Content-Length、 Content-Language、 Content-Encoding 是實體頭。

• Content-Length 實體報頭指示實體主體的大小，以字節爲單位，發送到接收方。

• Content-Language 實體報頭描述了客戶端或者服務端可以接受的語言，例如

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

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

常見的內容編碼有這幾種： gzip、compress、deflate、identity ，這個屬性能夠應用在請求報文和響應報文中

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

下面是一些實體標頭字段

請求標頭

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

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 請求頭指明瞭服務器的域名（對於虛擬主機來講），以及（可選的）服務器監聽的TCP端口號。若是沒有給定端口號，會自動使用被請求服務的默認端口（好比請求一個 HTTP 的 URL 會自動使用80做爲端口）。

Host: developer.mozilla.org

上面的 Accpet、 Accept-Language、Accept-Encoding 都是屬於內容協商的請求標頭，咱們會在下面說明

Referer

HTTP Referer 屬性是請求標頭的一部分，當瀏覽器向 web 服務器發送請求的時候，通常會帶上 Referer，告訴服務器該網頁是從哪一個頁面連接過來的，服務器所以能夠得到一些信息用於處理。

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

Upgrade-Insecure-Requests

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

Upgrade-Insecure-Requests: 1

If-Modified-Since

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

• 返回200，只有在給定日期的最後一次修改資源後，服務器纔會以200狀態發送回請求的資源。

• 若是請求從開始以來沒有被修改過，響應會返回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狀態發送回請求的資源。對於其餘方法，僅當最終現有資源的ETag與列出的任何值都不匹配時，纔會處理請求。

If-None-Match: "c561c68d0ba92bbeb8b0fff2a9199f722e3a621a"

ETag 屬於響應標頭，後面進行介紹。

內容協商

內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的標準。

內容協商主要有如下3種類型：

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

這種協商方式是由服務器端進行內容協商。服務器端會根據請求首部字段進行自動處理

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

這種協商方式是由客戶端來進行內容協商。

• 透明協商（Transparent Negotiation）

是服務器驅動和客戶端驅動的結合體，是由服務器端和客戶端各自進行內容協商的一種方法。

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

Accept

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

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

「

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

也就是說，MIME 類型其實就是一系列消息內容類型的集合。那麼 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

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

也就是說，這是一個放置順序，權重高的在前，低的在後，application/xml;q=0.9 是不可分割的總體。

Accept-Charset

accept-charset 屬性規定服務器處理表單數據所接受的字符集。

accept-charset 屬性容許您指定一系列字符集，服務器必須支持這些字符集，從而得以正確解釋表單中的數據。

該屬性的值是用引號包含字符集名稱列表。若是可接受字符集與用戶所使用的字符即不相匹配的話，瀏覽器能夠選擇忽略表單或是將該表單區別對待。

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

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

Accept-Language

首部字段 Accept-Language 用來告知服務器用戶代理可以處理的天然語言集（指中文或英文等），以及天然語言集的相對優先級。可一次指定多種天然語言集。和 Accept 首部字段同樣，按權重值 q來表示相對優先級。

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

請求標頭咱們大概就介紹這幾種，後面會有一篇文章詳細深挖全部的響應頭的，下面是一個響應頭的彙總，基於 HTTP 1.1

響應標頭

響應標頭是能夠在 HTTP 響應種使用的 HTTP 標頭，這聽起來是像一句廢話，不過確實是這樣解釋。並非全部出如今響應中的標頭都是響應標頭。還有一些特殊的咱們上面說過，有通用標頭和實體標頭也會出如今響應標頭中，好比 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

響應狀態碼

首先出現的應該就是 200 OK，這是 HTTP 響應標頭的狀態碼，它表示着響應成功完成。HTTP 響應標頭的狀態碼有不少，並作了以下規定

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

以 3xx 爲開頭的都表示須要進行附加操做以完成請求

以 4xx 的響應結果代表客戶端是發生錯誤的緣由所在。

以 5xx 爲開頭的響應標頭都表示服務器自己發生錯誤

Access-Control-Allow-Origin

一個返回的 HTTP 標頭可能會具備 Access-Control-Allow-Origin ，Access-Control-Allow-Origin指定一個來源，它告訴瀏覽器容許該來源進行資源訪問。不然-對於沒有憑據的請求 *通配符，告訴瀏覽器容許任何源訪問資源。例如，要容許源 https://mozilla.org 的代碼訪問資源，能夠指定：

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

若是服務器指定單個來源而不是 *通配符的話 ，則服務器還應在 Vary 響應標頭中包含Origin ，以向客戶端指示 服務器響應將根據原始請求標頭的值而有所不一樣。

Keep-Alive

上面咱們提到，HTTP 報文標頭會分爲四種，這實際上是按着上下文來分類的

還有一種分類是根據代理進行分類，根據代理會分爲端到端頭 和 逐跳標頭

而 Keep-Alive 表示的是 Connection 非持續鏈接的存活時間，以下

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

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

timeout：指示空閒鏈接必須保持打開狀態的最短期（以秒爲單位）。

max：指示在關閉鏈接以前能夠在此鏈接上發送的最大請求數。

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

Server

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

應該避免使用過於冗長和詳細的 Server 值，由於它們可能會泄露內部實施細節，這可能會使攻擊者容易地發現並利用已知的安全漏洞。例以下面這種寫法

Server: Apache/2.4.1 (Unix)

Set-Cookie

Cookie 又是另一個領域的內容了，咱們後面文章會說道 Cookie，這裏須要記住 Cookie、Set-Cookie 和 Content-Disposition 等在其餘 RFC 中定義的首部字段，它們不是屬於 HTTP 1.1 的首部字段，可是使用率仍然很高。

Transfer-Encoding

首部字段 Transfer-Encoding 規定了傳輸報文主體時採用的編碼方式。

Transfer-Encoding: chunked

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

X-Frame-Options

HTTP 首部字段是能夠自行擴展的。因此在 Web 服務器和瀏覽器的應用上，會出現各類非標準的首部字段。

首部字段 X-Frame-Options 屬於 HTTP 響應首部，用於控制網站內容在其餘 Web 網站的 Frame 標籤內的顯示問題。其主要目的是爲了防止點擊劫持（clickjacking）攻擊。

下面是一個響應頭的彙總，基於 HTTP 1.1

五、非 HTTP/1.1 首部字段

在 HTTP 協議通訊交互中使用到的首部字段，不限於 RFC2616 中定義的 47 種首部字段。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其餘 RFC 中定義的首部字段，它們的使用頻率也很高。這些非正式的首部字段統一概括在 RFC4229 HTTP Header Field Registrations 中。

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

HTTP 首部字段將定義成緩存代理和非緩存代理的行爲，分紅 2 種類型。

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

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

這些標頭必須發送給消息的最終接收者 : 請求的服務器，或響應的客戶端。中間代理必須從新傳輸未經修改的標頭，而且緩存必須存儲這些信息

Hop-by-hop（逐跳） 首部

分在此類別中的首部只對單次轉發有效，會因經過緩存或代理而再也不轉發。

下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段以外，其餘全部字段都屬於端到端首部。

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

 

7、HTTP 的優勢和缺點

一、HTTP 的優勢

簡單靈活易擴展

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

HTTP 的協議比較簡單，它的主要組成就是 header + body，頭部信息也是簡單的文本格式，並且 HTTP 的請求報文根據英文也能猜出來個大概的意思，下降學習門檻，可以讓更多的人研究和開發 HTTP 應用。

因此，在簡單的基礎上，HTTP 協議又多了靈活 和 易擴展 的優勢。

HTTP 協議裏的請求方法、URI、狀態碼、緣由短語、頭字段等每個核心組成要素都沒有被制定死，容許開發者任意定製、擴充或解釋，給予了瀏覽器和服務器最大程度的信任和自由。

應用普遍、環境成熟

由於過於簡單，普及，所以應用很普遍。由於 HTTP 協議自己不屬於一種語言，它並不限定某種編程語言或者操做系統，因此自然具備跨語言、跨平臺的優越性。並且，由於自己的簡單特性很容易實現，因此幾乎全部的編程語言都有 HTTP 調用庫和外圍的開發測試工具。

隨着移動互聯網的發展， HTTP 的觸角已經延伸到了世界的每個角落，從簡單的 Web 頁面到複雜的 JSON、XML 數據，從臺式機上的瀏覽器到手機上的各類 APP、新聞、論壇、購物、手機遊戲，你很難找到一個沒有使用 HTTP 的地方。

無狀態

無狀態其實既是優勢又是缺點。由於服務器沒有記憶能力，因此就不須要額外的資源來記錄狀態信息，不只實現上會簡單一些，並且還能減輕服務器的負擔，可以把更多的 CPU 和內存用來對外提供服務。

二、HTTP 的缺點

無狀態

既然服務器沒有記憶能力，它就沒法支持須要連續多個步驟的事務操做。每次都得問一遍身份信息，不只麻煩，並且還增長了沒必要要的數據傳輸量。由此出現了 Cookie 技術。

明文

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

對比 TCP、UDP 這樣的二進制協議，它的優勢顯而易見，不須要藉助任何外部工具，用瀏覽器、Wireshark 或者 tcpdump 抓包後，直接用肉眼就能夠很容易地查看或者修改，爲咱們的開發調試工做帶來極大的便利。

固然缺點也是顯而易見的，就是不安全，能夠被監聽和被窺探。由於沒法判斷通訊雙方的身份，不能判斷報文是否被更改過。

性能

HTTP 的性能不算差，但不徹底適應如今的互聯網，還有很大的提高空間。

參考資料：

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Technical_overview

《極客時間》- 透視 HTTP 協議

https://developer.mozilla.org/en-US/docs/Web/HTTP

https://baike.baidu.com/item/WEB服務器/8390210?fr=aladdin

https://baike.baidu.com/item/內容分發網絡/4034265

https://baike.baidu.com/item/HTML/97049?fr=aladdin

https://www.jianshu.com/p/3dd8f1879acb

《計算機網絡-自頂向下方法》

《圖解 HTTP》

HTTP協議的內容協商

https://www.w3school.com.cn/tags/att_form_accept_charset.asp