TCP congestion control - Wikipedia
Transmission Control Protocol (TCP) uses a congestion control algorithm that includes various aspects of an additive increase/multiplicative decrease (AIMD) scheme, along with other schemes including slow start[1] and a congestion window (CWND), to achieve congestion avoidance. The TCP congestion-avoidance algorithm is the primary basis for congestion control in the Internet.[2][3][4] Per the end-
kernel: TCP: time wait bucket table overflow の解消とTIME_WAITを減らすチューニング - 気ままにインフラエンジニア
整理がてら。 httpdが動いているあるホスト上で、 /var/log/messages に以下のようなメッセージが出ていた。 kernel: TCP: time wait bucket table overflow kernel: printk: 50078 messages suppressed. "netstat -tna |grep TIME_WAIT"すると、10万以上の数でTIME_WAITが出ている。これを解消するまでの流れ。 そもそもこの値は、カーネルパラメータの net.ipv4.tcp_max_tw_buckets で設定されている。デフォルトは16384。 （↑の通り、エラーが出た環境では既にかなり大きな値が設定されていたのだが。） /proc/sys/net/ipv4/tcp_max_tw_buckets システムが同時に保持する time-wait ソケットの最大
TCP/IP Time_Wait の時間について | old_3流プログラマのメモ書き
netstat -an で現在のセッション情報が見えるわけですが、とある Windows サーバでかなり TIME_WAIT が発生してました。 netstat のステータスで LISTENING が待ちうけ中、ESTABLISHED が通信中(コネクション確立)ってのは知ってたんですが、TIME_WAIT ってのはよくわかってなかったので調べてみました。 ということで、まずTCPでのコネクションの確立と切断処理を＠IT：連載 基礎から学ぶWindowsネットワーク 第16回 信頼性のある通信を実現するTCPプロトコル(3)で確認します。 ↑には分かりやすい状態遷移図があるので非常に参考になります。 これを見ると TIME_WAIT というのはコネクションのアクティブクローズ時(自身から切断要求時)に、コネクションしてたのと同じポートが再利用されないための待ち時間のようです。 この待ち時間
TCP/IP - TCP 3ウェイハンドシェイク
◆ TCP - コネクションの確立と切断 TCPはコネクション型プロトコル（通信相手の応答があってはじめて通信を開始する）であることから、 データ転送を行う前にコネクションの確立を行います。このTCPにおいて使用されるコネクションの確立 のことを3ウェイハンドシェイクといいます。以下の手順の通り “3回のやりとり" によって確立されます。 ① ホストAからホストBにコネクション確立の要求をします。つまり、TCPヘッダの中にあるSYNビットは 「1」でありACKビットが「0」であると分かります。シーケンス番号は最初だけはランダムな値が割り当て られます。今回は例として「0」とします。確認応答番号(いわゆるACK番号）は通信の開始にはありません。 ② ホストBはホストAのコネクション要求に応えます。そしてホストBからもコネクション確立を要求します。 つまりSYNは「1」ACKは「1」であること
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
