Changing the TCP RTO value in Linux
The reason you can't alter the RTO specifically is because it is not a static value. Instead (except for the initial SYN, naturally) it is based on the RTT (Round Trip Time) for each connection. Actually, it is based on a smoothed version of RTT and the RTT variance with some constants thrown into the mix. Hence, it is a dynamic, calculated value for each TCP connection, and I highly recommend thi
Linuxカーネルの「TCP_TIMEWAIT_LEN」変更は無意味？
小崎 資広 (KOSAKI Motohiro) @kosaki55tea . @sonots から日本のWeb界隈ではTCP_TIMEWAIT_LEN を変更してカーネルリコンパイルがデファクトという話を聞いて軽くぐぐってみたところ、たしかに大量にそのようなページがヒットする。しかもどれ一つとして理由が書いてない。そして日本特有の現象 2015-09-09 00:03:14 小崎 資広 (KOSAKI Motohiro) @kosaki55tea 軽くソースを見た感じだと、tcp_tw_reuse をセットすると１秒で TIME_WAITのsocketは再利用が始まるので、いまひとつリコンパイルの必要性が分からず。これ、ソース呼んで妥当性チェックした人がいるノウハウなのかなあ 2015-09-09 00:04:39
LinuxのTCP輻輳ウィンドウサイズやスロースタート閾値のキャッシュを無効化する – ビットログ
TCP通信の状態を監視していたところ、スロースタート閾値の初期値が、カーネル内で定義されている初期値と異なっていることがありました。調査したところ、Linuxに実装されているtcp_metricsが原因でした。本記事では、tcp_metricsの無効化方法について説明します。 Linuxカーネル2.6.6以降のTCP通信にはtcp_metricsという機能があります。tcp_metricsは、スロースタート閾値や輻輳ウィンドウサイズ、RTTといったTCP情報を送信先IPアドレスと関連付け、TCPコネクション終了時にキャッシュします。そして、キャッシュされた送信先IPアドレスへTCPコネクションを開始する時に、キャッシュしたTCP情報をその通信の初期値に設定します。 送信先IPアドレスのTCP情報をキャッシュすることで輻輳を防ぐことができる機能ですが、例えばiperfなどを使ってスループット
TCP再送タイムアウト時間の規格と実装 - co1row’s diary
先日、アンドリュー・タネンバウム先生のコンピュータネットワーク第5版を読んでいると気になる記述が出てきた。 曰く、TCP再送タイムアウト時間（RTO）は下記の式で求められる。 RTO = SRTT + 4 * RTTVAR SRTTとは平滑化したRTT値、RTTVARとは標準偏差…ではなく平均偏差（計算の簡略化のため）である。単にRTT値だけを元にタイムアウト時間を設定してしまうと、RTT値のブレが大きいときに不要なタイムアウトが発生しやすくなる。なので平均偏差も足しましょう…それも4倍もしておけば、いくらなんでもパケットが到達して相手が生きているならば応答が返ってくるはずだろう、と。そういう式である。OK、話はわかった。 しかし信じがたい記述が続く。 再送タイマー最小値は1秒となっている。これはスプリアス再送を防ぐために選ばれた値である。 本当だろうか？だったら計算なんてする必要はない。
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
Red Hat Enterprise Linux 7.1でもssコマンドは腐っているので使い物にならない - ろば電子が詰まつてゐる
以前、CentOS 7 (7.0.1406)およびRed Hat Enterprise Linux 7のssコマンドが腐っていたことにビックリして、「ssコマンドはバグと地雷の塊なのでnetstatの代わりにならない」という記事を書きました。 これはどういうお話かと言うと： RHEL 7からはnetstatコマンドなどが収録されているnet-toolsパッケージが非推奨となり、デフォルトではインストールすらされなくなりました。 しかしnetstatコマンドの代替であるssコマンドはかなり雑な感じで、UDPポートを「tcp」と表示するひどいバグがあります というお話でした。 このssコマンドのバグは、2014年2月にRed Hat Bugzillaにも上がっていました。 https://bugzilla.redhat.com/show_bug.cgi?id=1063927 というわけで、さす
TCPの再送タイムアウトを制御したい
TCPの再送タイムアウトで最近まで知らなかったことがあったのでメモ。 たとえば、APサーバとDBサーバがあるとする。 AP-DB間のDBCPで使うTCPコネクションは、DBサーバがノードダウンしたのであればさっさと再送リトライをあきらめて切れてほしいと思うのが普通だろう。 このTCPの再送リトライ処理は、何もいじらないと15分以上続くので、 できればTCPコネクション単位で細かく調整させてほしいと思うのは人情だと思う。 Linux の場合、昔はこの調整をしようと思うと、sysctl を使って /proc/sys/net/ipv4/tcp_retries2 の値を書き換えるしかなかった。 これは、リトライ回数でしか指定できず、そのリトライ間隔が回数ごとに変わっていく（長くなる）のでわかりにくい上に、そのOS上の全TCPコネクションで有効になってしまうという問題があった。つまり、このオプション
ネットワークの状況を確認するコマンド色々 | DevelopersIO
なんで相手に繋がらないの！？ サーバ管理していてよく起こる問題は、「なんで繋がらないの！？」ですよね。そこで、今回は基本的なネットワークをご紹介したいと思います。OSやツールのバージョンにより動作が異なりますので、それぞれ調べてみて頂ければと思います。今回は、Amazon Linux 2015.03を用いています。 ping 基本はpingですね。ICMPのにあるエコー要求/応答のpingを使って接続確認を行います。 $ ping yahoo.co.jp PING yahoo.co.jp (182.22.59.229) 56(84) bytes of data. 64 bytes from f1.top.vip.ssk.yahoo.co.jp (182.22.59.229): icmp_seq=1 ttl=54 time=4.84 ms 64 bytes from f1.top.vip.s
4.4. TCP_NODELAY と小さなバッファ書き込み
TCP (Transmission Control Protocol) で簡単に説明したように、デフォルトでは TCP は Nagle アルゴリズムを使用して小さな送信パケットを収集して一度にすべてのパケットを送信します。 これにより、 レイテンシに悪い影響が出ることがあります。
xinetd の設定
■はじめに 今回は、スーパーサーバーと呼ばれる xinetd の設定方法について説明していきます。スーパーサーバーとは、ポート監視用のデーモンプログラムで、あるポートに対してアクセスがあると、設定ファイル (/etc/xinetd.d/ 等) を元にポートに対応したサービス (ftp 等) を起動します。この際、ポートとサービスの関係は、/etc/services によって導かれます。 そして、Linuxでは、以前は、inetd と TCP wrapper(tcpd) の組合せによるアクセス制限が一般的に行なわれてきました。しかし、RedHat Linux 7Jより、inetd の上位互換性を持つ xinetd が標準となり、最近では、多くのディストリビューターが採用するようになりました。 xinetd は、単体で inetd + TCP wrapper(tcpd) の機能を持っているだけ
何か決めなきゃ駄目ですか。 Linuxのbacklogについて
少しだけ突っ込んだ話。 （曖昧さは人間の脳内補完に委ねるとして･･･。） LinuxにはTCPの3Wayハンドシェイク（即ち、SYN,SYN/SCK,ACK）状態保持に関連して、 次のようなパラメータを持っている。 net.ipv4.tcp_max_syn_backlog=1024 何それ？って人は # sysctl -a | grep tcp 等のコマンドで探します。 # sysctl -a | grep backlog？それじゃノイズが無さすぎて面白くｎ(ry これは、「LinuxがSYNを受信し、SYN/ACKで応答した状態をいくつ保持するか」というもの。 閾値を超えると、Linuxは新規に接続しようとするホストのリクエスト（SYN）を無視する。 最近のLinuxを、最近のハードウェアにとりあえずインストールすると、 初期値は上記のような1024とか言う数値になっていると思う。 利用
socat を使う (シリアル-TCP変換, etc.) [MA-X/MA-S/MA-E/IP-K Developers' WiKi]
// Examples for using socat (and filan) //"$" means normal user, "#" requires privileges, "//" starts a comment /////////////////////////////////////////////////////////////////////////////// // similar to netcat // connect to 10.1.1.1 on port 80 and relay to and from stdio $ socat - TCP:10.1.1.1:80 # similar to "netcat 10.1.1.1 80" // listen on port 25, wait for an incoming connection, use CR+NL
相手がいないのに ESTABLISHED になってる TCP ポート - tmtms のメモ
最近 ParallelServer というライブラリを作ったのですが、その最中に奇妙な状態になってる TCP ポートを見つけたので、メモっておきます。 Ruby では TCP サーバーは次のような感じで作ることができます。お手軽ですね。 require 'socket' Socket.tcp_server_loop(12345) do |socket, client_addr| socket.puts "Your IP address: #{client_addr.ip_address}" name = socket.gets socket.puts "Hello, #{name}" socket.close end これは 12345 ポートでクライアントからの接続を待ち、接続されたらクライアントのIPアドレスとクライアントからの入力をクライアントに送信して切断するだけの簡単なプログラム
socat - ソケットリレーツール (proxy) - Tomorrow is always fresh with no mistake in it.＠備忘録
SCTPという、TCPとUDPのよいとこ取りをしたようなプロトコルがある。「SCTP（ネットワーク通信）」に書いたとおり、echoサーバを作成したが、動作確認のためにクライアントが必要になった。 telnetなどのTCP用のツールは使えないので、クライアントのプログラムも作成したが、もっと簡単にためせるツールがないかと思っていたら、「socat」というコマンドを見つけた。 netcat（nc）（「netcat - ネットワーク万能ツール」を参照）をさらに機能強化して、これでもかというくらいいろいろオプションが指定できるようになっている。 あろうことかnetcatでは封印されているコマンドの実行も可能になっている。
Delayed ACK - Cube Lilac
これも研究関連で，遅延ACK（Delayed ACK）を無効にした状態でデータ通信をする必要がありまして． 今まではFreeBSDのPCで実験を行っていたのでsysctlで一発で無効にできたのですが，Linux系ではどうやらその方法では無理な模様． それで，JM projectで調べた所どうやらsetsockopt()を用いてquickackモードを有効にすれば良いらしいとの事なので，早速コードを修正して走らせて見たのですが・・・tcpdumpで見てる限り，思いっきり遅延ACKが動作してるぽいんですよね． 試行錯誤したところ，結局↓の説明が曲者だったようで・・・ TCP_QUICKACK 設定されていると quickack モードを有効にし、クリアされると無効にする。通常の TCP 動作では ack は必要に応じて遅延されるのに対し、 quickack モードでは ack はすぐに送信され
Note - 遅延ACKオプションに関するメモ
研究に関連する実験で，遅延ACK(Delayed ACK）オプションを無効にした状態で， データ通信をする必要があったのですが，その時に陥ってしまった事例． 今まではFreeBSDのPCで実験を行っていたため，sysctlで簡単に無効にすることができたのですが， どうやらLinux系ではその方法では無効にできないようです．そこで， JM Projectで調べたところ，setsockopt()を用いてquickackモードを有効にすれば良い， という記述を発見したので，早速コードを修正してテストしてみたのですが・・・tcpdump で観察している限り，遅延ACKオプションは有効になったままの様子． 試行錯誤した結果，どうやら以下の記述が問題となっていたようです． TCP_QUICKACK ・・・（中略）・・・ このフラグは永続的なものではなく、 quickack モードから/モードへ切り替え
ucspi-tcp
ucspi-tcp のインストール ucspi-tcp の以前のバージョンからのアップグレード tcpserver プログラム tcprules プログラム tcprulescheck プログラム argv0 プログラム fixcrio プログラム recordio プログラム rblsmtpd プログラム tcpclient プログラム who@ プログラム date@ プログラム finger@ プログラム http@ プログラム tcpcat プログラム mconnect プログラム addcr プログラムと delcr プログラム TCP 環境変数 それは何か？ tcpserver と tcpclient は TCP クライアント・サーバ・アプリケーションを構築するための使いやすいコマンドラインツールです。 tcpserver は入ってくる接続を待ち、各々の接続に対して、好みのプロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TCP の再送タイムアウト (RTO) (November 2, 2006)
https://github.com/hiboma/hiboma/blob/master/%E5%90%84%E7%A8%AE%E3%83%84%E3%83%BC%E3%83%AB%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%A0%E3%82%A2%E3%82%A6%E3%83%88%E5%AE%9F%E8%A3%85%E3%81%BE%E3%81%A8%E3%82%81.md
RSTを受信したときの挙動: じーくゎい