Webサービスのコンテキストでは、「TCP接続チャーン」という用語が使用されているのを見てきました。具体的には、 Twitterfinagleにはそれを回避する方法があります。それはどのように起こりますか？どういう意味ですか？
質問する
1920 次
1 に答える
9
この用語には複数の用途があるかもしれませんが、非常に短い時間内に多数の TCP 接続が確立され、クライアントやサーバーでパフォーマンスの問題が発生する場合に使用されるのを私は常に見てきました。
これは、何らかの種類の TCP 障害で自動的に接続するクライアント コードが記述されている場合によく発生します。この障害が、接続が確立される前 (またはプロトコル交換の非常に早い段階) で接続障害になった場合、クライアントは常に接続を行っているビジー状態のループに入る可能性があります。これにより、クライアント側でパフォーマンスの問題が発生する可能性があります。まず、CPU サイクルを消費する非常にビジーなループ内にプロセスが存在し、次に、各接続試行がクライアント側のポート番号を消費します。これが十分に高速になると、ソフトウェアはラップアラウンドできます。最大ポート番号に達したとき (ポートは 16 ビットの番号にすぎないため、これは確かに不可能ではありません)。
堅牢なコードを作成することは目的としては価値がありますが、この単純な「自動再試行」アプローチは少し単純すぎます。他のコンテキストでも同様の問題が見られます。たとえば、親プロセスが継続的に子プロセスを再起動すると、すぐにクラッシュします。これを回避するための一般的なメカニズムの 1 つは、ある種の増加するバックオフです。したがって、最初の接続が失敗すると、すぐに再接続します。短時間 (たとえば 30 秒) 以内に再び失敗した場合は、たとえば 2 秒待ってから再接続します。30 秒以内に再び失敗した場合は、4 秒間待機します。この手法の背景については、指数バックオフに関するウィキペディアの記事(このアプリケーションにはこのブログ投稿の方が適切かもしれません) を参照してください。
このアプローチには、クライアントやサーバーを圧倒しないという利点がありますが、クライアントが手動の介入なしで回復できることも意味します (これは、無人のサーバー上のソフトウェアや大規模なクラスター内のソフトウェアにとって特に重要です)。
回復時間が重要な場合は、TCP 接続作成の単純なレート制限も十分に可能です。ただし、サーバーごとに多数のクライアントが存在する場合、この単純化されたアプローチでは、高い接続レートを受け入れてから閉じるという負荷によってサーバーが圧迫されたままになる可能性があります。
指数関数的バックオフを使用する予定がある場合に注意すべき点 - 最大待機時間を課すことをお勧めします。そうしないと、長時間の障害により、サーバー側が接続の受け入れを再開した後、クライアントの回復に時間がかかりすぎることに気付くかもしれません。ほとんどの場合、妥当な最大値として 5 分程度をお勧めしますが、もちろんアプリケーションによって異なります。
于 2013-02-03T10:43:13.197 に答える