Javaのインタビュー - TCP接続とその最適化

-サーバーを最適化する際、バックエンドプログラマとして、ネットワーク接続が周りのカットの作品ですが、あなたがやっている時に最も基本的な部分でのネットワーク接続のように、ネットワークの最適化は、また、リングの一つであるTCP连接あなたが知っていますか？今日は、このセクションで詳しく見ていきます。

TCP接続が確立されている - スリーウェイハンドシェイクを

詳しいです

スリーウェイハンドシェイク

クライアントとサーバーの接続が確立されていないが、サーバーは、一般的にあるlisten状態
クライアントが積極的に、接続されたサーバへのSYNパケットを送信し、クライアントはなりSYN_SENT状態
サーバーは、クライアントから送信されたメッセージを受信するだけでなく、ACKを含んでいるSYNパケットをバックアップ。この場合、サーバは変更SYN_RCVDの状態を
クライアントは、サーバにACKパケットを送信し、ACKを確認するために、サーバーから送信されたSYNパケットを受信します。この場合、クライアントはなりESTABLISHED
サーバーはACKを確認し、クライアントのACKパケットを受信します。この時点で、サーバーもなり、ESTABLISHED
サーバーとクライアントとの通信が可能

2〜4のステップは、3ウェイハンドシェイクである、そしてなぜそれが3ウェイハンドシェイクを必要としているのですか？なぜ一度か二度、それ握手をしませんか？

まず第一に、私たちは、サーバとクライアントが通信のネットワークが成功するために、その彼らのメッセージを確実にし、メッセージを受信することができることができた場合にのみ知っている必要があります。

役割のステップ2は、サーバがメッセージを受信することができ、彼があることを知らせることです。

ステップ3は、クライアントの役割は、メッセージの送受信がOKであることを知るようにすることです、そしてサーバーが返す介してメッセージを送信する機能ack=x+1、メッセージが、元のクライアントの値に基づいて送信されるため、確認しましたseq=x。サーバが返したため、メッセージを受信する機能が受信されます。

ステップ4は、サーバーの役割がメッセージを送信する能力がOKであることを知るようにすることです（と同様のステップ3）。

linuxの表示

Linuxサーバを使用することができnetstat -anp | grep tcp、サーバおよびアプリケーションの各ポートの接続状態を確認するコマンドを。

また、設定ファイルのlinuxを変更することができ/etc/sysctl.conf、各状態の数を調整します

`SYN_SENT`ステート関連

積極的に接続されたとき、SYNは（ステップ2）試行回数を送信しました

nct.ipv4.tcp_syn_rctries = 6

ローカル接続ポート利用可能な範囲を確立します

net.ipv4.ip_local_port_range = 32768 60999

`SYN_RCVD`ステート関連

SYN_RCVD接続状態の最大数

net.ipv4.tcp_max_syn_backlog

パッシブ接続が確立され、再試行回数をSYN / ACK（ステップ3）を送信します

net.ipv4.tcp_synack_retries

次に、TCPコネクションのプロセスが確立され、そして、私たちが切断通常のTCPを見てみましょう

TCP切断 - 四手を振って

詳しいです

手を振っ四

クライアントとサーバー側の通常のデータ転送
クライアントがサーバにFINパケットを送信する、接続を中断し、クライアントが変更FIN_WAIT1状態を
FINサーバはクライアントがクライアントにACKパケットを送信し受信すると、サーバは変更CLOSE_WAITの状態を
クライアントはACKパケットサーバを受け取った後、クライアントはなりFIN_WAIT2状態
サーバからクライアントに送信されたFINメッセージは、サーバーになりLAST_ACK状態
クライアントは、サーバーから送信されたFINパケットをサーバにACKパケットを送信し受信した後、クライアントが変更TIME_WAIT状態を
サーバーがクライアントのACKパケットを受信した後、サーバはなりCLOSED状態
2MSL介してクライアント（最大セグメント寿命、パケットの最大生存時間）時間、またなった後CLOSEDの状態

前記の4倍である2,3,5,6-波のステップ。

`TIME_WAIT`その改善

それを読んだ後、私はあなたがなぜ質問、持っていると信じていますTIME_WAIT状態は2MSLを維持する必要があるの？それは、パケットの往復時間に少なくとも一度ことを保証しているため、ポートを再利用することはできません。

仮定すると、TIME_WAIT状態の継続時間が非常に短い、我々は以下のこのシナリオをシミュレートする必要があります。

クライアントは、ネットワークカードの資料3つのパケットは、サーバは、最初の2つだけ受信した前記サーバ、単一のACK = 2クライアントは、第3のメッセージを再送信し、クライアントに送信する3つのパケットを送信します。
サーバは、クライアントがFIN、ACKを受信した後に送信されたFINパケットを送信し、ACKが送信され、サーバが受信入射するTIME_WAIT状態（状態が非常に短いと仮定します）。
ここでもう一度、サーバーとクライアントが詰まった、第3のメッセージの前に、通常の3ウェイハンドシェイクの後に結果をデータの送信を開始するための接続を確立するために、そして今、最終的にはサーバーに送信されますが、サーバーは、このメッセージに対処する方法を知りません。

だから、これはTIME_WAITあまりにも長い間メッセージを受信しなかった場合、クライアントから送信された正しいメッセージが、期限切れになった場合でも、2MSLの理由を維持する必要性の状態は、それ以降の通信には影響を与えません。

しかし、それはまた問題をもたらす、TIME_WAIT状態を維持するために長い時間が、サーバー側の数が多いことを想定しTIME_WAITたTCP接続の状態は、同等のは、サーバのリソース（ポート）の多くを無駄にしました。この時点で、我々を調整することができ、以下の設定を変更することによって、サーバー：

net.ipv4.tcp_tw_reuse = 1

オンにすると、新しい接続を使用することができ、クライアントはまだあるTIME_WAITポートのステータス
タイムスタンプが存在するため、オペレーティングシステムは以下の構成を使用して、（例えば、上述した第3のメッセージを前記）遅いパケットを拒否することができます。

net.ipv4.tcp_timestamps = 1

その他の状態を最適化

`CLOSE_WAIT`状態

サーバが多数ある場合はCLOSE_WAIT、接続の状態を、アプリケーション・プロセスは接続を閉じなかった、最も可能性の高いバグを表示されます。

`FIN_WAIT1`状態

8 0に相当FINパケットを送信する再試行の回数を調整します

net.ipv4.tcp_orphan_retries = 0

`FIN_WAIT2`状態

維持するように調整FIN_WAIT2時間の状況を

net.ipv4.tcp_fin_timeout = 60

概要

確かに一般的な理解へのTCP接続を持っている必要があり、ここを参照してください。今、ほとんどの負荷分散を行うためにnginxのサーバーを使用し、したがって、私たちはこの原則に基づいて、関連する構成のnginxのいくつかを知っている必要があり、これは当社のサーバーのパフォーマンスチューニングは、より多くの助けがありますする必要があります。興味のある学生は、そこに新たな発見があると著者は議論したい場合は、以下のコメントを残してください見つけるために行くことを望むかもしれません。

私の公共の番号を追跡することができます興味を持っている、多分驚きがあるでしょう。

ここに画像を挿入説明