とことこロゴス
HoLブロッキング
順番に処理する仕組みで、先頭の処理が遅れたり止まったりすると、その後ろに並んでいる処理まで待たされてしまう問題。HTTP/1.1やTCPで起こり、HTTP/2やHTTP/3はこれを減らすために作られた。
イマシルちゃんの解説
HoLブロッキングは、前の処理の遅れに後続の処理まで巻き込まれる現象だよ。
例えばTCPは、受け取ったデータを送られた順にアプリへ渡すんだ。
途中のデータが失われると、それより後のデータが届いていても、再送で欠けた部分がそろうまで渡せないよ。
HTTP/2では複数のやり取りが同じTCP接続を使うので、この待ち時間が別のやり取りにも響くんだ。
HTTP/3が使うQUICは、通信の流れを表すストリームごとに順序を管理するよ。
そのため、データの欠落がない別のストリームは処理を続けられるんだ。
この解説はわかりやすかったですか？
より深い解説
定義
HoLブロッキング（Head of Line blocking：先頭による阻害）は、要求や データを直列に（順番に）処理する仕組みで、列の先頭にあるものの処理が終わるまで、後続のものが処理されずに待たされる現象である。
発生する層と対策
| 層 | 原因 | 対策 |
|---|---|---|
| HTTP（HTTP/1.1） | 1つのTCP接続の上では、リクエストを送ったら、そのレスポンスが返るまで次のリクエストを送れない（パイプラインでも、レスポンスは順番どおりに返す必要がある） | ブラウザが、同じサーバに複数のTCP接続を同時に張る（一般に最大6本程度） |
| HTTP（HTTP/2） | − | 1つのTCP接続の中に、ストリームを複数作り、リクエストとレスポンスを並列にやり取りする（多重化） |
| TCP | TCPは、送ったデータを順番どおりに届ける。1つのパケットが失われると、後ろのデータは届いていても、再送が届くまでアプリケーションに渡されない | HTTP/3（QUIC）で、UDPの上でストリームごとに独立して順序を管理する |
HTTPのバージョンごとの違い
| バージョン | HTTPのHoL | TCPのHoL | NAPTの変換エントリー |
|---|---|---|---|
| HTTP/1.1 | 起きる | 起きる | 並列にするため、TCP接続が増え、エントリーも増える |
| HTTP/2 | ストリームで解消 | 起きる（1つのTCP接続の中の全ストリームが影響を受ける） | 1つのTCP接続で済み、エントリーが減る |
| HTTP/3 | ストリームで解消 | 起きない（QUICがストリームごとに管理） | 1つのQUIC接続（UDP）で済む |
通信機器のHoLブロッキング
スイッチでも、入力ポートのキュー（待ち行列）の先頭のフレームが、混雑している出力ポートへの送信待ちで止まると、後ろにある別の出力ポート宛てのフレームまで待たされる。これもHoLブロッキングと呼ばれ、出力ポートごとに仮想的なキューを持つ（VOQ）ことで対策する。
午後での問われ方
「全ての処理が完了するまでに時間がかかる理由」を問われたら、先行の処理が終わるまで後続の処理が待たされるから、という直列処理の性質を答える。
実際の試験ではここに出る！全1問
ネットワークスペシャリスト
- 午後Ⅰ