Windows Info 第138回

Windows 10 RS5はHTTP/2とCUBICで速くて安全なインターネットを実現する!?

　Windows 10は、現在RS5（おそらくはWindows 10 Ver.1809）の完成に向かって、Insider Previewが進められている。

　このRS5のBuild 17730に関するマイクロソフトのブログにちょっと気になった記述がある（https://blogs.windows.com/windowsexperience/2018/08/03/announcing-windows-10-insider-preview-build-17730/）。「A Faster Safer Internet with HTTP/2 and CUBIC」（HTTP/2とCUBICで速くて安全なインターネット）というものだ。

　HTTP/2は、ウェブのアクセスに使うHTTP（Hyper Text Transfer Protocol」のバージョン2を意味し、CUBICは「CUBIC TCP」の略で、TCP（Transmission Control Portocol、いわゆるTCP/IPのTCP）で利用する輻輳制御（congestion control）のアルゴリズムの名前だ。

　このブログの内容を単純に解釈すると、「RS5には、HTTP/2とCUBICが入って、インターネットアクセスが速くなってより安全になる」と受け取れる。

　ところがギッチョン、そういうわけではないのだ。HTTP/2は、すでにInternet Expolorerが対応しているし、CUBICがWindowsに搭載されたのは、Creators Update（RS2）なのである。今回はこれについて考えてみることにする。

すでに各種最新ウェブブラウザでも搭載済のHTTP/2

　まずは、HTTP/2だ。HTTP/2は、2015年5月に正式な仕様となっているが、その前から仕様はインターネットドラフトとして公開されていた。マイクロソフトは、2014年にリリースされたWindows 10のプレビュー版の段階で、Internet Explorerに組み込んだことを公表している。

●IEBlog日本語　HTTP/2: 長く待たれた続編
　https://blogs.msdn.microsoft.com/ie_ja/2014/10/27/http2/

　このブログによれば、Windows 10に同梱されるIIS（Internet Infomation Server）へもHTTP/2を組み込んだとのことだ。つまり、Windows 10には、最初からHTTP/2が入っているのである。

Windows 10に付属のInternet Explorerは、TH1（Windows 10の最初のバージョン）からすでにHTTP/2に対応していたという。当然RS4に同梱されているIEもHTTP/2に対応しているし、EdgeやChrome、Firefox、Safariなどでも同じだ

　このため、現在のMicrosoft Edgeでも、HTTP/2を利用したアクセスが可能だ。以下のURLは、HTTP/1.1とHTTP/2を比較するデモのサイトである。インターネット上にあるので、すぐに条件が変わってしまい、必ずしもHTTP/2が速いわけではないが、何回か繰り返すとHTTP/2のほうが速い結果が出る回数が多くなるはずだ。

●HTTP/2 is the future of the Web, and it is here!
　https://http2.akamai.com/demo

　結論から言えば、RS5で対応するのは、Windows Server 2019のIISに搭載されるHTTP/2を使った機能なのである。

　RS5のInsider Previewと同時にWindows Server 2019のInsider Previewも進められている。それによれば、Windows Server 2019には「Connection Coalescing」と「Security Improvements」という2つの機能が搭載される。RS5でEdgeが対応するのはこの2つの機能なのである。つまり、Windows Server 2019がホストするウェブサーバーにアクセスする場合の話なのだ。

　もっとも、企業などで組織内向けにIISを使っているところもあるだろうから、まったくメリットのない話でもない。ただ、HTTP/2による高速化は、すでに現在のWindows 10 RS4でも達成されており、また、HTTP/2はTLS/SSLをサポートするサーバーで使われていることがほとんどであるため、セキュリティ上も問題はない。

一方のCUBICとは？

　もう1つのCUBICだが、こちらも結論からいうと、すでにRS4でもサポートされているため、RS5に初めて搭載されるわけではない。ただ、これまでのWindows 10のCUBICの実装では、性能が出なかったなどの何らかの違いがある可能性はある。そうでなければ「Improved performance on Windows 10 thanks to Cubic, the new default TCP congestion provider」（前述のブログ記事）などという書き方はできないはずだ。

　では、CUBICとは何か？　これはTCPに実装された輻輳制御の仕組み（アルゴリズム）の名前だ。すでにLinuxなどで使われている（2006年のLinux Kernel 2.6.19から搭載）。これに対して、Windowsは、2008年のWindows Server 2008やWindows Vistaから独自開発した「Compound TCP」という輻輳制御のアルゴリズムを利用してきた。これは1999年に開発されたNewRenoと呼ばれる輻輳制御アルゴリズムをベースにして、独自の改良を付け加えたものだ。

　輻輳とは、ネットワークが混み合って、通信が正常にできなくなってしまう問題だ。このため、ネットワークで通信するプログラムは、かならず輻輳制御の機能を持つ。ただし、このこと自体はかなり難しい問題である。というのも、ネットワークの状態を把握すること自体が簡単ではないからだ。そもそもネットワークの状態は、変化が激しく、測定に時間をかけてしまうと、状態を把握したときには、すでに状況が変わっていることもある。

　そこでTCPでは、通信相手からの応答や途中で廃棄されたパケット（ルーターはパケットを廃棄すると送信元に通知を送る）などの情報を使ってネットワーク状態を推測し、パケットを送信する速さを制御する。なおネットワークには、これとは別に「フロー制御」というのがある。これは、通信相手が手一杯なので通信を止めるという制御であり、送信元と送信先との関係で決まるもの。これに対して輻輳は、相手の状態に関係なく、ネットワークの状態で発生するものだ。イメージ的には交通渋滞のようなものだ。

　1986年10月にインターネット（米国のNFSnet）で輻輳が発生し、実質上、通信ができなくなる「輻輳崩壊」（Congestive collapse）が発生した。このため、輻輳制御はインターネットにとっては重要な問題となった。

　輻輳が発生しそうだとなったら、パケットを送信する時間間隔などを延ばして転送速度を制御するが、問題がなさそうなら、また間隔を短くしていかねばならない。このとき、アルゴリズムにより、輻輳検出のタイミングや速度を回復させるパターンなどが違って来る。

　TCPの輻輳制御に関しては、UNIX 4.3BSDの頃にすでに問題となり、1990年代からずっと研究が続けられており、TahoeとかRenoといった制御方法が使われていた。一説によれば、マイクロソフトのCompound TCPは、回復する速度が遅く、CUBIC TCPよりも不利になることがあるらしい。こうしたこともあって、マイクロソフトは、CUBICの搭載に踏み切ったようだ。

　CUBIC自体の実装は、RS2（Creators Update）で搭載されたが、その時点でのデフォルトはCompound TCPで、ユーザーが輻輳制御アルゴリズムを切り替える必要があった。それがRS3（Fall Creators Update）では、CUBIC TCPがデフォルトになった。なので、現在のRS4にもCUBICが搭載されていのである。

　独自の実装を開発しておきながら、Linuxに採用された輻輳制御を採用するのは、おそらく速度的に不利だったということをマイクロソフトも認識していたのだと思われる。とはいえ、インターネット利用でわずかであってもパフォーマンスが向上するのは悪いことではないだろう。