HTTP/1.1

具体例・ユースケース

HTTP/1.1は非常に基本的なプロトコルであるため、実は特別なツールがなくてもその通信を体感できます。例えば、以下のようにncコマンド（またはtelnet）でTCP接続を張り、手動でリクエスト行とHostヘッダーを入力するだけで、Webサーバーから生のHTTP/1.1レスポンスを受け取ることができます。

$ nc example.com 80
GET / HTTP/1.1
Host: example.com
Connection: close

実務でHTTP/1.1が主役として登場する代表的な場面は次の通りです。

• CDNとオリジンサーバー間の通信：Cloudflare、Amazon CloudFront、Fastlyなどの多くのCDNは、ブラウザとの間ではHTTP/2やHTTP/3で通信していても、背後のオリジンサーバー（実際にコンテンツを生成するアプリケーションサーバー）との接続はシンプルさと安定性を優先してHTTP/1.1のままというケースが多く見られます。
• 内部マイクロサービス間のREST API通信：社内システムやマイクロサービス間の通信では、gRPCのようなHTTP/2ベースの技術を使わず、あえてシンプルなJSON over HTTP/1.1のREST APIを採用するチームも少なくありません。curlでの疎通確認やWiresharkでのパケット解析が容易という「デバッグのしやすさ」が理由に挙げられます。
• 組み込み機器・IoTデバイス：メモリやCPUリソースが限られた組み込み機器では、HTTP/2のバイナリフレーミングやHPACK圧縮を実装するコストが見合わず、軽量なHTTP/1.1クライアントのみを搭載するケースが一般的です。
• 企業プロキシ・古いロードバランサー配下の環境：一部の企業ネットワークでは、プロキシやセキュリティ機器がHTTP/2のバイナリフレームを正しく解釈できず、通信がHTTP/1.1にフォールバックされることがあります。curlでcurl --http1.1 https://example.comのように明示的にバージョンを固定して検証するのは、こうした環境依存の問題を切り分ける定石の一つです。
• APIデバッグ・障害調査：HTTP/2やHTTP/3はバイナリ形式のため、Wiresharkなどでキャプチャしても人間がそのまま読むことはできません。障害調査でクライアントとサーバーのやり取りを目視確認したい場合、あえてHTTP/1.1に固定して通信させるのは今でも有効なデバッグ手法です。

HTTP/1.1の制限と課題

HTTP/1.1は長年にわたり活躍してきましたが、いくつかの構造的な制限があります。

• ヘッドオブラインブロッキング（Head-of-Line Blocking）：1本のTCP接続では、あるリクエストへのレスポンス生成に時間がかかると、その後ろに並ぶリクエストの処理もすべて待たされます。パイプライン化が普及しなかったこともあり、ブラウザは代わりに「1オリジンあたり複数のTCP接続を並行して張る」という回避策を採りました。ただしRFC 2616では推奨上限が2接続とされていたため、現在の主要ブラウザは実装上おおむね6本前後の同時接続を1オリジンに対して張ることで並列度を稼いでいます。
• ヘッダーの非圧縮によるオーバーヘッド：Cookieや認証トークンなどでヘッダーサイズが大きくなりがちな昨今のWebアプリケーションでは、リクエストのたびに同じような冗長なヘッダー情報をテキストのまま送信することになり、特にモバイル回線など帯域が限られる環境で無視できないオーバーヘッドになります。
• サーバープッシュの不在：クライアントが要求していないリソース（CSSに付随する画像など）をサーバー側から能動的に送ることができず、必要なリソースはクライアントが1つずつ発見・要求する必要があります。
• ドメインシャーディングという副作用：接続数制限を回避するために、画像配信用に別サブドメインを用意する「ドメインシャーディング」という最適化テクニックが広まりましたが、これはDNS解決やTLSハンドシェイクの追加コストを生むトレードオフでもありました。

これらの課題を解決するために設計されたのがHTTP/2（多重化とヘッダー圧縮HPACK）であり、さらにTCP自体のヘッドオブラインブロッキングまで解消したのがQUICを使うHTTP/3です。

混同されやすい用語・類似技術との違い

HTTP/1.1は名前が似ているバージョンや後継プロトコルと混同されがちです。主な違いを整理します。

実務導入・運用のポイント

• サーバー設定の確認：nginxではlisten 443 ssl;のみだとHTTP/1.1で待ち受け、http2 on;を追加するとHTTP/2が有効になります。意図せずHTTP/1.1のままになっていないか、設定ファイルを確認するのは基本的な棚卸し項目です。
• ロードバランサー配下でのプロトコル不一致：AWSのApplication Load BalancerなどではクライアントとのフロントエンドはHTTP/2で受け付けつつ、バックエンド（ターゲットグループ）との通信はHTTP/1.1で行う構成が一般的です。フロントとバックでプロトコルが異なることを前提に、ヘッダーサイズやKeep-Aliveのタイムアウト設定を両者で整合させる必要があります。
• Connectionヘッダーとhop-by-hopヘッダーの扱い：Connection、Keep-Alive、Transfer-Encodingなどは中継するプロキシごとに解釈・除去されるべきhop-by-hopヘッダーです。自前でリバースプロキシやAPIゲートウェイを実装する場合、これらのヘッダーをそのまま転送してしまうと予期しない挙動やスミグリングの原因になるため注意が必要です。
• デバッグ・切り分け手順：障害調査では、まずcurl -v --http1.1で生のヘッダーとステータスコードを確認し、次にブラウザの開発者ツールのNetworkタブでプロトコル列（http/1.1・h2・h3）を確認する、という順序が定石です。CDN経由の場合はCDNのエッジとオリジンで別々にプロトコルを確認する必要がある点も見落としがちです。
• セキュリティ上の考慮：Hostヘッダーインジェクション（アプリケーションがHostヘッダーの値を無条件に信頼してURL生成やキャッシュキーに使うことで起きる不正操作）やリクエストスミグリングは、HTTP/1.1のテキストベース・行区切りという仕様の緩さに起因する典型的な脆弱性クラスです。WAFやリバースプロキシの設定・アップデートを継続的に見直すことが実務上のポイントです。

2025〜2026年の最新動向

プロトコルとしてのHTTP/1.1自体は2022年のRFC 9110／9112への再編以降、大きな仕様変更は行われておらず、安定期に入っています。一方で利用のされ方には変化が続いています。公開Webサイトのフロントエンド（ブラウザとの通信）は、主要ブラウザとCDNの対応が進んだことでHTTP/2・HTTP/3への移行がさらに進んでおり、新規に構築されるサイトではHTTP/1.1がクライアント向けの既定プロトコルに選ばれる場面は少なくなりつつあります。

一方で、CDNやロードバランサーからオリジンサーバーまでの区間、社内向けAPI、レガシーな業務システム、組み込み機器・IoT向けの通信では、実装のシンプルさとデバッグのしやすさから、HTTP/1.1が今も現役の選択肢であり続けています。クラウドベンダー各社のマネージドロードバランサーやAPIゲートウェイでも、バックエンドとの接続プロトコルとしてHTTP/1.1がデフォルトまたは選択可能な設定として残されているのが一般的です。今後もHTTP/1.1が完全に姿を消すことは考えにくく、「フロントはHTTP/2・HTTP/3、内部はHTTP/1.1」という多層的な使い分けが実務上の標準的な構成として定着しつつあると言えます。

Q. HTTP/1.1とは何ですか

HTTP/1.1は、1997年にRFC 2068として標準化され、1999年にRFC 2616で改訂されたWeb通信の基盤プロトコルです。持続的接続・Hostヘッダー必須化・チャンク転送エンコーディングなどを導入し、2022年にはRFC 9110／9112として仕様が再編されました。テキストベースで人が読める構造のため、HTTP/2・HTTP/3以降のバイナリプロトコルと異なり、デバッグのしやすさが今も評価されています。

Q. HTTP/1.1とHTTP/2はどちらを使うべきですか

公開Webサイトのフロントエンド（ブラウザとの通信）では、多重化とヘッダー圧縮によりページ表示が高速になるHTTP/2（またはHTTP/3）を選ぶのが基本です。一方、CDNからオリジンサーバーまでの区間、社内API、組み込み機器などシンプルさやデバッグ容易性を優先したい場面では、あえてHTTP/1.1を使い続ける判断も実務では珍しくありません。

Q. HTTP/1.1はまだ安全に使えますか

プロトコル自体に致命的な欠陥があるわけではありませんが、リクエストスミグリングやHostヘッダーインジェクションなど、テキストベースゆえの解釈の曖昧さに起因する脆弱性クラスが知られています。TLS（HTTPS）で通信を暗号化すること、リバースプロキシ・WAF・Webサーバーを最新版に保つことが安全に運用する上での前提になります。

Q. なぜHTTP/1.1のパイプライン化は普及しなかったのですか

先頭のレスポンスが遅れると後続もすべて待たされるヘッドオブラインブロッキング問題を解消できず、加えて一部のプロキシがパイプライン化に正しく対応していなかったため、Chrome・Safariなど主要ブラウザは標準で有効化しませんでした。この課題を根本から解決する技術として設計されたのがHTTP/2の多重化です。

Q. 2025〜2026年のHTTP/1.1の位置づけはどう変わっていますか

プロトコル仕様自体は2022年のRFC 9110／9112以降大きな変更はなく安定しています。公開サイトのフロントエンドではHTTP/2・HTTP/3への移行がさらに進む一方、CDN・オリジン間通信や社内システム、組み込み機器の世界ではシンプルさを理由にHTTP/1.1が引き続き広く使われており、「フロントは新しいプロトコル、内部はHTTP/1.1」という使い分けが実務上の標準構成として定着しています。

Q. Keep-AliveとPersistent Connectionは同じものですか

HTTP/1.0時代の非標準拡張として登場した「Keep-Alive」という名称が、HTTP/1.1で標準化された持続的接続（Persistent Connection）を指す通称として今も広く使われています。仕組みとしてはほぼ同じ目的（TCP接続の再利用）を持ちますが、HTTP/1.1では持続的接続がデフォルトの挙動であり、明示的なKeep-Aliveヘッダーがなくても有効になる点がHTTP/1.0との違いです。