When doing IPC using TCP/IP sockets using the loopback address, do common networking stacks skip framing the message in lower-level PDUs?

In some environments such as Java, it's natural 开发者_Go百科to use TCP/IP sockets to pass messages between processes on the same host using the 'localhost' address (127.0.0.1 in IPv4, or ::1 in IPv6). (Because Java tends not to expose other IPC mechanisms in its API).

Clearly, this has the potential to be a lot slower than IPC via message passing over pipes, or IPC using shared-memory.

On the other hand, if the TCP/IP networking stack realised that both ends of the connection were on the loopback interface, it might be able to do a fair bit of optimisation so that the efficiency might not differ much from using pipes.

But do common operating systems (Windows, Linux) implement such optimisations in their TCP/IP stacks?

Yes. When a packet/data to a Loopback address(127.x.x.x) is received, the IP layer of the TCP/IP uses the Loopback route to route the packet to itself.

Looback Route

Network Destination || Netmask || Gateway || Interface || Metric

127.0.0.0 |||||||||||||||||||||| 255.0.0.0 || 127.0.0.1|| 127.0.0.1 || 1

After routing it to itsef, at TCP/UDP layer with the help of protocol control blocks(per connection data structure) the corresponding socket and its owner process will be identified to deliver the packet/data.

Bottom line, All the tasks at Data Link layers and Physical layers(of OSI Model) will be avoided.

Depends upon the OS, and the configuration being used. The answer is yes if you are asking for default behavior.

This is the reason why you are not able to use tools like wireshark to sniff local loopback scenarios.

[Edit from another user]: Actually, this is possible, you have to choose the Loopback interface (Testing with Wireshark 3.4)

Specifically in linux when packets are transmitted on the loopback interface the kernel raises a "software" interrupt for each packet. From that point on the packet reception is identical to the packet reception flow for a physical device. So you are correct in your assumption that communication over the loopback interface would be much slower than alternate IPC mechanisms such as unix sockets.

I guess the kernel code path can be optimized. For e.g., we could call the receive code path directly from the transmit code path of loopback interface.