LinuxのTCP SYNの再送間隔の初期値が3秒から1秒に変更されていた - 元RX-7乗りの適当な日々
ということに、(今更？)気付いたお話です。 HAを組んだ際のVIPの切り替えテストをやっているときに、高負荷時とかは切り替えに7秒ぴったりかかるケースとかがあって、7秒って何の数字だろうと疑問を持ちました。 OSは、CentOS 6.4(2.6.32-358.23.2.el6.x86_64)です。 TCP SYNの再送間隔が、1...2...4...秒になっている で、tcpdumpを眺めていると以下のようなシーケンスです。 11:50:35.689301 IP client-host.8957 > server-host.http: Flags [S], seq 1616681830, win 14600, options [mss 1460,sackOK,TS val 889880946 ecr 0,nop,wscale 7], length 0 11:50:36.688503 IP
How TCP backlog works in Linux
When an application puts a socket into LISTEN state using the listen syscall, it needs to specify a backlog for that socket. The backlog is usually described as the limit for the queue of incoming connections. Because of the 3-way handshake used by TCP, an incoming connection goes through an intermediate state SYN RECEIVED before it reaches the ESTABLISHED state and can be returned by the accept s
TCP Slow Start と MSS, initcwnd などのメモ
現実的な値と根拠など Slow Start などの例に良く出てくる数字の論拠と、個々の単位がどこで決まってくるかを主に取り扱う。というメモ。苦手科目だ。_:(´ཀ`」 ∠): Max Segment Size (MSS) の決定 この MSS がウインドウサイズ（一度に転送するデータサイズ）の単位として扱われる。（後述） TCP コネクションが 3-way handshake によって確立される際、ノード間で下記のような MSS に関するやり取りが発生する。 各ノードは Maximum Transmission Unit (MTU) から TCPヘッダ20バイト、IPヘッダ20バイトの計40バイトを引いた値を MSS として提示する 各ノードの希望 MSS のうち低い方を、そのコネクションにおける MSS とする たとえばイーサネットでは最大1,500バイト（オクテット）がIP通信に利用で
TCPカーネルパラメータによる障害復旧時間の短縮 - GeekFactory
クラスタ構成のサーバでは、障害発生後にクライアントがすぐに復旧しない場合があります。サーバ側がフェイルオーバした後にクライアント側が再接続するまでの時間を短くする方法を紹介します。 クライアントからサーバに接続するとソケットはESTABLISHEDになります。もしESTABLISHEDになったソケットで正しくパケットが送信されなかった場合、OSは再送を試みます。再送に失敗してソケットをクローズするまでの時間はOSの設定によります。 OSがTCP接続の異常を検知してからクローズするまでの時間を短くするには3つの方法があります。 パケットの再送回数を少なくする。 TCPレイヤでKeep Aliveパケットを送信する。この方法はTCP Keep Aliveに対応しているアプリのみ可能。 アプリケーションレイヤでKeep Aliveパケットを送信する。この方法はNullパケットを投げる等に対応して
tcpflow -- TCP Flow Recorder
tcpflow -- A TCP Flow Recorder Note: I am no longer actively maintaining tcpflow. This page has the most recent version I released personally. Maintenance has been taken over by Simson Garfinkel, who distributes new versions at his site. Downloads and Documentation The most recent version of tcpflow is v0.21, released 7 August 2003. You can also see the history of previous releases. There is an HT
TCP Tune
Enabling High Performance Data Transfers System Specific Notes for System Administrators (and Privileged Users) These notes are intended to help users and system administrators maximize TCP/IP performance on their computer systems. They summarize all of the end-system (computer system) network tuning issues including a tutorial on TCP tuning and easy configuration checks for non-experts. Introduct
[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サーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
