TCPの再送タイムアウトを制御したい
TCPの再送タイムアウトで最近まで知らなかったことがあったのでメモ。 たとえば、APサーバとDBサーバがあるとする。 AP-DB間のDBCPで使うTCPコネクションは、DBサーバがノードダウンしたのであればさっさと再送リトライをあきらめて切れてほしいと思うのが普通だろう。 このTCPの再送リトライ処理は、何もいじらないと15分以上続くので、 できればTCPコネクション単位で細かく調整させてほしいと思うのは人情だと思う。 Linux の場合、昔はこの調整をしようと思うと、sysctl を使って /proc/sys/net/ipv4/tcp_retries2 の値を書き換えるしかなかった。 これは、リトライ回数でしか指定できず、そのリトライ間隔が回数ごとに変わっていく（長くなる）のでわかりにくい上に、そのOS上の全TCPコネクションで有効になってしまうという問題があった。つまり、このオプション
Manpage of TCP
Section: Linux Programmer's Manual (7) Updated: 2008-08-08 Index JM Home Page roff page 名前 tcp - TCP プロトコル 書式 #include <sys/socket.h> #include <netinet/in.h> #include <netinet/tcp.h> tcp_socket = socket(AF_INET, SOCK_STREAM, 0); 説明 これは RFC 793, RFC 1122, RFC 2001 で定義されている TCP プロトコルを NewReno 拡張と SACK 拡張を含めて実装したものである。 TCP は、 ip(7) 上の二つのソケット間に、信頼性の高い、ストリーム指向の全二重 (full-duplex) 通信を提供する。 v4 と v6 の両方のバージ
はやいTCPサーバの書き方 - nyaxtのPC作業ログ
cagra高速化にあたってのノウハウを一部公開してみます。また明日校正/更新します。つっこみ待ちです。 select(2)の代わりにepoll_wait(2), kqueue, /dev/epoll等を使う 他に山ほど解説ページがあるので略 大量のディスクリプタを処理するようなサーバの場合、多少効果があるかもしれません。しかし、クライアント数が少ない場合、劇的な性能の向上は見込めないとおもいます。クライアント数が多い場合は、１セッション１スレッドなモデルではOS側のタスクスイッチングのオーバーヘッドが効いてくることも多いです。クライアント数を増やすには複数のセッションを１スレッドで処理できるようにすると良いです。実装にあたっては、non-blocking ioを活用すると効果的です。 TCP_NODELAYを設定する Nagleアルゴリズムをオフにします。多少応答性が良くなります。 これっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
富士通研究所、ソフトウェアだけで通信性能を大幅に改善する新技術を開発
