TL;DR
1997 年に RFC 2068 で発表された HTTP の標準バージョン。持続的接続（Keep-Alive）とパイプライン化を導入した。
なぜ必要か
HTTP/1.0 では、1 つの TCP 接続で 1 つのリクエストと 1 つのレスポンスしか処理しなかった。TCP は、データを送る前に 3 回のやり取り（ハンドシェイク）で接続を確立する。そのため、1 つのページにある画像、JavaScript、CSS などを取りに行くたびに接続を張ると、性能が落ちる。
仕組み
持続的接続
TCP 接続を再利用して、複数のリクエストとレスポンスを処理する。リソースごとに TCP 接続を確立する必要がなくなった。
パイプライン化
1 つの TCP 接続で、レスポンスを待たずに複数のリクエストを送る。
注意点
パイプライン化では、サーバはリクエストを受けた順にレスポンスを返す必要がある。そのため、1 つのレスポンスが遅れたり失われたりすると、それ以降のレスポンスも使えなくなる（HOL ブロッキング）。この問題は TCP 自体でも起こり、HTTP/3 は QUIC でこれを解決している。
一部のサーバやプロキシがパイプライン化をサポートしていないこともあり、今はあまり使われない。代わりに HTTP/2 のマルチプレキシングが使われる。
関連
出典
- RFC 2068。その後、1999 年に RFC 2616、2014 年に RFC 7230〜RFC 7235、2022 年に RFC 9110 で改訂された
- HTTP の持続的接続 - Wikipedia
- HTTP パイプライン - Wikipedia