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?
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 184.38.45.1, 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.
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.
Webserver notified with the following process
Accept ()
Liseten()
bind()
socket()
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:
access.log
error.log
other_vhosts_access.log
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.
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.
