WEBサーバのTCPコネクション数に上限はあるのか？ - Qiita
はじめに アクセス数がすごい環境は大抵高負荷環境でもあるので対策としてApacheの設定やサーバ構成のセオリーをすぐ見つけられて実際試しても目に見えて良くなります。 アクセス数の多さで起こる問題は実際に負荷をかけてみないと表面化しません。 問題が分かったら設定やパラメータを調整して現状がましになるようにするだけです。 ですが限りあるリソースの中でTCPセッションを十分にコントロールしようとするとすぐ手詰まりです。 WEBサーバがしているやりとりの基礎が足りていないそんな気がしていたのでTCPに目を向けてみました。 行き着いた結果は 待ち受け側とリクエスト側ではボトルネックが違う リクエスト時はTCPのエフェメラルポートが上限 待ち受け時はTCPよりもファイルディスクリプタが上限 になりやすい という良く見かける設定を見直すということになりましたが、どうやってそうなっているのかが今回の成果だ
TCPカーネルパラメータによる障害復旧時間の短縮 - GeekFactory
クラスタ構成のサーバでは、障害発生後にクライアントがすぐに復旧しない場合があります。サーバ側がフェイルオーバした後にクライアント側が再接続するまでの時間を短くする方法を紹介します。 クライアントからサーバに接続するとソケットはESTABLISHEDになります。もしESTABLISHEDになったソケットで正しくパケットが送信されなかった場合、OSは再送を試みます。再送に失敗してソケットをクローズするまでの時間はOSの設定によります。 OSがTCP接続の異常を検知してからクローズするまでの時間を短くするには3つの方法があります。 パケットの再送回数を少なくする。 TCPレイヤでKeep Aliveパケットを送信する。この方法はTCP Keep Aliveに対応しているアプリのみ可能。 アプリケーションレイヤでKeep Aliveパケットを送信する。この方法はNullパケットを投げる等に対応して
CLOSE_WAITのセッションを早く消す方法 - つれづれなる・・・
原因はおそらくwebサーバ〜DBサーバ間のセッションがネットワーク的に不安定だったからだと思うけど、DBサーバで netstat -an すると 大量の CLOSE_WAIT のセッションが残ってしまって、MySQL の最大コネクション数にまで達してしまってwebの表示が出来なかった。CLOSE_WAIT をいきなり消すことは出来ないので、早めに消えるようにしたいときは tcp_keepalive_time TCPセッションが確立されて検査が実施されるまでの時間 時間になると tcp_keepalive_intvl と tcp_keepalive_probes の値にしたがって検査を実施する tcp_keepalive_intvl 次の検査を実行するときの待ち時間 tcp_keepalive_probes 検査の回数のそれぞれの値を小さくしてあげればよい。変更方法は vi で :wq する
Stomp - Protocol
Stomp Protocol Specification, Version 1.0 Initially the client must open a socket (I'm going to presume TCP, but really it is kind of irrelevant). The client then sends: The ^@ is a null (control-@ in ASCII) byte. The entire thing will be called a Frame in this doc. The frame starts with a command (in this case CONNECT), followed by a newline, followed by headers in a <key>:<value> with each head
2007-03-31
相手のアプリケーションがcloseして、こちらのアプリケーションがcloseせずにいる場合(ハーフクローズの状態、上の図参照)、一定時間後に相手側のFIN_WAIT2と、こちらのCLOSE_WAITが消えた。この現象は、2つのタイマーが関係しているらしい。 http://www.linux.or.jp/JM/html/LDP_man-pages/man7/tcp.7.html FIN_WAIT2は、 tcp_fin_timeout でタイムアウトする。デフォルトは60秒。 CLOSE_WAITは tcp_keepalive_time 秒後に(デフォルトは2時間)、接続が有効かどうかを確認する(keep-aliveプローブを送信)。 相手側がFIN_WAIT2で待っている場合は、ACKが返ってきて接続が維持される。 相手側が tcp_fin_timeout によってクローズ済みの場合、リセッ
TCPにウェブサイトを危険にさらす脆弱性--スウェーデンの研究者が発見
スウェーデンの2人の研究者が、悪用されると大規模なサービス拒否攻撃につながる可能性があるTCPの脆弱性を複数発見した。今のところ回避方法はなく、修正プログラムも提供されていない。 TCPスタックでは、どのコンピュータがネットワークで通信できるかを決めるルールが定義される。Outpost24の最高セキュリティ責任者（CSO）であるRobert E. Lee氏はCNET Newsに対し、「私たちが話し合っているベンダーはこの脅威を深刻に受け止めているようだ」と述べた。 Lee氏と主任セキュリティ研究員であるJack Louis氏が作成した「UnicornScan」という名前のポートスキャナを使ったテストで、脆弱性が発見された。このツールは、Outpost24での脆弱性評価および侵入テストに使われている。Lee氏はスウェーデン語のポッドキャストで、ルールでは、ポートスキャンが短時間で終わらない場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
