長いURLは回線容量を無駄に消費？ 102
ストーリー by hylom
ちりも積もれば 部門より
ちりも積もれば 部門より
あるAnonymous Coward 曰く、
Facebookなどで使われている長いURLは回線容量を無駄に消費しているとの記事がO3 Magazineに掲載されている（本家/.記事より）。
記事ではcompete.comのトラフィック統計を使いFacebookの典型的なページを分析。150文字を超える長さとなる場合もあるというURLを短くすることで75MBit/秒の回線容量を節約できると算出されたとのこと。これらの非常に長いURLに続くGETリクエストも回線容量に影響を与えていると指摘する。
Facebookだけでなく同様の問題を抱えるサイトは多く、またWordPressなどのCMSツールにも当てはまるという。高トラフィックなサイトを最適化する興味深いアプローチではあるが、実際にこのような目的でURLの長さを考慮しているサイトなどあるのだろうか？
URL末尾のスラッシュ (スコア:3, すばらしい洞察)
それは嘘（was Re:URL末尾のスラッシュ） (スコア:2, 参考になる)
http://www.exapmle.com
http://www.exapmle.com/
両者に発生するトラフィックに違いはないよ。
Re:それは嘘（was Re:URL末尾のスラッシュ） (スコア:3, 参考になる)
>http://www.exapmle.com
>http://www.exapmle.com/
上と下で
>両者に発生するトラフィックに違いはないよ。
のは、サーバー名の直下の"/"だからです(RFCは失念)
http://www.example.com/hoge [example.com]
http://www.example.com/hoge/ [example.com]
なら、
1. www.example.com の /hoge をくれ。
-> /hoge はないが、/hoge/ はあるよ。
2. www.example.com の /hoge/ をくれ。
-> つ /hoge/
という感じで、ブラウザとサーバがやり取りするので、トラフィックに差が出ます。
ルートの時だけ、例外なのです。
#もちろん、/hoge があれば、/hoge/ へのアクセスは発生しません。
Re:それは嘘（was Re:URL末尾のスラッシュ） (スコア:1)
そうですね。そのせいで、サーバがどっと混でしまいます。
Re:URL末尾のスラッシュ (スコア:1, 興味深い)
スラッシュを付のURLを指定してもさ、デザイナーのスラッシュが無い方が見栄えがいいという意見で、スラッシュなしにされちゃうんだぜ？
Re:URL末尾のスラッシュ (スコア:1, 興味深い)
［なんとかかんとか］［検索］
ってのが多いから、それだけで無駄なトラフィックですね。
リダイレクトといえば日本のMY YAHOOがひどいです。imgタグに書かれているsrcの多くがリダイレクトされます。すげー無駄。
Re:URL末尾のスラッシュ (スコア:1)
いまでもそうだよ。「http://srad.jp/it」とかあくせすしてみそ。
コンテンツじゃなくて，こんな応答がかえってくるよ。
で，あらためて「http://srad.jp/it/」にリクエストがいく。
結論が… (スコア:2, すばらしい洞察)
どうしてここから:
よって全てのISPは、非常に長いURLによる回線容量への影響が出ないぐらい、太い回線をユーザーに提供しなくてはならない。ここでいう「影響が出ない」とは、長いURLを使っても短いURLを使っても、その差が 1/10000 以下になるような回線の太さを言う。
という結論に至らないのか、謎でなりませぬ…
# 極論には極論で対処。
fjの教祖様
USER_AGENTも，ですよ (スコア:2, すばらしい洞察)
長いっていうなら，UAもだろ。
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2; .NET CLR 2.0.50727; .NET CLR 1.1.4322; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; msn OptimizedIE8;JAJP)
そもそも http:// のスラッシュ2つが… (スコア:2)
それなんてティム・バーナーズ＝リー氏？
# 自らツッコミ
そんなバナナ＞回線容量 (スコア:1, 興味深い)
ただ、検索エンジン上位表示目的でURLを短くしていたり、階層構造を
浅くしたりしている所は多いと思う。
長いURL (スコア:1)
長いURLといえば、Facebookなんかより、ウィキの日本語ページ名でしょう。あれだけは人の紹介するのに躊躇する。
メールに書く時とかは、tinyurl必須という感じです。
Re: (スコア:0)
tinyurlなんか何所にリダイレクトされるか知らないし、ずっとスパムの短縮URLに使われているから信用できない
これをビジネスで使う人がいたら、すぐに取引を止めることにする
Re: (スコア:0)
じゃあWikimediaFoundation自身でtinyurl相当の機能を提供すればいいんじゃね？
ふんぞり返ってねえでさっさとやれ＞日本語版ビューロクラティ
Re:長いURL (スコア:2, 興味深い)
もう一度。
ウィキペディア内でショートカットを作る事はありますよ。
WP:VPとか、WP:NOTとか。ただ、一般の記事には利用しません。
ウィキペディア内の短縮サービスがあってもいいという意見は反対しません。結構賛成かも。
Re:長いURL (スコア:1)
ビューロクラットの権限は、makesysop、desysopくらいなのですが。システムをいじる権限はありませんよ。
Re:長いURL (スコア:3, すばらしい洞察)
元の長いURIにアクセスしたほうが、プレビューを表示してジャンプするより
トラフィックが小さいので、トラフィック的には本末転倒ですね。
アラスカ送り (スコア:1)
エーベルバッハ少佐？
Re:長いURL (スコア:1, すばらしい洞察)
誰がウィキペディアのことを言ってるの?
ウィキペディアに限らず、記事タイトルに日本語使ってるウィキのサイトのURLは長いでしょ。
ページのソースのコンパクト化も必要 (スコア:1, すばらしい洞察)
無駄に複雑なコードをコンパクトにするだけで相当な効果が上がりそうですよ。
Re: (スコア:0)
そんなことより (スコア:1, すばらしい洞察)
ブログの本文検索のログに「のでは」なんて残ってて、誰が検索してるのよ？とか思ったらグーグルのクローラだったりするし。
Re:そんなことより (スコア:1)
>>検索エンジンのクロールの方がよっぽど無駄に帯域食ってるでしょうに。
でも、そういう意見は何故か見つからなかったり。
クローラが悪さしてる、って例を調べると、百度のクローラの例はゴマンと出てくるのに、
それ以上、派手にクローラ流してるグーグルの事って、ググッても出てこないんですよね。
Re:そんなことより (スコア:3, おもしろおかしい)
Re:そんなことより (スコア:1)
百度は、かつて、数アクセス/秒の「攻撃」と言えるぐらいの酷いGETをしましたから、別格かと思います。
今はまともらしいですが、かつてのそんなアクセスの時に robots.txt に Disallow: を書き加えてそのままのWebサイトが結構あるかも。
8.3 (スコア:1)
※昔はファイル名一つ決めるのに苦労したなぁ…
長いＵＲＬ (スコア:1, おもしろおかしい)
そうだよね。
あんまり長いと、こぶが引っ込んじゃうよね。
本当にトラフィックが減る？ (スコア:1)
URLが少々長かったところで、通常は1パケット(ほとんどの場合1500バイトくらいまで)に収まるわけだし、トラフィックは変わらないのではないでしょうか？
パケットの分割が起こるほど長いURLなら話は変わりますが、ここで挙げられているのはたかだか150バイト程度のことのようですし。
Re:本当にトラフィックが減る？ (スコア:2)
ＬＡＮで使われるイーサネットのデータ長は１５００ほどですが、ＷＡＮで使われるＡＴＭのデータ長は４８です。
経路にＡＴＭが使われていない可能性があるかもしれませんが、使われていると思ったほうが良いと思います。
やりすぎた対策 (スコア:1)
http://example.com/?S=xxx
HTTPサーバも改造して
http://example.com/xxx
これでOK
Re:やりすぎた対策 (スコア:1)
Re:やりすぎた対策 (スコア:1)
エコ (スコア:1)
回線容量じゃなくて、エコとかCo2削減量とかで表現すれば
受けがいいのに
スタンスの違い (スコア:1)
「見てもらってる」
という立場ならば、見てもらう方々のためには少々のマシンリソースや
トラフィックが増大するのもやむなしだと思います。
スラッシュ1文字を省いてOKな分だけユーザに優しいですからね。
「見せてやってる」
という偉い方のWebサイトならば、見せてもらってる人々が偉い方の
ために末尾にスラッシュをつけるべきじゃないでしょうか。
偉い方に迷惑をかけるなんてとんでもない話ですからね。
トラフィックを減少させたい方は、「必ずスラッシュを入れろよ！」
とふんぞり返って上から言うのが良策です。
#トラフィックと比例してアクセス数が減少しますorz
TV CMから見直す (スコア:1)
URLを云々言うより、詳しくは「xxxx」で検索みたいなCMを辞めればトラフィックのみならず検索エンジンの負荷も減らせるだろうし。いいんじゃないだろうか。
あれがどの程度効果ある物か解らないけど、少なくとも自分は殆ど覚えてないなぁ。
結局メーカーページに行くけど、ブランド名が違うだけで別サイトになっていたり階層深かったりでなかなか目的のところにたどり着けなくて、URLの長さがどうだろうとダメダメなサイトが多い。
携帯なんかは意識する。 (スコア:1)
最近は、パケホとかでだいぶ気にしなくなりましたが、一昔前（今も少しは）までは
携帯のURLを一字でもけずって容量を軽くし、その空いた所に表示したいテキスト
をいれるなんてことをよくやっていました。
結果、URLが、http://www.hoge.com/i/t/r.php?uid=NULLGWDOCOMO&a=hoge&b=foo
なんて、開発者がぱっと見ても、よくわからないファイル名&変数になっていて
困り果てたことが多々ありましたねぇ。。
検索表示の絞込みはどうですか？ (スコア:1)
Googleの検索結果は、長いサブドメインのURLを持っているため
これが帯域消費の大部分を占めているのでは？
対策としては、検索結果の表示を少なめにすればいいのでは。
検索条件としてもで、ユーザ環境や趣向に応じた条件を自動的に付加して
検索結果の要望マッチ率を上げるような工夫もいると思います。
実際にこのような目的でURLの長さを考慮しているサイトなどあるのだろうか？ (スコア:0)
Re:実際にこのような目的でURLの長さを考慮しているサイトなどあるのだろうか？ (スコア:1)
Re:実際にこのような目的でURLの長さを考慮しているサイトなどあるのだろうか？ (スコア:2, おもしろおかしい)
redirectで無駄なトラフィックを増やしてくれるサイトですね。
Re:実際にこのような目的でURLの長さを考慮しているサイトなどあるのだろうか？ (スコア:1)
（多分皮肉だと思いますが）
Googleマップなんて目印つきのURLは200～250文字ぐらい [google.co.jp]になりますね。
塵も積もれば山となる (スコア:0)
単に共通・頻出部分は太らせるな、という事かと。
(無駄が容易に増えやすいから)
Re:塵も積もれば山となる (スコア:3, 参考になる)
ハフマン符合というわけですな。
でもその前に、XML を通信の基盤に使っている時点で、効率を無視している気がするなぁ。
以前、とあるXMLデータを単純に gzip しただけで、容量が半分以下になってしまいました。
そもそも、なんで end tag に名前が必要なんだ。
閉じ括弧（のようなもの）でイイじゃないか。
Re:塵も積もれば山となる (スコア:2)
それなんてSGML
# まだ、過去じゃないよね…。
Re:塵も積もれば山となる (スコア:1)
ブラウザが実際にサポートしているかどうかはともかく、文法上はHTMLでもSGMLの短縮タグ機構が使えるらしいですよ。
参考: http://bakera.jp/yomoyama/shorttag [bakera.jp]
1を聞いて0を知れ!
end tag に名前 (スコア:1)
閉じ忘れたカッコを発見しようとしたときに範囲を限定できて楽だから？
Re:長いドメイン (スコア:1)
この際、（色々と）頑張ってhp.co.jp取ってください。
-- う～ん、バッドノウハウ？
Re:長いドメイン (スコア:1)
.hp
fjの教祖様
Re:長いドメイン (スコア:1)
Re:長いドメイン (スコア:2)