HTTP總結（簡介、狀態碼和各版本對比）

1 http 簡介與具體過程

1.1 簡介

HTTP協議是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫,是基於客戶端/服務端（C/S）的架構模型，通過一個可靠的連結來交換資訊，是一個無狀態、無連線、媒體獨立的請求/響應協議。用於從全球資訊網（WWW:World Wide Web ）伺服器傳輸超文字到本地瀏覽器的傳送協議

HTTP基於TCP/IP通訊協議來傳遞資料（HTML 檔案, 圖片檔案, 查詢結果等）。

1.2 HTTP 工作原理

HTTP協議工作於客戶端-服務端架構上。瀏覽器作為HTTP客戶端通過URL向HTTP服務端即WEB伺服器傳送所有請求。

Web伺服器有：Apache伺服器，IIS伺服器（Internet Information Services）等。

Web伺服器根據接收到的請求後，向客戶端傳送響應資訊。

HTTP預設埠號為80，但是你也可以改為8080或者其他埠。

1.3 特點

• HTTP是無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
• HTTP是媒體獨立的：這意味著，只要客戶端和伺服器知道如何處理的資料內容，任何型別的資料都可以通過HTTP傳送。客戶端以及伺服器指定使用適合的MIME-type內容型別。
• HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議**對於事務處理沒有記憶能力。**缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

1.4 工作概況

2 request 和 response 報文

Request

請求行（request line）、請求頭部（header）、空行和請求資料四個部分組成，下圖給出了請求報文的一般格式。

Response

響應也由四個部分組成，分別是：狀態行、訊息報頭、空行和響應正文。

3. HTTP方法的安全性和冪等性

安全性，僅指該方法的***多次呼叫不會產生副作用***，不涉及傳統意義上的“安全”，這裡的***副作用是指資源狀態***。即，安全的方法不會修改資源狀態，儘管多次呼叫的返回值可能不一樣(被其他非安全方法修改過)。

冪等性，是指該方法***多次呼叫返回的效果(形式)一致***，客戶端可以重複呼叫並且期望同樣的結果。冪等的含義類似於程式語言中的setter方法[1]，一次呼叫和多次呼叫產生的效果是一致的，都是對一個變數進行賦值。安全性和冪等性含義有些接近，容易搞混。

HTTP方法的安全性和冪等性見下表 :

方法名	安全性	冪等性
GET	是	是
HEAD	是	是
OPTIONS	是	是
DELETE	否	是
PUT	否	是
POST	否	否

（1）可以認為安全的方法都是隻讀的方法(GET, HEAD, OPTIONS)

（2）DELETE方法的語義表示刪除伺服器上的一個資源，第一次刪除成功後該資源就不存在了，資源狀態改變了，所以DELETE方法不具備安全特性。然而***HTTP協議規定DELETE方法是冪等的***，每次刪除該資源都要返回狀態碼200 OK，伺服器端要實現冪等的DELETE方法，必須記錄所有已刪除資源的後設資料(Metadata),否則，第二次刪除後返回的響應碼就會類似404 Not Found了。

（3）PUT和POST方法語義中都有修改資源狀態的意思，因此都不是安全的。但是PUT方法是冪等的，POST方法不是冪等的，這麼設計的理由是：

• HTTP協議規定，POST方法修改資源狀態時，URL指示的是該資源的父級資源，待***修改資源的ID資訊在請求體中攜帶***。而PUT方法修改資源狀態時，URL直接指示待修改資源。因此，同樣是建立資源，重複提交POST請求可能產生兩個不同的資源，而重複提交PUT請求只會對其URL中指定的資源起作用，也就是隻會建立一個資源。

4 HTTP 狀態碼

參考-部落格

騰訊雲社群——狀態碼

1xx 表示通知資訊的，如請求收到了或正在進行處理，需要請求者繼續執行操作。

2xx 表示成功，如接受或知道了。

3xx 表示重定向，表示要完成請求還必須採取進一步的行動。

4xx 表示客戶的差錯，如請求中有錯誤的語法或不能完成。

5xx 表示伺服器的差錯，如伺服器失效無法完成請求。

4.1 常見狀態碼

• 100 Continue

  1. HTTP 100 Continue資訊狀態響應程式碼表明目前為止的所有內容都是正常的，並且客戶端應該繼續請求或者如果它已經完成則忽略它。
  2. 狀態：100 Continue

• 101 Switching Protocols

  1. HTTP 101 Switching Protocols響應程式碼指示伺服器正在根據傳送包括Upgrade請求頭的訊息的客戶端的請求 切換到的協議。
  2. 伺服器在此響應中包含一個Upgrade響應標題，指示它切換到的協議。
  3. 狀態 101 Switching Protocols

• 200 OK 伺服器成功處理了請求

• 204 請求被受理但沒有資源可以返回

• 206

  1. HTTP 206 Partial Content成功狀態響應程式碼指示請求已成功並且主體包含所請求的資料範圍，如Range請求標題中所述。如果只有一個範圍，則整個響應Content-Type設定為文件的型別，並提供一個Content-Range。如果傳送了幾個範圍，則Content-Type設定為multipart/byteranges並且每個片段都覆蓋一個範圍，並且使用Content-Range和Content-Type對其進行描述。

  2. 狀態 ：206 Partial Content

  3. 例項：

     包含一個範圍的響應：
     HTTP/1.1 206 Partial Content
     Date: Wed, 15 Nov 2015 06:25:24 GMT
     Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
     Content-Range: bytes 21010-47021/47022
     Content-Length: 26012
     Content-Type: image/gif
     ... 26012 bytes of partial image data ...
     
     包含以下幾個範圍的響應：
     HTTP/1.1 206 Partial Content
     Date: Wed, 15 Nov 2015 06:25:24 GMT
     Last-Modified: Wed, 15 Nov 2015 04:58:08 GMT
     Content-Length: 1741
     Content-Type: multipart/byteranges; boundary=String_separator
     
     --String_separator
     Content-Type: application/pdf
     Content-Range: bytes 234-639/8000
     
     ...the first range...
     --String_separator
     Content-Type: application/pdf
     Content-Range: bytes 4590-7999/8000
     
     ...the second range
     --String_separator--
     複製程式碼

     狀態: 206 Partial Content

• 301 永久性重定向，請求的URL已移走

  1. 被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個URI之一。如果可能，擁有連結編輯功能的客戶端應當自動把請求的地址修改為從伺服器反饋回來的地址。除非額外指定，否則這個響應也是可快取的。新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。
  2. 如果這不是一個GET或者HEAD請求，因此瀏覽器禁止自動進行重定向（（第二次 POST 時，環境可能已經發生變化（POST 方法不是冪等））），除非得到使用者的確認，因為請求的條件可能因此發生變化。
  3. 注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們傳送的POST請求得到了一個301響應的話，接下來的重定向請求將會變成GET方式。
  4. 搜尋引擎更新它們到資源的連結（在 SEO 中，據說連結汁被髮送到新的 URL）
  5. 狀態： 301 Moved Permanently

  res.writeHead(301,{
           'Location': 'http://127.0.0.1:3000/login'
       })
  複製程式碼

• 302 臨時重定向，維護

  1. 要求客戶端執行臨時重定向（原始描述短語為“Moved Temporarily”）。由於這樣的重定向是臨時的，客戶端應當繼續向原有地址傳送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可快取的。 新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。
  2. 如果這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向（第二次 POST 時，環境可能已經發生變化（POST 方法不是冪等）），除非得到使用者的確認，因為請求的條件可能因此發生變化。
  3. 注意：雖然RFC 1945和RFC 2068規範不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，並且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。 因此狀態碼303和307被新增了進來，用以明確伺服器期待客戶端進行何種反應。
  4. 搜尋引擎不會更新他們到資源的連結（在 SEO 中，據說連結果汁不會被髮送到新的 URL）
  5. 狀態 ： 302 Found

• 303 See Other（檢視其他）

  1. 對應當前請求的響應可以在另一個URI上被找到，**當響應於POST（或PUT / DELETE）接收到響應時，客戶端應該假定伺服器已經收到資料，並且應該使用單獨的GET訊息發出重定向。這個方法的存在主要是為了允許由指令碼啟用的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。**同時，303響應禁止被快取。當然，**第二個請求（重定向）可能被快取。**新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，否則響應的實體中應當包含指向新的URI的超連結及簡短說明。
  2. 注意：許多HTTP/1.1版以前的瀏覽器不能正確理解303狀態。如果需要考慮與這些瀏覽器之間的互動，302狀態碼應該可以勝任，因為大多數的瀏覽器處理302響應時的方式恰恰就是上述規範要求客戶端處理303響應時應當做的。
  3. 狀態 ： 303 See Other

• 304 表示未修改，客戶的快取資源是最新的，要客戶端使用快取

  1. HTTP 304 Not Modified客戶端重定向響應程式碼指示不需要重新傳輸請求的資源。這是對快取資源的隱式重定向。這發生在請求方法是安全的時候，比如一個 GET或者一個HEAD請求，或者當請求是有條件的並且使用一個 If-None-Match或者一個If-Modified-Since標頭時。
  2. 等效200 OK響應會包括頭Cache-Control，Content-Location，Date，ETag，Expires，和Vary。
  3. 狀態：304 Not Modified

• 307 Temporary Redirect（臨時重定向）

  1. HTTP 307 Temporary Redirect重定向狀態響應程式碼指示所請求的資源已暫時移動到由Location標題給定的 URL 。
  2. 原始請求的方法和主體被重用來執行重定向的請求。在你想要改變方法的情況下，改為GET使用303 See Other。當你想給一個PUT不是上傳資源的方法，而是一個確認資訊（如“你成功上傳 XYZ”）時，這很有用。
  3. 307和302之間的唯一區別在於307該方法和主體將不會被重定向的請求時改變保證。使用302，一些老客戶錯誤地將方法改變為GET：使用非GET方法的行為，然後302在Web上不可預知，而使用307的行為則是可預測的。對於GET請求，它們的行為是相同的。
  4. 狀態 ： 307 Temporary Redirect

• 308 Permanent Redirect （永久重定向）

  1. HTTP 308 Permanent Redirect重定向狀態響應程式碼指示所請求的資源已明確移動到Location標題給定的 URL 。瀏覽器重定向到這個頁面，搜尋引擎更新它們到資源的連結（在 SEO 中，據說連結汁被髮送到新的 URL）。
  2. 請求方法和主體不會被更改，301但有時可能會被錯誤地更改為GET方法。
  3. 一些 Web 應用程式可能會以非標準方式使用308 Permanent Redirect並用於其他目的。例如，Google 雲端硬碟使用308 Resume Incomplete響應來向客戶端指示上傳不完整的時間。

• 400 Bad Request

  1. 400 由於語法無效，HTTP400 Bad Request 響應狀態碼指示伺服器無法理解請求。客戶不應未經修改就重複此請求。
  2. 狀態 400 Bad Request

• 401 Unauthorized

  1. HTTP 401 Unauthorized客戶端錯誤狀態響應程式碼指示該請求尚未應用，因為它缺少目標資源的有效認證憑證。此狀態與包含有關如何正確授權資訊的WWW-Authenticate標頭一起傳送。
  2. 狀態：401 Unauthorized

• 403 Forbidden

  1. HTTP 403 Forbidden客戶端錯誤狀態響應程式碼指示伺服器理解請求但拒絕授權。這種狀態與此類似401，但在這種情況下，重新認證將不會產生任何影響。訪問是永久禁止的並且與應用程式邏輯相關聯（如不正確的密碼）。
  2. 狀態：403 Forbidden

• 405 Method Not Allowed

  1. HTTP 405 Method Not Allowed響應狀態碼指示伺服器已知請求方法，但已被禁用且無法使用。這兩個強制性方法，GET和HEAD，絕不能被禁用，不應返回該錯誤程式碼。
  2. 狀態：405 Method Not Allowed

• 409

  （Conflict）表示請求的資源與資源的當前狀態發生衝突

• 410

  （Gone）表示伺服器上的某個資源被永久性的刪除

• 500 內部伺服器錯誤，伺服器遇到一個錯誤，使其無法為請求提供服務

• 503 伺服器正忙，伺服器超時

4.2 一些狀態碼的使用場景

1. 使用301的場景：（一般是資源位置永久更改）

   1. 域名到期不想續費（或者發現了更適合網站的域名），想換個域名。
   2. 在搜尋引擎的搜尋結果中出現了不帶www的域名，而帶www的域名卻沒有收錄，這個時候可以用301重定向來告訴搜尋引擎我們目標的域名是哪一個。
   3. 空間伺服器不穩定，換空間的時候。

2. 302的場景：（一般是普通的重定向需求：臨時跳轉）

   1. 未登入前先使用302重定向到登入頁面,登入成功後再跳回到原來請求的頁面

      比如我未登入京東前我就訪問京東的個人介面https://home.jd.com/,然後就會重定向到登入介面，響應的狀態碼為302，並且返回了location為登入介面的url，並且附帶了ReturnUrl方便我們登入後跳回到https://home.jd.com/

   2. 有時候需要自動重新整理頁面，比如5秒後回到訂單詳細頁面之類。

   3. 系統進行升級或者切換某些功能時，需要臨時更換地址

   4. 像微博之類的使用短域名，使用者瀏覽後需要重定向到真實的地址之類。

      例如我訪問一個微博的秒拍視訊連結：t.cn/RuUMBnI，然後重…

   5. 電腦端與移動端的轉換

   6. 比如我訪問網頁端頁面https://www.taobao.com/，302重定向到了移動端頁面m.taobao.com

3. 303 幾乎沒有，一般就是用302

4. 307的場景

   很少用，與302類似，只不過是針對POST方法的請求不允許更改方法

5. 308的場景

   很少用，與301類似，只不過是針對POST方法的請求不允許更改方法

4.3 引申的問題和思考

1. 303和307的存在，歸根結底是由於POST方法的非冪等屬性引起的。

2. 308 的存在，返回時301對於某些使用HTTP/1.0協議的瀏覽器，當它們傳送的POST請求得到了一個301響應的話，接下來的重定向請求將會變成GET方式。

3. 301/302/303/307/308的區別 及注意點

   1. 301，302是http1.0的內容，303、307、308是http1.1的內容。
   2. 301和302本來在規範中是不允許重定向時改變請求方法的（將POST改為GET），但是許多瀏覽器卻允許重定向時改變請求方法（這是一種不規範的實現）。
   3. 301表示搜尋引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址；302表示舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜尋引擎會抓取新的內容而儲存舊的網址。
   4. 因為301與302的區別，所以導致產生302網址劫持，故不建議使用302重定向（然而瀏覽器預設是使用302重定向）

4. 301請求碼進行跳轉被谷歌認為是將網站地址由 HTTP 遷移到 HTTPS的最佳方法, 但是淘寶就是 302跳轉

5. 實體應該包含一個帶有指向新URI的超連結的短超文字註釋

   since many pre-HTTP/1.1 user agents do not understand the *** status.

6. 401 和 403 的區別

   1. 401 用於認證，而不是授權。接收到401響應時。 伺服器會告訴您，“您沒有經過身份驗證——或者根本沒有經過身份驗證，或者身份驗證不正確——但是請重新進行身份驗證，然後重試。”為了幫助您解決問題，它將始終包含描述如何進行身份驗證的www-authenticate頭。
   2. 為了獲得授權，我使用403禁止響應。它是永久的，它與我的應用程式邏輯有關，它比401更具體。 伺服器收到403的響應後會告訴您：“對不起。我知道你是誰——我相信你說你是誰——但你只是沒有訪問這個資源的許可權。如果你向系統管理員友好地詢問，你可能會得到許可。但在你的困境改變之前，請不要再打擾我。”
   3. 對於認證丟失或不正確的情況，應使用401未經授權響應，並且當使用者經過認證但未被授權對給定資源執行請求的操作時，應隨後使用403禁止響應。

5. HTTP長連線（HTTP persistent connection ）

HTTP的長連線和短連線

HTTP Keep-Alive模式

5.1 概述

長連結 ：就是資料傳輸完成了保持TCP連線不斷開（不發RST包、不四次握手），等待在同域名下繼續用這個通道傳輸資料；相反的就是短連線。

http 1.0中預設是關閉的，需要在http頭加入"Connection: Keep-Alive"，才能啟用Keep-Alive。

http 1.1中預設啟用Keep-Alive，如果加入"Connection: close "，才關閉。

是否能完成一個完整的Keep-Alive連線就看伺服器設定情況。

優點

可以報告錯誤而不必關閉TCP連線

errors can be reported without the penalty of closing the TCP connection

1. HTTP請求和響應可以通過管道連線。流水線允許客戶機在不等待每個響應的情況下發出多個請求，從而使單個TCP連線的使用效率更高，執行時間更低。
2. 通過減少TCP開啟造成的資料包數量，並允許TCP有足夠的時間來確定網路的擁塞狀態，可以減少網路擁塞。
3. 由於TCP的連線開啟握手沒有花費時間，因此後續請求的延遲會減少。

5.2 問題

(1) 長連線的資料傳輸完成識別 —— 使用長連線之後，客戶端、服務端怎麼知道本次傳輸結束呢？（如何判斷http訊息的大小、訊息的數量）？

1. Conent-Length

   靜態頁面或圖片等

   Conent-Length表示實體內容長度，客戶端（伺服器）可以根據這個值來判斷資料是否接收完成。

2. Transfer-Encoding

   動態頁面 等

   即如果要一邊產生資料，一邊發給客戶端，伺服器就需要使用"Transfer-Encoding: chunked"這樣的方式來代替Content-Length。

   伺服器是不可能預先知道內容大小，可以使用Transfer-Encoding：chunk模式來傳輸資料了。chunk編碼將資料分成一塊一塊的發生。Chunked編碼將使用若干個Chunk串連而成，由一個標明長度為0的chunk標示結束。

6. 流水線技術（管道化連線）

使用了HTTP長連線（HTTP persistent connection ）之後的好處，包括可以使用HTTP 流水線技術，它是指，在一個TCP連線內，（多條請求放入佇列）當第一條請求發往伺服器的時候，第二第三條請求也可以開始傳送了，在高延時網路條件下，這樣做可以降低網路的環回時間，提高效能。

限制

• 如果客戶端無法確認連線是持久的，就不應該使用管道
• 必須按照與請求相同的順序回送HTTP響應，因為HTTP報文中是沒有序列號的，所以如果收到的響應失序了，就沒辦法將其與請求匹配起來
• HTTP客戶端必須做好連線會在任意時刻關閉的準備，還要準備好重發所有未完成的管道化請求
• HTTP客戶端不應該用管道化的方式傳送會產生副作用的請求，比如POST請求。

6.1 Head of line blocking

第一個請求耗費了伺服器很多的處理時間，那麼後面的請求都要等待第一個處理完，也就出現了線頭阻塞。

7. request 和 response 報文頭部欄位

request 頭

response 頭

1. referer 當前頁面 對html的請求來自上一個頁面的 url, ajax請求是當前的url

2. HTTP 請求訊息頭部例項：

   Host：rss.sina.com.cn 
   User-Agent：Mozilla/5、0 (Windows; U; Windows NT 5、1; zh-CN; rv:1、8、1、14) Gecko/20080404 Firefox/2、0、0、14 
   Accept：text/xml,application/xml,application/xhtml+xml,text/html;q=0、9,text/plain;q=0、8,image/png,*/*;q=0、5 
   Accept-Language：zh-cn,zh;q=0、5 
   Accept-Encoding：gzip,deflate 
   Accept-Charset：gb2312,utf-8;q=0、7,*;q=0、7 
   Keep-Alive：300 
   Connection：keep-alive 
   Cookie：userId=C5bYpXrimdmsiQmsBPnE1Vn8ZQmdWSm3WRlEB3vRwTnRtW <-- Cookie 
   If-Modified-Since：Sun, 01 Jun 2008 12:05:30 GMT 
   Cache-Control：max-age=0 
   複製程式碼

3. HTTP 響應訊息頭部例項：

   Status：OK - 200 <-- 響應狀態碼，表示 web 伺服器處理的結果。 
   Date：Sun, 01 Jun 2008 12:35:47 GMT 
   Server：Apache/2、0、61 (Unix) 
   Last-Modified：Sun, 01 Jun 2008 12:35:30 GMT 
   Accept-Ranges：bytes 
   Content-Length：18616 
   Cache-Control：max-age=120 
   Expires：Sun, 01 Jun 2008 12:37:47 GMT 
   Content-Type：application/xml 
   Age：2 
   X-Cache：HIT from 236-41、D07071951、sina、com、cn <-- 反向代理伺服器使用的 HTTP 頭部 
   Via：1.0 236-41.D07071951.sina.com.cn:80 (squid/2.6.STABLE13) 
   Connection：close
   複製程式碼

8. HTTP的基本優化

影響一個HTTP網路請求的因素主要有兩個：頻寬和延遲。

1. 頻寬
2. 延遲
   1. 瀏覽器阻塞（HOL blocking）：瀏覽器會因為一些原因阻塞請求。瀏覽器對於同一個域名，同時只能有 4 個連線（這個根據瀏覽器核心不同可能會有所差異），超過瀏覽器最大連線數限制，後續請求就會被阻塞。
   2. DNS 查詢（DNS Lookup）：瀏覽器需要知道目標伺服器的 IP 才能建立連線。將域名解析為 IP 的這個系統就是 DNS。這個通常可以利用DNS快取結果來達到減少這個時間的目的。
   3. 建立連線（Initial connection）：HTTP 是基於 TCP 協議的，瀏覽器最快也要在第三次握手時才能捎帶 HTTP 請求報文，達到真正的建立連線，但是這些連線無法複用會導致每次請求都經歷三次握手和慢啟動。三次握手在高延遲的場景下影響較明顯，慢啟動則對檔案類大請求影響較大。

9. HTTP,HTTP2.0,SPDY,HTTPS

HTTP1.0、HTTP1.1和HTTP2.0的區別

9.1 HTTP1.0和HTTP1.1的區別

HTTP1.0只是使用一些較為簡單的網頁上和網路請求上

1. 快取處理

   • HTTP1.0 使用 If-Modified-Since,Expires
   • HTTP1.1 使用Entity tag，If-Unmodified-Since, If-Match, If-None-Match

2. 頻寬優化及網路連線的使用

   • HTTP1.0中，存在一些浪費頻寬的現象，例如客戶端只是需要某個物件的一部分，而伺服器卻將整個物件送過來了，並且不支援斷點續傳功能 [斷點續傳功能——詳情](#10. 斷點續傳原理)

3. 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如

   • http 409
   • http 410

4. Host頭處理

   • HTTP1.1的請求訊息和響應訊息都應支援Host頭域，且請求訊息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。

5. 長連線，HTTP 1.1支援長連線（Persistent Connection）和請求的流水線（Pipelining）處理，在一個TCP連線上可以傳送多個HTTP請求和響應，減少了建立和關閉連線的消耗和延遲，在HTTP1.1中預設開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要建立連線的缺點。

9.2 HTTPS與HTTP的區別

• HTTPS協議需要到CA申請證書，一般免費證書很少，需要交費。
• HTTP協議執行在TCP之上，所有傳輸的內容都是明文，HTTPS執行在SSL/TLS之上，SSL/TLS執行在TCP之上，所有傳輸的內容都經過加密的。
• HTTP和HTTPS使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。
• HTTPS可以有效的防止運營商劫持，解決了防劫持的一個大問題。

9.3 SPDY：HTTP1.x的優化

google提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性 ， SPDY位於HTTP之下，TCP和SSL之上，這樣可以輕鬆相容老版本的HTTP協議(將HTTP1.x的內容封裝成一種新的frame格式)，同時可以使用已有的SSL功能。

具體優化如下：

1. 多路複用，針對HTTP高延遲的問題，SPDY優雅的採取了多路複用（multiplexing）。多路複用通過多個請求stream共享一個tcp連線的方式，解決了HOL blocking的問題，降低了延遲同時提高了頻寬的利用率。

2. 請求優先順序（request prioritization）。多路複用帶來一個新的問題是，在連線共享的基礎之上有可能會導致關鍵請求被阻塞。SPDY允許給每個request設定優先順序，這樣重要的請求就會優先得到響應。 比如瀏覽器載入首頁，首頁的html內容應該優先展示，之後才是各種靜態資原始檔，指令碼檔案等載入，這樣可以保證使用者能第一時間看到網頁內容。

3. header壓縮。前面提到HTTP1.x的header很多時候都是重複多餘的。選擇合適的壓縮演算法可以減小包的大小和數量。

4. 基於HTTPS的加密協議傳輸，大大提高了傳輸資料的可靠性。

5. 服務端推送（server push）

   把客戶端所需要的資源伴隨著index.html一起傳送到客戶端，省去了客戶端重複請求的步驟。正因為沒有發起請求，建立連線等操作，所以靜態資源通過服務端推送的方式可以極大地提升速度。

9.4 HTTP2.0和SPDY的區別

HTTP2.0可以說是SPDY的升級版（其實原本也是基於SPDY設計的），但是，HTTP2.0 跟 SPDY 仍有不同的地方。 HTTP2.0和SPDY的區別：

1. HTTP2.0 支援明文 HTTP 傳輸，而 SPDY 強制使用 HTTPS
2. HTTP2.0 訊息頭的壓縮演算法採用 HPACK，而非 SPDY 採用的 DEFLATE

9.5 HTTP2.0和HTTP1.X 的區別

1. 新的二進位制格式（Binary Format），HTTP1.x的解析是基於文字。基於文字協議的格式解析存在天然缺陷，文字的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進位制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進位制格式，實現方便且健壯。
2. 多路複用（MultiPlexing），即連線共享，即每一個request都是是用作連線共享機制的。一個request對應一個id，這樣一個連線上可以有多個request，每個連線的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求裡面。
3. header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量資訊，而且每次都要重複傳送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重複header的傳輸，又減小了需要傳輸的大小。
4. 服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。[參考](#服務端推送（server push）)

9.6 HTTP2.0的多路複用和HTTP1.X中的長連線複用的區別

• HTTP/1.* 一次請求-響應，建立一個連線，用完關閉；每一個請求都要建立一個連線；
• HTTP/1.1 Pipeling解決方式為，若干個請求排隊序列化單執行緒處理，後面的請求等待前面請求的返回才能獲得執行機會，一旦有某請求超時等，後續請求只能被阻塞，毫無辦法，也就是人們常說的[線頭阻塞](#6.1 Head of line blocking)；
• HTTP/2多個請求可同時在一個連線上並行執行。某個請求任務耗時嚴重，不會影響到其它連線的正常執行；

10. 斷點續傳原理

HTTP必知必會——斷點續傳原理

要實現斷點續傳的功能，通常都需要客戶端記錄下當前的下載進度，並在需要續傳的時候通知服務端本次需要下載的內容片段。

HTTP1.1協議（RFC2616）中定義了斷點續傳相關的HTTP頭 Range和Content-Range欄位

示例 ：

1. 客戶端下載一個1024K的檔案，已經下載了其中512K
2. 網路中斷，客戶端請求續傳，因此需要在HTTP頭中申明本次需要續>傳的片段： Range:bytes=512000- 這個頭通知服務端從檔案的512K位置開始傳輸檔案
3. 服務端收到斷點續傳請求，從檔案的512K位置開始傳輸，並且在HTTP頭中增加： Content-Range:bytes 512000-/1024000 此時服務端返回的HTTP狀態碼應該是206，而不是200。

問題

（1）終端發起續傳請求時，URL對應的檔案內容在服務端已經發生變化，此時續傳的資料肯定是錯誤！

• 此時我們需要有一個標識檔案唯一性的方法。在RFC2616中也有相應的定義，比如實現Last-Modified來標識檔案的最後修改時間，這樣即可判斷出續傳檔案時是否已經發生過改動。同時RFC2616中還定義有一個ETag的頭，可以使用ETag頭來放置檔案的唯一標識，比如檔案的MD5值。 終端在發起續傳請求時應該在HTTP頭中申明If-Match 或者If-Modified-Since 欄位，幫助服務端判別檔案變化。
• 另外RFC2616中同時定義有一個If-Range頭，終端如果在續傳是使用If-Range。**If-Range中的內容可以為最初收到的ETag頭或者是Last-Modfied中的最後修改時候。**服務端在收到續傳請求時，通過If-Range中的內容進行校驗
• 校驗一致時返回206的續傳回應，不一致時服務端則返回200迴應，迴應的內容為新的檔案的全部資料。

關於HTTP協議，一篇就夠了