Java などの一部の環境では、「localhost」アドレス (IPv4 では 127.0.0.1、IPv6 では ::1) を使用して、同じホスト上のプロセス間でメッセージを渡すために TCP/IP ソケットを使用するのが自然です。(Java はその API で他の IPC メカニズムを公開しない傾向があるため)。
明らかに、これは、パイプを介したメッセージ パッシングを介した IPC や、共有メモリを使用した IPC よりも大幅に遅くなる可能性があります。
一方、TCP/IP ネットワーク スタックが、接続の両端がループバック インターフェース上にあることに気付いた場合、パイプを使用した場合とあまり変わらないように、かなりの最適化を行うことができる可能性があります。
しかし、一般的なオペレーティング システム (Windows、Linux) は、TCP/IP スタックにそのような最適化を実装していますか?
はい。ループバックアドレス（127.xxx）へのパケット/データが受信されると、TCP/IPのIP層はループバックルートを使用してパケットをそれ自体にルーティングします。
ルーバックルート
ネットワークの宛先|| ネットマスク|| ゲートウェイ|| インターフェース|| メトリック
127.0.0.0 |||||||||||||||||||||| 255.0.0.0 || 127.0.0.1 || 127.0.0.1 || 1
それをitsefにルーティングした後、プロトコル制御ブロック（接続データ構造ごと）の助けを借りてTCP / UDP層で、対応するソケットとその所有者プロセスが識別され、パケット/データを配信します。
結論として、（OSIモデルの）データリンク層と物理層でのすべてのタスクが回避されます。
OS、および使用されている構成によって異なります。デフォルトの動作を求めている場合、答えは「はい」です。
これが、wireshark などのツールを使用してローカル ループバック シナリオを盗聴できない理由です。
特にLinuxでは、パケットがループバックインターフェースで送信されると、カーネルは各パケットに対して「ソフトウェア」割り込みを発生させます。それ以降のパケット受信は、物理デバイスのパケット受信フローと同じになります。したがって、ループバック インターフェイスを介した通信は、UNIX ソケットなどの代替 IPC メカニズムよりもはるかに遅くなるという仮定は正しいです。
カーネル コード パスを最適化できると思います。たとえば、ループバック インターフェイスの送信コード パスから受信コード パスを直接呼び出すことができます。