1

I'm interested in understanding, conceptually (e.g., similar to how many of the concepts in networking are explained in textbooks like Tanenbaum's Computer Networks, or Kurose's Computer Networking), how a virtual private server (VPS) processes an incoming packet with data conceptually and it is mapped to my virtual instance among the thousands of virtual instances that are running in parallel.

Assume thus that my blog, myawesomerants.com, is hosted on some of the well known VPS providers, such as AWS Lightsail. A user is delighted to have found my website on Google and clicks on it.

What happens then?

I assume the VPS provider maintains some dynamic DNS, in order to map to which physical machine my request has to be directed. But then what, do they use ports behind which the variois VMs that make up the VPS sit, in order to assign the packet to the specific VM which is my server?
I'm really having trouble imagining how this might work. How processes can be matched to packets is delightfully clearly described in the books above, but unfortunately they contain no information on how a VPS might work. There's also this answer, but it does not give any useful information to me.

In order to understand better how this works, the following question is also of immediate relevance:

(How) Could I tell, as a client clicking on myawesomerants.com if the content was served from a VPS, instead of a physical server?

Improve this question
4
  • " if the content was served from a VPS, instead of a physical server?" You can't. The server doesn't sign its IP packets with "– Yours truly, your favourite neighbourhood virtual server". Apart from like, checking the IP address for myawesomerants.com and seeing if it's one of the blocks owned by AWS, GCP, Azure, etc. Commented Dec 20, 2022 at 17:43
  • @Alexander I know of course that a VPS has no such IP packet signature :) But how would I verify whether an IP belongs to AWS, GCP, Azure? I would be surprised if there are public lists online... Commented Dec 28, 2022 at 22:54
  • I know, I was just being coy. My point was that the whole point of a virtual server is to emulate the capabilities of a real server. There's no requirement to behave in some uniquely identifiable way that gives away the fact that it's virtualized and not bare metal. " would be surprised if there are public lists online.", well, be surprised! How the IP addresses are divided up to ranges and assigned to owners is public record. See docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html for example. Commented Dec 28, 2022 at 23:02
  • A VPS is a simulated physical server. It's a simulated physical server. It does all the same networking things that a physical server does! Commented Jan 5, 2023 at 19:43

2 Answers 2

Reset to default
1

You can ask a DNS server for the IP address of myawesomerants.com. You can then contact that IP address directly (but I think https might have problems on your client, not sure) and it will go to the same place for some time. The VPS will have set up routing information just like a normal server would, except it has given the same routing information for many virtualised servers. So your connection goes to the AWS machines which send it on to the myawesomerants.com server.

You can't detect at that level that it is virtual. You can lookup location information for the IP address. That is either faked to where myawesomerants is supposed to be, or points to the physical location of the AWS servers. Still, myawesomerents.com could have installed their own server 100 meters away from the AWS servers so you can't be sure.

If you were a government agency, you could figure out that there are lots and lots of routes client -> multiple hops -> same AWS server -> individual servers. So then you would know.

You might figure out that this little myawesomerents.com server can handle incredible amounts of traffic and conclude it handles more traffic than the site could pay for if it used its own hardware. So indirectly you can figure out if they are using AWS, but not directly.

Improve this answer
2
  • Thanks for the insightful answer. I'm still puzzled by a few things: 1) "The VPS will have set up routing information just like a normal server would, except it has given the same routing information for many virtualised servers." So how does (say) AWS do the packet forwarding to my specific VPS instance? Does every VPS that receives (say) an http packet use a different socket internally (i.e. a packet for myawesomerents.com comes in on socket 80, but AWS redirects it to (say) socket 1234, where my VPS is sitting)? Commented Dec 28, 2022 at 22:59
  • 2) "you could figure out that there are lots and lots of routes client -> multiple hops -> same AWS server -> individual servers" why would that indicate that it is an AWS erver - and how would you figure out that there are lots and lots of router? (Sorry if my questions are so basic, I'm still a beginner, trying to learn how different networking components fit together) Commented Dec 28, 2022 at 23:01
1

I assume the VPS provider maintains some dynamic DNS, in order to map to which physical machine my request has to be directed. But then what, do they use ports [...] in order to assign the packet to the specific VM which is my server?

Usually each VPS gets its own public IP address and the physical server knows which VM has which IP. As each VPS runs its own instance of an operating system (i.e. with its own network stack), the network package is simply forwarded to the "virtual network interface" of the right VPS. And that is the whole magic of processing a network package in the context of VPS.

So this has nothing to do with ports (which are a concept of TCP at the transport layer of the OSI model), as IP works "one layer below" at the network layer. The physical server acts like a network switch for all VPS running on it.

From the networks point of view there are just multiple IP addresses assigned to the same physical server. So there is nothing special about it from the clients perspective (usually it does not even know there are other IPs assigned to the same server).

A more interesting question is about how a shared web hosting service with shared IP knows what website to deliver: There is no way at the network layer to find out which site was requested. Also the transport layer cannot help here, because all clients connect to the same port (80 for HTTP or 443 for HTTPS).

Requests for all sites assigned to this single IP address are directed to the same web server* which then looks at the Host HTTP header to determine which site to deliver. Look for name-based virtual hosting to get more information about this. HTTPS complicates the issue even more, requiring Server Name Indication (SNI) to know what certificate to provide.

* … or something that acts like one, like a CDN or a VPS, possibly in combination with IP Anycast and/or other techniques…

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.