Web server socket

Question

When a client sends a request to web server. Does the web server open a new socket ?. Or is an existing open socket used for the new request ?. If it does open a socket for each new request, how is this managed since Http is a stateless protocol. Also is this same for all web servers or do different web servers handle this differently ?.

Answer 1

Basic answer: The server will have bound to a socket and will be waiting for a connection. It is stateless since a client will open many separate connections and each request can stand alone.

Not exactly sure how various web servers handle it though.

Hope that helps in some way.

Answer 2

A socket listens on a single port, and all requests likely come to the web server via the same port. So (generally speaking) there is a single socket that accepts all incoming requests, each of which is then passed on to a handler thread. Usually these handler threads are pooled and reused, since it is expensive to keep destroying and creating them.

Edit: I stand corrected. As per Alex Martelli's response, socket.accept() creates a new socket. And so then it does become valid to talk about persistent connections.

Here's a nice little example (from http://devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=396), though this does not make use of thread pooling:

import java.io.*;
import java.net.*;
import java.util.*;

public final class WebServer {
    public static void main(String args[]) throws Exception {

        //Establish the listen socket
        int PORT = 5306;     //select your favorite number > 1123
        ServerSocket listenSocket = new ServerSocket(PORT);

        //Process HTTP service requests in an infinite loop
        while(true) {
            //listen for TCP connection request
            //Construct an object to process the HTTP request message
            HttpRequest request = new HttpRequest(listenSocket.accept());
            Thread thread = new Thread(request);
            thread.start();
        }
    }
}

As far as statelessness, things like cookies and sessions are used to identify a user from one request to another. A cookie is data written to the client that is sent to the server with each request, and a session is represented by an ID which can be put into the URL or sent by other means.

Answer 3

http://en.wikipedia.org/wiki/HTTP#Persistent_connections might help

Answer 4

Using Unix terminology (which is near universal -- sockets were introduced in the BSD flavor of Unix and spread everywhere from there), pretty much any TCP network server (web- or otherwise) will have done a listen on a socket bound to a "well-known port" (typically but not necessarily port 80 for HTTP servers). When a client connects, the server is notified (in OS-dependent ways) and it can then do an accept on the listening socket, which does create a new socket.

Depending on the level of HTTP protocol in use (the normal 1.1, or the old but still used 1.0) and some headers in the request, the client may be asking for a one-use socket (which will deal with just one request and one response), or, more commonly these days, a persistent one (also known, with older terminology dating to late HTTP 1.0 days, as a "keep alive" connection). The server does not have to honor the client's request for the connection to be persistent, but typically tries to because it makes client performance SO much better. Each server may definitely pick their own heuristics about when it's too loaded (too many requests coming in at once) to honor requests for persistent connections.

HTTP is still stateless even when persistent connections are in use -- the client may make different requests on the still-open socket, and/or try opening different sockets, and HTTP just deals with each request/response pair separately. The socket's persistence only saves time in terms of TCP handshakes &c (since HTTP does work on top of TCP, each new TCP connection requires its own handshake, &c).