ソケットAPIのaccept（）関数はどのように機能しますか？

ソケットAPIは、TCP / IPおよびUDP / IP通信（つまり、私たちが知っているネットワークコード）の事実上の標準です。ただし、そのコア機能の1つは、accept()少し不思議です。

セミフォーマルな定義を借用するには：

accept（）はサーバー側で使用されます。リモートクライアントから新しいTCP接続を作成するために受信した着信試行を受け入れ、この接続のソケットアドレスペアに関連付けられた新しいソケットを作成します。

つまり、acceptサーバーが新しく接続されたクライアントと通信できる新しいソケットを返します。（accept呼び出された）古いソケットは開いたままで、同じポートで新しい接続をリッスンします。

どのように機能しacceptますか？どのように実装されていますか？このトピックについては多くの混乱があります。多くの人が受け入れて新しいポートを開いたと主張し、あなたはそれを通してクライアントと通信します。しかし、新しいポートが開かれていないため、これは明らかに真実ではありません。実際には、同じポートを介して異なるクライアントと通信できますが、どうやって？複数のスレッドrecvが同じポートを呼び出す場合、データはどこに行くべきかをどのようにして知るのでしょうか？

それは、ソケット記述子に関連付けられているクライアントのアドレスの行に沿ったものだと思います。データがrecvそれを通過するときはいつでも、正しいソケットにルーティングされますが、よくわかりません。

このメカニズムの内部の仕組みについて徹底的に説明していただければ幸いです。

混乱は、ソケットがサーバーIP：サーバーポートで識別されると考えることにあります。実際には、ソケットはカルテットの情報によって一意に識別されます。

Client IP : Client Port そして Server IP : Server Port

したがって、サーバーIPとサーバーポートは、受け入れられたすべての接続で一定ですが、クライアント側の情報により、すべてがどこに向かっているかを追跡できます。

明確にするための例：

たとえば192.168.1.1:80、1つのサーバーと2つのクライアントがある10.0.0.1とし10.0.0.2ます。

10.0.0.1ローカルポート1234で接続を開き、サーバーに接続します。これで、サーバーには次のように識別される1つのソケットがあります。

10.0.0.1:1234 - 192.168.1.1:80  

今10.0.0.2ローカルポートでの接続が開き5678、サーバへとコネクトします。これで、サーバーには次のように識別される2つのソケットがあります。

10.0.0.1:1234 - 192.168.1.1:80  
10.0.0.2:5678 - 192.168.1.1:80

ユーザーからの回答「17 of 26」に追加するだけです

ソケットは実際には5つのタプルで構成されています-（ソースIP、ソースポート、宛先IP、宛先ポート、プロトコル）。ここで、プロトコルはTCPまたはUDPまたは任意のトランスポート層プロトコルである可能性があります。このプロトコルは、IPデータグラムの「プロトコル」フィールドのパケットで識別されます。

したがって、まったく同じ4タプルでプロトコルフィールドが異なる同じクライアントと通信するサーバー上の異なるアプリケーションを使用することができます。例えば

サーバー側のApache（TCP上のserver1.com:880-client1:1234）と（UDP上のserver1.com:880-client1:1234）上のWorld of Warcraft

他の4つのフィールドがすべて同じであっても、クライアントとサーバーの両方がこれをIPパケットのプロトコルフィールドとして処理するため、どちらの場合も異なります。

これを学んでいたときに私を混乱させたのは、用語が物理的なものであることsocketをport示唆し、実際にはそれらがネットワーキングの詳細を抽象化するためにカーネルが使用する単なるデータ構造であるということでした。

したがって、データ構造は、異なるクライアントからの別々の接続を維持できるように実装されています。それらがどのように実装されるかについては、答えはa。）どちらでも構いません。ソケットAPIの目的は、実装が重要ではないこと、またはb。）見ているだけです。1つの実装の詳細な説明を提供する強く推奨されるStevensの本の他に、LinuxまたはSolarisまたはBSDの1つにあるソースを確認してください。

他の人が言ったように、ソケットは4タプル（クライアントIP、クライアントポート、サーバーIP、サーバーポート）によって一意に識別されます。

サーバーIPで実行されているサーバープロセスは、アクティブソケットのデータベース（どのようなテーブル/リスト/ツリー/アレイ/マジックデータ構造を使用するかは気にしません）を維持し、サーバーポートでリッスンします。（サーバーのTCP / IPスタックを介して）メッセージを受信すると、データベースに対してクライアントIPとポートをチェックします。クライアントIPとクライアントポートがデータベースエントリで見つかった場合、メッセージは既存のハンドラーに渡されます。それ以外の場合は、新しいデータベースエントリが作成され、そのソケットを処理するために新しいハンドラーが生成されます。

ARPAnetの初期の頃は、特定のプロトコル（FTPの1つ）は、指定されたポートで接続要求をリッスンし、ハンドオフポートで応答していました。その接続のためのさらなる通信はハンドオフポートを経由します。これは、パケットごとのパフォーマンスを向上させるために行われました。当時のコンピュータは、数桁も低速でした。