I have a basic understanding of how HTTP works. I understand the client (web browser) makes a request and server responds back to the request. However, the thing I don't understand is how does a web server know when the client makes a request?

If someone calls me my phone rings and I get notified. Similarly how does a webserver get notified about the request?

  • 2
    How is this not a duplicate 5 years after Super User was launched? – Peter Mortensen Nov 1 '14 at 8:44

There's a lot of layers to this. And importantly, many of them are interchangeable.

For example, you can have a coax-cable network, an ethernet, or a Wi-Fi down at the physical level. HTTP works on top of all of those, but each of them has a slightly different handling of the payload being sent around.

HTTP works on top of another protocol, called TCP, which in turn more or less runs on top of yet another protocol, called IP (nowadays mostly in two variants - IPv4 and IPv6).

So the HTTP server registers an IP address (like, or most often "any"), along with a TCP port (80 being the default for HTTP, but in general anything from 1 to 65535), with the operating system. Now, the HTTP server tells the OS to ping it when data (or another message) comes. The OS knows when that happens, because the network interface card driver tells it that. And the NIC driver is told by the NIC itself, which actually has its own software to interpret the electrical signals on the network cable (or the wireless signals in the air etc., you get the idea).

Side note:

If you want to know more about how the NIC can initiate communication with the driver / OS, you might want to lookup some basic info on hardware interrupts - basically, whatever the CPU is currently doing is stopped, and the program flow switches to an interrupt handler routine - an extremely simple piece of code that takes care of notifying the system, and then immediately returns control back to the original thing the CPU was doing. In fact, it might answer you a lot of questions about the inner workings of the OS and the computer itself - like how an operating system can "steal" CPU from running applications and shuffle the CPU resources between different applications running at the same time, even if they do not coöperate.

Back to business:

In your manual telephone analogy, imagine that your phone doesn't actually ring. To know if you're having a phone call attempt, you'll have to look at the screen periodically and check. To make this easier to manage for the HTTP server (since there's already quite a few layers who do that periodical check), you can actually block on the check attempt.

So instead of checking, seeing there's nothing there and checking again, you basically keep looking at the screen all the time. However, you've basically got a whole separate system for handling this (in your case, the hearing center, which checks the air vibrations for useful information, the ring), so it doesn't actually require your attention (CPU time).

This is further improved by techniques that allow you to monitor many connections at once (IOCP). This gets closer and closer to the phone ring system - you have a room with ten thousand phones, but you only care about those that are ringing at the moment, the others aren't taking any of your attention.

  • Careful, "ping" has a different totally unrelated meaning in networking. Also, why has nobody mentioned "hardware interrupts"? – Lie Ryan Oct 31 '14 at 13:37
  • 1
    @LieRyan Well, yeah, that's in the part where the NIC tells the NIC driver. It just feels like a tiny little speck in the huge list of abstractions that are involved, and really, outside of people playing around with old-school architectures, embedded devices or driver developers, it's pretty obscure knowledge, sadly. But well, I guess I'll add a quick mention. – Luaan Oct 31 '14 at 15:10
  • 1
    Are ports just numbers ? or are they physical pins on the NIC Card ? I find it hard to imagine there might be 65536 ports – Dhiwakar Ravikumar Nov 1 '14 at 9:14
  • 2
    @DhiwakarRavikumar: Yes, ports are just numbers. They are made up by a program or the operating system, they do not correspond to anything in hardware. – sleske Nov 1 '14 at 12:03
  • 1
    @DhiwakarRavikumar Ports are just numbers, but hardware interrupts actually used to be hardware pins on the CPU (so you had a different pin for "got a divide by zero!" and another for "the alarm clock is ringing"). So you only had three or seven different interrupts or such most of the time. It's comparable to the old phone stations - they used to actually have physical pins you had to connect to make the call, but they're switched in software nowadays just like TCP ports. – Luaan Nov 3 '14 at 8:53

Computers use a concept called "ports", analogous to "extensions" for a telephone switchboard: The client is not only "calling" the server IP address, but also sends the request to a specific port on that server.

There are thousands of ports (wikipedia list), e.g. port 80 is the default for HTTP.

The trick is that a program, e.g. a webserver, can register itself to listen on a particular port. Then the OS will pass any requests coming in on that port on to that program.

The point of having several ports is that you can have multiple services running on the same server at the same time, by using different ports they won't interfere with each other.

  • 65,535 ports to be exact – ub3rst4r Nov 1 '14 at 4:58

Webserver notified with the following process

Accept ()

Say webserver listens on port 80, when the request from client comes on port 80, it will accept a connection with the accept() system call. This call typically blocks until a client connects with the server.

Then Listen for connections with the listen() system call and Bind the socket to an address using the bind() system call.

Atlast creates a socket with the socket() system call.

Hope this helps!


You have /var/log/apache2 directory with the following directory:


It's related to you want from client, and how to notify, sms, email , and so on.

My suggesstion:

You can create an log server and send every your log such as mail server , dns server , web server and so on, Then you can parse it, Even same server uses db and you can run query.

  • Thanks for the reply, but I think you misunderstood my question. I meant when I get a phone call, my phone rings. So I know that I got a phone call because my phone rang. Similarly when the client makes a request, how is the webserver notified? – raj curious Oct 31 '14 at 5:11

I guess the web server registers call back functions with the port.

So that whenever anything is received on that particular port, the system calls that call back function registered earlier. Inside that call back, it may set an event or something like that and then the webserver would have a dedicated thread waiting on that event. This thread will run and queue this request to the main list of requests that the webserver is already processing.

What I gave here is a very superficial & macro view of the things happening. For more precise answers let's wait till the experts come in.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.