ロードバランサは、実行中のプラットフォームに基づいて同時に使用できるtcpポートにいくつかの制限を設けます（たとえば、Linuxは最大65535個のTCPポートを同時に開くことができます） 。これは、バランサがボトルネックになり、バックエンドサーバーファームがより多くの要求を同時に処理できる場合でも、多数の同時要求を超えてサービスすることができないことを意味します。この問題を克服する方法はありますか？ロードバランサのスケーラビリティと最大#tcpポート
TCPとUDPのポート番号は16ビットなので、特定のIPには65535個しかありません（ポート0は私が信じると無効です）。しかし、TCP接続は4タプル（送信元IP、送信元ポート、宛先IP、宛先ポート）によって識別されます。 （詳細はwikipediaのように見えます）
クライアント - バランサ要求の場合：各インバウンド接続に固有の（送信元IP、送信元ポート）がある限り、問題はありません。クライアントは通常これを保証します。この側面の唯一の問題は、ごくわずかなIPv4アドレスの後ろに顧客をNATする膨大なISPからアクセスすると、ページあたり多くのイメージを持つ非常に人気の高いWebサイトであるということでした。それはおそらくあなたの状況ではありません。
上記のNAT問題と同様の状況が発生している可能性があるので、balancer-> backendリクエストが面白いです。私はLinuxが普通は別のソケットephemeral portを割り当てようとしていると思いますが、デフォルトでは28,233しかありません。また、IIRCではTIME_WAIT状態のものを使用しないので、実際には多くの接続を同時に開くことなく範囲を使い果たすことができます。 IIRCこの制限に達するとconnect（または接続する前に明示的にソケットをバインドする場合はbind）にEADDRINUSEのエラーが発生します。
bind/connectより前のソケットにSO_REUSEADDRを設定してください。net.ipv4.tcp_tw_reuseおよび/またはnet.ipv4.tcp_tw_recycleをオンにします。connectを自動的に割り当てさせるのではなく、bind経由で使用するソースIPおよび/またはポートを明示的に選択します。あなたは同じ4タプルで2つの同時接続を持つことはできませんが、それ以外のものは問題ありません。 （例外：私は、同じ4組のためのTIME_WAIT再利用が大丈夫であるかどうかによって考えにパントよ、私はいくつかのTCPのRFCを読んでTIME_WAITについての私の記憶をリフレッシュする必要があると思います。）おそらくよ少しの実験をしなければならない。良いことは、問題を理解したら、それを再現してテストして、それを修正したかどうかをテストすることです。