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

時間  2019-11-17
標籤 http 總結 簡介 狀態 版本 對比 欄目 HTTP/TCP 简体版
原文   原文鏈接

1 http 簡介與具體過程

1.1 簡介

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

HTTP基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。git

1.2 HTTP 工做原理

HTTP協議工做於客戶端-服務端架構上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。github

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

Web服務器根據接收到的請求後，向客戶端發送響應信息。ajax

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的內容，30三、30七、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/五、0 (Windows; U; Windows NT 五、1; zh-CN; rv:一、八、一、14) Gecko/20080404 Firefox/二、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/二、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-4一、D0707195一、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個錯誤狀態響應碼，如

  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協議，一篇就夠了

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程