TCPクライアントがサーバのリスニングポートでconn'nを要求すると、サーバはそれを受け入れ、このクライアントとのコネクションです。したがって、クライアントはこの新しいポートでサーバーと通信します。サーバへのTCP接続要求を要求した後、クライアントはその端にあるサーバによって生成された別のポートで応答を受け取ることができます
上記のステートメントが真で可能な場合、サーバーが新しく生成されたポートをクライアントに伝達する方法。 conn'n要求に応答して、サーバーからクライアントへのパケットは、送信元ポート（サーバーのリスニングポートまたはサーバーがクライアント用に生成した新しいポート）としてのポートを持ちます。 クライアントはこのポートを受け入れて使用するか、エラーが発生しますか？私はlwipスタックを使って組み込みシステムに2つのクライアントと1つのサーバを持つアーキテクチャを実装するためにこれを必要とします。
に関して、 ED
サーバーは新しいポートを作成しません。これは新しいTCP 接続を作成し、クライアントからの接続要求を送信したIPとポートに応答パケットを送信します。 （TCPコネクションは、各側のIPアドレスとポートを持っています。）
サーバーに接続すると、ポート番号を自分で取得するには、システムによってあなたに割り当てられている（あなたがない限りbindソケットの前に接続する）。サーバーのネットワークスタックが接続要求に応答すると、「送信元」ポートがサーバーの新しいポート番号になり、メッセージの「宛先」ポートが自分のポートになります。これは、クライアント側のネットワークスタックがどのようなポートを持っているかを知る方法です。
接続に使用されるサーバー上の新しいポート番号は、実際のサーバープログラムによって設定または変更することはできません。使用可能なポート番号を取得するサーバーマシン上のネットワークスタックです。
を編集する：connections are established、a.k.a.という三方向ハンドシェイクの方法について少しお読みください。
「サーバーの新しいポート番号」がなく、「使用可能なポート番号を取得する」という名前はありません。受け入れられたソケットは、リスニングソケットと同じポート番号を使用します。 – EJP
lwipスタックを使用して組み込みシステムに実装する必要があります。 *クライアントがサーバーのリスニングポートで接続要求を送信すると、サーバーのリスニングポートを持つサーバーからの応答が期待されますヘッダーの送信元ポート次に、クライアントは新しいtcp接続の詳細（特にポート番号）を知るようになります。 –
クライアントは接続しようとしているサービスのサーバーのよく知られたポートであるため、宛先ポートを認識します。クライアントはソースポートを選択しているのでそれを知るでしょう - それは最初のパケットを*から送るポートです。 –
こんにちは、あなたの指摘しています。クライアントは宛先のよく知られたポートが何であるかを知るでしょう。しかし、1つのクライアントが接続要求にこのよく知られたポートを使用し、このチャネルでデータ通信が開始されるシナリオを考えてみましょう。これで、別のクライアントが接続を望むとき、それは同じ既知のポートで要求を送信します。今サーバがこの接続を受け入れ、この接続のための（既知のポートではなく）新しいポートを取得したい場合、それは可能です。またはサーバーは新しいソケットを作成しますが、ソースポートを既知のポートと同じに保ちます。 –