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

時間 2019-11-11

標籤 http 發展歷史積一時之跬步，臻千里之遙程欄目 HTTP/TCP 简体版

原文原文鏈接

http版本導圖

2. HTTP版本之概念篇

HTTP（超文本傳輸協議),是互聯網上應用最爲普遍的一種網絡協議，定義了瀏覽器怎樣向服務器請求文檔，以及服務器怎樣把文檔傳送給瀏覽器。HTTP基於TCP/IP協議的應用層協議，它不涉及數據包傳輸，主要規定了客戶端和服務器之間的通訊格式，默認使用80端口。

HTTP/0.9版本篇

要點

客戶端向服務器請求網頁，服務器只能迴應HTML格式的字符串，不能迴應別的格式。
只有GET方式
服務器發送完畢。就關閉TCP鏈接

缺點

每一個TCP鏈接只能發送一個請求;發送數據完畢，鏈接就關閉，若是還要請求其餘資源，就必須再新建一個鏈接
TCP鏈接的新建成本很高，由於須要客戶端和服務器三次握手，而且開始時發送速率較慢
網頁加載的外部資源越多，性能就越差
只有一種請求方式

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鏈接只能發送一個請求，每請求一個文檔就須要兩倍的RTT往返時間開銷(一個RTT用於鏈接TCP鏈接，另外一個用於請求和接收文檔)。

如圖所示：當HTTP協議首先要與服務器創建TCP鏈接，這就須要三次握手。當三次握手的前兩部分完成後(即通過一個RTT時間後)，萬維網客戶就把HTTP請求報文做爲第三次握手的第三個報文的數據發送給萬維網服務器，服務器收到HTTP報文後，就把所請求的文檔做爲響應報文返回給客戶。

發送數據完畢，鏈接就關閉，若是還要請求其餘資源，就必須再新建一個鏈接。
TCP鏈接的新建成本很高，由於須要客戶端和服務器三次握手，而且開始時發送速率較慢。（爲了解決這個問題：有些瀏覽器在請求時，用了一個非標準的CONNECTION字段。即CONNECTION:KEEP-ALIVE請求服務器不要關閉TCP鏈接，以便其餘請求複用，服務器一樣回覆這個字段；以實現TCP的複用，直到客戶端或服務器主動關閉鏈接，但，這不是標準字段，不一樣實現的行爲可能不一致，所以不是根本的解決辦法。
網頁加載的外部資源越多，性能就越差。

5. HTTP/1.1版本篇html

要點

引入了持久鏈接(PERSISITENT CONNECTION),即TCP鏈接默認不關閉，能夠被多個請求複用，不用聲明（簡單的說：就是服務器在發送響應後仍熱在一段時間內保持這條鏈接，使同一個用戶（瀏覽器）和該服務器能夠繼續在這條鏈接上傳送後續的HTTP請求報文和響應報文）。CONNECTION:KEEP-ALIVE客戶端和服務器發現對方一段時間沒有活動，就能夠主動關閉鏈接。不過，規範的作法是，客戶端在最後一個請求時明確要求服務器關閉TCP鏈接。CONNECTION:CLOSEgit
目前，對於同一個域名，大多數瀏覽器容許同時創建6個持久鏈接。github
引入了管道機制，即在同一個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協議是無鏈接，無狀態的；(無鏈接：雖然HTTP使用了TCP鏈接，但通訊的雙方在交換HTTP報文以前不須要創建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延遲