Why can my Docker app receive UDP data without publishing the port?-CodePudding

I'm learning Docker networking. I'm using Docker Desktop on Windows.

I'm trying to understand the following observations:

Short version in a picture:

Longer version:

First setup (data from container to host)

I have a simple app running in a container. It sends one UDP-datagram to a specific port on the host (using "host.docker.internal")
I have a corresponding app running on the host. It listens to the port and is supposed to receive the UDP-datagram.

That works without publishing any ports in docker (expected behavior!).

Second setup (data from host to container)

I have a simple app on the host. It sends one UDP-datagram to a specific port on the loopback network (using "localhost")
I have a corresponding app running in a container. It listens to the port and is supposed to receives the UDP-datagram.

That works only if the container is run with option -p port:port/udp (expected behavior!).

Third setup (combination of the other two)

I have an app "Requestor" running in a container. It sends a UDP request-message to a specific port on the host and then wants to receive a response-message.
I have a corresponding app "Responder" running on the host. It listens to the port and is supposed to receive the request-message. Then it sends a UDP response-message to the endpoint of the request-message.

This works as well, and - that's what I don't understand - without publishing the port for the response-message!

How does this work? I'm pretty sure there's some basic networking-knowledge that I simply don't have already to explain this. I would be pleased to learn some background on this.

Sidenote:

Since I can do curl www.google.com successfully from inside a container, I realize that a container definitely must not publish ports to receive any data. But there's TCP involved here to establish a connection. UDP on the other hand is "connectionless", so that can't be the (whole) explanation.

CodePudding user response：

After further investigation, NAT seems to be the answer.

According to these explanations, a NAT is involved between the loopback interface and the docker0 bridge.

This is less recognizable with Docker Desktop for Windows because of the following (source):

Because of the way networking is implemented in Docker Desktop for Windows, you cannot see a docker0 interface on the host. This interface is actually within the virtual machine.