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