皆さんこんにちは!広報委員会です。
今回はインターネットのプロトコルの一種で注目されている「QUIC」についてご紹介したいと思います。
まず始めにプロトコルとは何かご存知でしょうか?
プロトコルとは、コンピュータでデータをやりとりするために定められた手順や規約、信号の電気的規則、通信における送受信の手順などを定めた規格を意味します。
これが定められているおかげで、メーカーや機種を超えた通信が可能になります。
もともと「QUIC」とは、Googleが開発した「大量のアクセスを高速で処理するためのプロトコル」になります。QUICはweb専用のプロトコルでしたが、HTTP(web)以外でも使用できるように改変され、標準化されました。
このQUICを使用した次世代のweb通信プロトコルを「HTTP/3」と呼びます。
さて、ではなぜプロトコルをQUICに変更しようという動きになったのでしょうか。
それは現在、普及しているプロトコルに問題があったからです。
今現在、HTTPで主流として使用されているプロトコルを「TCP」と呼びます。現在、このTCPには通信が遅いという大きな問題点があります。可能な限り高速な通信が行えるように様々な工夫や最適化が行われてきましたが、TCP自体を見直すという動きに変わってきています。それが今回のQUICを採用することとなった大きな理由と言われています。
先程も紹介した通り、QUICは通信パフォーマンスを高めたプロトコルになります。TCPで問題となっていた内部での再送自動化により通信を確実に行える代わりに通信が遅くなるという問題点を解消することができます。
しかし、QUICはTCPでは約束されていた通信の保証がありません。その代わりにリアルタイム性の高いUDPを使い、QUIC独自の通信制御を組み込み信頼性を獲得し、「HTTP/3」に採用されるに至りました。
さて、ここで一つ不安に思うのが、「長年改良されてきたTCPに劣らないパフォーマンスを発揮してくれるのか?」ということです。先ほど、QUICは通信を早くするために通信の保証をしないと述べました。独自のセキュリティやノウハウを確立してるとはいえ、長年の研究には及ばないのでは?という不安もありますよね。そこで、こんな記事を紹介します。Fastlyの奥一穂氏とJana lyengar氏が公開した、TCPとQUICの比較について述べた記事です。
この記事では、「QUICはTCPの計算効率に並ぶことができるか?」という比較を行っています。左の表では、CPUを100%利用したときのベンチマークを測定しています。見てみると「TLS over TCP」では461Mbps、「QUIC」では、434Mbpsとなっており、後者の方がパフォーマンスが高くなっていることが分かります。この他にも、Acknowledge-ment(肯定応答/確認応答)を減らすといった最適化を行い、ひとつのパケット内の容量を増やすことで複数のパケットをまとめやすくするなどといった効率化を行っています。
fastly
https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency