19:34前回の記事のつづきです。月が変わり、帯域制限の対象ではなくなったはずなのでもう一度測定してみました。864KB/sあ、速い・・・。帯域制限がかかっていたファイルタイプと、そうでないファイルの速度差がなくなりました。月末に測定した時の転送時間は、zipファイルは80秒弱、pdfファイルは2秒ちょっとでした。上記表以外にも複数回測定してみましたが、概ね安定した速度です。帯域制限がかかっていないと思っていたファイルでも転送速度がだいぶ速くなっています。LTEプランの帯域制限中の挙動はおそらく以下のような挙動かなと思われます。特定のタイプと一致すると更に帯域制限される(96Kbpsくらい?)ただし、帯域制限の目安の通信量をどの程度超えたかや、基地局の混雑具合によって制限値が変わるという書き込みも見られるので、数値は環境によって変わるかもしれません。LTEの回線でアプリのテストをしているときに謎の不具合として発見しました。スピードテストや、普通のブラウジングは快適に行えているのに何故かzipファイルの転送時のみものすごく遅くなり、最初は自分のアプリの不具合を疑いましたがHTTP通信全般で発生するようです。LTEで、「当月のご利用通信量が10GB以上」で帯域制限を行うと公表されています。テストした日までの通信量は10.588GBで、目安の通信量を超過している状態です。この状態でHTTPによるリクエストを出すと、ファイル種類によって挙動が変わります。月初めはどのような挙動になるか不明なので来月になったらやってみます。以下コマンドで1MBのダミーファイルを生成。count=1ファイルの中身はそのままで、拡張子のみを色々変えてwgetで転送してみた結果が以下です。502KB/s1回づつしか測定していないので誤差は大きいと思いますが、ファイルタイプによって明確な差がついていることは明らかです。10倍どころか30倍違う・・・!1MB転送するのに1分以上もかかっているようでは、実用的にはかなりキツイ状態です。HTTPSにした場合は帯域制限かからなくなります。LTEプラン)では、HTTP通信の内容を見て帯域制限を実施していることがわかります。.aikatsuは制限がかかっていないので、「JPEGは制限しない」のようなホワイトリストでなく、「zipは制限する」といったブラックリスト方式みたいですね。僕が発見したのはzip,bin,exe,lzh,7z,rarですが、他にもあるかもしれません。次にファイルタイプの判別方法ですが、ファイルの拡張子ではなくMIMEタイプを見て判別しているようです。ファイルに以下を以下のようにしてMIMEタイプを変更して同じRARファイルをダウンロードした場合です。376KB/sその他、いくつかオレオレMIMEを指定してみましたが帯域制限はうけませんでした。よって、HTTPサーバの設定を変更してMIMEタイプを変えてしまえば帯域制限を免れることができますね...。いうか最近のWebサーバはRARとかまでMIMEが正しく設定されているのか・・・。していいか分からない苦情が来ることに備えるには以下の対策が考えられます。(実際これが原因で帯域制限の仕様を知った・・・)・HTTPSを利用する昨今色々あるので、もう全部HTTPSにできればそれが良いかもしれません。・MIMEタイプを変更するこれを変えてしまうのは反則かもしれませんが、現実的にはzipなどのMIMEが間違っていてもダウンロードさえされれば別に困りません。image/jpegなどにするとブラウザ側が困るので、www/unknownあたりにしておくのが無難かと思います。すげえ!とりあえず、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時まで制限」という方にひっかかっているものと思われます。測定が1回づつしかやってない件については、面倒だからなんですが、数値見てもらえばわかるように1回で十分に誤差ではない有意な差が出ているので問題ないかと思います。実際体感してみればわかりますけどとんでもない差なので・・・。記事中にも書きましたが公表された帯域制限にひっかかっている状態の話です。プロトコルによって帯域制限かけるのは、古くはP2Pなどで遮断はダメだけど帯域制限ならOKという方向で概ね世の中落ち着いているようなので、キャリアは真っ当な対応をしていると個人的には思ってます(ただ、帯域制限は僕の契約時には存在せず、後から導入されたものなのでキャリアとしてもあまり強く制限できない事情もあるのかもしれません)。一方でサービス提供者やアプリ開発者の立場からはすごく迷惑なので仕様を明確にしてユーザーに分かるようにしておいてほしいですね。・MIMEタイプの変更は本当にやるひとはあまり居ないと思いますが、普通のWebサイトだったらやっぱ止めたほうがいいと思います。一方で、スマホなどのアプリ内でzipでアーカイブしたアプリ内データをHTTP使ってダウンロードするなんて仕様にしていると、「このアプリだけクソ遅いので星ひとつです。金返せ」とか書かれかねないので本当に注意が必要です。アプリ側を変更しないで今すぐできる対策としてはやっぱMIMEタイプ変更は、けっこういいアイデアかと思ったんですけど。どちらにしても、これからは「IPネットワークもはや透過的ではない」と思ってアプリケーション開発をしないといけないってことですね。