HTTP的發展歷史 【積一時之跬步，臻千里之遙程】

五公里發表於2019-05-12
HTTP
  1. http版本導圖

HTTP的發展歷史 【積一時之跬步，臻千里之遙程】

  1. HTTP版本之概念篇
    HTTP的發展歷史 【積一時之跬步，臻千里之遙程】
  • HTTP（超文字傳輸協議),是網際網路上應用最為廣泛的一種網路協議，是一個客戶端和伺服器端請求和應答的標準（TCP），用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少。HTTP基於TCP/IP協議的應用層協議，它不涉及資料包傳輸，主要規定了客戶端和伺服器之間的通訊格式，預設使用80埠。
  1. HTTP/0.9版本篇
要點
  • 客戶端向伺服器請求網頁，伺服器只能回應HTML格式的字串，不能回應別的格式。
  • 只有GET方式
  • 伺服器傳送完畢。就關閉TCP連線
缺點
  • 每個TCP連線只能傳送一個請求;傳送資料完畢，連線就關閉，如果還要請求其他資源，就必須再新建一個連線
  • TCP連線的新建成本很高，因為需要客戶端和伺服器三次握手，並且開始時傳送速率較慢
  • 網頁載入的外部資源越多，效能就越差
  • 只有一種請求方式
  1. HTTP/1.0版本篇
要點
  • 任何格式的內容都可以傳送。網際網路不僅可以傳輸文字，還可以傳輸影像，視訊，二進位制檔案。（由於傳送的資料可以是任何格式，因此可以把資料壓縮後再傳送。CONTENT-ENCODING欄位說明資料壓縮的方法
壓縮的方式有（可以並列多個，用逗號隔開）：
CONTENT-ENCODING:GZIP
CONTENT-ENCODING:COMPRESS
CONTENT-ENCODING:DEATE
複製程式碼
  • 除了GET命令，還引入POST命令和HEAD命令，豐富了瀏覽器與伺服器的互動手段。
  • HTTP請求和回應格式發生改變，除了資料部分，每次通訊都包括頭部分，用來描述資料，
  • 新增的功能還包括：狀態碼(STATUS CODE)，多字符集支援，多部分傳送(MULTI-PART TYPE)，許可權(ANTHORIZATION)，快取(CACHE)，內容編碼(CONTENT ENCODING)等
HTTP/1.0請求的例子：

GET/HTTP/1.0 
USER-AGENT:MOZILLA/5.0(MACINTOSH;INTEL MAC OS X 10_10_5 ) 
ACCEPT:*/*
第一行為請求命令,必須在尾部新增協議版本(HTTP/1.0)
後面為多行頭資訊，描述客戶端情況
複製程式碼
HTTP/1.0回應的例子：
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:字元編碼，HTTP 1.0規定 頭部必須是ASCII碼，後面可以是任何格式，
因此，伺服器回應時，CONTENT-TYPE的作用是：告訴客戶端，資料是什麼格式
複製程式碼
缺點
  • 每個TCP連線只能傳送一個請求。
  • 傳送資料完畢，連線就關閉，如果還要請求其他資源，就必須再新建一個連線。
  • TCP連線的新建成本很高，因為需要客戶端和伺服器三次握手，並且開始時傳送速率較慢。（為了解決這個問題：有些瀏覽器在請求時，用了一個非標準的CONNECTION欄位。即CONNECTION:KEEP-ALIVE請求伺服器不要關閉TCP連線，以便其他請求複用，伺服器同樣回覆這個欄位；以實現TCP的複用，直到客戶端或伺服器主動關閉連線，但，這不是標準欄位，不同實現的行為可能不一致，因此不是根本的解決辦法。
  • 網頁載入的外部資源越多，效能就越差。

5. HTTP/1.1版本篇

要點

  • 引入了持久連線(PERSISITENT CONNECTION),即TCP連線預設不關閉，可以被多個請求複用，不用宣告。CONNECTION:KEEP-ALIVE客戶端和伺服器發現對方一段時間沒有活動，就可以主動關閉連線。不過，規範的做法是，客戶端在最後一個請求時明確要求伺服器關閉TCP連線。CONNECTION:CLOSE

  • 目前，對於同一個域名，大多數瀏覽器允許同時建立6個持久連線。

  • 引入了管道機制，即在同一個TCP連線裡面，客戶端可以同時傳送多個請求。（提高HTTP協議的效率）；舉例說明：客戶端需要請求兩個資源，HTTP1.0是在同一個TCP連線裡面，先傳送A請求，然後等待伺服器做出回應，收到後再傳送B請求；管道機制是允許瀏覽器同時發生A請求和B請求，但是伺服器還是按照順序，先回應A請求，完成後再回應B請求

  • 一個TCP連線可以傳送多個回應，勢必要有機制，區分資料包是屬於哪一個回應的。這就是CONTENT-LENGTH欄位的作用，宣告本次回應的資料長度。

CONTENT-LENGTH:3495
告訴瀏覽器本次回應的長度是3495個位元組，後面的位元組就屬於下一個回應
複製程式碼
  • 分塊傳輸編碼；HTTP1.1採用分塊傳輸編碼；使用CONTENT-LENGTH欄位的前提是伺服器傳送回應之前，必須知道回應資料的長度。但對於一些耗時的動態操作來說，這意味著，伺服器要等所有操作完成，才能傳送資料，顯然效率不高，更好的處理方式是：伺服器每產生一塊資料，就傳送一塊，採用“流模式（STREAM）”取代“快取模式(BUFFER)”.因此1.1版規定可以不使用CONTENT-LENGTH欄位，而使用“分塊傳輸編碼”，只要請求或回應的頭資訊有TRANSFER-ENCODING欄位，就表明回應的資料將由數量未定的資料塊組成。TRANSFER-ENCODING:CHUNKED 每個非空的資料塊之前，會有16進位制的數值，表示這個塊的長度，最後是一個大小為0的塊，就表示本次回應的資料傳送完。
Eg:
HTTP/1.1 200 OKCONTENT-TYPE: TEXT/PLAINTRANSFER-ENCODING: CHUNKED

25
THIS IS THE DATA IN THE FIRST CHUNK

1C
AND THIS IS THE SECOND ONE

3
CON

8
SEQUENCE

0

複製程式碼
  • ** 新增功能**：PUT,PATCH,HEAD,OPTIONS,DELECT. 客戶端的頭資訊增加HOST欄位，用來指定伺服器的域名。 HOST:WWW.EXAMPLE.COM 有了HOST欄位，就可以將請求發往同一臺伺服器的不同的網站，為虛擬主機的新起打下了基礎。
缺點
  • 雖然複用TCP連線，但是在同一個TCP連線裡面，所有的資料通訊都是按照次序進行的。伺服器只有處理完一個回應，才能進行下一個回應。(解決辦法：A. 減少HTTP請求數;B:同時多開持久連線)

6. HTTP/2版本篇

要點
  • 採用二進位制協議：HTTP/1.1的頭資訊是文字（ASCII編碼），資料體可以是文字（解析非常麻煩），也可以是二進位制。而HTTP/2則是一個徹底的二進位制協議，頭資訊和資料體都是二進位制，通稱為“幀”（FRAME）:頭資訊幀和資料幀。二進位制協議的一個好處是：可以定義額外的幀，解析方便。
  • 多路複用(雙向，實時的通訊)：HTTP/2複用TCP連線，在一個連線裡，客戶端和服務端都可以同時傳送多個請求或回應，而不用按照順序一一對應，這樣就避免“隊頭阻塞”。舉例來說：在一個TCP連線裡面，伺服器同時收到A請求和B請求，先回應A請求，結果發現處理過程非常耗時，於是就傳送A請求已經處理好的部分，接著回應B請求，完成後，才傳送B請求剩下的部分。
  • 資料流：HTTP/2的資料流是不按順序傳送的，同一個連線裡面連續的資料包，可能屬於不同的回應。因此必須要對資料包標記，指出它屬於哪個回應。HTTP/2將每一個請求或回應的所有資料包，稱為一個資料流。每個資料流都有一個獨一無二的編號。資料包傳送時，都必須標記資料流ID，用於區分它屬於哪一個資料流，另外規定：客戶端發出的資料流，ID一律為奇數，伺服器發出的，ID為偶數。資料流傳送一半時，客戶端和伺服器都可以傳送訊號，取消這個資料流。即HTTP/2可以取消某一個請求，同時保證TCP連線還開著，可以被其他請求使用。客戶端還可以指定資料流的優先順序，優先順序越高，伺服器就越早回應。
  • 頭資訊壓縮：HTTP2以前的版本協議不帶有狀態，每次請求都必須附上所有的資訊。所以，請求的很多欄位都是重複的，比如COOKIE和USER AGENT,一模一樣的內容，每次請求都必須附帶，這很浪費很多寬頻，也影響速度。HTTP/2優化了這一點。引入了頭資訊壓縮機制。一方面：頭資訊使用GZIP或COMPRESS壓縮後再傳送，另一方面，客戶端和服務端同時維護一張頭資訊表，所有欄位都會存入這個表，生成一個索引號，以後就不傳送同樣欄位，只傳送索引號，提高速度。
  • 伺服器推送：HTTP/2允許伺服器未經請求，主動向客戶端傳送資源-->伺服器推送。eg:客戶端請求一個網頁，這個網頁裡面包含靜態資源。正常情況下，客戶端必須收到網頁後，解析HTML原始碼，發現有靜態資源，再傳送靜態資源請求；其實，伺服器可以預期到客戶端請求網頁後，很可能再請求靜態資源，所以主動把這些靜態資源隨網頁一起發給客戶端。
缺點
  • 請求太多時也需要排隊

7. HTTPS版本篇

要點
  • HTTPS 是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL
  • HTTPS協議的主要作用是：建立一個資訊保安通道，來確保陣列的傳輸，確保網站的真實性
  • HTTPS的SSL加密是在傳輸層實現的
工作原理
  • 客戶使用HTTPS URL訪問伺服器，則要求WEB 伺服器建立SSL連結。
  • WEB伺服器接收到客戶端的請求之後，會將網站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。
  • 客戶端和WEB伺服器端開始協商SSL連結的安全等級，也就是加密等級。
  • 客戶端瀏覽器通過雙方協商一致的安全等級，建立會話金鑰，然後通過網站的公鑰來加密會話金鑰，並傳送給網站。
  • WEB伺服器通過自己的私鑰解密出會話金鑰。
  • WEB伺服器通過會話金鑰加密與客戶端之間的通訊。
優點
  • 使用HTTPS協議可認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器
  • HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比HTTP協議安全，可防止資料在傳輸過程中不被竊取、改變，確保資料的完整性。
  • HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
缺點
  • HTTPS握手階段比較費時，會使頁面載入時間延長50%，增加10%~20%的耗電。
  • HTTPS快取不如HTTP高效，會增加資料開銷。
  • SSL證書也需要錢，功能越強大的證書費用越高。
  • SSL證書需要繫結IP，不能再同一個IP上繫結多個域名，IPV4資源支援不了這種消耗。
HTTP和HTTPS的區別
  • HTTPS協議需要證書，費用較高。
  • HTTP是超文字傳輸協議，傳輸的資料都是未加密的即明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協議。
  • 使用不同的連結方式，埠也不同，一般而言，HTTP協議的埠為80，HTTPS的埠為443
  • HTTP的連線很簡單，是無連線，無狀態的；(無連線：每次連線只處理一個請求，服務端處理完客戶端一次請求，等到客戶端作出回應之後便斷開連線;無狀態：是指服務端對於客戶端每次傳送的請求都認為它是一個新的請求，上一次會話和下一次會話沒有聯絡);HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比HTTP協議安全。
  • HTTPS提升訪問速度（可以對於，請求資源所需時間更少，訪問速度更快，相比HTTP1.0）
  • HTTPS允許多路複用：多路複用允許同時通過單一的HTTP/2連線傳送多重請求-響應資訊。改善了：在HTTP1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有一定數量限制（連線數量），超過限制會被阻塞。
  • 二進位制分幀：HTTP2.0會將所有的傳輸資訊分割為更小的資訊或者幀，並對他們進行二進位制編碼
  • HTTP2首部壓縮;伺服器端推送(相對於HTTP1.0)
7. SSL/TLS協議介紹

網際網路的通訊安全是建立在SSL/TLS協議之上。不使用SSL/TLS的HTTP協議，就是不加密的通訊；會帶來三大風險：

  • （1）竊聽風險：第三方可以獲取通訊內容；
  • （2）篡改風險：第三方可以修改通訊內容。
  • （3）冒失風險：第三方可以冒充他人身份參與通訊。
SSL/TLS就是為了解決這三大風險而設計的，希望達到：
  • （1）所有資訊都是加密傳播，第三方無法竊聽
  • （2）具有校驗機制，一旦被篡改，通訊雙方立即發現。
  • （3）配備身份證書，防止身份被冒充。
SSL/TLS協議的基本思路

採用公鑰加密法，即客戶端先向服務端索要公鑰，然後用公鑰加密資訊，客戶端收到密文後，用自己的私鑰解密。

如何保證公鑰不被篡改？

解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。

公鑰加密計算量太大，如何減少耗用的時間？

解決方法：每一次對話（SESSION），客戶端和伺服器端都生成一個"對話金鑰"（SESSION KEY），用它來加密資訊。由於"對話金鑰"是對稱加密，所以運算速度非常快，而伺服器公鑰只用於加密"對話金鑰"本身，這樣就減少了加密運算的消耗時間。

SSL/TLS協議的基本過程：
  • （1） 客戶端向伺服器端索要並驗證公鑰。
  • （2） 雙方協商生成"對話金鑰"。
  • （3） 雙方採用"對話金鑰"進行加密通訊。 上面過程的前兩步，又稱為"握手階段"（HANDSHAKE）。 開始加密通訊之前，客戶端和伺服器首先必須建立連線和交換引數，這個過程叫做握手；HTTP耗時 = TCP握手；HTTPS耗時 = TCP握手 + SSL握手 所以，HTTPS肯定比HTTP耗時，這就叫SSL延遲
8.** 參考文章**

2019-05-12 21:16:45 星期日

相關文章