http 主要版本的歷史

時間 2021-06-03

標籤 javascript css html java 算法瀏覽器緩存服務器 app post 欄目 HTTP/TCP 简体版

原文原文鏈接

1、定義
http協議：超文本傳輸協議（通訊協議），用於從服務器傳輸超文本到本地瀏覽，創建再TCP/IP協議基礎上
三個特色：
一、無鏈接
是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間
二、無狀態
是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快
三、靈活
容許傳輸任意類型的數據對象。傳輸的類型由Content-Type（Content-Type是HTTP包中用來表示內容類型的標識）加以標記 javascript

HTTP/0.9版本
特色：結構簡單，僅有GET請求，純文本格式css

例如GET /index.html
表示：TCP創建鏈接後，客戶端向服務端請求index.html頁面，協議規定，服務端只能返字符串，返回後即關閉TCP連接，若是請求的頁面不存在，也不反悔任何錯誤碼，這也是無狀態的一個體現

HTTP/1.0版本
相比較上一個版本增長了以下主要內容：html

增長了post請求，豐富了瀏覽器與客戶端的互動手段
傳輸數據不限於文本，能夠是圖片、視頻、二進制文件等內容
增長了協議版本號
增長的響應狀態碼
引入了HTTP HEADER（頭部）概念，讓HTTP處理請求更加靈活

GET /HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

其中content-type是體現靈活的字段，咱們常見的value值包括：text/html, text/css, image/png, application/javascript, application/x-www-form-urlencoded form, Multipart/form-data，以上數據統稱爲MIME類型。java

1.0的缺點：
鏈接沒法複用：每一個TCP鏈接只能發送一個請求。發送數據完畢，鏈接就關閉，若是還要請求其餘資源，就必須再新建一個鏈接。
爲了解決這個問題，有些瀏覽器在請求時，用了一個非標準的Connection字段：Connection: keep-alive，表示TCP能夠複用，直到主動關閉連接。算法

上面是又沒有keep-alive的區別，可是這不是標準字段，不一樣實現的行爲可能不一致，所以不是根本的解決辦法，而且TCP的新建成本很高，由於每次連接服務端和客戶端都須要通過三次握手，而且開始時發送的速率較慢。瀏覽器

HTTP/1.1版本
也就是目前位置用的最多的一個版本，相比較1.0版本增長了：緩存

持久連接，默認TCP不關閉，能夠被多個請求複用，不用申明connection:keep-alive字段
新增了PUT、PATCH、OPTIONS、DELETE請求方法，也新增了許多狀態碼
強制HOST頭：HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。有了Host字段，就能夠將請求發往同一臺服務器上的不一樣網站，爲虛擬主機的興起打下了基礎
緩存處理：HTTP/1.0 使用 Pragma:no-cache + Last-Modified/If-Modified-Since + Expire來做爲緩存判斷的標準；HTTP/1.1 引入了更多的緩存控制策略：Cache-Control、Etag/If-None-Match
管道機制（pipelining）：即在同一個TCP連接裏面，客戶端能夠同事發送多個請求。從而進一步改善HTTP協議的效率問題服務器

例如：客戶端須要請求兩個資源。之前的作法是，在同一個TCP鏈接裏面，先發送A請求，而後等待服務器作出迴應，收到後再發出B請求。管道機制則是容許瀏覽器同時發出A請求和B請求，可是服務器仍是按照順序，先回應A請求，完成後再回應B請求,經過下圖能夠很清晰的看出區別

1.1缺點：
雖然1.1版容許複用TCP鏈接，可是同一個TCP鏈接裏面，全部的數據通訊是按次序進行的。服務器只有處理完一個迴應，纔會進行下一個迴應。要是前面的迴應特別慢，後面就會有許多請求排隊等着。這稱爲「隊頭堵塞"（Head-of-line blocking）
解決方案：
一、減小請求數量（雪碧圖）
二、多開持久連接，以下圖中並行的請求，就是多開了幾個TCP連接，可是瀏覽器也有規定，同一域名下TCP開啓的個數時有限，通常不超過10個，這也是SEO中，將資源CDN的緣由。app

我的看法：1.1版本中增長了許多頭部的標識，使得請求更加的靈活，例如類型、緩存等等！利用好了能大幅提高請求效率，也能夠看成優化的重點去攻克！可是也有太多的字段須要去學習，有利有弊吧!接下來就是重點HTTP/2post

HTTP/2版本
爲何是2而不是2.0，由於標準委員會不許備發佈子版本，下一個版本將是HTTP/3
一、二進制傳輸：在HTTP1.x中，咱們是經過文本的方式傳輸數據。基於文本的方式傳輸數據存在不少缺陷，文本的表現形式有多樣性，所以要作到健壯性考慮的場景必然有不少，可是二進制則不一樣，只有0和1的組合，所以選擇了二進制傳輸，實現方便且健壯。爲了保證HTTP不受影響，那就須要在應用層（HTTP2.0）和傳輸層（TCP or UDP）之間增長一個二進制分幀層。在二進制分幀層上，HTTP2.0會將全部傳輸的信息分爲更小的消息和幀，並採用二進制格式編碼，其中HTTP1.x的首部信息會被封裝到Headers frame，而Request Body則封裝到Data frame。

二、頭部壓縮（Header Compression）：專門爲頭部壓縮設計了Hpack算法，簡單來講就是客戶端和服務端共同維護一份相同的靜態表和動態表，在編碼時直接用表的index代替，能夠大幅下降頭部大小

三、服務端推送（server push）：容許服務器未經請求，主要向客戶端發送資源。

客戶端請求一個網頁，這個網頁裏面包含不少靜態資源。正常狀況下，客戶端必須收到網頁後，解析HTML源碼，發現有靜態資源，再發出靜態資源請求。其實，服務器能夠預期到客戶端請求網頁後，極可能會再請求靜態資源，因此就主動把這些靜態資源隨着網頁一塊兒發給客戶端了

四、多路複用：也是最重要的一項，原由是1.X版本中的「隊頭阻塞」，這裏面有三個比較重要的概念

消息：邏輯上的http消息，好比一系列Data frame 和一個Header frame 組成的請求消息
幀（frame）：最小的數據單位
流（stream）：多個幀組成數據流，每一個幀會標識出該幀屬於哪一個流，通俗講流是鏈接中的一個虛擬信道，能夠承載雙向消息傳輸，每個流都有惟一的標識，爲了防止兩個流ID衝突，客戶端發起的流具備奇數ID，服務端發起的流具備偶數ID，全部的HTTP2通訊都在一個TCP連接上完成，這個鏈接能夠承載任意數量的雙向數據流Stream。相應地，每一個數據流以消息的形式發送，而消息由一或多個幀組成，這些幀能夠亂序發送，而後根據每一個幀首部的流標識符從新組裝。

舉個例子，每一個請求是一個數據流，數據流以消息的方式發送，而消息又分爲多個幀，幀頭部記錄着stream id用來標識所屬的數據流，不一樣屬的幀能夠在鏈接中隨機混雜在一塊兒。接收方能夠根據stream id將幀再歸屬到各自不一樣的請求當中去。
另外，多路複用（鏈接共享）可能會致使關鍵請求被阻塞。HTTP2裏每一個數據流均可以設置優先級和依賴，優先級高的數據流會被服務器優先處理和返回給客戶端，數據流還能夠依賴其餘的子數據流。
可見，HTTP2實現了真正的並行傳輸，它可以在一個TCP上進行任意數量HTTP請求。而這個強大的功能則是基於「二進制分幀」的特性。

宏觀上看，基於二進制分幀層，htp2能夠在共享TCP連接的基礎上，同時發送請求和響應，HTTP消息被分解爲獨立的幀，交錯發出，最後在另外一端根據ID和首部將它們從新組合起來。

以上就是HTTP2主要的特色，接下來會是HTTP3的特色，未完待續。。。。