通信の最適化対策

一部の方々の間で話題になっている通信の最適化について、原理と対策について説明します。

今回の説明では、説明責任や法律は置いておいて、技術的な問題だけにフォーカスします。

「通信の最適化」の話題の発端

  • とあるゲームのパッチ配布がSoftbank環境で失敗するという事象が起きました。
  • 原因は、キャリア側で端末に送信する画像ファイルを不可逆圧縮しており、プログラムでパッチの整合性の確認に失敗してしまうものだそうです。
  • 実はSoftbankだけでなくau、NTTドコモでも同様の仕組みを組み込んでいました。
  • 「そんなの聞いていない」「電気通信事業法の通信の秘密の侵害だ」という声があがっています。

japanese.engadget.com

togetter.com

ネットワークの規格

ネットワークを流れるデータは幾つもの規格に沿ってデータが正しく送信されるようになっています。インターネットは無数の組織が管理する大量の機械を中継して送信されるため、それらが相互に接続できるように国際的な規格が決められています。 皆さんが見ているWebページを例にすると、

上記以外にも通信相手を見つけるためのDNSやARP、MACなどたくさんの規格が関係しています。その規格のいずれもが、RFCやIEEEなどの国際的な規格として公開されています。

通信レイヤーとWebサービス

HTTP〜Ethernetの規格では送ったデータがそのまま届くことを実現しようとしています。 普段利用しているWebサービスはHTTPまでの層が規格通りに動いていることを前提として提供されています。ここで、どこか1つの層が想定外の動きをするとWebサービスが想定通りの動きをしなくなります。

また、1つのWebサービスがコケても下位のネットワーク全体には影響はありませんが、下位のネットワークで何かあると、その上で動いているすべてのサービスに影響があります。

通信の最適化の影響範囲は、その回線を使う全てのサービスということになります。

通信の最適化 = 未知の通信基盤

エンジニアは単に、ネットワークの規格に沿って、送ったデータがそのまま届くことを期待したプログラムを作ります。(途中でメディア変調や可逆圧縮はあるにしても)サーバから送ったデータと全く同じデジタルデータがクライアントで受信できることを想定しています。

しかし、実は、どの通信事業者もプログラムで判定可能なデータの変更ルール(＝仕様)を公開しておらず、どのデータ形式が規格通りに到達するのか不明です。 スマートフォンがクライアントの場合のHTTP通信上のJPEGは確認された1パタンでしかありません。 例えばHTTPの拡張で定義されたWebDAVや80番ポートを使うHTTP2で同様の事象が発生しない保証はあるのか、80番ポートの通信だけが対象なのか、バイナリデータの先頭部分が偶然JPEGヘッダと同様のパタンとなる場合はどうか。 今まで前提として使っていた通信経路は実は規格に沿っていない未知の通信基盤で、話題の発端となったゲームの不具合は、それによって確認できた不具合の1つということです。

対策

前述のような信用出来ない場合、送ったデータがそのまま届くことを自分で保証する必要がでてきます。 いまのところ現実的な解法はHTTPS(SSL)を利用することです。 HTTPSには改ざん検知の仕組みがあるので、(通信の最適化が改ざんにあたるかどうかは置いておいて)ある程度の対策にはなります。また、通信内容が暗号化されるため、通信事業者によるパケットの書き換えが難しくなります。

セキュリティプロトコルマスター（1）：Webを安全にするというSSLの中身を見せて (1/3) - ＠IT

www.itmedia.co.jp

ただし、HTTPSも万能ではなく、端末のRoot証明書次第で書き換えが可能です。

qiita.com

通信事業者がコレをやるとSSL通信の安全性そのものが揺らぐので流石に禁じ手にはなっていると思います。

jp.globalsign.com

既存WebサービスのHTTPS対応状況

思いつくクラウドサービス、写真共有サイト、ブログなどのHTTPS対応状況を調べました。 ブラウザのURLを見ただけなので確実とは言えません。参考までに。

とりあえず、クラウドやGitHubにアップした画像が変更されていることは無さそうです。一部ブログなどは影響ありそうです。

PROCESS WARPはwwwがHTTP, prevはHTTPSです。