Pound が Header Buffer を 2KByte しか確保しない不都合
本業の Web サーバの構成について以前書いた記憶もあるのですが、Lighttpd や Apache2 の mod_proxy が流行る前に構築したこともあって、ちょっとだけ Pound が流行った？時によくある構成で組んでます。ザックリ図にしてみると な感じになっています。で、前から薄々気がついてはいたのですが、この構成、致命的な欠陥があるんです。 その欠陥とは、pound の HTTP リクエストのヘッダ処理の実装にあります。pound のソースは適当にしか読んでいないので、間違ってる可能性もありますが、図にするとヘッダーのサイズ最大値の処理がこんな感じになっています。 ヘッダーの中でサイズが大きいと言えば、Cookie しかないですね。その Cookie に関しては RFC 2109 （set-cookieについて）と RFC 2965 （set-cookie2について）で定められて
Pound の SSL セキュリティレベルを制限（上げる）方法
最近、会社のセキュリティーレベルを上げるべくいろいろな活動がされています。で、最近きたお達しが、Web サーバの SSL の暗号レベルの強化。具体的に言うと、今となっては時代遅れな SSLv2 を許可せず、SSLv3 にすると言うもの。そして、暗号強度の弱い暗号化を許可しないという２点です。 普段、SSL のレベルなんて気にしてネットをやっている方は数少ないと思いますが、IE や FireFox のオプションで指定可能です。例えば、IE だとこんなかんじです。 通常、SSLv2 にチェックがついていると思います。ここで、SSLv2 のチェックを外せば、より暗号強度の強い暗号方式をサーバ側に要求して SSL 通信をすることができます。 クライアント側の設定はこれで完了ですが、サーバ側も当然ながら設定が必要です。 デフォルトの設定（何も設定しない場合）で許可される暗号方式 通常の場合、サーバに
[ロ] ロードバランサ Pound のセッショントラッキング – LOWTECH.NE.JP
Poundでセッション保持もできるということで、どこまでできるのか調べてみた。 用途としては、osCommerceの改造版であるOpenBazaarをこれまたずいぶん改造した 自製ショッピングカートでの負荷分散を実施したいなぁというのが動機です。 以下の情報を発見 5.1 Can I have session tracking based on URL and/or Cookie? Pound can track sessions based on client IP address, a cookie, an URL parameter or BasicAuthentication. These options are mutually exclusive – only one of them can be used per UrlGroup. クライアントIPアドレス、Cookie、U
Poundで作るロードバランサとSSLラッパ（1/4） ― ＠IT
Webサーバの負荷を軽減する方法として、リバースプロキシによる代行とロードバランサによる分散が考えられる。今回は、これらによる負荷の低減方法について解説する。（編集部） Apache自体のチューニングによる性能向上には限界があります。よりパフォーマンスを求めるなら、次にやるべきことはメモリの追加や高性能なCPUへの交換など、ハードウェアの見直しです。しかし、それにも限界があります。 リバースプロキシとロードバランサ ハードウェア単体による性能向上が限界に達した場合は、サーバ構成の見直しを行います。まず考えられるのが、リバースプロキシをWebサーバの前面に立ててクライアントからのアクセスを肩代わりさせる方法です。Webサーバがボトルネックになるのを防ぐとともに、セキュリティ向上にも寄与します。 もう1つの方法は、より高可用性を意図した構成として負荷の分散を図ることです。高可用性とは、サーバの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Output logs to file option for Pound
