> For the complete documentation index, see [llms.txt](https://http3-explained.haxx.se/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://http3-explained.haxx.se/ja/why-quic/why-tcphol.md).

# TCP head-of-line ブロッキング

## TCP head-of-line ブロッキング

HTTP/2 は TCP を使って動作し、従来のバージョンの HTTP を使用するよりも少ない TCP コネクション数になります。

TCP は信頼性の高い転送のためのプロトコルで、基本的には2つのマシンの間につながった仮想的な鎖のように考えることができます。

一方の端からネットワーク上に出されたデータは、結果的に、もう一方の端に全く同じ順番で到達します（または通信が途切れます）。

![a TCP chain between two computers](/files/-LvW36RhYtOh6iUIAkc1)

HTTP/2 を使うことで、典型的なブラウザは数十または数百の並列データ転送を単一の TCP コネクション上で行います。

HTTP/2 を話す2つのエンドポイント間にあるネットワーク上で一つのパケットがドロップされると、それはすなわち、その損失したパケットが再送され、宛先に届けられるまでの間、TCP コネクション全体が停止することを意味します。

TCP がこの「鎖」であるため、一つのつなぎ目が突然欠落すると、その欠落したもの以降すべてのつながりが待つ必要があります。

2つの別々のストリームを単一コネクションで送信するときに鎖を使って図解したイラスト。

赤色のストリームと緑色のストリーム:

![the chain showing links in different colors](/files/-LvW36RnZxzFY7KrlZth)

これが、TCP ベースの head-of-line ブロックになります！

パケットロス率が上がるにつれて、HTTP/2 のパフォーマンスはますます低下します。

2 %のパケットロス (これはかなりひどいです、念のため。) があるネットワーク環境では、大抵の場合において HTTP/1 のほうがパフォーマンスが良くなることがテストで証明されています。

これは、HTTP/1 では通常6つまでの TCP コネクションを使ってパケットを送信するためです。

つまり、パケットが損失した箇所があっても他のコネクションが止まることはないということです。

TCPを使用する限り、この問題を解決することは簡単ではありません。

## ブロックを解消するための独立したストリーム

QUIC では、2つのエンドポイントの間に、接続を安全にし、データ配信を信頼できるものにするコネクションのセットアップが依然として存在します。

![a QUIC chain between two computers](/files/-LvW36RhYtOh6iUIAkc1)

このコネクション上で2つの異なるストリームをセットアップする際、それらは独立したものとして扱われるため、一つのストリームのあるつなぎ目が損失した場合、そのストリームの、特定のチェインのみが、停止し再送制御を行います。

黄色のストリームと青色のストリームがそれぞれ2つのエンドポイント間で通信を行うイラストがこちらです。

![two QUIC streams between two computers](/files/-LvW35oOH4Xtr4ClEuBt)