最近、Golang を使って TCP 通信プログラムを書いていたところ、奇妙な Close エラーが発生したので、記録して共有します。
背景
私が作成した TCP 通信プログラムでは、Go 標準ライブラリの net パッケージを使用して、DialTCP 関数を介してサーバーに接続しました。通信が完了したら、Close メソッドを使用して接続を閉じます。ほとんどの場合、このプロセスは成功します。ただし、Close メソッドを呼び出すと、奇妙なエラーがスローされ、プログラムがクラッシュすることがあります。
エラーの説明
-Close tcp call error-
説明: ピアによってリセットされました`
エラー ログに表示され、Close メソッドを使用して閉じられました。接続すると、「ピアによるリセット」エラーが報告されます。これは、サーバーが接続を積極的に閉じていることを意味します。
トラブルシューティング
最初のステップでは、ソース コードをチェックし、Close メソッドを呼び出す前に接続が閉じられていないことを確認しました。 2 番目のステップでは、コードの観点から問題を分析し、コードの欠陥を除去します。
3 番目のステップでは、この問題を検索したところ、同様のケースが見つかりました。オープンソース コミュニティ Github では、多くの人が同様の問題に遭遇しています。これはオペレーティング システムの TCP 仕様の実装に問題があると考える人もいれば、ネットワーク カード ドライバのエラーであると考える人もいます。この情報を見た後、TCP プロトコルの仕様を確認したところ、確かに接続を閉じる操作を待機する TIME_WAIT 時間が存在することがわかりました。
具体的には、TCP 接続が閉じられた後、オペレーティング システムは、接続が完全に閉じられたことを確認するまで一定時間待機してから、関連リソースを解放します。この時間は通常 2MSL (最大セグメント存続期間) で、Linux のデフォルトは 60 秒です。この待機時間中に同じアドレスとポートを持つ新しい接続要求があると、RST セグメントがトリガーされ、相手が接続を早期に終了し、「ピアによるリセット」エラーが発生します。
それでは、この問題をどうやって解決すればいいのでしょうか?
解決策
この問題には 2 つの解決策があります:
Linux カーネルのパラメータを変更して、TIME_WAIT 時間を延長します。待機時間を長くすると、接続が完全に閉じられるようになります。もちろん、この延長期間中に、長期間 TIME_WAIT 状態になっているシステム内の接続の数も増加します。
接続を閉じるときは、SO_REUSEADDR オプションをオンにして、接続アドレスを再利用できるようにします。このようにして、接続が閉じられた後、次の新しい接続で元のアドレスを直接再利用できるため、「ピアによるリセット」エラーが回避されます。具体的な実装方法は次のとおりです。
conn, err := net.DialTCP("tcp", nil, tcpAddr) err = conn.SetReuseAddr(true) err = conn.Close()
概要
上記は、Golang を使用して TCP 通信プログラムを作成したときに遭遇した、奇妙な Close エラー ケースです。これは、TCP 仕様で要求される TIME_WAIT 時間により、接続がすぐに解放されないためです。待機時間を延長するか、SO_REUSEADDR オプションを有効にすることで、このタイプのエラーを回避できます。同時に、これは、ネットワーク プログラミングを行うときに、不要なエラーを避けるために TCP 仕様の詳細に注意を払う必要があることも思い出させます。
以上がgolang tcp クローズエラーレポートの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。