Open Web Alliance（OWA）の考えるプロキシサーバ
Open Web Alliance（OWA）とは、アメリカのATIS（電気通信標準化連合）内の1団体で、暗号化やプライバシーに準拠したプロキシサーバの要件を制定しようとしている団体です。
メンバには、米国キャリアや世界各地の通信ベンダが入っています。（下記参照）
OWAの課題意識は全て以下の資料に説明されています。（英語です）
http://www.atis.org/openweballiance/docs/OWAIntroductionPPT2.pdf
その課題認識の主張は、要約するとただ一点。
暗号化された通信において、キャリアの通信コントロールサービスが提供できない。
これだけです。
資料中にはSPDYに関する記載が全編に渡って見受けられますが、SPDY通信（SPDY Proxyを介した通信も同様）において、Webアクセスは全て暗号化されてしまうので、キャリアの提供するコンテンツフィルタなどのサービスを提供できなくなってしまう。ということを言っています。
上記の資料中には直接言及していませんが、要はキャリアのビジネスが無くなってしまう。それでは不便なケースが出てくる場合があるし、何より通信キャリアが困るということが言いたいのだと思います。
だから、暗号化やプライバシーを踏まえた上でのユーザから信頼されるプロキシサーバが必要で、それを制定するのがOWAだ、というスタンスに見えます。
上記の、「通信コントロールサービス」が提供できなくなるという直接的なビジネスへのインパクトももちろん気にしていると思いますが、何より通信データの中身が見えなくなることによるデータ収集へのインパクトを懸念しての動きだと私は思っています。
データには膨大なビジネスが埋まっています。ユーザにハッキリと分かるような形ではビジネスにしないのだと思いますが、通信キャリアは確実にそれを狙っています。
個人的には、それによって便利なサービスを享受できるようになるならそれで良いですが、嫌がる人もいるのは想像できます。だから資料中には明示的にはキャリアの狙いを書かずに、慎重な言い回しがされています。
SPDYやHTTP/2の拡がりを初めとして、End to Endの暗号化はこれからもどんどん進んでいく方向です。
キャリア陣営が自分たちのビジネスをEnd to Endの暗号化から守るために、どのような動きをしていくのか、とても興味があります。もっとハッキリと自分たちの主張をしていくのか、それとも別の理由を隠れ蓑にして自分たちに都合のいい環境作りを進めていくのか、あるいはあきらめるのか。今後も追って行きたいと思います。
なお、これらの、キャリアによるプロキシ制定の動きは、OWAが設立される前からあり、HTTP/2標準化が進んでいた時期に平行でドラフトが提出された「Explicit Trusted Proxy」にその源流を認めることができます。現状、ドラフトのまま放置されていますが、興味ある方はこちらも確認してみてください。
GoogleがQUICへの本格的な取り組みを発表 -QUICが生まれた背景-
Googleは、「Make the Web Faster」という名を付けられた取り組みによって、常にWeb高速化に向けた取り組みを続けています。
今回は、そのWeb高速化の取り組みのひとつであるQUICについて紹介します。
QUIC（Quick UDP Internet Connections）
QUICは、SPDYやHTTP/2と同様、Webアクセスの高速化を目的としたプロトコルです。
プロトコルスタックとしては、Web用のプロトコルにも関わらず、TCPを使っていません。
どうなっているのかというと、UDP上にTCP相当の信頼性や輻輳制御の機能を持った層が乗っかっていて、さらにその上にTLS相当の暗号化層が乗っかっています。その上に最上位のアプリケーション層としてHTTP 1.1やHTTP/2が乗ります。
TCPには、Webの高速化にあたり以下のような課題があり、プロトコル仕様上、越えられない壁になっています。
- Long Fat Pipe：前のパケットのACKが返ってくるまで次のパケットを送信できない。
- Head of Line Blocking：先頭パケットがロスしたら、後続パケットは先頭パケットの再送を待ってから処理される。
- Slow Start：スループットは徐々にしか上がらない。
今までは、HTTP層が高速化のボトルネックになっていたので、TCPのボトルネックが目立っていなかったのですが、SPDYがある程度普及し、HTTP/2が検討されるようになり、トランスポート層で高速化の限界が見えてきていました。そこでTCPの代替としてのプロトコルがGoogle内で検討されるようになりました。
ただ、全く新しいトランスポート層プロトコルを作るのは、理想的ではありますが現実的ではありません。何故ならば、すでにWebはできているからです。Webを構築するネットワーク機器は、セキュリティ上の要求から、トランスポート層のプロトコルとして、基本的にTCPかUDPしか通しません。
だからGoogleはUDPをベースにしたのです。しかし、TCPの「信頼性を担保する機能」だったり、「輻輳制御する機能」だったりは捨てたくありません。
要は、QUICはUDPとTCPのいいとこどりをしています。さらに徐々に当たり前になりつつあるTLSを使ってEnd to Endの暗号化も実施しています。
ちなみに仕様は公開されており、詳細を確認したい方はこちらの記事を入り口にQUICの森の中に入ってみてください。英語です。
Chromium Blog: Experimenting with QUIC
Googleのスタンス
さて、上記のような背景から生まれ、Googleによって開発/検証されてきたQUICですが、2015年4月17日にChromium Blogにて今後の取り組み計画が発表されました。
Chromium Blog: A QUIC update on Google’s experimental transport
発表内容は大きく2点です。
今でも既にそうですが、気づかないうちにQUICを使っているという状況が増えそうです。 Googleがここまで本格的な取り組みを実施しているということで、SPDYと同じように様々なステークスホルダを巻き込んで普及していくのだと思います。また、SPDYと同じような流れで今後標準化されるプロトコルのベースになるのだと思います。もうこの辺は規定路線かと思います。
私の興味は、今と比べてどれくらいの高速化効果があるのか、どのくらいのペースで普及するのか、です。
高速化効果などは機を見て検証し、また記事にて公開してみたいと思います。
HTTP Archiveについて
HTTP Archiveは、Webにおける技術的な最新の流れを確認することができるサイトです。
Googleが、主要1万サイトをリストアップして、そのサイトへのクロール結果を基にした各種の統計情報を公開しています。
たとえば以下のような情報を確認できます。
- 1つのWebサイトでの、平均転送データ量と平均リクエスト数
- 1つのWebサイトでの、HTML/JS/CSS/画像ファイルごとの平均転送データ量
- TCPコネクション数
- キャッシュ可能なリソースの割合
- GoogleのライブラリやAPIを使っているサイトの割合
- Flashを使っているサイトの割合
- HTTPSリクエストの割合
- 4xx、5xxなどのエラーが返されるサイトの割合
- CDNを利用しているサイトの割合
- 1つのWebサイト内での平均的なリソース構成
これらのデータは月に2回（1日と15日）に更新されます。また、各データのダウンロードにも対応しているので、自分で独自の分析にかけることも可能です。
これらの情報を見て、自分のサイトへのアクセスを増やすための参考にすることなどはできなさそうです。
Webの技術的な全体像を俯瞰から見ることができるので、Web全体を対象にしたサービスやソフトウェア、ソリューション、製品を検討しなければいけないような人にとっては大変参考になるサイトです。
HTTPS（SSL/TLS）通信の割合
「NSAによる大規模通信傍受」の暴露に端を発して、WebサイトのHTTPS化（暗号化）が進んでいると言われています。今回は、その進んでいると言われている「HTTPSサイトの全体に占める割合」について見ていきます。
2015年4月現在で、HTTPSを使うサイトの割合は15%
いきなり結論ですが、2015年4月19日の最新データとしては、15%です。
このデータは「HTTP Archive」というサイトに公開されています。
HTTP Archive こちらはトップページです。
HTTP Archive - Trends こちらはhttps通信の割合の推移を示したグラフです。
このサイトはGoogleが作成しています。Alexaの情報を基にして、アクセス数の多い1万サイトをリストアップして統計情報を取得しているとのことです。なので本当の意味でWebの全てを表している訳ではないということだけ注意してください。ただ、ほぼ全てと言うことに問題は無いと思います。
この数値を見て初めに感じたのは、まだまだ少ないなという印象です。こういう記事を書くくらいなので、無意識に多少のバイアスが掛かっているんだろうなとは思いますが、それでももう少しHTTPS化が進んでいるものと思っていました。
しかし、グラフを見ると少し数値の印象が変わってきます。
1年前に9%だったものがこの1年で15%に増えているのです。1.5倍以上の伸びです。
WebサイトのHTTPS化を後押しする要因や状況変化 - Webinar
上記の記事で、WebサイトのHTTPS化を進める要因を書きましたが、こういった要因を基にしたHTTPS化が本格化してきていると言えそうです。
さらに1年後にはこの数値はどこまで増えているんでしょうか？
HTTPSサイトの割合の数値については、定期的に追っていきたいと思います。
HTTP Archiveには、ほかにもWebに関する様々な統計情報が公開されています。
HTTP Archiveについてはまた別記事で紹介したいと思います。
WebサイトのHTTPS化を後押しする要因や状況変化
最近、https化しているWebサイトが増えています。少し前までWebトラフィックにおけるhttpとhttpsの割合は、9：1とか8：2程度というのがだいだいの感覚になっていましたが、このところその割合の天秤がhttps側にどんどん傾いてきているようです。
本記事では、Webサイトの「https化」を後押している要因や様々な状況変化を、いくつか整理して挙げておきたいと思います。
NSAによる大規模盗聴
いわずと知れた元NSA勤務のスノーデンが暴露した国家規模での盗聴です。この暴露により、各種プロトコルのRFC化時において、通信路盗聴への防御を仕様に含めることが当たり前になりました。
インターネットジャイアントたちはこれまでに無かった拒否反応を示しています。
特にGoogleではサービスのhttps化が進んでおり、Googleのサービスは基本的にhttpsに移行されています。
http/2対応ブラウザにおけるhttpスキームのサポート対象外化
元をたどると、結局1点目の大規模盗聴に行き着くのですが、http/2のサポートにおいて、ChromeとFirefoxはhttpスキームをサポートしないことを発表しています。ChromeとFirefoxではhttp/2においてhttpsしか対応しません。
Googleの検索アルゴリズムにおけるhttpsサイトの優遇化
2014年の8月に、Googleが検索アルゴリズムとしてhttpsのサイトを優遇していくことを発表しました。
Google ウェブマスター向け公式ブログ: HTTPS をランキング シグナルに使用します
SEOを気にするサイトではこれは由々しき問題です。実は大規模盗聴よりこちらの要因のほうがhttps化の促進に大きい影響を与えるのではと考えています。
無料SSL証明書発行機関の出現
そのままです。有料だった証明書が無料になるから、よりセキュリティの高いhttpsサイトが増えるでしょう。
米電子フロンティア財団（EFF）や米アカマイ・テクノロジーズ、米シスコシステムズ、米モジラなどインターネット関連の名だたる企業や組織がスポンサーとなっている非営利団体が2015年の夏以降、無料でのSSL証明書発行を計画しています。
News ＆ Trend - 「SSL証明書無償配布」がもたらすWebの変革、企業ネットの管理にも影響：ITpro
最後に
さて、ではhttps化が進むとどうなるか。
もちろん便利になることも大きいです。
End To Endで通信内容が暗号化されますので、通信路上では盗聴がされなくなります。また、暗号化されたままの情報を保持しておいて、数年後の計算機パワーなどで暗号鍵が解読できたら数年前の通信内容を復号化して解読するというようなことも想定されますが、それを防ぐ仕組みもすでに取り入れられたりもしています。
参考：Forward secrecy - Wikipedia
逆に、今まで受けられていた通信キャリアのサービスが受けられなくなるようなことも出てきます。具体的には別の記事にまとめたいと思いますが、その原因はEnd To Endで通信内容が暗号化されることで通信キャリアがその通信をコントロールできなくなることです。
https化が広がることによって、単純に便利になるだけではないということだけ、覚えておいてください。
日本国内におけるインターネットトラフィックの特性
総務省では半年に一度、「我が国のインターネットにおけるトラヒックの集計・試算」と題して、日本国内におけるインターネットにおけるトラフィック量の集計結果を公表しています。
総務省｜我が国のインターネットにおけるトラヒックの集計・試算
調査対象は日本国内の主要ISP6社（シェア50%弱）となっています。
本記事では、日本国内のインターネットトラフィックがどのような特性を持っているかを見てみたいと思います。
日本全体のトラフィック量
- 総ダウンロードトラフィックは3.6T（テラ）bps。バイト表示に変換すると450GB（ギガバイト）/秒。24万人が同時に地デジをインターネット経由で見ているのと同じくらい。分かりにくいですね。。
1年前から40%弱の伸び率で、伸び率自体も加速しています。このまま伸びていくとどこまでのトラフィック量になるんでしょう。 - 総アップロードトラフィックは0.93Tbps。
時間帯別のトラフィック傾向
- 1日のピークは22時前後です。逆に一番少ないのは4時くらい。
- 曜日ごとのピークの高さはほとんど同じ。
曜日ごとに比較して差があるのは、平日と土日です。ピークの高さは同じですが、土日は日中からトラフィックがある程度あります。平日は日中はそれほどありません。 - アップロードも（絶対値は違いますが）だいたい同じ傾向です。
こんなイメージです。
固定と移動のトラフィック比較
- ダウンロードトラフィックについて、固定は移動の5倍程度です。スマホが普及してきているとはいえ、定額制だとこうなりますね。
- アップロードトラフィックについては、固定は移動の8倍強です。こちらはダウンロードよりも差が大きいです。スマホは閲覧するためのデバイスであってPCのようにコンテンツを作成するデバイスではないと言われる事の証左かと思います。
以上、総務省報告からざっくりと日本のインターネットにおけるトラフィック特性を読み取ってみました。
こちらの情報は、半年に一度、総務省から集計結果が発表されますので、今後定期的に内容を見ていきたいと思います。
Microsoft（マイクロソフト）のブラウザ戦略 ～ IE と Spartan ～
MicrosoftがWindows 10に搭載するブラウザについて、戦略などを発表しました。
Microsoftのブラウザと言えば、言わずと知れたInternet Explorerですが、Windows 10においてもIEは生き残ります。ただ、モダンブラウザとしてもう一つ新たなブラウザが搭載されるようです。製品名はまだ決まっていません。現在開発中であり、コードネームは「Project Spartan」。
本記事では、Windows 10に2つのブラウザが搭載されることになった経緯や、2つのブラウザの役割分担とMicrosoftのブラウザ戦略について、簡単に紹介します。
Internet Explorer（IE）
IEは、Windows95から搭載が始まったMicrosoft製のブラウザです。Windows95以降のWindowsには無料で標準的に搭載されたことから、Windowsのシェアと同様に圧倒的なシェアを持っていました。
（最近はGoogle ChromeやMozilla Firefox、Apple Safariなどのブラウザにかなり押され気味になってきてはいますが）
特に企業内においては、企業システムでサポートされるブラウザはほぼIE一択となっているため、限りなく100%に近いシェアになっていると思われます。
ITの世界に限らず、製品のシェアが高いことは良いことなのですが、この「企業システムでのデフォルトブラウザになっていること」がブラウザ戦略においてMicrosoftをがんじがらめに縛っている最大の要因です。
企業ユーザがたくさん居すぎてIEを捨てられないのです。そして企業システムの進化は遅く、変化にも乏しいので、新機能を入れたり機能変更をすると自社のシステムに影響の出る企業ユーザからクレームが来てしまうのです。
Project Spartan
その一方で、Webの進化に伴うブラウザの進化は近年加速度的にその速度を増しています。その先頭を走っているのはChromeとFirefoxの2台巨頭。意外にもAppleは進化のトップ争いには参加してきていません。2台巨頭はHTML5などの最新機能を、仕様確定前の段階からどんどん実装しています。
コンシューマでのシェアにおいて、IEの機能の少なさ、進化の遅さを嫌ったアーリーアダプターのシェアをChrome、Firefoxに奪われています。
また、スマートフォンのブラウザはChrome or Safariのどちらかです。IEを使っている人なんてまったくいません。
そのような状況を打破しようと、MicrosoftはIEではないブラウザの開発を決意しました。それがSpartanです。
IEとは別製品を作ることで、最新機能をどんどん取り入れて進化の先頭を走ることでアーリーアダプターのシェアを戻したいという意図が見えます。
全てのサービスにおいて、エンドとエンド（この場合は、サービスサーバとブラウザ）を押さえることで自社のサービスを完全にコントロールして提供できるのは非常に重要なことです。（Googleなんかは完全にこの戦略です）
2つのブラウザの役割分担
IEはレガシーユーザ向け、Spartanはイノベーター・アーリーアダプター向けです。それはそのまま「企業・一般ユーザ向け」と「Web開発者・先進ユーザ向け」と言い換えることもできるでしょう。
Microsoftのブラウザ戦略（想定）
Microsoftはそう遠くない将来にIEを捨てたいと考えているはずです。同じような機能をもった2つの製品をラインナップしておくのはリソースの無駄が大きいです。
では、どうするのか。SpartanとIEの製品イメージをなるべく近づけてリリースして企業システムにSpartanもサポートさせるということが必要になると思います。IEを捨てるためには企業ユーザをIEから離れさせなければなりません。
企業内においてもSpartanを使わせて、そのまま家でもSpartanを使ってもらう。そうすることでアーリーアダプタのシェアも回復する。IEも捨てられる。
（一般ユーザが自分が使っているブラウザを気にすることはないでしょう）
ポイントは、機能的には2つのブラウザは別物だとしても製品イメージを近づけること。それこそ製品名を似たものにしてしまうというのはありかも知れません。（先進ユーザにはがっかりされるかもしれませんが）企業ユーザ向けのサポートには最大限に注力すべきです。
スマホ向けについては、Microsoftは、まずはOSシェアを取らないことには始まらなく、ブラウザをどうして行くかを検討する段階にはありません。
まとめ
Microsoftの2つのブラウザとその役割分担、そして2つのブラウザ製品を使ったブラウザ戦略について想定を交えて紹介しました。
ユーザとしては、Microsoftからもいいブラウザが出てきて競争を促し、Web全体のエコシステムに良い影響を与えてくれることを願います。
