HTTP的發展歷史

  1. http版本導圖

2. HTTP版本之概念篇
  • HTTP(超文本傳輸協議),是互聯網上應用最爲廣泛的一種網絡協議,定義了瀏覽器怎樣向服務器請求文檔,以及服務器怎樣把文檔傳送給瀏覽器。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連接只能發送一個請求,每請求一個文檔就需要兩倍的RTT往返時間開銷(一個RTT用於連接TCP連接,另一個用於請求和接收文檔)。
如圖所示:當HTTP協議首先要與服務器建立TCP連接,這就需要三次握手。當三次握手的前兩部分完成後(即經過一個RTT時間後),萬維網客戶就把HTTP請求報文作爲第三次握手的第三個報文的數據發送給萬維網服務器,服務器收到HTTP報文後,就把所請求的文檔作爲響應報文返回給客戶。
  • 發送數據完畢,連接就關閉,如果還要請求其他資源,就必須再新建一個連接。
  • TCP連接的新建成本很高,因爲需要客戶端和服務器三次握手,並且開始時發送速率較慢。(爲了解決這個問題:有些瀏覽器在請求時,用了一個非標準的CONNECTION字段。即CONNECTION:KEEP-ALIVE請求服務器不要關閉TCP連接,以便其他請求複用,服務器同樣回覆這個字段;以實現TCP的複用,直到客戶端或服務器主動關閉連接,但,這不是標準字段,不同實現的行爲可能不一致,因此不是根本的解決辦法。
  • 網頁加載的外部資源越多,性能就越差。

5. HTTP/1.1版本篇

要點
  • 引入了持久連接(PERSISITENT CONNECTION),即TCP連接默認不關閉,可以被多個請求複用,不用聲明(簡單的說:就是服務器在發送響應後仍熱在一段時間內保持這條連接,使同一個用戶(瀏覽器)和該服務器可以繼續在這條連接上傳送後續的HTTP請求報文和響應報文)。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協議是無連接,無狀態的;(無連接:雖然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延遲

    最後,給大家推薦一個前端學習進階內推交流羣685910553前端資料分享),不管你在地球哪個方位,
    不管你參加工作幾年都歡迎你的入駐!(羣內會定期免費提供一些羣主收藏的免費學習書籍資料以及整理好的面試題和答案文檔!)

如果您對這個文章有任何異議,那麼請在文章評論處寫上你的評論。

如果您覺得這個文章有意思,那麼請分享並轉發,或者也可以關注一下表示您對我們文章的認可與鼓勵。

願大家都能在編程這條路,越走越遠。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章