2015年7月の投稿一覧

Y!mobileはHTTPのプロトコルを監視して帯域制限を行っている

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ネットワークもはや透過的ではない」と思ってアプリケーション開発をしないといけないってことですね。崖に負けるな！

Windowsのファイル名ソート順の再現が難しい件（StrCmpLogicalW）

Posted on 2015年7月7日(火) 04:29

最近「ComicGlassのソートがWindowsの並びと違う」とご意見を頂きました。

WindowsXP以降ではファイル名のソート順が数値などを解釈する自然な並びになるようになっています。
よって単純なコードの比較とは違う結果になります。

よく説明されるのは、
20string
2string
3string
というソート順だったのが
2string
3string
20string
という感じになることでしょうか。

WindowsであればStrCmpLogicalW()というAPIを呼び出すとこのソートが行われます。
Windows以外の環境でこのソートを再現する方法は、検索するといくつか提案されていますが、どうも結果が違います。
公式な仕様が見つかればいいんですが、どうも見つかりません。

そこで、それを再現すべくそもそもWindowsがどのようにソートしているか実験してみました。
（特に海外のサイトの情報はUnicode文字に関する配慮がほとんどされてない事が多いので）

結論から言うと、StrCmpLogicalWを再現するのって無理ゲーなんじゃないかと・・・。
いい方法あったら是非教えてください。

とりあえず、以下調査結果でございます。

・StrCmpLogicalWは記号、数値、その他文字の順で並ぶ

ASCIIやUnicodeでは「！」は「０～９」より前にあるが「;」などは数値より後です。
しかしながらWindowsでは「;」などの記号も数値より前に並びます。

（Unicodeコード順）
!test.txt
0test.txt
;test.txt

（Windows）
!test.txt
;test.txt
0test.txt

というわけで、その文字が「記号」であるか「数値」であるか「その他文字」であるかを区別しているようです。

そこで問題になるのが、何が記号で何が記号でないか。

（記号になる例）
!
;
®
µ
§
»
★

（記号にならない一例）
¼
À

うーん。規則性がわからん。
プログラムを組んでStrCmpLogicalWで実際に試してみたのですが、かなり後ろの方のコードまで記号扱いになるものとと文字扱いになるものが入り乱れています。
どうもUnicodeコンソーシアムが規定するUNICOD文字一覧表に記号かどうかの情報があるようです。
つまりUnicodeとして記号かどうかで判断されており、それは規則性などなく全一覧を知らないとどうにもならない。
まぁ、それだけなら全コードの情報を持っておけばいいのですが・・・

・・・しかし！
Windowsが知らない新しいUnicodeは正しく解釈していないような気がします・・・。

例えばU+2639（☹）、U+263A（☺）、U+263B（☻）は記号扱いですが、その他顔文字は記号になりません。
もしかしたらWindowsではサロゲートペアが正しく処理されていないだけかもしれません・・・。

これは心が折れますね・・・！

・StrCmpLogicalWは全角の記号も半角と記号と同じ扱いになる

同じ記号の場合は全角の方が後になる。
・・・ってことは正準等価性を使った正規化してるんでしょうかね？
その説を支持する結果として「»」が「§」よりも前に並ぶんですよね。コードは後ろなのに。

しかし後述しますが、数値で混在すると別々に評価されるっぽい。つまり単純に先に正規化しても駄目と・・・。

・StrCmpLogicalWは数字が並んでいる場合はまとめて１つの意味付けがされる

0001.txt
2.txt
003.txt

これはファイルに0から順に名前つけて桁が増えた時に変な順番になるのを防げます。

・StrCmpLogicalWは20桁以上の数値は数値として扱わない

符号なし64bitで表せる値の最大値は18,446,744,073,709,551,616で20桁なので、20桁目からオーバーフローします。
よって、Windowsも64bit演算で扱える最大値の19桁まで取り扱うようになっていると思われます。
これは実装が楽で助かります。

・StrCmpLogicalWは全角の０～９も数字として扱われる
　・ただし半角全角混在の場合はそうならない。何故だ・・。

情報求む・・・・！

とりあえずASCIIコードにある記号だけ記号として解釈し、数値は19桁まで数値として認識する、という方法でだいたい近い結果にはなります。一致はしませんが。

円柱を横から見ても四角ではない

Posted on 2015年7月6日(月) 23:16

娘が小学校１年生になりました。
どうも「算数」って苦手・・

娘が納得しなかった問題で、

”（これを）よこから みると しかくに みえるね！”という男の子が出てくるのですが娘はこれに納得しないのです。

「四角にはならない」と言うのですが・・・うん、僕にも四角には見えない。

円柱は立体物で、「四角に見える」とか「円に見える」と言うには平面に投影した結果を言っています。

３次元の形状を２次元に投影する方法はいくつかありますが、目でみる場合には「透視投影」を行うことになります。
要するに遠くのものは小さく見えるし、近くのものは大きく見えます。

つまり、、、

円柱を描いてみます。

視点を変換して横から見てみます。

四角じゃない。

これが四角に見えるためには無限の距離から見なければなりません。もちろん無限の距離にあるものなんて大きさが限りなく０なので見えません。
図面のように平行射影すれば円柱の側面は四角に見えるかもしれませんが、目で見たら絶対四角にはならないんですよね。

おそらく問題の意図としては正射影したらどんな形かと言いたいんだとは思いますが、正射影を説明するのも難しいし・・と思ったけど、「遠くから見たら四角っぽくなるでしょ」というファジーな説明でなんとなく理解してくれたみたいです。。
うーん。算数やっぱり難しい。。