HTTP/s HTTP/s HTTP3

介紹

這是我最喜歡的主題之一，這將是一篇知識豐富的文章。所以請仔細閱讀。

域分片

• 域分片是一種用於提高網站速度和效能的技術。
• 它涉及跨多個域分割或「分片」資源。
• 當瀏覽器載入網站時，它會向網站伺服器發出請求以下載不同類型的資源，如 HTML、CSS、JavaScript、圖像等。
• 但是，瀏覽器限制它們對單一網域進行的並發連接（下載）數量。 （6，取決於瀏覽器）
• 透過跨多個網域分片資源（例如，從與腳本不同的網域提供映像），您可以繞過此限制並同時下載更多資源，這可以加快頁面載入時間。

多用

• 允許透過單一連線同時發送多個請求和回應（預設約 100）

注意：-

• 但是，要注意的是HTTP/2，最新版本的HTTP協定，支援多路復用，

如何採用/更改當前協定

• 要從 HTTP/1 切換到 HTTP/2，您需要將伺服器設定為支援 HTTP/2。

• 具體步驟取決於您使用的伺服器軟體。以下是一些常見伺服器的一般步驟：

阿帕契：

• Apache 從 2.4.17 版本開始支援 HTTP/2。要啟用它，您需要在 Apache 配置中包含 mod_http2 模組，然後將 Protocols h2 http/1.1 新增到您的配置中。

Nginx：

• Nginx 從 1.9.5 版本開始支援 HTTP/2。若要啟用它，請在 Nginx 設定的監聽指令中包含 http2，如下所示：listen 443 ssl http2。

Node.js：

-如果您使用 Node.js，則可以使用內建的 http2 模組來建立 HTTP/2 伺服器。

注意：-

請記住，HTTP/2 在大多數瀏覽器中都需要 HTTPS，因此您也需要為您的伺服器設定 SSL 憑證。

從前端的角度來看我們做了什麼？

• 不，從 HTTP/1 到 HTTP/2 的切換是在伺服器層級處理的，而不是在客戶端或前端層級處理。
• 但是，一旦您的伺服器支援HTTP/2，您可能需要重新考慮HTTP/1 常見的某些效能最佳化技術，例如網域分片或資產串聯，因為它們對於HTTP/2 可能是不必要的，甚至是有害的.

客戶端和伺服器如何連接

HTTP/1

• HTTP/1 在每個請求/回應模型的單一連線上運行。這意味著對於從客戶端到伺服器的每個請求，都會建立一個單獨的 TCP 連線。

• 如果一個網頁需要多種資源（如映像、CSS、JavaScript 檔案），則需要建立多個 TCP 連線。

• 這可能會導致稱為「隊頭阻塞」的問題，其中資源的載入可能會被前一個資源的載入所阻止。

• HTTP/1 不支援伺服器推送，這表示伺服器只能傳送客戶端請求的資源。

HTTP/2

• HTTP/2 引入了多路復用，它允許透過單一 TCP 連線同時發送多個請求和回應。這有效地消除了隊頭阻塞問題。

• HTTP/2 也引入了伺服器推送，伺服器可以在客戶端請求資源之前主動向客戶端發送資源。這可以透過減少客戶端和伺服器之間的往返請求來提高效能。

• HTTP/2 還支援標頭壓縮，這可以減少開銷並提高效能，特別是對於行動用戶。

HTTP/2 也支援標頭壓縮

• HTTP/2 引入了一項名為 標頭壓縮 的新功能，它減少了 HTTP 標頭的開銷。

• 在 HTTP/1 中，標頭以純文字形式發送，這可能會很大，並且會為每個請求和回應增加顯著的開銷。

• 對於標頭中包含 cookie 或令牌的請求尤其如此。

• HTTP/2 使用一種名為 HPACK 壓縮 的機制來壓縮標頭。

• HPACK 是一種簡單且安全的字串壓縮方案，可以減少標頭的大小，使 HTTP/2 請求和回應更快、更有效率。

HPACK 壓縮在內部工作

• これは、動的テーブル として知られる、クライアント側とサーバー側の両方で以前に送信されたヘッダー フィールドのリストを維持することによって行われます。

• 後続のリクエストまたは応答でヘッダー フィールドが繰り返される場合、ヘッダー フィールド全体を送信する代わりに、動的テーブル内のエントリを参照するインデックスが送信されます。

• これにより、特にリクエスト間で多くのヘッダーが繰り返される場合、リクエストと応答のヘッダーのサイズが大幅に削減されます。

HTTP/3

• HTTP/3 は、HTTP プロトコルの次のメジャー バージョンです。これは、Google によって開発されたトランスポート層プロトコルである QUIC の上に構築されています。

HTTP/2 と比較した HTTP/3 の利点をいくつか示します。

速度の向上:

• HTTP/3 は、HTTP/1 および HTTP/2 で使用されるトランスポート プロトコルである TCP よりも高速で信頼性が高くなるように設計された QUIC を使用します。
• QUIC は接続確立時間を短縮し、サーバーへの最初の接続を高速化します。

パケットロスのより適切な処理:

• HTTP/2 では、パケットが失われると、すべてのストリーム (リクエスト/レスポンス) が遅くなります。 QUIC はストリームを独立して処理することでこの問題を解決するため、失われたパケットは 1 つのストリームにのみ影響します。

接続の移行:

• QUIC は接続の移行をサポートしています。つまり、ユーザーがネットワークを変更した場合 (Wi-Fi から 4G への切り替えなど)、既存の接続を維持して新しいネットワークに移行できます。

• これは、元の IP アドレスに関連付けられている TCP では不可能です。

デフォルトの暗号化:

• QUIC にはデフォルトで TLS 1.3 暗号化が含まれています。これにより、プロトコルの安全性が高まり、接続のセットアップに必要な往復回数が削減されます。

サーバープッシュ:

• HTTP/2 と同様、HTTP/3 もサーバー プッシュをサポートしており、クライアントがリソースを要求する前に、サーバーがリソースをクライアントにプロアクティブに送信できます。

注:-

HTTP/3 にはいくつかの利点がありますが、現時点ではまだ広くサポートまたは使用されていないことに注意することが重要です。

参照:-

1. https://frontendmasters.com/courses/realtime/
2. https://developer.mozilla.org/en-US/docs/Web/HTTP
3. https://developer.mozilla.org/en-US/docs/Glossary/HTTP_2
4. https://developer.mozilla.org/en-US/docs/Glossary/HTTP_3

以上是HTTP/s HTTP/s HTTP3的詳細內容。更多資訊請關注PHP中文網其他相關文章！