全1910文字
PR

 アプリケーションの高度化やデータ通信量の増加に対応するため、TCP/IPの後継となる技術の検討も始まっている。その代表格が「QUIC」というプロトコルだ。TCPに取って代わる可能性があるとして注目されている。

 QUICは、米グーグルが自社のWebサービスで大量のアクセスを高速に処理するために開発した独自プロトコルをベースにしている。同社はこのプロトコルを2015年にIETFへ提出。その後、TLSの機能を取り込み、HTTP以外にも使えるようにするなどの変更を加えて標準化へと至った(図6-1)。

図6-1●TCPに代わる高速プロトコル「QUIC」
図6-1●TCPに代わる高速プロトコル「QUIC」
もともとは米グーグルがHTTPの処理を高速化する目的で開発したプロトコルだが、HTTP以外にも使えるように改良したものをIETFが標準化した。
[画像のクリックで拡大表示]

UDPでTCP相当の信頼性を確保

 QUICの主な特徴は、「TCPと同等の再送制御や輻輳制御を備える」「通信開始時の決まりごと(ハンドシェーク)による遅延が小さい」「複数の通信路を利用して通信を効率化する」「いったん通信した相手と再接続する場合はハンドシェークなしで通信できる」の4つだ。

 従来のWeb通信はTCPとTLSを使う。QUICはUDPを利用するため、TCPと同等の再送や輻輳の制御を組み込んだ。さらに、TLSによるハンドシェークを利用して1度のやりとりだけで通信路を確立できるようにした(図6-2)。

図6-2●通信開始時のハンドシェークの数を削減
図6-2●通信開始時のハンドシェークの数を削減
QUICでは、TCPとTLSでそれぞれ必要だったハンドシェークをTLSの1度だけに減らすなどして、通信の効率化を図っている。
[画像のクリックで拡大表示]

 またQUICは、TCPで問題となる「ヘッドオブラインブロック」を回避できる。これは、TCPセグメントを連続で送るとき、先頭のセグメントにエラーが起こるとその再送が完了するまで、後続のセグメントを送れないという現象だ。

 従来のWeb通信では単一の通信路を使うため、先行するTCPセグメントでエラーが発生すると後続するセグメントを処理できない。一方、QUICを使った通信は複数の通信路を確立して、並行してデータをやりとりする。ある通信路でデータが損失して再送が必要になっても、別の通信路で並行してデータを送信できる。

 さらにQUICでは、TLS 1.3の0-RTTという機能を使うことで、再接続の処理を高速化できる。従来のWeb通信では、一度通信したことがある相手でも、再度接続する場合はTCPの3ウエイハンドシェークやTLSのハンドシェークを行う必要がある。一方0-RTTでは、こうした事前のやりとりをせずに通信路を再確立する。