Backlogってなんぞや - ukinau's diary
はじめに サーバソフトウェアの設定ファイル等でよく見かける項目であるBacklogってどういう意味なんだろうと、少し調べたのでメモを残します。 Backlog apacheやnginx、memchachedなどのサーバ系ソフトウェアの設定ファイルの中で設定することが多い、このBacklogとは何なのかをここでは言及する。 サーバアプリケーションがlistenしているソケットがacceptしていない、確立済TCPセッションを何個までOS側で保持するかを定義したもの。 例えば、下記のようなサーバーアプリケーションがあるとする。 server.py import evenlet server_sock = eventlet.listen(('0.0.0.0', 6001),backlog = 1) new_sock, address = server_sock.accept() new_sock
Server::Starterに対応するとはどういうことか - limitusus’s diary
StarletやStarmanと組み合わせてよく使われているServer::Starterですが、普段気にしないような部分を読む機会があったのでメモ。 Server::Starterは --port (TCP) や --path (Unix Domain Socket) を渡すとこれでlisten(2)して起動するworkerに引き渡してくれる。 これはfork(2)とexec(2)によってファイルディスクリプタを引き継ぐことにより実現されているが、ファイルディスクリプタそのものをどのように引き渡しているのか、という問題。 exec(2)により実行バイナリは差し換わってしまうので、プログラム中の変数により引き継ぐことはできない。 Server::Starterではこれを環境変数SERVER_STARTER_PORTにより実現している。 おおよそ以下のような感じ。 FD = integer
[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority
前回の続き。 パケット自体を零さずに処理に入った後にSYNを落とすのは以下3パターン。 syncookie無効時にsynのbacklog(tcp_max_syn_backlog)が溢れている listenのbacklogが溢れている(3way-handshake完了後のaccept待ち接続) net.ipv4.tcp_tw_recycleの制限に抵触 で、今回問題になっていたのは最後のtcp_tw_recycleへの抵触だった。 現象として発生しうるのは、以下の条件をすべて満たす場合 サーバ側でnet.ipv4.tcp_tw_recycleが有効 TCPタイムスタンプオプションを使用 同一IPからの接続でセッションを跨ぐとセットされるTCPタイムスタンプの値が戻る場合がある 最後の条件が微妙だが、TCPタイムスタンプの値としてセットされる値は起動時を 起算時にしていたりと実装によって初期値
![[unix] Linux SYNパケット取りこぼし (2) 2007-05-21 - LowPriority](https://cdn-ak-scissors.b.st-hatena.com/image/square/264702d4cb37ced3c2fd5dda6a1368c235356862/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127119925553%2F17680117127119930188%2F1557218483)
TCP Fast Openを試してみる - milieuの日記
kernel3.8がリリースされてついにTCP Fast Openがクライアント、サーバサイド共に実装さた。カーネルのソースを見てみるとやはり結構な変更でpatchで2000行レベルらしく、これ仕事で実装したくないなーというかバグを出す自信があるというのが正直な感想だが、とりあえず動作概要ぐらいは知っておかないとまずいので遊んでみた。TCP Fast Openの認証？部分でAESを使うらしくSandy BridgeならAES-NIを使えばCPU負荷的に問題ないかとか調べたかったが、家で使用しているPCはCPUが残念ながらWestmereなのでそれは諦めた。動かすにあたりFedora18を用意しないと！と思いたちVM環境にインストール。そういえばFedora18がリリースされた当初はVMwareにインストールを試みたが失敗したという苦い記憶が蘇えったが、今回はVirtualboxだったおかげ
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 によってクローズ済みの場合、リセッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
