Experts.jp日本に、もっとエキスパートを。API,...最新Webプロトコルの傾向と対策」の内容をご紹介します。最新のWebプロトコルが続々と誕生1990年から10年間ほどは、HTTPというたった一つのプロトコルが、Web通信用のプロトコルとして使われていました。UDP、QUICといった、新しいプロトコルが続々と誕生してきました。この4年間ほどで、これらの多くのプロトコルが誕生してきた背景・理由をこれから説明します。約20年間に渡り、Webを支え続けているHTTPの仕組みをまずは説明します。HTTPは非常に単純なプロトコルで、ブラウザ・サーバ間でリクエスト・レスポンスがやり取りされる仕組みとなっています。ブラウザから「index.htmlがほしい」とサーバへリクエストを送信すると、サーバからそのHTMLファイルがレスポンスとして送信されます。その後、ブラウザから「CSSがほしい」とサーバへリクエストを送信すると、またサーバからレスポンスが返ってくるという流れになります。ここで問題となるのが、ブラウザがサーバへリクエストを送信してレスポンスが返ってくるまでの間、ブラウザが次のリクエストを送信できないということです。Timeと言いますが、例えばこれが100ミリ秒だとすると、全て合計するとこの時間だけで1~2秒かかる場合があります。この状況を改善するために、TCPの接続を複数張り、同時に複数のリクエストを送信するという方法があり、これが今のHTTPのメジャーな使用方法となっています。この方法で改善はするのですが、例えばChromeですとブラウザから同一のサーバに対しては、同時に6つまでしかリクエストを送信できないという制限があり、どうしても待ち時間が発生してしまいます。このような制限がある中でWebサービスのレスポンス性を高めるために、やり取りされる複数のリソースを一つにまとめて、リクエスト・レスポンスの回数を減らすという方法があります。Spritesという手法があります。Twitterのアイコンなど、リクエストによって動的に表示させる画像を変更しなければならない状況では、このような手法を使うことはできません。このような課題があり、そもそも開発者側でこのようなパッキング・テクニックを使わなくても済むように、複数のリソースをまとめるための一般的な方法が求められるようになりました。複数のリソースを一つにまとめるSPDY複数のリソースを一つにまとめて通信するプロトコルとして、SPDYがあります。SPDYでは、一つのTCP接続の中で、複数のリクエストを送信することができ、これによって高速化が図られています。常にSPDYを使用すればよいというわけではありません。ネットワークの遅延がない状況ですと、SPDYの方がHTTPSよりも常に速いのですが、ネットワークの遅延が100ミリ秒ある状況ですと、HTTPSの方がSPDYよりも速くなります。通信するリソースサイズが大きくなればなるほど、その通信速度の差は大きくなります。Pipeという問題があります。TCPでデータをダウンロードする際は、データが複数の小さいパケットに分割されてサーバからブラウザへ送られます。ブラウザは、ある程度パケットをダウンロードすると、サーバへACK(Acknowledgement:受信応答)を送信し、サーバはブラウザからのACKを受信することで、次のデータをブラウザへ送信します。ここで、サーバが、ブラウザからのACKを受信するまで次のデータを送信することができないという問題があります。そのため、レイテンシが増えるにつれて、ブラウザからのACKの待ち時間が増えることになります。Pipeと呼ばれる問題です。すごく太い、例えば1GBくらいの回線があったとしても、100ミリ秒などの遅延があると、1GBという速度は到底でません。Pipeの影響を受けやすくなります。Pipeの影響が大きくなり、SPDYの方がHTTPSよりも通信速度が遅くなります。このように、常にSPDYの方が速いというわけではありません。Blockingという問題についても、SPDYの方がより大きな影響を受けます。Blockingとは、TCP通信内でサーバから送られるデータが欠損する(パケット・ロスが起こる)と、そのデータが再送されるまでは、その後続のデータがブラウザへ送信されないという問題です。Blockingの影響を大きく受けることになります。以上のようなSPDYを使用することによる問題は、SPDY自体に原因があるわけではありません。Blockingといった制限があることに原因があります。Webの進化によって、TCPの制限が顕著になってきたのです。このように、TCPの制限がWebサービスに影響を及ぼすことがわかってきたため、「TCP以外のプロトコルを使った方が良いのではないか」という議論が国際標準化の場でなされるようになってきました。Blockingが起こりにくい新たなプロトコルを提案しています。Blockingが起きないプロトコルが提案されています。インターネットのあらゆる機器に影響があるため、TCPを代替するこれらのプロトコルの普及には、時間がかかると考えられます。ユーザの体感速度を上げるTCPの制限により、SPDYが速いとは一概に言えない状況の中で、Web開発者は、「速度とは何か」を今一度考える必要があります。結局は、全てのコンテンツをブラウザへダウンロードするということはそれほど重要なことではなく、ユーザへ、最低限見せなければならない情報を素早く見せる、つまり、ユーザの体感速度をあげることが重要になります。体感速度を上げる方法として、ファーストビューのレンダリングを高速化させ、ファーストビューに関係ない画像やスクリプトを後でダウンロードするという方法があります。Prioritiesというものがあります。これを使うことで、タグの中に、あるアトリビュートを指定するだけで、そのリソースを後から読み込むことができます。具体的には、後から読み込むようにしたいリソースについては、タグに属性「lazyload」を指定することで、そのリソースを後から読み込むことができます。/>P2P通信を実現するWebRTCWebRTCの特徴はP2Pにあります。WebSocketを使ってブラウザ間でメッセージのやり取りを行う場合、必ずサーバを経由して通信しなければなりません。WebRTCを使う場合は、サーバを介せず、ブラウザ間で直接データをやり取りすることができます。P2P通信を実現させるためには、通信対象の端末のIPアドレスとUDPのポート番号を知る必要があります。通常は端末がNATの内側にあるため、インターネット上でやり取りをする際に必要となる、NATの外側のIPアドレスとポート番号を知ることができません。NATの外側のIPアドレスとポート番号を知るために、WebRTCではICEという仕組みを使用するのですが、その中でSTUNサーバというものがあります。端末は、STUNサーバへUDPのパケットを送信すると、NATの外側にあるIPアドレスとポート番号を知ることができます。そのようして得られた自分のIPアドレスとポート番号を、通信したい端末とお互いに交換しあうことで、P2P通信を行うことができます。STUNサーバは、フルコーンNATのように、宛先のIPアドレスを気にしないNATでないと使用できないため、シンメトリックNATではSTUNサーバを使用することができません。ちなみに、大体の家庭のNATはフルコーンNATで、企業で使用されるNATはほとんどがシンメトリックNATです。WebRTCでは、STUNサーバが使えない場合は、TURNサーバを使うようになっています。TURNサーバを使う場合は、WebSocketを利用してブラウザ間でデータをやり取りする場合と同様に、このTURNサーバを介してデータのやり取りが行われるようになります。TURNサーバを使うことなくP2P通信を行うことができます。セキュリティの観点から同一LAN内のP2P通信が禁止されていることがあり、同一LAN内であってもP2P通信を行うためにTURNサーバが必要になる場合があります。TURNサーバが不要になると思われているのですが、NATの代わりとなるファイアーウォールが恐らく設置されることになると思いますので、ファイアーウォールを超えてP2P通信を実現させるために、STUNのようなサーバが必要になると考えられます。