【２ちゃんねるビューア】　巡回機能の巻。Part3

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50

824 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:00 ID:???: ＞811
とりあえず、gikozillaプロジェクトの発足と
その現状については関知している？
＃今はgikozillaもたいがい氏んでるけどな。
825 ：Dream ★ ：02/03/27 00:02 ID:???: >>819
いえね、そういう意味では、いわゆる２ちゃんねる側の人たち、
夜勤さんとかひろゆきとか、トオルさんもかも知れないけど、
気を使っていると思いますけどね。
ただ、サーバが破綻している現状があって、この現状をおかしい、
って思わない人がいるんならしょうがないでしょうけど、
おかしい、とおもって、協力しよう、って思う人がいたら、
単純に私は可能だと思いますけどね。
●機能の実装だって、そういう経緯でされたんじゃないんですか？
826 ：Dream ★ ：02/03/27 00:02 ID:???: >>824
不勉強ですいませんです。
827 ：Dream ★ ：02/03/27 00:03 ID:???: >>816
ちょっと、その辺は私の感知できる部分ではないし、
私自身Monazilla不参加なので、まずいっすかねぇ？参加しないと・・・
どうなんでしょ？
828 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:03 ID:???: >>819
現時点でのmonazillaツールの定義は「有償IDの認証機能を備えている2chブラウザ」
だと思われ

そして有償IDはクライアントの特定や制限に利用できる有効な手段と思う
829 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:04 ID:o8ZVbcMf: subject.txtのアクセスに、なんらかのパスワードが必要なようにしておけば、
それを正規に得ていないツール/会社からのアクセスを「不正アクセス」と
して、罪に問うことができますね。
管理者がパスワードを「みだりに知らせてはならない」としておけば、あとは
実際にその機密性が保たれているかどうかは問題ではない。

日本の法律が、米国に所在する2chのサーバに適用されればですけど。
830 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:05 ID:???: 一番簡単なのは、2chが自分の責任でツールを提供する事なんだけど
（monazillaのツール作者にお任せでなく）
でも、現状ではそこまで出来ない。
結局、ツールで規制する事には限界がある（溜息
831 ：Dream ★ ：02/03/27 00:06 ID:???: 単純明快に
「subject.txtもdatも基本認証の中に隠しちゃえ」
みたいなことが言えるのは、私がニュートラルな場所にいるからだと思ってるんですけどね。
夜勤さんは、このスレッドのどこかで、
「私からそういうことを言えた義理はないです」みたいな事いってましたし。
「管理者以外の人間が批判されたりしませんか？」って気を使ってましたし。
832 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:06 ID:???: >>829
だからsubback.html(またはそれに相当するもの)を使うだけだってのに..
833 ：Dream ★ ：02/03/27 00:07 ID:???: >>829
運用会社が日本にあるのだから、専管裁判所は札幌地裁になるんじゃないっすか？
834 ：Dream ★ ：02/03/27 00:07 ID:???: >>832
この話回ってますね、四週目くらいです
835 ：Dream ★ ：02/03/27 00:08 ID:???: >>832
subback.htmlにアクセスしてきたIPを弾く機能って、実装難しいですかねぇ？
836 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:10 ID:???: IPによりアク禁をかけるのは、それじたいは難しくないが、
そのIPリストを誰が管理するのかということと、
レイヤー8以降の問題が山積みではある。
837 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:13 ID:???: >>836
2ちゃんねるの場合 political layer の所が難しいよな。
Big-Server はサーバの表面程度しかいじれない。
ひろゆきはやる気もスキルもない。
838 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:15 ID:???: >>835
subback.htmlにどういうアクセスをしてきたものを弾くんでしょう？
通常使用でも見ることがあると思いますが
839 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:15 ID:???: gikozilla騒動について知らない、歴史を軽視するような
香具師は、monazilla part2の、、、あ、offaw落ちか、、、
http://www.google.com/search?q=cache:EU7vRQnwjxQC:pc.2ch.net/test/read.cgi/tech/1005282763/+&hl=ja
140～を参照セヨ
840 ：Dream ★ ：02/03/27 00:19 ID:???: >>838
その辺は今話し手も仕方ないと思いますし、実装するとしたらなおさらいわないと思います。
私実装する人間ではありませんし、どんな権限もないです。
841 ：Dream ★ ：02/03/27 00:22 ID:???: ツール作者さま。
「monazillaツールと課金及び転送量・鯖負荷問題を考えるスレ」
http://kaba.2ch.net/test/read.cgi/accuse/1016974669/542-543

なのですが、これ今まだたたき台を作ってるという感じなのですが、
作者さん達の現時点での見解とかご提案とかアドバイスとか、そんな感じの
お話をいただければ、と思いますです。

現在いただいているコメントです。。

委員長さん→http://pc.2ch.net/test/read.cgi/software/1016905060/671
西安さん　→http://pc.2ch.net/test/read.cgi/software/1016905060/672
842 ：AJA6H/Ws ◆MPnX7dHA ：02/03/27 00:29 ID:???: 過去ログを縦読みしたけど、
昨日からなーんも進展がないような気がするんだけど・・・^^;
843 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:35 ID:???: >>842
現状の2ちゃんねるの問題が、それだけ深刻だと言う事
844 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:38 ID:???: >831
転送量や負荷を抑えるために
subback.htmlより小さいsubject.txtを読んだりread.cgiより負荷の小さいdat直読みしたりするツール
の使用が推奨されてるわけで、
subject.txtやdatを隠して誰が得するのか説明しろｺﾞﾙｧ(ﾟдﾟ)

ゲイツか？
845 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:39 ID:???: subject.txtを使った荒らしが減る。
846 ： ◆hAnYaNVA ：02/03/27 00:40 ID:???: TCPの3-Way-Handshakeは重い、という話をきいた
ことがあったので、あちしのツールではKeep-Aliveによる
Persistance-Connectionがなるべく途切れないように
しているわけだですけども、intervalがあるなら、当然
Connectionは毎回切れるわけで、そういうものなのか、と。

intervalを間に挟んだり、複数の鯖を交互に使用したりして
軽減される負荷というのは、Keep-AliveしてHandshakeを
削減するのよりも大きいのかな？という疑問はありますです。
847 ：Dream ★ ：02/03/27 00:41 ID:???: >>844
一定の枠を用意して、みたいないいカタすると官僚のようだけど、
ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
ツール作者さんには、subject.txtやdatを公開するって形だと、どうなんでしょね？

＃ずっと私は、それを提案してきているんですけど
＃誤解されていますか？
848 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:42 ID:???: 公式発表的には、subject.txtは隠されているのですが。
つか、あなた、ブラウザから取得できますか。
849 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:42 ID:???: >>847
それなら隠すといわずに取得に制限を加えると言った方がいいのでわ
850 ：Dream ★ ：02/03/27 00:44 ID:???: >>846
インターバルを挟む、という思想は、ツールによる断続的で集中的な
リクエストを防ぐ、という視点に大きく立脚しちゃっているものだと思います。
作者さんの視点で、どういう方法が、サーバの負荷と転送量という問題に対して
効果的である、という、啓蒙というか、教育というか(私みたいなのに対して)
をしていただけると、とてもうれしいです。
851 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:45 ID:???: >>846
>>725-726 ではとっとと切断、って言って終わってるけど、
もうちょっと考えるべき事だと思う。

「じゃあ Keep alive せずに Rapid fire しろっていうことか?」
と誤解する人が出るのが怖い。
852 ：Dream ★ ：02/03/27 00:46 ID:???: >>849
ああなるほど。

＃ここまでに、このスレッドでも前スレでもしつこくさんざん書いてたから了解済みだ
＃という思いこみでした。
＃すみませんでした
853 ：Dream ★ ：02/03/27 00:48 ID:???: >>851
是非お願いします。
SYN ACKの認証が正直きつい、というのがそもそも、dat直取りで巡回を
されたくない、という話の始点だったと思うんです。
私自身は、その程度の認識しかなく、
「だったらどうやるのが効果的なのか？」
については、是非お聞かせいただきたいと思っております。
854 ：Dream ★ ：02/03/27 00:52 ID:???: もちろん、dat直取りのもう一つの要因としては
転送量に影響する、というところもありますけど、これは、
要求されるのはHEAD情報だけで、datを直に取ってるわけではない、
というお話だと思いましたが・・・・
その場合でも、SYN←→ACKのハンドシェイク的に、サーバ負荷につながっていないのか？
とか、いろいろ、お聞きしたいことがありますです。

あと夜勤さんに、
http://www.yakin.cc/pv200201.html
には、HEAD要求は含まれていますか？というのを確認させていただきたいと思います。
PVという言い方の印象では、GETのみ、で、ページ単位のカウントのような気がします。
(イメージファイルとかそういう者を除いている、という意味で)
お願いします。
855 ：AJA6H/Ws ◆MPnX7dHA ：02/03/27 00:53 ID:???: >>843
なるほど
856 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:58 ID:???: 場合わけをきちんとしようや。
・更新があるばあい
　・Head(stat) [+ Get(read)]
　・ims-Get(stat&read)
・ない場合。
　・Head(stat)
　・ims-Get(stat)
で、どっちにしろ、更新があれば中身をみたくなるわけで、
むしろIf-Modified-SinceをつけたGetの方が軽いのでは？
というのがすくなくとも8ヶ月前の結論だったわけですが。
857 ：名無しさん＠お腹いっぱい。 ：02/03/27 00:59 ID:???: >>854
あの～普通に巡回といわれるものはすべてIf-Modified-Since付きのGETですよ。
巡回時に自動でHEAD→GETとわざわざ無駄なことやってるものは即刻修正すべし、です。
858 ：Dream ★ ：02/03/27 01:01 ID:???: >>857
ああ、はい。
巡回じゃなくて、更新チェックですよね。はい・・・
859 ： ◆hAnYaNVA ：02/03/27 01:04 ID:???: ＞ようするに、サーバ維持策を打ち出して、賛同して参加してくらさる
＞ツール作者さんには、subject.txtやdatを公開するって形だと、
＞どうなんでしょね？

ところで、これは現在のsubject.txtの状態と具体的に
どのあたりが異なるのでしょうか？
860 ：Dream ★ ：02/03/27 01:07 ID:???: >>859
いまはhtaccessやcgi内部で判別してアクセス受け付けてるようですが、
たとえば、基本認証使ってリクエスト受ける、というイメージです。
イメージ的には。
861 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:08 ID:???: >>859
ぎこはにゃ～ん作者登場。
862 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:13 ID:???: >>860
ナニを認証するのさ？●？
863 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:15 ID:???: >>860
それが何の解決になるの？鯖負担が増えるだけでは？
荒らしツールはどれかのツールに簡単になりすましができるけど。
864 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:16 ID:???: >862
ツール（と作者）、じゃないかな。
セキュリティ的にはヨワヨワでないも同然だけど、
そこを不正アクセス禁止法で補助するような感じがする。
865 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:16 ID:???: >>863　荒らし対策の話をするスレなのか？
866 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:17 ID:???: >>865
違うはずなんだけど、まとめ役がそっちに話を持っていくんだもの。
867 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:19 ID:???: >>860
イメージとか、イメージ的では正直意味がとれないよ。
具体的な説明求む。
868 ：Dream ★ ：02/03/27 01:22 ID:???: >>867
すいません。イメージなイメージ的にエクスキューズな単語ですけど、
＞たとえば、基本認証使ってリクエスト受ける
これそのものずばりではないかと愚考します。
869 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:22 ID:???: >>866　責任転嫁すな。
870 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:24 ID:???: ん、だから普通にsubject.txtをGETしても
HTTP/1.1 401 Authorization Required
が帰ってきて、ちゃんとパス送らないと
受信できねって事だろ。
で、このパスを勝手に解析すると不正アクセス防止法に触れる可能性があると。
871 ：Dream ★ ：02/03/27 01:25 ID:???: >>865
荒らしが過負荷の要因になっていない、または、別の手段で対応が出来る、
ということであれば、そういう仕組みは一切要らないかと思います。
たとえば、特定の業者がdatクロールして利益を得ようとしているわけです。
たとえば、全くランダムなdatから書き込みを抽出して、それを、
subject.txtで特定のスレッド拾って、bbs.cgiにPOSTしたりしているわけです。
そういう行為を、負荷低減策として検討する必要がないのであれば、
datもsubjectも、現行のままでよろしいのではないかと思います。
872 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:27 ID:???: >>870
法律なんか気にするな！
873 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:29 ID:???: >>871
それが問題なんだからそっちを対処しようよ。

手に入れたデータまたはその統計を商業利用しようとしている
ところから金を取れるように何か利用規定を設ければいい。

具体的には抜き打ちでIP統計とって、異常に多いところの
IPがどっかの会社だったら「金払え」って言えばいいよ。

抜け道はあるかもしれないけど、それはそれで
バレた日にはその会社は２ちゃんねらに潰される
874 ：873 ：02/03/27 01:31 ID:???: 抜け道はあるかも → 抜け道はたくさんあるけど
だった。

少なくともちょっとは金取れるようになるよ。
そしてその金で回線増強なりなんなりできる、と。
875 ：Dream ★ ：02/03/27 01:32 ID:???: >>873
でもですね、やっぱしあれなんですよ。
荒らしが発生していない日でも、厳然としてサーバはぱんぱん
帯域かつかつ。なんだそうです。
876 ：867 ：02/03/27 01:32 ID:???: >>868
いや、基本認証使ってリクエスト受けると、基本認証する分だけ
負荷が増すと思うんで、その辺どう考えてるのか知りたいなと。
877 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:33 ID:???: 現状だとUAをモナジラと詐称するだけで、
荒らしツールだろうとなんだろうとsubject.txtは受信できちゃうわけで、
しかもそれは法にはふれない。犯罪じゃない。
（UAを偽る＝鯖を騙す＝詐欺罪って話もなきにしもあらずって感じらしいが）

そこを認証にすれば、不正アクセス防止法違反という立派な犯罪にできる。
だから荒らしツールを抑制できる。
悪質なら訴えれば逮捕される。
って事だな。

まぁ、俺ならそんな事されたらsubback.htmlで同じ事するけどね。
それもなくなったとしてindex.htmlから生成すればいいし、
それもだめだったら
http://pc.2ch.net/test/read.cgi/software/1016905060←ここのキーを
現在時刻からさかのぼって存在をチェックしてランダムに荒らすようにだってできる。
ブラウザで見れてカキコできる時点で、なんでもできるわな、そりゃ。

つか、むしろそういう規制された方が燃えるね。
なんとしても荒らしてやろう！ってな。
878 ：873 ：02/03/27 01:34 ID:???: >>875
この話は批判要望に書くべき内容だった。すまんこ。

荒らしが原因の日もあるだろうけど問題なのは
慢性的にクロールしてる企業がいるで重い
ってとこかと
879 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:35 ID:???: かちゅーしゃのアクセスが多い、ってのはそういう企業が作ったツールが
とりあえず有名なかちゅーしゃのUAを偽ってる、ってパターンが多かったりしてね
880 ： ◆hAnYaNVA ：02/03/27 01:36 ID:???: でもそれは、オープンソースの死だよね。
dat、subject.txtのgetにpassが必要で、
それをツールに埋め込んでしまう時点で。
881 ：Dream ★ ：02/03/27 01:38 ID:???: なにか起死回生の良いアイデアありませんでしょうか？
882 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:38 ID:???: >>880 >>768 で一度指摘されたが、返答なし
オープンソースの場合、隠しているとはどう考えても言えないから
法に頼るのも難しいと思われるが
883 ：877 ：02/03/27 01:38 ID:???: >>880
パス埋め込んでもかんけねーよ。
認証なんてなんの暗号化もされてないんだから、
ローカルでプロクシ立てて通信内容のぞき見れば、
すぐにパスなんて分かるっつーの。
仮にプロクシ立てられなくてもTCP/IP通信内容をのぞき見るツールだってあるんだし。
884 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:41 ID:???: というか自分がなにを発信しているか、受信しているかはすぐわかる。
885 ：Dream ★ ：02/03/27 01:42 ID:???: >>882-883
なんか代替案がありましょうか？
886 ： ◆hAnYaNVA ：02/03/27 01:43 ID:???: BASIC認証はたとえなので、Digest認証くらいは
使うものだと当然思っていましたが、、、
別にこれがSSLのClient Certificationでもそんなに
話は変わらないと思うのですが。
887 ：Dream ★ ：02/03/27 01:45 ID:???: 誰かの書いた内容について、批判したり、だめな面を指摘するのは
すごく簡単だと思うんですよね

でも、ここ重役会議やっているわけじゃないんですよ。
どうしようかね？って話してるつもりなんです。

私の提案に不具合や不足があったらとっとと引っ込めます。
良い案を考えていただけるととてもうれしいんです。
(否定すんなよ、ていうんじゃないですよ、もちろん(笑))
888 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:46 ID:???: だから平凡なパスを埋め込むというのは愚行。
送信内容の一部を暗号化して・・・ってのなら効果はあるけどね。
一部にPGPを使うとか。（遅そー）
889 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:46 ID:???: そもそも、大体subject.txtをいかに強いセキュリティをもって隠したところで、
subback.htmlだってなんだってあるんだから無駄って話でしょ。
890 ：Dream ★ ：02/03/27 01:47 ID:???: >>886
ええ、仕様を決めているんではなくて、要求分析というか
まだそこまでいっていないブレインストーミング的な話ではないかと思います。
そう宣言しているレスが、残っているはずです。
891 ：Dream ★ ：02/03/27 01:48 ID:???: >>889
なんでそこではなしがとまっちゃうかな？
ずっと同じ方ですか？
じゃ、どうすればいいの？
892 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:48 ID:???: 公開鍵が公開されてなければ（ツール内に隠蔽されてれば）いけるかも。
893 ：892 ：02/03/27 01:49 ID:???: しかしこの方法はソース丸見えなのには(j2ch-cashだっけ？)使えないな
894 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:49 ID:???: >>891
どうしようもないって事かと
895 ：Dream ★ ：02/03/27 01:51 ID:???: >>894
いや、あなたがそういう感想なのはわかりましたので、
だったらもうあなたの意見わかったのでもういいです。おつかれさまでした。
896 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:55 ID:???: どうせやられるんだからsubbackよりsubjectの方がまだましだ。
異様にアクセス多いIPだけ完全アクセス禁止にしろ。
897 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:56 ID:???: >>894
今回の問題については、100% 完全無欠のシステムを作るのは無理。
だけど、できることはあるはず。UserAgent 詐称だって、
それをやる人がどれだけ存在するかどうかの問題。

規制したことで、トータル的に負荷が減るならやる価値はある。
そのためにも統計とデータが必要。
これからの2ちゃんねるは、様々な実験が必要なんだよ。
898 ：Dream ★ ：02/03/27 01:57 ID:???: 【２ちゃんねるビューア】　巡回機能の巻。Part4
http://pc.2ch.net/test/read.cgi/software/1017161683/l50

ちょっと早いですけれど、次のスレを用意しておきました。
899 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:57 ID:???: >>896
そうだね。それが一番現実的かつ簡単。

そのIPアドレスがどっかのプロバイダでないにもかかわらず
アホみたいにアクセスが頻繁だったら禁止ってのはいいかも。
900 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:58 ID:???: >>875
荒らし対策しても意味無いってこと？
901 ：名無しさん＠お腹いっぱい。 ：02/03/27 01:59 ID:???: ツール側と鯖側でsubject.txtを強度な暗号化して通信したとしても、
結局自分のPCから発信してるわけで、
串とかで通信内容のぞき見られたら、
荒らしツール、dat総ざらいツールでもそのまま使えちゃうんじゃないの？
まったく同じリクエストを送信するだけじゃないの？
902 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:01 ID:???: >901
は、SSLについてもっと勉強してください。
903 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:01 ID:???: >>900
先日のkaba鯖アタックのときは、対策が非常に効果的だったよ。
対策してないときは、ロードアベレージ 150 は軽く越えてたはず。
904 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:09 ID:???: >>898

>>1のテンプレが古い。
905 ：Dream ★ ：02/03/27 02:10 ID:???: >>901
でも、その行為は、これまでのグレーではなく、
レッドになるわけですよね？法的には。

「そういう使い方をされたくないために意図された」
ものを乗り越えるんですから。
906 ：Dream ★ ：02/03/27 02:11 ID:???: >>904
ああ！すいません。
907 ：Dream ★ ：02/03/27 02:13 ID:???: >>904
http://pc.2ch.net/test/read.cgi/software/1017161683/10

このあたりでお許し下さい。
908 ：Dream ★ ：02/03/27 02:15 ID:???: >>903
そうなんですか？
対策効いて沈静化したのか、攻撃終わって沈静化したのか
わかりませんでした。
909 ： ◆JOKESIZE ＠JOKESIZE ★ ：02/03/27 02:15 ID:???: どなたか批判要望板の容量を教えてください。
１０００行く前に１０２４ｋの制限でdat落ちする可能性がおおいので
長文レスが多いもので、、、って漏れか（ｗ
910 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:20 ID:???: >>909
このすれも300kも全然いってないから大丈夫
911 ：Dream ★ ：02/03/27 02:24 ID:???: >>910
こっちあげでいって、９５０くらいまで使いますですか？
わたし、いったんお休みいたします。
早めにスレ立てましてすんません。
912 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:31 ID:???: GickoBrowser修正改良版
Information

(2002/03/26)　暫定的にかちゅのUAを借りてsubject.txt取得するようにしました
913 ：西安 ◆CYANh33g ：02/03/27 02:33 ID:???: >>912
なんでかちゅ・・・・。
しかもそれって実質 kage の UA よね・・・。
914 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:47 ID:???: ◆hAnYaNVA さんじゃないけど、インターバルの件でどうしても納得いかない。

「インターバルを設ける理由」から
「巡回を不便にして巡回自体(回数/スレ数)を減らす」目的を除き
純粋に「複数のリクエストを送る必要がある」場合。

Keep-Aliveしたまま接続断を待つ/サーバーを待たせるのは論外とし、
同じサーバーに対してのconnectionは
一つに限定する(タブブラウザなどは複数？)場合、

本当に、
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
　connect-request-response-close
　-interval-
が、
　connect-
　　request-response-request-response-request-response
　-close
よりサーバーに優しいか、結論は出ているのかな？

詳しい条件等は全然知らないので、2chには当てはまらないかもしれないけど
Apache自体はKeep-Aliveの実装によって50%近く負荷が下がったらしい。
game鯖等が軽くなったのは、インターバルを設けた効果ではなく、
単にread.cgiのrawモードを不可にした効果に思えるのだけれど。
915 ：名無しさん＠お腹いっぱい。 ：02/03/27 02:47 ID:???: リクエストの集中が問題というかもしれないが、
仮にKeep-Aliveにしも、サーバーが処理するリクエストは、
各接続に対して同時に１つだけなのだから
接続要求の度にacceptすることを考えれば
Keep-Aliveしたままの方がトータルの負荷は少ないと思う。
そもそも、同時接続数が256では足りないような状態のサーバーに対して
単独のクライアントからのリクエストが連続しない程度で
負荷分散になるとはとても思えない。

それでも、Keep-Aliveにしたら次のリクエストを待つ間の
idleなconnectionが負荷を高める原因だと言うのならば、
リクエストをパイプラインして送ればいい。
　connect-
　　request+request+request - response+response+response
　-close
これならidleなconnectionも発生しないし、無駄なconnect/closeもない。
HEAD等の軽いリクエストを数十件まとめて送り
レスポンスにかかる時間を比較しすれば
サーバーが短時間で処理を完了して解放されるのがわかる。

どこか間違ってる？あるいは何か見落としてる？
916 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:18 ID:???: 話が追いきれてないけど、書いとく。
# 今は話がループしてるっぽいし。

●で認証を行うか、ツールで認証を行うかと聞かれれば、
私は●を進めますが。何故かというと
1.ツール認証はhttp内で行うには抜け道が多いから
2.●で認証は無料ユーザにも発行することができ、
　ココの負荷を把握することができるから。
の二点が理由なんですが。

●の発行で無料用の話って出てないよね？
917 ：Dream ★ ：02/03/27 03:28 ID:???: 【２ちゃんねるビューア】　巡回機能の巻。Part3
http://pc.2ch.net/test/read.cgi/software/1016905060/l50
でいま、２ちゃんの負荷低減とかを話してます。

ところで、２ちゃんねるはいま、htaccessを使ってRewriteCondをつかい、
各ツールなどにdatなどを供給している訳なのですが、
「httpd.conf」に一本化し、htaccessを一切使わないようにすれば、サーバの負荷低減がはかれる、
というお話をなさった方が居られました。
お聞きしたいのは、この方法をに変えると、どのくらい負荷が低減するのか？
といった、見積もり的な試算は可能なのか？ということと、
具体的に、これを裏付けるベンチマーク結果などは、存在するのか？
という２点です。
もし、おわかりの方、この問題に詳しい方が居られましたら、上記スレッドで
お話をいただければと思います。
よろしくお願いします。

マルチポストしてきました。うざくてすんません。
918 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:40 ID:???: スレが立てられない。
だれか2ちゃん専用ブラウザ「かちゅ～しゃ」Part588を立ててくれ。
http://pc.2ch.net/test/read.cgi/win/1017034701/904
919 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:47 ID:???: >>917
>>314
できもしないこと話してどうするんですか?
920 ：Dream ★ ：02/03/27 03:52 ID:???: >>919
はい。
劇的に効果があるんだったら、再度提案してみたいし、もし、
劇的に効果があるなんて言えない内容だったら、もう忘却してしまったらいいかと思っただけです。
921 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:54 ID:???: >>917を夜勤に無理強いする。

負荷軽減を要望するが、変化を望まない夜勤がボトルネック。
922 ：名無しさん＠お腹いっぱい。 ：02/03/27 03:57 ID:???: >>920
今すぐ忘却してしまっていいと思います。
923 ：918 ：02/03/27 03:59 ID:???: Dream ★さんスレ立てありがとうございます。
でもソフトウェア板…

283KB

新着レスの表示

スレッドリストへ戻る全部前100 次100 最新50

0ch BBS 2004-10-30