TCPでポート番号は実際にどのように機能しますか？

Question

上記の質問を読みましたが、回答に一貫性がないようです。

ソケット接続を正確に定義するものは何ですか？

(sockid, source ip, source port, dest ip, dest port)

またはのみ：

(source ip, source port, dest ip, dest port)

2つの異なるプロセス（2つの異なるブラウザーなど）が同じ送信元ポートでWebサーバーと通信できますか？（destポートはデフォルトで同じです）

同じブラウザの異なるタブの場合はどうなりますか？

また、回答の1つで述べたように、1つのWebページが複数のサーバー（広告サーバーなど）に同時に接続できます。複数のサーバーに同時に接続する場合、Webブラウザー（Chrome、Firefoxなど）は同じポートを使用して各サーバーに接続しますか、それともサーバーごとに異なるポートを使用しますか？

Paul1307 · Accepted Answer

私はこれが遅いことを知っていますが、スレッドはまだインターネット上にあり、Webでの信頼できる回答が非常に少ない一般的な質問であるため、これでさえ、それにつまずくかもしれない人のためのより完全で簡潔な説明に値します遅い日付。

ブラウザーを開いてWebサイト（たとえばgoogle.com）を表示します。 Webサイトを指定するプロセスでは、コンピューターはポート番号を任意に選択して、その「ソースポート」として使用します。番号は、「ダイナミック、プライベート、またはエフェメラルポート」の始まりである49152を超えますが、利用可能な最大のポート番号である65535未満になります。選択したポート番号は、そのブラウザの「インスタンス」に関連付けられています。
ただ面白くするために、ブラウザで新しいタブを開き、URL行に「google.com」と入力します。目的は、別のものを探しているため、google.comの2つのインスタンスを実行することです。次に、コンピューターは、最初のセッションで使用した「ソース」ポートとは異なる、そのセッションの2番目のポート番号を選択します。実際、これを何度も行うことができ、各セッションには、各インスタンスに関連付けられた一意の「ソース」ポートがあります。
パケットはgoogle.comに送信され、すべてのインスタンスの宛先ポート番号はポート80になります。Webサーバーは、ポート80で受信接続要求を「リッスン」します。開いたgoogle.comとのセッションごとに、コンピューターから見た宛先ポートは常にポート80になりますが、ブラウザーでのgoogle.comへの接続の各インスタンスでは、送信元ポートは一意になります1つのブラウザインスタンスで1つの特定のタブを一意に識別します。これは、コンピュータ上でそれらが区別される方法です。
google.comが最初のリクエストを取得します。その応答では、ポート80がソースポートとして指定されます。ここが面白いところです。 google.comから受け取った各クエリは、「ソケット」として扱われます。これは、IPアドレスと、google.comにアクセスしたプロセスに関連付けられた特定のポート番号の組み合わせです。したがって、たとえば、IPアドレスが165.40.30.12であり、google.comとの通信の4つのインスタンスのソースポートとしてコンピュータが使用したソースポート番号（google.comを開く4つの異なるタブがあるとしましょう）は61235、62421、58392、および53925。これらの4つの「ソケット」は、165.40.30.12：61235、165.40.30.12：62421、165.40.30.12：58392、および165.40.30.12:53925になります。「IPアドレス：ソースポート番号」の各組み合わせは一意であり、google.comは各インスタンスを一意として扱います。 google.comは「ソケット」、つまりIPアドレスとポートの組み合わせに応答して通信します。
コンピュータはgoogle.comから応答を取得し、ポート番号で解析する宛先「ソケット」として受信したものでそれらを分類し、google.comからの応答を適切なブラウザウィンドウまたはタブに適切に割り当てます。毎回、正しいウィンドウに正しい応答が表示されるので、問題はありません。
「でも、あなたが考えているのは、「誰かが誤って同じポート番号を使用した場合-61235としましょう-私がソース番号に使用したのと同じですか？これはgoogle.comを混乱させませんか？」 google.comはIPアドレスとポート番号の組み合わせである「ソケット」を追跡しているため、まったくありません。他の誰かが当然、そして私たちが心から望んでいるように、使用しているものとは異なるIPアドレスを使用しているとします。たとえば、152.126.11.27であり、IPアドレスとポート番号の組み合わせは一意です-152.126.11.27:61235-ポート番号が同じであっても、それらの異なるIPアドレス。
Google.comが1000人のユーザーから1000個のクエリを取得し、すべてポート80を宛先ポート番号として使用するかどうかは関係ありません（ポートgoogle.comは着信通信をリッスンしています）。これらの1000人のユーザーはすべて一意のIPアドレスを持っているためです。。 google.comはクライアントを一意で追跡します。また、常に一意である必要がありますね。 -IPアドレスと「ソース」ポート番号で構成されるソケット番号。それらの1000個のクライアントのすべてが何らかの方法で同じ「ソース」ポート番号を使用することができたとしても（最大ではない可能性があります）、IPアドレスは異なり、他のすべてのソース間でソース「ソケット」を一意にします。
このように説明されているのを見ると、これはかなり単純です。これにより、Webサーバーは常に1つのポート（80）でリッスンでき、さまざまなクライアントと区別できることが明らかになります。それはクエリで受け取ったIPアドレスを単に見るだけではありません-そのWebサーバーで複数のWebページを開くことができることに気づくまで、最初はすべて一意である必要がありますが、ソースポートで組み合わせて、すべてのクエリを一意にします。これがかなり明確であることを願っています。考えればエレガントなシステムですが、理解すればシンプルです。

Barmar · Answer

順番に質問をする：

接続は以下によって定義されます。

{プロトコル、ローカルIP、ローカルポート、リモートIP、リモートポート}

（送信時にはローカルポートが送信元となり、受信時には宛先となるため、送信元と宛先ではなく、ローカルとリモートと言う方が適切です。）

Sockidは、ファイル記述子が開かれたディスク上のファイルにマッピングされるのと同じように、カーネル内の接続にマッピングされるユーザープロセスの単なる記述子です。

2つの異なるプロセスを同じローカルポートにバインドすることはできません。ただし、2つのプロセスが同じ接続を使用する可能性があります。ソケット記述子を親プロセスから子プロセスに継承するか、記述子をプロセス間通信を使用してプロセス間で渡すことができます。 2つのプロセスは実際には同じ接続を共有しているため、同じポートを使用します。

このプロトコルでは、異なるリモートサーバーまたはポートに接続するときに同じローカルポートを使用できますが、ほとんどのTCPスタックはこれを許可しません。ローカルポートをバインドするためのAPIは、送信接続または受信接続のリッスンに使用し、ポートがバインドされるまで意図は指定されません。特定のポートでリッスンできるのは1つのソケットだけなので、APIは複数のソケットがポート（これには特別な例外がありますが、この説明には関係ありません）結果として、すべての発信接続は異なるローカルポートを使用します。そのため、ブラウザが複数の接続（同じまたは異なるWebサーバーへの）を開くと、ローカルポートが異なります。