整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
本文中，我們將簡要回顧 HTTP 協議的發展歷史。對 HTTP 不同語義的完整討論超出了本文的范圍，但理解 HTTP 的關鍵設計變更以及每個變更背后的動機將為我們討論 HTTP 性能提供必要的背景
-- Ilya Grigorik
譯注：本文來源于 2013 年出版的《 High Performance Browser Networking 》的第九章，因此有些信息略有過時。事實上，現在 HTTP/2 已經有相當的不是，而新的 HTTP/3 也在設計和標準制定當中。
超文本傳輸協議(Hypertext Transfer Protocol)（HTTP）是互聯網上最普遍和廣泛采用的應用程序協議之一。它是客戶端和服務器之間的通用語言，支持現代 Web。從最初作為單個的關鍵字和文檔路徑開始，它已成為不僅僅是瀏覽器的首選協議，而且幾乎是所有連接互聯網硬件和軟件應用程序的首選協議。
在本文中，我們將簡要回顧 HTTP 協議的發展歷史。對 HTTP 不同語義的完整討論超出了本文的范圍，但理解 HTTP 的關鍵設計變更以及每個變更背后的動機將為我們討論 HTTP 性能提供必要的背景，特別是在 HTTP/2 中即將進行的許多改進。
蒂姆·伯納斯·李(Tim Berners-Lee) 最初的 HTTP 提案在設計時考慮到了簡單性，以幫助他采用他的另一個新想法： 萬維網(World Wide Web)。這個策略看起來奏效了：注意，他是一個有抱負的協議設計者。
1991 年，伯納斯·李概述了這個新協議的動機，并列出了幾個高級設計目標：文件傳輸功能、請求超文檔存檔索引搜索的能力，格式協商以及將客戶端引用到另一個服務器的能力。為了證明該理論的實際應用，構建了一個簡單原型，它實現了所提議功能的一小部分。
然而，即使這聽起來也比實際復雜得多。這些規則支持的是一種非常簡單的，對 Telnet 友好的協議，一些 Web 服務器至今仍然支持這種協議：
$> telnet google.com 80
Connected to 74.125.xxx.xxx
GET /about/
(hypertext response)
(connection closed)
請求包含這樣一行：GET 方法和請求文檔的路徑。響應是一個超文本文檔，沒有標題或任何其他元數據，只有 HTML。真的是再簡單不過了。此外，由于之前的交互是預期協議的子集，因此它獲得了一個非官方的 HTTP 0.9 標簽。其余的，就像他們所說的，都是歷史。
從 1991 年這些不起眼的開始，HTTP 就有了自己的生命，并在接下來幾年里迅速發展。讓我們快速回顧一下 HTTP 0.9 的特性：
流行的 Web 服務器，如 Apache 和 Nginx，仍然支持 HTTP 0.9 協議，部分原因是因為它沒有太多功能！如果你感興趣，打開 Telnet 會話并嘗試通過 HTTP 0.9 訪問 google.com 或你最喜歡的網站，并檢查早期協議的行為和限制。
1991 年至 1995 年期間，HTML 規范和一種稱為 “web 瀏覽器”的新型軟件快速發展，面向消費者的公共互聯網基礎設施也開始出現并快速增長。
完美風暴：1990 年代初的互聯網熱潮
基于蒂姆·伯納斯·李最初的瀏覽器原型，美國國家超級計算機應用中心（NCSA）的一個團隊決定實現他們自己的版本。就這樣，第一個流行的瀏覽器誕生了：NCSA Mosaic。1994 年 10 月，NCSA 團隊的一名程序員 Marc Andreessen 與 Jim Clark 合作創建了 Mosaic Communications，該公司后來改名為 Netscape（網景），并于 1994 年 12 月發布了 Netscape Navigator 1.0。從這一點來說，已經很清楚了，萬維網已經不僅僅是學術上的好奇心了。
實際上，同年在瑞士日內瓦組織了第一次萬維網會議，這導致 萬維網聯盟(World Wide Web Consortium)（W3C）的成立，以幫助指導 HTML 的發展。同樣，在 IETF 內部建立了一個并行的 HTTP 工作組(HTTP Working Group)（HTTP-WG），專注于改進 HTTP 協議。后來這兩個團體一直對 Web 的發展起著重要作用。
最后，完美風暴來臨，CompuServe，AOL 和 Prodigy 在 1994-1995 年的同一時間開始向公眾提供撥號上網服務。憑借這股迅速的浪潮，Netscape 在 1995 年 8 月 9 日憑借其成功的 IPO 創造了歷史。這預示著互聯網熱潮已經到來，人人都想分一杯羹！
不斷增長的新 Web 所需功能及其在公共網站上的應用場景很快暴露了 HTTP 0.9 的許多基礎限制：我們需要一種能夠提供超文本文檔、提供關于請求和響應的更豐富的元數據，支持內容協商等等的協議。相應地，新興的 Web 開發人員社區通過一個特殊的過程生成了大量實驗性的 HTTP 服務器和客戶端實現來回應：實現，部署，并查看其他人是否采用它。
從這些急速增長的實驗開始，一系列最佳實踐和常見模式開始出現。1996 年 5 月， HTTP 工作組(HTTP Working Group)（HTTP-WG）發布了 RFC 1945，它記錄了許多被廣泛使用的 HTTP/1.0 實現的“常見用法”。請注意，這只是一個信息性 RFC：HTTP/1.0，如你所知的，它不是一個正式規范或 Internet 標準！
話雖如此，HTTP/1.0 請求看起來應該是：
$> telnet website.org 80
Connected to xxx.xxx.xxx.xxx
GET /rfc/rfc1945.txt HTTP/1.0 ?
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Accept: */*
HTTP/1.0 200 OK ?
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 01 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 1 May 1996 12:45:26 GMT
Server: Apache 0.84
(plain-text response)
(connection closed)
前面的交互并不是 HTTP/1.0 功能的詳盡列表，但它確實說明了一些關鍵的協議更改：
請求頭和響應頭都保留為 ASCII 編碼，但響應對象本身可以是任何類型：HTML 文件、純文本文件、圖像或任何其他內容類型。因此，HTTP 的“超文本傳輸”部分在引入后不久就變成了用詞不當。實際上，HTTP 已經迅速發展成為一種超媒體傳輸，但最初的名稱沒有改變。
除了媒體類型協商之外，RFC 還記錄了許多其他常用功能：內容編碼、字符集支持、多部分類型、授權、緩存、代理行為、日期格式等。
今天，幾乎所有 Web 上的服務器都可以并且仍將使用 HTTP/1.0。不過，現在你應該更加清楚了！每個請求都需要一個新的 TCP 連接，這會對 HTTP/1.0 造成嚴重的性能損失。參見 三次握手 ，接著會 慢啟動 。
將 HTTP 轉變為官方 IETF 互聯網標準的工作與圍繞 HTTP/1.0 的文檔工作并行進行，并計劃從 1995 年至 1999 年完成。事實上，第一個正式的 HTTP/1.1 標準定義于 RFC 2068，它在 HTTP/1.0 發布大約六個月后，即 1997 年 1 月正式發布。兩年半后，即 1999 年 6 月，一些新的改進和更新被納入標準，并作為 RFC 2616 發布。
HTTP/1.1 標準解決了早期版本中發現的許多協議歧義，并引入了一些關鍵的性能優化：保持連接，分塊編碼傳輸，字節范圍請求，附加緩存機制，傳輸編碼和請求管道。
有了這些功能，我們現在可以審視一下由任何現代 HTTP 瀏覽器和客戶端執行的典型 HTTP/1.1 會話：
$> telnet website.org 80
Connected to xxx.xxx.xxx.xxx
GET /index.html HTTP/1.1 ?
Host: website.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __qca=P0-800083390... (snip)
HTTP/1.1 200 OK ?
Server: nginx/1.0.11
Connection: keep-alive
Content-Type: text/html; charset=utf-8
Via: HTTP/1.1 GWA
Date: Wed, 25 Jul 2012 20:23:35 GMT
Expires: Wed, 25 Jul 2012 20:23:35 GMT
Cache-Control: max-age=0, no-cache
Transfer-Encoding: chunked
100 ?
<!doctype html>
(snip)
100
(snip)
0 ?
GET /favicon.ico HTTP/1.1 ?
Host: www.website.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4)... (snip)
Accept: */*
Referer: http://website.org/
Connection: close ?
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: __qca=P0-800083390... (snip)
HTTP/1.1 200 OK ?
Server: nginx/1.0.11
Content-Type: image/x-icon
Content-Length: 3638
Connection: close
Last-Modified: Thu, 19 Jul 2012 17:51:44 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Via: HTTP/1.1 GWA
Date: Sat, 21 Jul 2012 21:35:22 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Etag: W/PSA-GAu26oXbDi
(icon data)
(connection closed)
哇，這里發生了很多事情！第一個也是最明顯的區別是我們有兩個對象請求，一個用于 HTML 頁面，另一個用于圖像，它們都通過一個連接完成。這就是保持連接的實際應用，它允許我們重用現有的 TCP 連接到同一個主機的多個請求，提供一個更快的最終用戶體驗。參見 TCP 優化 。
要終止持久連接，注意第二個客戶端請求通過 Connection 請求頭向服務器發送顯示的 close。類似地，一旦傳輸響應，服務器就可以通知客戶端關閉當前 TCP 連接。從技術上講，任何一方都可以在沒有此類信號的情況下終止 TCP 連接，但客戶端和服務器應盡可能提供此類信號，以便雙方都啟用更好的連接重用策略。
HTTP/1.1 改變了 HTTP 協議的語義，默認情況下使用保持連接。這意味著，除非另有說明（通過 Connection:close 頭），否則服務器應默認保持連接打開。
但是，同樣的功能也被反向移植到 HTTP/1.0 上，通過 Connection:keep-Alive 頭啟用。因此，如果你使用 HTTP/1.1，從技術上講，你不需要 Connection:keep-Alive 頭，但許多客戶端仍然選擇提供它。
此外，HTTP/1.1 協議還添加了內容、編碼、字符集，甚至語言協商、傳輸編碼、緩存指令、客戶端 cookie，以及可以針對每個請求協商的十幾個其他功能。
我們不打算詳細討論每個 HTTP/1.1 特性的語義。這個主題可以寫一本專門的書了，已經有了很多很棒的書。相反，前面的示例很好地說明了 HTTP 的快速進展和演變，以及每個客戶端-服務器交換的錯綜復雜的過程，里面發生了很多事情！
要了解 HTTP 協議所有內部工作原理，參考 David Gourley 和 Brian Totty 共同撰寫的權威指南： The Definitive Guide。
RFC 2616 自發布以來，已經成為互聯網空前增長的基礎：數十億各種形狀和大小的設備，從臺式電腦到我們口袋里的小型網絡設備，每天都在使用 HTTP 來傳送新聞，視頻，在我們生活中的數百萬的其他網絡應用程序都在依靠它。
一開始是一個簡單的，用于檢索超文本的簡單協議，很快演變成了一種通用的超媒體傳輸，現在十年過去了，它幾乎可以為你所能想象到的任何用例提供支持?？梢允褂脜f議的服務器無處不在，客戶端也可以使用協議，這意味著現在許多應用程序都是專門在 HTTP 之上設計和部署的。
需要一個協議來控制你的咖啡壺？RFC 2324 已經涵蓋了超文本咖啡壺控制協議（HTCPCP/1.0）- 它原本是 IETF 在愚人節開的一個玩笑，但在我們這個超鏈接的新世界中，它不僅僅意味著一個玩笑。
超文本傳輸協議（HTTP）是一個應用程序級的協議，用于分布式、協作、超媒體信息系統。它是一種通用的、無狀態的協議，可以通過擴展請求方法、錯誤碼和頭，用于超出超文本之外的許多任務，比如名稱服務器和分布式對象管理系統。HTTP 的一個特性是數據表示的類型和協商，允許獨立于傳輸的數據構建系統。
RFC 2616: HTTP/1.1, June 1999
HTTP 協議的簡單性是它最初被采用和快速增長的原因。事實上，現在使用 HTTP 作為主要控制和數據協議的嵌入式設備（傳感器，執行器和咖啡壺）并不罕見。但在其自身成功的重壓下，隨著我們越來越多地繼續將日?；愚D移到網絡 —— 社交、電子郵件、新聞和視頻，以及越來越多的個人和工作空間，它也開始顯示出壓力的跡象。用戶和 Web 開發人員現在都要求 HTTP/1.1 提供近乎實時的響應能力和協議 性能，如果不進行一些修改，就無法滿足這些要求。
為了應對這些新挑戰，HTTP 必須繼續發展，因此 HTTPbis 工作組在 2012 年初宣布了一項針對 HTTP/2 的新計劃：
已經有一個協議中出現了新的實現經驗和興趣，該協議保留了 HTTP 的語義，但是沒有保留 HTTP/1.x 的消息框架和語法，這些問題已經被確定為妨礙性能和鼓勵濫用底層傳輸。
工作組將使用有序的雙向流中生成 HTTP 當前語義的新表達式的規范。與 HTTP/1.x 一樣，主要傳輸目標是 TCP，但是應該可以使用其他方式傳輸。
HTTP/2 charter, January 2012
HTTP/2 的主要重點是提高傳輸性能并支持更低的延遲和更高的吞吐量。主要的版本增量聽起來像是一個很大的步驟，但就性能而言，它將是一個重大的步驟，但重要的是要注意，沒有任何高級協議語義收到影響：所有的 HTTP 頭，值和用例是相同的。
任何現有的網站或應用程序都可以并且將通過 HTTP/2 傳送而無需修改。你無需修改應用程序標記來利用 HTTP/2。HTTP 服務器將來一定會使用 HTTP/2，但這對大多數用戶來說應該是透明的升級。如果工作組實現目標，唯一的區別應該是我們的應用程序以更低的延遲和更好的網絡連接利用率來傳送數據。
話雖如此，但我們不要走的太遠了。在討論新的 HTTP/2 協議功能之前，有必要回顧一下我們現有的 HTTP/1.1 部署和性能最佳實踐。HTTP/2 工作組正在新規范上取得快速的進展，但即使最終標準已經完成并準備就緒，在可預見的未來，我們仍然必須支持舊的 HTTP/1.1 客戶端，實際上，這得十年或更長時間。
via: https://hpbn.co/brief-history-of-http/#http-09-the-one-line-protocol
作者： Ilya Grigorik 選題： lujun9972 譯者： MjSeven 校對： wxy
本文由 LCTT 原創編譯， Linux中國 榮譽推出
介
AsciidocFX是一個功能強大的AsciiDoc編輯器和工具鏈，它使用JavaFX 21構建。AsciiDoc是一種輕量級標記語言，用于編寫文檔、書籍、幻燈片和其他形式的出版物。AsciidocFX提供了一個直觀的用戶界面，讓用戶能夠輕松地創建、編輯和導出AsciiDoc文檔。
特性
AsciidocFX具有許多令人印象深刻的特性，使其成為AsciiDoc文檔處理的理想選擇。下面是該工具的一些突出特性：
1. 強大的編輯功能
AsciidocFX提供了豐富的編輯功能，使用戶能夠高效地編寫AsciiDoc文檔。編輯器具有語法高亮顯示、自動完成、即時預覽等功能，可幫助用戶準確無誤地編寫和格式化文檔。
2. 多格式導出
AsciidocFX支持將AsciiDoc文檔導出為多種格式，包括PDF、Epub、Mobi和HTML。這使得用戶能夠根據需要靈活地生成不同格式的文檔，并輕松地與其他人共享或發布。
3. 自定義主題和樣式
該工具允許用戶自定義文檔的外觀和樣式。用戶可以選擇不同的主題和樣式表，以滿足其特定需求，并創建專業而個性化的文檔。
4. 圖形化界面
AsciidocFX提供了一個直觀的圖形化界面，使用戶能夠輕松管理和組織復雜的AsciiDoc項目。用戶可以在一個集成的環境中創建、編輯和預覽文檔，提高工作效率并減少錯誤。
5. 插件生態系統
AsciidocFX支持插件擴展，用戶可以根據自己的需求選擇和安裝各種插件。這使得用戶能夠根據自己的工作流程和偏好定制編輯器，并添加額外的功能和集成。
6. 多平臺支持
AsciidocFX可在多個操作系統上運行，包括Windows、Mac和Linux。這使得用戶可以在他們喜歡的操作系統上使用這個功能強大的工具，并與不同平臺上的其他人方便地協作。
使用示例
以下是使用AsciidocFX創建AsciiDoc文檔的簡單示例流程：
總結
AsciidocFX是一個強大而靈活的AsciiDoc編輯器和工具鏈，它通過使用JavaFX 21提供了一個直觀的用戶界面和豐富的功能。它支持多種格式的導出，自定義主題和樣式，插件擴展以及跨平臺的多平臺支持。無論是撰寫文檔、編寫書籍、創建幻燈片還是生成其他形式的出版物，AsciidocFX都是一個值得考慮的選擇。它簡化了AsciiDoc文檔處理的流程，提供了便捷的編輯環境和導出選項，使用戶能夠高效地創建專業級的文檔作品。
項目地址：https://github.com/asciidocfx/AsciidocFX
我們知道HTTP是瀏覽器中最重要且使用最多的協議，它不僅是瀏覽器與服務端的通信語言，更是互聯網的基石。隨著瀏覽器的不斷更新迭代，HTTP為了適應技術的更新也在不斷進化，學習HTTP的最佳途徑就是從瀏覽器的發展視角來了解HTTP的演進：即將完成使命的HTTP/1、正在向我們走來的HTTP/2、未來的HTTP/3
HTTP 是瀏覽器與服務端最主要的通信協議
20 世紀 60 年代，美國國防部高等研究計劃署（ARPA）建立了 ARPA 網，這被認為是互聯網的起源。70 年代，研究人員基于對 ARPA 網的實踐和思考，發明出了著名的 TCP/IP 協議。該協議具有良好的分層結構和穩定的性能，并在 80 年代中期進入了 UNIX 系統內核，促使更多的計算機接入了網絡。
1989 年，蒂姆伯納斯-李博士發表了一篇論文，提出了在互聯網上構建超鏈接文檔系統的構想。在篇文章中他確立了三項關鍵技術：URI、HTML、HTTP。
1991年HTTP（HyperText Transfer Protocol，超文本傳輸協議）正式誕生，萬維網協會（World Wide Web Consortium，W3C）和互聯網工程任務組（IETF）制定了 HTTP 0.9 標準。該協議誕生之初的作用是傳輸超文本內容HTML，并且只支持GET請求。
協議定義了客戶端發起請求、服務端響應請求的通信模式。所以當時的請求報文只有一行：
GET + 請求的文件路徑
服務端在收到請求后會返回一個以 ASCII 字符流編碼的 HTML 文檔。
請求： GET /index.html
響應： <html><body>Hello HTTP/0.9</body></html>
流程：
特點： 簡單，一個請求需要一個連接。
HTTP/0.9 雖然簡單，但是它充分驗證了 Web 服務的可行性
隨著互聯網的發展，之前的HTTP/0.9已經無法滿足用戶需求了，瀏覽器希望通過HTTP來傳輸腳本、樣式、圖片、音視頻等不同類型的文件，所以在1996年HTTP進行了一次版本更新：
請求： 第一行請求命令+版本信息，后面的多行為頭信息
GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*
響應： 響應頭信息 + 空行(\r\n) + 數據部分
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 2345
Expires: Thu, 05 Dec 2020 16:00:00 GMT
Last-Modified: Wed, 5 August 2020 15:55:28 GMT
Server: Apache 0.84
<html>
<body>Hello World</body>
</html>
HTTP/1.0最主要的缺點還是跟HTTP/0.9一樣，每一個TCP連接只能發送一個HTTP請求，服務器發送完響應，就關閉連接。如果后面需要請求新的數據，則需要再次建立TCP連接，但是TCP建立連接的三次握手成本比較高，并且TCP連接初始的時候發送數據的速度相對較慢，有一個慢啟動和擁塞避免的階段。極端情況，如果每次請求的數據很少，但是請求很頻繁，這樣每次請求很少的數據都需要建立連接然后斷開。
為了解決這個問題，在1.0版本使用了一個非標準的Connection頭部字段。當客戶端再請求頭部信息里面帶上Connection：keep-alive的時候，服務器在發送完響應數據之后，就不會斷開TCP連接了，從而達到復用同一個TCP連接的目的。但是由于不是標準字段，不同的實現可能導致表現得不一致，因此不能從根本上解決這個問題。
HTTP/1.0最核心的改變是增加了頭部設定，頭部內容以鍵值對的形式設置。請求頭部通過 Accept 字段來告訴服務端可以接收的文件類型，響應頭部再通過 Content-Type 字段來告訴瀏覽器返回文件的類型。頭部字段不僅用于解決不同類型文件傳輸的問題，也可以實現其他很多功能如緩存、認證信息等。
HTTP/1.0 并不是一個“標準”，只是一份參考文檔，不具有實際的約束力。
隨著互聯網的快速發展，HTTP/1.0也無法滿足用戶需求了，最根本的問題就是鏈接問題， HTTP/1.0 每進行一次通信，都需要經歷建立連接、傳輸數據和斷開連接三個階段。當一個頁面引用了較多的外部文件時，這個建立連接和斷開連接的過程就會增加大量網絡開銷。
為了解決 HTTP/1.0 的問題，1999 年推出的 HTTP/1.1 有以下特點：
它指的是在一個TCP連接內，多個HTTP請求可以并行，客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但服務器端必須按照接收到客戶端請求的先后順序依次回送響應結果，以保證客戶端能 夠區分出每次請求的響應內容。
HTTP/1.1 通過長連接減少了大量創建/斷開連接造成的性能消耗，但是它的并發能力受到限制，表現在兩個方面：
2012年google提出了SPDY的方案，優化了HTTP1.X的請求延遲，解決了HTTP1.X的安全性，具體如下：
2015 年正式發布的 HTTP/2 默認不再使用 ASCII 編碼傳輸，而是改為二進制數據，來提升傳輸效率。
客戶端在發送請求時會將每個請求的內容封裝成不同的帶有編號的二進制幀（Frame），然后將這些幀同時發送給服務端。服務端接收到數據之后，會將相同編號的幀合并為完整的請求信息。同樣，服務端返回結果、客戶端接收結果也遵循這個幀的拆分與組合的過程。
有了二進制分幀后，對于同一個域，客戶端只需要與服務端建立一個連接即可完成通信需求，這種利用一個連接來發送多個請求的方式稱為多路復用。每一條路都被稱為一個stream（流）。
特點：
缺點：
HTTP/2雖然解決了許多問題，但在TCP協議級別上仍然存在類似的隊頭問題，而TCP仍然是Web的構建基礎。當 TCP 數據包在傳輸過程中丟失時，在服務器重新發送丟失的數據包之前，接收方無法確認傳入的數據包。由于 TCP 在設計上不遵循 HTTP 之類的高級協議，因此單個丟失的數據包將阻塞所有進行中的 HTTP 請求的流，直到重新發送丟失的數據為止。這個問題在不可靠的連接上尤為突出，這在無處不在的移動設備時代并不罕見。
HTTP/2 由于采用二進制分幀進行多路復用，通常只使用一個 TCP 連接進行傳輸，在丟包或網絡中斷的情況下后面的所有數據都被阻塞。
HTTP/2 的問題不能僅靠應用程序層來解決，因此協議的新迭代必須更新傳輸層。但是，創建新的傳輸層協議并非易事。傳輸協議需要硬件供應商的支持，并且需要大多數網絡運營商的部署才能普及。
幸運的是還有另一種選擇。UDP 協議與 TCP 一樣得到廣泛支持，但前者足夠簡單，可以作為在其之上運行的自定義協議的基礎。UDP 數據包是一勞永逸的：沒有握手、持久連接或錯誤校正。HTTP3 背后的主要思想是放棄 TCP，轉而使用基于 UDP 的 QUIC （快速UDP互聯網連接）協議。
與 HTTP2 在技術上允許未加密的通信不同，QUIC 嚴格要求加密后才能建立連接。此外，加密不僅適用于 HTTP 負載，還適用于流經連接的所有數據，從而避免了一大堆安全問題。建立持久連接、協商加密協議，甚至發送第一批數據都被合并到 QUIC 中的單個請求/響應周期中，從而大大減少了連接等待時間。如果客戶端具有本地緩存的密碼參數，則可以通過簡化的握手重新建立與已知主機的連接。
為了解決傳輸級別的線頭阻塞問題，通過 QUIC 連接傳輸的數據被分為一些流。流是持久性 QUIC 連接中短暫、獨立的“子連接”。每個流都處理自己的錯誤糾正和傳遞保證，但使用連接全局壓縮和加密屬性。每個客戶端發起的 HTTP 請求都在單獨的流上運行，因此丟失數據包不會影響其他流/請求的數據傳輸。
協議版本 | 解決的核心問題 | 解決方式 |
0.9 | HTML 文件傳輸 | 確立了客戶端請求、服務端響應的通信流程 |
1.0 | 不同類型文件傳輸 | 設立頭部字段 |
1.1 | 創建/斷開 TCP 連接開銷大 | 建立長連接進行復用 |
2 | 并發數有限 | 二進制分幀 |
3 | TCP 丟包阻塞 | 采用 UDP 協議 |
SPDY | HTTP1.X的請求延遲 | 多路復用 |
一個完整的HTTP是包含請求與響應的，所以需要通過TCP來創建連接通道
一個TCP通道可以通過多個HTTP請求
一般來講需要通過三次握手來確認連接過程，規避因為網絡原因從而產生的資源消耗，從而創建TCP連接
第一次握手： 客戶端發送syn包(syn=x)到服務器，并進入SYN_SEND狀態，等待服務器確認；
第二次握手： 服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手： 客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢后，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP 連接都將被一直保持下去。
與建立連接的“三次握手”類似，斷開一個TCP連接則需要“四次握手”。
第一次揮手： 主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不 會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但是，此時主動關閉方還可 以接受數據。
第二次揮手： 被動關閉方收到FIN包后，發送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號）。
第三次揮手： 被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
第四次揮手： 主動關閉方收到FIN后，發送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。
HTTP 1.1支持長連接（PersistentConnection）和請求的管道（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection: Keep-Alive； HTTP1.0默認使用短連接，規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求處理后立即斷開TCP連接，服務器不跟蹤 每個客戶也不記錄過去的請求。要建立長連接，可以在請求消息中包含Connection: Keep-Alive頭域，如果服務器愿意維持這條連接，在響應消息中也會包含一個Connection: Keep-Alive的頭域。
在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since,If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，并且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接。
在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。
在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。
官網提供了多種版本的對比測試有HTTP1.1與HTTP2的比較，還有服務器端推送(server-push)不同個數之間的比較：（由于網絡延遲不同，測試結果或有差異）
可以看到分別使用HTTP/1.1和HTTP/2加載同一張由多張小圖片組成的大圖片：HTTP/1.1用了7.41s，而HTTP/2只用了1.47s。HTTP2比HTTP/1.1快了將近5倍。
因為為了加載這張大圖，需要請求許多的小圖，HTTP/1.1采用的是串行請求，所以速度要比采用并行請求的HTTP/2要慢上許多。
HTTPS是以安全為目標的 HTTP 通道，是 HTTP 的安全版。HTTPS 的安全基礎是 SSL。SSL 協議位于 TCP/IP 協議與各種應用層協議之間，為數據通訊提供安全支持。
SSL 協議可分為兩層：
HTTPS的優點
HTTPS的缺點
作者：前端南玖
出處：https://www.cnblogs.com/songyao666/p/16065502.html
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
