My Interpretation of localhost and 127.0.0.1

 

Incident

When executing a test, I see the below message 

The target is unreachable, Please make sure your target is up and running

I have multiple Docker images running on my machine.  Most of these images are different products that are bound to run locally.

Debugging and Observations

In this context, I'm using http://127.0.0.1:portNumber as an IP to communicate with an application which is a Docker image.  I see the above said message.

But, I have not mentioned any IP address specifically; and there is no port forward.  This puts me into question -- What's going wrong here?

I use http://localhost:portNumber and try to communicate with a Docker image. Now the test execution does not see the message above said.

I see  a next question in me:

• Isn't localhost and 127.0.0.1 both mean the same on a local box?

Debugging and Interpretation

1. I see the IP address 127.0.0.1 refers to a loopback interface on a local box
2. When TCP/IP sees the IP address which starts with 127, it understands this is a loopback request
• This request does not go out of the local box
• The response to this request is returned to the top TCP/IP layer of the same local box
3. But, the local box does need to have the same and only one IP address, that is 127.0.0.1
4. The IP of the local box can range from 127.0.0.1 to 127.255.255.255 along with the combination of port numbers which can range from 0 to 65535
• 0 is the reserved port number in TCP/IP; it cannot be used
5. localhost is the domain name for the loopback IP address which is 127.x.x.x.
• This also means, the loopback IP of localhost does not necessarily have to be 127.0.0.1 all time
• It can be different
• And, if the port number is used along with the loopback IP address, then 127.0.0.1 can still be used with different port numbers for different applications and its communication
• Are localhost:5555 and localhost:8888 two different applications on the same IP address?
• It looks so! Technically and logically as well it looks okay
• But, using the same IP address with a different port number is a monolith concept, right?
• Apart from the monolith concept, this is not a good approach
• But, for now when running multiple Docker images locally and testing locally, this is a state and transition which is more likely to occur
  
6. Further I see, the application which is binded to the domain name localhost might not necessarily have the IP address 127.0.0.1 always
• The IP can range up to 127.255.255.255
• This indicates me there is a difference between 127.0.0.1 and localhost
• That is, localhost and 127.0.0.1 does not mean one and the same every time
7. I see there should be binding here to the local box's domain name -- localhost
• This is a differentiator

Given this context, that is, running multiple Docker images locally and testing within a TCP/IP of a local box,

• I see using localhost [with port number] in the URL is a wise strategy in testing if 127.0,0,1 fails.  

Knowing the exact local IP address with the port number should work.  If this fails, we have an incorrect port number or a problem connecting to the port.  

All these are being spoken in the context of

• A local box
• Communication between the images on a local box.

It is all about which application on the local box has taken [registered] the domain name localhost.  Or, find the exact IP address on the loopback interface along with the port number used by an application

How I'm bringing up the servers and what the configuration includes for the IP address and port numbers, is not to be taken casually. Especially on the local box!

Your Thoughts?

If you see my interpretations are incorrect, kindly help me to learn by commenting on this blog post.  We will connect to share and discuss.  I'm open to unlearn and learn!

Note: I have read about the term Small Weight Tests.  These tests have requests and communication which does not go out of the box.  The request and response happen within the box with little or no I/O and CPU operations.