超文本傳輸協定（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做為識別。
================================================
喜歡撰寫文章的你，不妨來了解一下：
Web3.0時代下為創作者、閱讀者打造的專屬共贏平台 — 為什麼要加入？
歡迎加入一起練習寫作，賺取知識，累積財富！
