Posted on 2015年8月3日(月) 19:34
前回の記事のつづきです。
月が変わり、帯域制限の対象ではなくなったはずなのでもう一度測定してみました。
（1MBのファイルを転送）
| ファイルタイプ |
転送時間 |
速度 |
| .zip |
1.2秒 |
849KB/s |
| .bin |
0.9秒 |
1.10MB/s |
| .exe |
1.1秒 |
966KB/s |
| .lzh |
1.2秒 |
864KB/s |
| .pdf |
1.2秒 |
869KB/s |
| .aikatsu |
1.2秒 |
864KB/s |
あ、速い・・・。
帯域制限がかかっていたファイルタイプと、そうでないファイルの速度差がなくなりました。
月末に測定した時の転送時間は、zipファイルは80秒弱、pdfファイルは２秒ちょっとでした。
上記表以外にも複数回測定してみましたが、概ね安定した速度です。
また、帯域制限がかかっていないと思っていたファイルでも転送速度がだいぶ速くなっています。
（同じく平日で、時間帯もほぼ同じですが、違う日ではあるので単なる通信環境の違いかもしれませんが）
というわけで、Y!mobile LTEプランの帯域制限中の挙動はおそらく以下のような挙動かなと思われます。
・全体的に帯域制限される（3Mbpsくらい？）
・HTTP転送において、レスポンスヘッダに含まれるContent-Type: が特定のタイプと一致すると更に帯域制限される(96Kbpsくらい？）
ただし、帯域制限の目安の通信量をどの程度超えたかや、基地局の混雑具合によって制限値が変わるという書き込みも見られるので、数値は環境によって変わるかもしれません。
Posted on 2015年7月21日(火) 05:01
旧EMOBILE LTEの回線でアプリのテストをしているときに謎の不具合として発見しました。
スピードテストや、普通のブラウジングは快適に行えているのに何故かzipファイルの転送時のみものすごく遅くなり、最初は自分のアプリの不具合を疑いましたがHTTP通信全般で発生するようです。
。
契約回線は旧EMOBILE LTEで、「当月のご利用通信量が10GB以上」で帯域制限を行うと公表されています。
テストした日までの通信量は10.588GBで、目安の通信量を超過している状態です。
この状態でHTTPによるリクエストを出すと、ファイル種類によって挙動が変わります。
月初めはどのような挙動になるか不明なので来月になったらやってみます。
以下実験結果です。
以下コマンドで1MBのダミーファイルを生成。
% dd if=/dev/zero of=test.zip bs=1M count=1
ファイルの中身はそのままで、拡張子のみを色々変えてwgetで転送してみた結果が以下です。
| ファイルタイプ |
転送時間 |
速度 |
| .zip |
95秒 |
9.68KB/s |
| .bin |
72秒 |
13.1KB/s |
| .exe |
74秒 |
12.6KB/s |
| .lzh |
73秒 |
12.8KB/s |
| .7z |
78秒 |
12.1KB/s |
| .rar |
77秒 |
12.7KB/s |
| .jpg |
2.1秒 |
480KB/s |
| .png |
2.3秒 |
436KB/s |
| .pdf |
2.6秒 |
388KB/s |
| .cbz |
2.1秒 |
495KB/s |
| .pptx |
3.1秒 |
335KB/s |
| .aikatsu |
2.0秒 |
502KB/s |
１回づつしか測定していないので誤差は大きいと思いますが、ファイルタイプによって明確な差がついていることは明らかです。１０倍どころか３０倍違う・・・！
1MB転送するのに１分以上もかかっているようでは、実用的にはかなりキツイ状態です。
なお、HTTPSにした場合は帯域制限かからなくなります。
（どれでも変わらないはずなのでzipのみ実験）
| ファイルタイプ |
転送時間 |
速度 |
zip
(HTTPS) |
2.8秒 |
371KB/s |
この結果から、Y!mobile（のEMOBILE LTEプラン）では、HTTP通信の内容を見て帯域制限を実施していることがわかります。
また、.aikatsuは制限がかかっていないので、「JPEGは制限しない」のようなホワイトリストでなく、「zipは制限する」といったブラックリスト方式みたいですね。
僕が発見したのはzip,bin,exe,lzh,7z,rarですが、他にもあるかもしれません。
次にファイルタイプの判別方法ですが、ファイルの拡張子ではなくMIMEタイプを見て判別しているようです。
.htaccess ファイルに以下を以下のようにしてMIMEタイプを変更して同じRARファイルをダウンロードした場合です。
AddType image/jpeg rar
| MIME |
転送時間 |
速度 |
| application/x-rar-compressed |
93秒 |
9.25KB/s |
| image/jpeg |
2.1秒 |
491KB/s |
| www/unknown |
2.7秒 |
376KB/s |
その他、いくつかオレオレMIMEを指定してみましたが帯域制限はうけませんでした。
よって、HTTPサーバの設定を変更してMIMEタイプを変えてしまえば帯域制限を免れることができますね…。
というか最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・・。
サーバ管理者側の対策
スピードテストで測定すると速いのに、お前のサイトからダウンロードすると遅ぇよ！ と、どうしていいか分からない苦情が来ることに備えるには以下の対策が考えられます。
（実際これが原因で帯域制限の仕様を知った・・・）
・HTTPSを利用する
昨今色々あるので、もう全部HTTPSにできればそれが良いかもしれません。。。
・MIMEタイプを変更する
これを変えてしまうのは反則かもしれませんが、現実的にはzipなどのMIMEが間違っていてもダウンロードさえされれば別に困りません。
ただimage/jpegなどにするとブラウザ側が困るので、www/unknownあたりにしておくのが無難かと思います。
AddType www/unknown zip
AddType www/unknown rar
AddType www/unknown exe
AddType www/unknown lzh
AddType www/unknown 7z
AddType www/unknown bin
のような感じで.htaccessファイルに書いておくだけで転送速度が30倍に！ すげえ！
とりあえず、ComicGlassのサンプルファイル置き場はこの対策で乗り切ります。
もちろんブラックリストに入っているMIMEは今日現在の挙動なので今後は変わるかもしれません。
自分で薦めておいて何ですが、みんながこんなことやり始めたらHTTP崩壊だな・・・。
利用者側の対策
できることは少ないですが、HTTP通信の内容がわからなければいいわけなので、VPN接続してトンネル経由でアクセスすれば制限はかかりません。
ただ、帯域制限としては良心的な気もします。
実際に公表された通信量を超えても、HTML,JPEGやPDFなど通常のブラウジングには制限がかからないので通常の利用に弊害がありません。
また、HTTP以外の通信は特に制限されている様子はありません。
僕のようなzipをHTTP転送するのに特化されている特殊なアプリ開発者にとっては罠もいいところですが・・・。
補足
上に書いた通信速度はByte/秒です。
通信速度はbit/秒で書いてあることも多いので注意してください。
12KB/sは96kbpsになります。
400KB/sは約3.1Mbpsになります。
よって、今回のテストでも制限を受けないファイルタイプであれば3Mbps程度は出ており、たぶん制限なくてもこんなもんです。
追記(15/07/22)
いくつか補足と訂正を。
・「最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・」と書きましたが、正確には（Apacheが）/etc/mime.typesを参照してるだけですね。すみません。
・測定は平日昼間（正午ころ）行っています。夜間はプロトコル関係なく帯域制限がかかります。こちらは「24時間ごとのご利用通信量が約366MB以上の場合当日21時から翌日2時まで制限」という方にひっかかっているものと思われます。
測定が１回づつしかやってない件については、面倒だからなんですが、数値見てもらえばわかるように１回で十分に誤差ではない有意な差が出ているので問題ないかと思います。実際体感してみればわかりますけどとんでもない差なので・・・。２秒or１分の差ですからね・・・。
・上記挙動は、記事中にも書きましたが公表された帯域制限にひっかかっている状態の話です。
プロトコルによって帯域制限かけるのは、古くはP2Pなどで遮断はダメだけど帯域制限ならOKという方向で概ね世の中落ち着いているようなので、キャリアは真っ当な対応をしていると個人的には思ってます（ただ、帯域制限は僕の契約時には存在せず、後から導入されたものなのでキャリアとしてもあまり強く制限できない事情もあるのかもしれません）。
一方でサービス提供者やアプリ開発者の立場からはすごく迷惑なので仕様を明確にしてユーザーに分かるようにしておいてほしいですね。
・MIMEタイプの変更は本当にやるひとはあまり居ないと思いますが、普通のWebサイトだったらやっぱ止めたほうがいいと思います。
一方で、スマホなどのアプリ内でzipでアーカイブしたアプリ内データをHTTP使ってダウンロードするなんて仕様にしていると、「このアプリだけクソ遅いので星ひとつです。金返せ」とか書かれかねないので本当に注意が必要です。
アプリ側を変更しないで今すぐできる対策としてはやっぱMIMEタイプ変更は、けっこういいアイデアかと思ったんですけど。
どちらにしても、これからは「IPネットワークもはや透過的ではない」と思ってアプリケーション開発をしないといけないってことですね。崖に負けるな！
