編集部が選ぶ「みんなに見てほしい」イチオシまとめはこちら
27
Ryo Shi3z @shi3z_bot
あと、そもそもGoogleフォトがJPEGを再圧縮してるがこれはいいのか。GoogleがやるのはよくてKDDIはダメなのか。それともこの議論に参加している人が全員頭が悪いのか
高木一郎 @takagiichiro
@shi3z_bot TCP通信をコネクションの両端ではなく中間で書き換えてしまうのがダメでは。ブラウザやProxyでならTCPの両端ですよね。
Ryo Shi3z @shi3z_bot
そんな面倒くさい実装をKDDIができるとは思えないですが。エンドツーエンドで通信の秘密を守りたければSSLを使うのが常識では? twitter.com/takagiichiro/s…
高木一郎 @takagiichiro
@shi3z_bot 漏洩リスクの高い時にSSLを使うのは当然賛成ですが、そうでもない時に、TCP上のHTTPで、サーバが送信したデータと端末が受信したデータは基本的に同一であることを期待するのはこれまでの常識だったと思います。それを無断で中間でトランスコードしますって話ですよ。

高木一郎 @takagiichiro
@shi3z ウェブサーバーが配布している写真をダウンロード保存したら、KDDIが再圧縮した違うファイルがローカルに保存されるって嫌じゃないですか。Proxyも無くサーバーにHTTP接続したのに。TCP接続の両端ではなく中間でHTTP内容を書き換える技は魅力的なのでしょうか。
shi3z @shi3z
.@takagiichiro たぶんTCP/IPの中間ではなく スマホ→基地局→ホスト(★)→HTTP→Webサーバのなかの、★のとこであってTCP/IPのなかじゃないんじゃないかなー。だってバラでデータきたら面倒だし
高木一郎 @takagiichiro
@shi3z スマホ上で走っているブラウザやアプリのプロセスがTCP接続を開始してHTTPリクエスト作ってるんですよ。 TCP接続の開始点はアプリで終了点はウェブサーバーです。 Proxyを使わないダイレクトの端末サーバー間TCP接続を書き換えると言うから皆問題視したのです。
shi3z @shi3z
@takagiichiro わかった。もうau使うのはやめましょう
nut @nut320
おおっと、スマートフォンの通信を古いガラケーのブラウザと同じだと思ってるからそういう解釈なのか……ここiPhone以来の5~7年くらいの技術についていけないとこうなるのかな。他山の石。 twitter.com/shi3z/status/6…

高木一郎 @takagiichiro
NEC 通信事業者向け>キャリア >SDN >Traffic Management Solution >ソリューションの進化 jpn.nec.com/nsp/tms/evolut… 『キャリアの収益アップ↑↑』 pic.twitter.com/kj1rAs2mQu
 拡大
ツイートまとめ 32563 view 741 117 users 52 shi3z氏「通信の最適化のトラブルはアプリ作者の能力の問題」 「まともな開発者なら3年前から対応してるはず」 「利用する側(アプリ作る側は特に)が工夫しなきゃなんない話」

コメント

nrturnover @nrturnover 2015-07-16 06:21:05
100%のオレンジジュースを送付するのに途中で水分飛ばして粉ジュースにして(輸送コスト削減)、最後に水分足して戻してたいして変わらないでしょ?って言ってるような感じ
倉瀬美都 @clausemitz 2015-07-16 07:28:45
nrturnover いや。半分のオレンジジュースを運んで、販売店で偽物を半分入れて、100%オレンジジュースって言ってるレベルw
ひし @Hissssa_ 2015-07-16 08:06:40
nrturnover clausemitz 産地表示がなくなったり、「絞りたて生ジュース」が商品価値だったりしてて、発覚しても配送業者はだんまり、窓口が知らされてなくて変な受け答えをしたり、事情通(?)が「俺は知ってた」「対策しない奴が悪い」等言い出してる状況ですねw 笑えないけど。
Localio Projects @LocalioProjects 2015-07-16 09:59:22
TCPの終端はプロバイダ側ルーターの透過プロキシであってコンテンツ提供元のWebサーバでは無いんだろうな。TCPの途中でトラフィック書き換えるみたいな面倒なことやるぐらいなら宛先ポートで透過プロキシに繋いだほうが簡単。
くりあ/CLEA-R-NOT-3 @Clearnote_moe 2015-07-16 10:06:50
nrturnover それを「輸送業者が」ちゃんと説明せずにやってるのが本件ですな。ジュースメーカーは「果汁100%(ストレート)」として出荷してるのに、客に届くのは「果汁100%(濃縮還元)」という。
Localio Projects @LocalioProjects 2015-07-16 10:16:15
圧縮できる情報かはmimetypeでわかる。画面表示用かファイル保存用かはContent-Dispositionでわかる。「写真をダウンロード保存したら〜」はFUD。それにHTTP上で大事な画像をやり取りするのであればzipなりrarで圧縮してから転送するのが普通じゃないかな(デザイナーさんからの納品でアーカイブしていない生画像ファイルなんてみたことありません)。
🍤💨の沼海老 @mtoaki 2015-07-16 10:25:20
LocalioProjects そういう勝手な思い込みでやったから問題になった。
kwicnn @icnnkw 2015-07-16 11:45:16
携帯電話とかPalmに使われていたNetfrontってWebブラウザはパケ死しないようにそれ用の画像圧縮サービスを経由していたから今でもそうだと思っていると認識が食い違うのか。
いろもく @iromoku 2015-07-16 11:59:48
この手の形容はあまり好きではないのですが、どうしても「ガラパゴス技術者」という言葉が浮かんできてしまいますね…
高木一郎 @takagiichiro 2015-07-16 12:30:06
LocalioProjects Content-Dispositionはサーバーがどうして欲しいかであって、受信側がどうしたいかとは無関係では。またauの回答は「WebサーバからのHTTPレスポンスヘッダに応じての制御には対応しておりません」だそうです。
cocoon @cocoonP 2015-07-16 12:30:06
「実際にソシャゲでアップデートの際に、特定のキャリアだけパッチデータのファイルサイズチェックに引っかかっていつまでたってもアップデートが終了しないという不具合が発生した」から2年前からあった問題が今になって広く知られたんだよなあ。だから「何の問題があるの?」っていう意見はおしなべて愚か。実例があるんだから。
高木一郎 @takagiichiro 2015-07-16 12:35:16
LocalioProjects 実際にどういった形で実装されているのかはわかりませんが、それがユーザーとサーバーに知らせずに透過的に行われていれば問題は同じことです。
Aki @Aki_8ara 2015-07-16 18:52:18
そもそもパケット通信の定義というか前提として、ある単位のパケットは送信と受信は同じ物という前提がある。その内容が異なっていたら、破損パケットは破棄する。昔のブラウザやGoogleの写真圧縮は、インフラの制約があるから、レイヤー7以上の領域で仕様制限をかけてるだけ。何も前提がなく同じデータを送ったら1200bpsで1ヶ月かけてもハイビジョン動画を送るのが通信網。
Aki @Aki_8ara 2015-07-16 18:58:08
昨日冥王星に最接近した探査機ニューホライズンズは、20~30GBの探査データをこれから来年春くらいまでかけて800bit/secの通信回線で送る。物理層ってのはそういうモノだと思う。Ack/Nack確認が数時間がかりでね
ちくわぶ @chikuwavu 2015-07-17 00:11:27
iPhone以来の技術どころか、PHS単体でPIAFS使って接続(DataScope等)から行けば20世紀からずーっと同じで変わっていないし・・・ ずっと前から興味もなかったから知らなかったことを想像で上から目線で語ってしまって反発食らったんじゃないのかなぁ・・・
3mのパブリックエネミーちくわ @tikuwa_zero 2015-07-17 21:58:06
「これまで問題なかったし、これからも問題ない」じゃないんだよね。「これまでも問題だったけどたまたま表面化してこなかった」だけで。
ログインして広告を非表示にする
ログインして広告を非表示にする