The Relationship Between HTTP Protocol and TCP/IP Protocol

HTTP long and short connections are essentially TCP long and short connections. HTTP is an application layer protocol that uses TCP protocol at the transport layer and IP protocol at the network layer. The IP protocol mainly solves network routing and addressing issues, while the TCP protocol mainly solves how to reliably deliver data packets over the IP layer, ensuring that all packets sent from one end are received at the other end of the network in the same order as they were sent. TCP has reliable, connection-oriented characteristics.

Understanding Why HTTP Protocol is Stateless

The HTTP protocol is stateless, meaning that the protocol has no memory capability for transaction processing, and the server doesn’t know what state the client is in. In other words, there is no connection between opening a webpage on a server and previously opening a webpage on that server. HTTP is a stateless connection-oriented protocol. Being stateless doesn’t mean that HTTP cannot maintain a TCP connection, and it certainly doesn’t mean that HTTP uses the UDP protocol (connectionless).

What are Long Connections and Short Connections?

In HTTP/1.0, short connections are used by default. This means that the browser and server establish a connection for each HTTP operation, but the connection is terminated once the task is completed. If a client browser accesses an HTML or other type of Web page that contains other Web resources such as JavaScript files, image files, CSS files, etc., the browser will establish an HTTP session each time it encounters such a Web resource. However, from HTTP/1.1 onwards, long connections are used by default to maintain connection characteristics. HTTP protocols using long connections will add this line of code to the response header: Connection:keep-alive. In the case of using a long connection, when a webpage is fully opened, the TCP connection used to transmit HTTP data between the client and server will not close. If the client accesses the webpage on this server again, it will continue to use this already established connection. Keep-Alive will not permanently maintain the connection; it has a retention time that can be set in different server software (such as Apache). Both the client and server must support long connections to implement them. The long and short connections of the HTTP protocol are essentially the long and short connections of the TCP protocol.

TCP Connection

When using TCP protocol for network communication, a connection must be established between the server and client before any actual read/write operations. When the read/write operations are completed and both parties no longer need this connection, they can release it. Establishing a connection requires a three-way handshake, while releasing it requires a four-way handshake, so establishing each connection consumes resources and time.

TCP Short Connection

Let’s simulate a short connection scenario. The client initiates a connection to the server, the server accepts the client connection, and both parties establish a connection. After the client and server complete a read/write operation, their connection is actively closed.

TCP Long Connection

Now let’s simulate a long connection scenario. The client initiates a connection to the server, the server accepts the client connection, and both parties establish a connection. After the client and server complete a read/write operation, their connection is not actively closed, and subsequent read/write operations will continue to use this connection.

Let’s first talk about the TCP keepalive function mentioned in TCP/IP in Detail. The keepalive function is mainly provided for server applications. Server applications want to know whether the client host has crashed, so they can use resources on behalf of the client. If the client has disappeared, leaving a half-open connection on the server, and the server is waiting for data from the client, the server will wait indefinitely for client data. The keepalive function attempts to detect such half-open connections on the server side.

If a given connection has no activity for two hours, the server sends a probe segment to the client. The client host must be in one of the following four states:

1. The client host is still running normally and is reachable from the server. The client’s TCP responds normally, and the server knows that the other party is normal. The server resets the keepalive timer after two hours.
2. The client host has crashed and is either shut down or restarting. In either case, the client’s TCP does not respond. The server will not receive a response to the probe and will time out after 75 seconds. The server sends a total of 10 such probes, each at an interval of 75 seconds. If the server does not receive a response, it assumes that the client host is closed and terminates the connection.
3. The client host has crashed and has restarted. The server will receive a response to its keepalive probe, which is a reset, causing the server to terminate the connection.
4. The client is running normally, but the server is unreachable. This situation is similar to category 2; TCP can only discover that it has not received a response to the probe.

How to Choose Between Long and Short Connections

Long connections are often used for frequent operations, point-to-point communications, and situations where the number of connections cannot be too many. Each TCP connection requires a three-way handshake, which takes time. If each operation first establishes a connection and then operates, processing speed will be reduced significantly. So, if the connection is not disconnected after each operation, subsequent processing can directly send data packets without establishing a TCP connection. For example, database connections use long connections. Using short connections for frequent communication will cause socket errors, and frequent socket creation is also a waste of resources.

Web services like HTTP websites generally use short connections because long connections consume certain resources on the server side. For websites with such frequent connections from thousands or even millions of clients, using short connections saves resources. If long connections were used, and there were thousands of users at the same time, each user occupying one connection would be unimaginable. Therefore, short connections are better for situations with high concurrency but where each user does not need frequent operations.