【闇パケ】を解明するスレ

闇パケ(ユーザーが取得するデータ以外に課金されるパケット)は
どこのキャリアもグレーゾーンとしておりキャリアが増やそうと思えば
いくらでも増やすことができる。
つまりパケット半額を謳い、その一方で闇パケを増やして
ユーザーを騙すのも容易である現状は明らかにおかしい。

そこで闇パケを報告しあい、
キャリアが闇パケを勝手に増やしにくい環境にしよう。
＆どういう条件の時に多くの闇パケを消費するかみんなで明かそう。

キャリア：DoCoMo
機種：N900i
URL：http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/sysctl/sunrpc.txt
ファイルサイズ：843byte(7パケット)
消費パケ数：12パケット
闇パケ：5パケット
画像：OFF
電波状況：3本

※URLを予めブックマークに登録し、
　測定日にはブックマークから直接上記URLへ接続し、
　その日はそれ以外のパケット通信を行わない。
※定額にしろ等は趣旨が違うのでスルーで。

( ゜Д゜)ﾎﾟｶｰﾝ

>>1死ね

闇パケなんて怖くて食えねぇよ。
今どきは下手したら命も危ないからな。

>>1

パケ代500万使ってさらにダイヤモンドルースと高級リトグラフ買って氏ね

メールがきたらどうすんだ？電源OFFか？

>>1
ヘッダ情報等は考慮してるか？









とﾏｼﾞﾚｽ。

>>6
もちろん一機種だけ持ってる人は測定は厳しいと思う。

>>7
考慮してというかヘッダも闇パケにもちろん含まれるだろうね。
ヘッダ等全て含めて今回は闇パケ5パケット。
当然URL等も送信しなければならないから闇パケが
全てだめというのではないです。
(無ければ無いに越したことはないが…)

今度はちょっと大きいファイルを測定しようと思う。
ちなみに一個目のURLはキャリアによる区別を受けないと
思われるテキストで小さめのものを適当に選びました。

>>8
ヘッダはケータイにしろPCにしろパケット通信時には必要不可欠なものだから闇に入るわけが無いだろ。

まずは、ヘッダ無しで通信する方法を考えろ。
話はそれからだ。

言われただけ払えばええやん。
もしくは定額にしるべし。

みんな1みたいにメールこないわけじゃないからな、そゆのはひとりでやってくれないか

>>8
発想はいいと思うんだがな。。。
実際、携帯電話は基本的にダイレクトでTCP接続しているわけではない。
あうの場合だが、ブラウザ(Openwave)から一度そのブラウザに特化しているProxyを経由しているわけだ。
(正確に言うと現在は Openwave Enhanced Service Flamework 1.1.3.x Proxy Server)

要するにそのままの情報でパケット通信で飛ばされるわけではないので生データとの誤差は普通。



間違ってたりしたら誰か訂正ｷﾎﾞﾝ。


それにヘッダっつのーもかなり長いんだが。実際見て見ればわかるが。（あうでしか確認してないけど。

＞闇パケ(ユーザーが取得するデータ以外に課金されるパケット)は
＞どこのキャリアもグレーゾーンとしておりキャリアが増やそうと思えば
＞いくらでも増やすことができる。
闇パケがプロトコルヘッダなどなら増やしようが無い。
それ以外の要素もあるというのであればそれを書いてくれ。

>>13
＞生データとの誤差は普通。
有る無しで言えば誤差は当然"ある"という結論で問題ないが
じゃーその誤差はどのくらい？

>>14
＞闇パケがプロトコルヘッダなどなら増やしようが無い。
なにのプロトコルについて増やしようが無いと？
例えばHTTPプロトコルであれば少なくともUA等の
キャリアが規定できるものがいくらでもあると思うが。
さらに言えば13での話のように外向けには当然標準プロトコルが
使用されるが端末⇔キャリアサーバーまでは独自プロトコル使ってるかも。

>>15
回答の的が外れてるが先にhttpヘッダについて。。。
実際にソケットをあけて送ってくる情報を確認してみた。

実際かなりの量のヘッダだった。あうなんだが、送られてきたhttpヘッダだけで1,265byte(約9.88Packet)あった。
しかしながら、ヘッダ情報=接続に必要な情報 な訳だからしょうがないとは思う。
確かに必要もなさそうなヘッダ情報も一部含まれている。。。

少々長いが、W11H/auから接続したときに吐き出されたヘッダ情報を>>16に乗せておきまつ。

かなり情報量が多くて送信できませんでした。。。
http://data.uploda.net/anonymous/etc2/upload25696.txt
こちらで確認ください。

連書きすまそ。
提案なんだが、実測するならヘッダ情報のことも完全に考えて
(最初にヘッダも計算に含めて)計ってくれたら、それはそれでいいと思うんだが。。。

>>7が言いたいのはサーバーから確認可能なHTTPリクエストヘッダについては
サーバー側で計測可能だから闇ではなく明らかなパケットだから
闇パケの内訳から無くそうってことでOK？
(消費パケ数-実ファイルサイズ-HTTPリクエストサイズ=闇パケ)

ただそうするとキャリアのサーバーでHTTPを加工していないか、
加工してからパケ数を計測していないといけない。
>>16>>17を見るとキャリアのサーバーが機種によって
HTTPを加工してるように見える。
ちょっとHTTPヘッダがでかすぎ…。

なのでHTTPリクエストがサーバー側で計測可能でも
どこの時点のパケットを課金しているか不明なので
HTTPリクエストも含めて闇パケだと思う。
(消費パケ数-実ファイルサイズ=闇パケ)

>>14
＞例えばHTTPプロトコルであれば少なくともUA等の
＞キャリアが規定できるものがいくらでもあると思うが。
いくらでもあるという認識は激しく間違ってるぞ。
RFC2616でちゃんと何をどうすれば良いか決めてある。
http://www.studyinghttp.net/rfc_ja/2616/rfc2616.ja
http://www.ietf.org/rfc/rfc2616.txt
まさかRFCを無視してまでキャリアがデータ水増しをするって言うんじゃないだろうな？

＞端末⇔キャリアサーバーまでは独自プロトコル使ってるかも。
WAP2.0端末では普通にTCP/IP、HTTPを使ってるよ。
http://www.itmedia.co.jp/mobile/news/0108/02/wap2.html
http://k-tai.impress.co.jp/cda/article/keyword/7509.html

真面目に闇パケについて語るならもう少し調べて書いた方が良いんじゃないか？

HTTPに詳しくないから自信ないが
1つのヘッダフィールドの長さは決まってる？
例えばUser-Agentの長さを1KB程度積むのはRFC2616に違反するの？
RFCに従って、フィールドを埋めまくるなんてこともできると思うが。。。
間違ってる？

＞＞端末⇔キャリアサーバーまでは独自プロトコル使ってるかも。
＞WAP2.0端末では普通にTCP/IP、HTTPを使ってるよ。
＞http://www.itmedia.co.jp/mobile/news/0108/02/wap2.html
＞http://k-tai.impress.co.jp/cda/article/keyword/7509.html
itmediaの図にWirelessProfiledTCPとあるが…。

＞真面目に闇パケについて語るなら
＞もう少し調べて書いた方が良いんじゃないか？
そうは思うが、いくら調べてもキャリアが公表しない限り
確実な情報はない。
どこのキャリアがどこのレイヤで課金してるかも定かじゃない。
パケット通信と言うぐらいだからレイヤ3かな？
実際に課金されるデータからの検証が一番有用と思う。

良スレになってきたんじゃねぇの。>>1の意向とは違うベクトルで。

よし。>>1はまずパケット通信を勉強してみよう。
ttp://www5e.biglobe.ne.jp/~aji/3min/

料金明細をとると、何バイトの送受信をしたかが載ってるから、
より正確に把握できないか？

１ヶ月かかるのが大変だが。

>>21
ヘッダフィールドの長さは決まってないはず。
だからといってRFCの範囲内で埋めまくるといっても、
ヘッダフィールド内の要素はそれぞれ意味があるから作られたわけで、
全く意味を持たせないで埋められる要素なんてほとんど無い感じだぞ。
User-Agentの長さを1KBにするというが、そういうことを行っている前例など無いぞ。
前例がないから無理とは言わないが、まともな電気通信事業者がそんな危険を冒すだろうか？
加えてUser-Agentを弄れば一発でばれるからその会社のブランドを落とすことにもなるだろう。
これだけwebが発達している世の中でそんなことをすれば2chとかで物凄い勢いで叩かれるだろうし、
それだけでなくこんどはマスコミもかぎつけてくるんじゃないだろうか？
第一、そんな危険を冒さなくとも元々通信量は増加傾向にあるわけで、
俺は到底あり得ないと思うね。
どうしても余計に通信して欲しいならプロトコルに手を出すんじゃなくて端末を弄るだろう。
例えばキャッシュアルゴリズムを意図的に馬鹿にしたりとかね。
噂によるとこれは既にDoCoMoの505iだかでやられたらしいが。

Wireless Profiled TCP/IPっていうのは殆どTCP/IPと同じだよ。
パラメータをちょっと変更してる程度。
具体的にはデータサイズの変更、タイムアウト時間の設定、輻輳制御の調整等だな。
HTTPも使ってると書いたけど、正確にはWireless Profiled HTTPだね。
双方ともWAP2.0で標準化されているので独自プロトコルというのはあり得ない。

＞そうは思うが、いくら調べてもキャリアが公表しない限り
＞確実な情報はない。
独自プロトコルとか使ってたりはしないということは確実だろ？
既に大分前から報道されてるわけだし。
＞実際に課金されるデータからの検証が一番有用と思う。
TCP/IPで再送が発生すれば全く正しくない結果が出るだろ。
正確を期するなら全然駄目だ。
俺はいまいち思いつかないので代案を提案出来ないが、
本気で検証したいならもう少し手段を考えるべきだと思う。

＞ヘッダフィールド内の要素はそれぞれ意味があるから作られたわけで、
＞全く意味を持たせないで埋められる要素なんてほとんど無い感じだぞ。
意味を持たせて埋めることもできると思う。
たとえば>>16、>>17に記載があるようにauはヘッダフィールドのACCEPTが
かなりでかいがドコモは空白になっている。
ACCEPT分まで課金されているかは分からないが…。

キャリア：DoCoMo
機種：N900i
URL：http://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/BUG-HUNTING
ファイルサイズ：7,973byte(63パケット)
消費パケ数：71パケット
闇パケ：8パケット
画像：OFF
電波状況：3本

ファイルサイズが約10倍になっているのに
闇パケは3パケの上昇でとどまっています。
サイズが増えてもHTTP層で3パケも増えるとは考えられないので
TCP/IP層での課金となりますね。
レイヤ3でのSDUの課金かな？。
レイヤ3のPDUでの課金ですとファイルサイズが10倍に
なったらもっと闇パケが増えてもよさそうだし。

キャリア：docomo
機種：P2102
URL：ttp://www.linux.or.jp/JF/JFdocs/kernel-docs-2.6/sysctl/sunrpc.txt
ファイルサイズ：843byte(7パケット)
消費パケ数：13パケット
闇パケ：6パケット
画像：OFF
電波状況：3本

機種による誤差か再送による誤差なのかデータが少ないから
わからない。

キャリア：DoCoMo
機種：N900i
URL：http://www.nttdocomo.co.jp/imode/policy/privacy/index.html
ファイルサイズ：1,182byte(html)+892byte(gif)=17パケット
消費パケ数：25パケット
闇パケ：8パケット
画像：ON
電波状況：3本

ひと言：gifファイルの取得にも別にリクエスト出てるだろうけど
　　　　あんまりパケット増になりませんでした。
　　　　ドコモは結構良心的な闇パケ設定なのかな(笑)。

ヘッダが闇パケのわけねええーーー！！
>>1は本当機械オンチ

消費パケ数-実ファイルサイズでいいんじゃない？
ヘッダに余分な情報入れてないとも限らんし。

ムーバはパケ数少なく済むって聞いたことがある。
だれか試して。