超文本傳輸協定(HyperText Transfer Protocol,縮寫: HTTP),主要做為數據通訊的基礎協定,舉凡我們上網的網頁、圖片…,都是由HTTP協定為基底標準,讓服務端與用戶端可以相互通訊,達到互動、傳遞資訊的作用,而從最初版的單向傳輸也隨著時代的演進,應用漸趨複雜的趨勢下慢慢優化到雙向互動,而大數據的時代下,龐大的數據量也凸顯了傳輸效率的問題,因而也對這部分進行改善,讓傳輸更加順暢,就讓我們一起來看看HTTP的演進史吧!
HTTP 1.0的遠古時代
每一次都需要建立連線,並且只能有一次的請求。
HTTP 1.1 做了些改進
HTTP1.1版本之下,在一個請求中可以夾帶多個請求,並回傳,以此來減少多次連線的開銷,以此來改善HTTP1.0多次連線的問題。
到了HTTP/2的現代又有什麼大躍進?
在HTTP1的時代雖然做了很多連線上的改進,但是隨著用來越多應用都搬移到網路上,雙向溝通的需求也越趨明顯,而1.x版的架構下並沒有支援Server端主動通知Client端的機制,在HTTP 2也都加入了這些特性。
在傳輸上也將原本整包資料的傳送方式切碎成小包小包, 並給予每一包一個編號, 送到目的地之後再重組, 如此一來就可以傳送多批資料也不會有等待一批資料過於久的現象。
幾個優點如下: ● Header壓縮,減少傳輸成本。
● 支援Server Push,由伺服器推送資料到瀏覽器。
● 連線重複使用,減少開銷。
下一個未來發展的重點「HTTP/3」
我們在簡介說明的部分有稍微提到,未來隨著數據量以及更多的需求轉移到互聯網時,為了避免堵塞造成使用體驗不佳,因而在傳書上持續的演化,而HTTP/2之前仍然是追求可靠性傳輸的TCP協定,在HTTP/3大膽的引進了UDP不可靠傳輸的概念,但也並非完全不可靠,而是基於UDP做了一些改良,這個協定稱為QUIC:
由上圖,很明顯的看到我們原本三次的傳輸來確認雙方可以進行通訊的過程,改良到只要一次就完成,更何況TCP + TLS更多次確認的過程,這邊其實QUIC的過程已經包含TLS了,只是未將詳細過程羅列,有興趣者請參考Wiki。
但我們的心中一定充滿著幾個疑問: ● 為什麼QUIC能保證可靠性呢? ⇒ 因為加入了RAID5的演算機制,一次的傳送多個封包中,會加入一包檢驗的加總,並且可以反推哪一包失敗,進行某包重傳即可。
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 資料包: A+B+C
檢驗包: N
關係為: A+B+C=N
當第「A」包丟失時, A = Z — B — C
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — ● QUIC後續不用重新連接嗎? ⇒ 不用,因為連接可以重複使用,其中加入了Connection ID做為識別。
================================================