<<
Recently, our website has been frequently throwing a 503 error: “HTTP Error 503. The service is unavailable”. But it goes back to normal after a refresh or two.
It’s very likely that the maximum number of concurrent connections for the website has been exceeded.
What exactly is an HTTP connection? When a page loads, with its images, stylesheets, and scripts, are all those resource requests using a single connection or multiple connections?
Some people online say that to save connections, you should merge external CSS and JS files, or inline them; even combine images into a single sprite and use CSS for positioning. Clearly, in that context, one request uses one connection, and the connection is closed once the request completes.
But in IIS, there’s an option for “Keep-Alive” HTTP connections with a configurable timeout. If every single resource requires opening a new connection, and that connection stays alive instead of dying promptly, how many connections would be enough? The implication here seems to be that one connection can be reused multiple times.
Which one is correct?
Actually, both are.
The HTTP protocol is stateless and connectionless. Connectionless means each connection is restricted to handling a single request, and it disconnects after receiving the response. But that’s said to be HTTP/1.0.
HTTP/1.1 introduced the concept of persistent connections, meaning the same HTTP connection can handle multiple requests sequentially. Most modern browsers reportedly support this. It makes sense if you think about it—establishing an HTTP connection incurs a high cost, similar to a database connection. That’s why we try to complete all operations within one database connection, just like when you go to the supermarket, you don’t make a separate trip for each item; otherwise, you’d be shopping until dark.
However, even with persistent connections, I still have some doubts: Does a single page truly use only one connection? What if some resources are particularly large, like images, and other elements can’t wait? Would another connection be opened? And if the HTTP timeout is set to 20 minutes, wouldn’t that be a huge waste?
Also, even if a single page uses only one connection, merging CSS, JS, and images is still meaningful. Because fewer files mean fewer requests sent, which should also have a performance impact.
Appendix 1:
A typical web page consists of an HTML file and various embedded elements, including images, CSS files, JavaScript files, and so on. At the HTTP protocol level, each embedded element is no different from that HTML file: the browser needs to fetch each one from the server. An early, typical browser implementation worked like this: when a user typed in a URL, the browser established a connection with the server, requested the HTML page, and then began parsing the HTML page while receiving it from the server. Upon encountering an embedded element, it could immediately open a second connection to request it. Moreover, if there were many embedded elements, it might open multiple connections to request them simultaneously. Once all necessary elements were downloaded, the browser would render the page. This process was the browser implementation envisioned by the early HTTP/1.0 protocol.
HTTP/1.0’s multi-connection operating model had room for improvement. The process of establishing a TCP connection goes like this: the client sends a network packet to the server saying it wants to establish a connection; the server, upon receiving it, replies with a packet saying “I’m willing”; then the client must send another packet to the server saying “Okay, let’s start transferring data.” This back-and-forth of three packets is needed just to establish a TCP connection. After the connection is established, the browser sends a request to the server, and the server sends a response back to the browser. When this is done, several more packets are exchanged back and forth to close the TCP connection. If a page has many elements with short file lengths, each element requiring its own connection would result in a massive number of network packets just for establishing and tearing down TCP connections. Furthermore, TCP has a characteristic called “slow start,” which can be roughly explained as follows: A TCP connection requires the sender to send a certain number of packets before the receiver replies with an “I’ve received it” packet. Also, each packet’s header gets rewritten as it passes through each router. Therefore, in a network without packet loss, larger packets mean greater network efficiency. The way a TCP connection finds the optimal packet size is that, early in the connection’s establishment, the packet size is very small. Based on network conditions, the programs on both ends gradually increase the packet size to match the bandwidth and improve transmission efficiency. So, if a browser opens a request, sends it, and immediately closes the connection, that connection’s data transfer will struggle to reach the speed that the bandwidth could support.
For these various reasons, HTTP/1.1 soon emerged, introducing the concept of persistent connections. This means a single HTTP connection can handle multiple requests sequentially, while using certain mechanisms to ensure separation between individual requests. The specific process is: After the server sends a response to the browser, it does not close the connection immediately. Once the browser determines that the previous request’s response has been fully received, it can send a second request over the same connection. This operating mode drastically reduces the number of network packets, and experiments have shown this approach to be very effective. However, since maintaining connections consumes some server resources, servers generally don’t keep persistent connections alive forever, and establishing too many persistent connections between browsers and servers is not recommended.
Persistent connections can be further accelerated through pipelining. As seen above, a browser needs to wait for the complete receipt of the previous request’s response on a persistent connection before sending the next request. If the connection to the server is relatively slow, the persistent connection often spends most of its time waiting rather than sending/receiving data. Pipelining means the browser can send multiple requests to the server at once on a single persistent connection, and the server will respond to those requests sequentially over that connection. This mode of operation is especially effective when combined with browser caching. For example, after a picture has been viewed, it is stored in the browser’s cache. On the next request, the browser tells the server, “I already have a cached version of this picture, its modification time was XXXX. If the picture hasn’t been modified on the server since then, don’t resend it.” In this case, the server will send a very short “304 Not Modified” response. Without pipelining, each such query would require a network round-trip. With pipelining, the browser can simultaneously ask the server whether four images have been modified. If the server supports pipelining well, it can even put all four responses into a single network packet to send back—a significant acceleration.
An early proposed use case for pipelining was that, if the server supported pipelining well, it could distribute the two requests within a single pipeline to two different CPUs for processing, further speeding up the response time. Of course, this might not be particularly useful.
========================================
Appendix 2:
Introduction
HTTP is an object-oriented protocol belonging to the application layer. Due to its simplicity and speed, it is suitable for distributed hypermedia information systems. It was proposed in 1990 and, after several years of use and development, has been continuously refined and expanded. Currently, the sixth edition of HTTP/1.0 is used on the WWW, the standardization of HTTP/1.1 is in progress, and a proposal for HTTP-NG (Next Generation of HTTP) has already been made.
The main features of the HTTP protocol can be summarized as follows:
1. Supports the client/server model.
2. Simple and fast: When a client requests a service from the server, it only needs to transmit the request method and path. Common request methods include GET, HEAD, and POST. Each method defines a different type of interaction between the client and the server. Because the HTTP protocol is simple, the program size of the HTTP server is small, resulting in very fast communication speeds.
3. Flexible: HTTP allows the transfer of any type of data object. The type being transferred is marked by Content-Type.
4. Connectionless: The meaning of connectionless is that each connection is limited to processing a single request. Once the server has processed the client’s request and received the client’s acknowledgement, it disconnects. Using this method can save transmission time.
5. Stateless: The HTTP protocol is a stateless protocol. Stateless means the protocol has no memory capability for transaction processing. The lack of state means that if subsequent processing requires previous information, it must be retransmitted, which might lead to an increase in the amount of data transferred per connection. On the other hand, the server responds faster when it doesn’t need previous information.
I. HTTP Protocol Deep Dive: The URL
HTTP (Hypertext Transfer Protocol) is a stateless, application-layer protocol based on a request/response model, typically relying on TCP connections. HTTP/1.1 introduced a persistent connection mechanism. The vast majority of web development involves web applications built on top of the HTTP protocol.
The format of an HTTP URL (a special type of URI containing sufficient information to locate a specific resource) is as follows:
http://host[":"port][abs_path]
“http” indicates that the HTTP protocol should be used to locate the network resource; “host” represents a valid Internet host domain name or IP address; “port” specifies a port number, defaulting to port 80 if empty; “abs_path” specifies the URI of the requested resource. If the URL does not contain an abs_path, it must be given in the form of “/” when used as the request URI. Usually, the browser handles this automatically for us.
e.g.:
1. Input: www.guet.edu.cn
Browser automatically converts it to: http://www.guet.edu.cn/
2. http:192.168.0.116:8080/index.jsp
II. HTTP Protocol Deep Dive: The Request
An HTTP request consists of three parts: the request line, the message header, and the request body.
1. The request line begins with a method token, followed by a space, then the Request-URI and the protocol version. The format is as follows: Method Request-URI HTTP-Version CRLF
Where Method indicates the request method; Request-URI is a Uniform Resource Identifier; HTTP-Version indicates the HTTP protocol version of the request; and CRLF represents a carriage return and line feed (no individual CR or LF characters are allowed except as the terminating CRLF).
There are several request methods (all in uppercase), with explanations for each as follows:
GET Requests to retrieve the resource identified by the Request-URI.
POST Appends new data after the resource identified by the Request-URI.
HEAD Requests to retrieve the response message headers for the resource identified by the Request-URI.
PUT Requests the server to store a resource and use the Request-URI as its identifier.
DELETE Requests the server to delete the resource identified by the Request-URI.
TRACE Requests the server to echo back the received request information, primarily used for testing or diagnostics.
CONNECT Reserved for future use.
OPTIONS Requests to query the server’s capabilities, or to query options and requirements related to a resource.
Application examples:
<<
One-step operation
4xx: Client Error — The request contains a syntax error or cannot be fulfilled
5xx: Server Error — The server failed to fulfill a valid request
Common status codes, descriptions, and explanations:
200 OK // Client request successful
400 Bad Request // Client request has a syntax error and cannot be understood by the server
401 Unauthorized // Request is not authorized; this status code must be used with the WWW-Authenticate header field
403 Forbidden // Server received the request but refuses to provide service
404 Not Found // Requested resource does not exist, e.g., an incorrect URL was entered
500 Internal Server Error // The server encountered an unexpected error
503 Server Unavailable // The server is currently unable to process the client’s request and may return to normal after some time
e.g.: HTTP/1.1 200 OK (CRLF)
2. Response headers are described later
3. The response body is the content of the resource returned by the server
IV. Detailed Explanation of the HTTP Protocol: Message Headers
An HTTP message consists of a request from the client to the server and a response from the server to the client. Both request and response messages consist of a start-line (for request messages, the start-line is the request line; for response messages, the start-line is the status line), message headers (optional), an empty line (a line containing only CRLF), and a message body (optional).
HTTP message headers include general headers, request headers, response headers, and entity headers.
Each header field consists of a name + “:” + space + value. The names of message header fields are case-insensitive.
1. General Headers
Among general headers, a few header fields are used for all request and response messages but are not used for the entity being transferred, only for the message being transferred.
e.g.:
Cache-Control is used to specify caching directives. Caching directives are unidirectional (caching directives appearing in a response may not necessarily appear in a request) and independent (the caching directives of one message do not affect the caching mechanism processing another message). The similar header field used in HTTP/1.0 is Pragma.
Caching directives for requests include: no-cache (used to indicate that a request or response message cannot be cached), no-store, max-age, max-stale, min-fresh, only-if-cached;
Caching directives for responses include: public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age, s-maxage.
e.g.: To instruct the IE browser (client) not to cache a page, the server-side JSP program can be written as follows: response.sehHeader("Cache-Control","no-cache");
//response.setHeader("Pragma","no-cache"); has the same effect as the above code, and usually the two are //used together
This line of code will set the general header field in the sent response message: Cache-Control:no-cache
The Date general header field indicates the date and time the message was generated
The Connection general header field allows sending options for the specified connection. For example, specifying whether the connection is persistent, or specifying the “close” option to notify the server to close the connection after the response is complete
2. Request Headers
Request headers allow the client to pass additional information about the request and information about the client itself to the server.
Commonly used request headers
Accept
The Accept request header field is used to specify which types of information the client can accept. e.g.: Accept: image/gif indicates that the client wishes to accept resources in GIF image format; Accept: text/html indicates that the client wishes to accept HTML text.
Accept-Charset
The Accept-Charset request header field is used to specify the character sets acceptable to the client. e.g.: Accept-Charset:iso-8859-1,gb2312. If this field is not set in the request message, the default is that any character set is acceptable.
Accept-Encoding
The Accept-Encoding request header field is similar to Accept, but it is used to specify acceptable content encodings. e.g.: Accept-Encoding:gzip.deflate. If this field is not set in the request message, the server assumes that the client can accept various content encodings.
Accept-Language
The Accept-Language request header field is similar to Accept, but it is used to specify a natural language. e.g.: Accept-Language:zh-cn. If this header field is not set in the request message, the server assumes that the client can accept various languages.
Authorization
The Authorization request header field is primarily used to prove that the client has the right to view a certain resource. When a browser accesses a page and receives a response code of 401 (Unauthorized) from the server, it can send a request containing the Authorization request header field to ask the server for verification.
Host (This header field is mandatory when sending a request)
The Host request header field is primarily used to specify the Internet host and port number of the requested resource. It is usually extracted from the HTTP URL. e.g.:
We enter in the browser: http://www.guet.edu.cn/index.html
The request message sent by the browser will contain the Host request header field as follows:
Host: www.guet.edu.cn
Here, the default port number 80 is used. If a port number is specified, it becomes: Host: www.guet.edu.cn:specified port number
User-Agent
When we log into forums online, we often see welcome messages that list the name and version of our operating system and the browser we are using. Many people find this quite fascinating. In fact, the server application obtains this information from the User-Agent request header field. The User-Agent request header field allows the client to tell the server about its operating system, browser, and other attributes. However, this header field is not mandatory. If we were to write our own browser and not use the User-Agent request header field, then the server side would be unable to learn our information.
Request header example:
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/"80b1a4c018f3c41:8317" (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)
3. Response Headers
Response headers allow the server to pass additional response information that cannot be placed in the status line, as well as information about the server and information for further access to the resource identified by the Request-URI.
Commonly used response headers
Location
The Location response header field is used to redirect the recipient to a new location. The Location response header field is commonly used when changing domain names.
Server
The Server response header field contains the software information used by the server to process the request. It corresponds to the User-Agent request header field. Below is an example of the Server response header field:
Server: Apache-Coyote/1.1
WWW-Authenticate
The WWW-Authenticate response header field must be included in a 401 (Unauthorized) response message. When the client receives a 401 response message and sends an Authorization header field request asking the server to verify it, the server’s response header includes this header field.
e.g.: WWW-Authenticate:Basic realm="Basic Auth Test!" //It shows that the server uses a basic authentication mechanism for the requested resource.
4. Entity Headers
Both request and response messages can transfer an entity. An entity consists of entity header fields and an entity body, but this does not mean that the entity header fields and entity body must be sent together; entity header fields can be sent alone. Entity headers define meta-information about the entity body (e.g., whether there is an entity body) and the resource identified by the request.
Commonly used entity headers
Content-Encoding
The Content-Encoding entity header field is used as a modifier for the media type. Its value indicates what additional content encoding has been applied to the entity body. Therefore, to obtain the media type referenced in the Content-Type header field, a corresponding decoding mechanism must be used. Content-Encoding is used this way to record the document’s compression method, e.g.: Content-Encoding: gzip
Content-Language
The Content-Language entity header field describes the natural language used by the resource. If this field is not set, it is assumed that the entity content is intended for readers of all languages. e.g.: Content-Language:da
Content-Length
The Content-Length entity header field is used to indicate the length of the entity body, represented as a decimal number stored in bytes.
Content-Type
The Content-Type entity header field is used to indicate the media type of the entity body sent to the recipient. e.g.:
Content-Type:text/html;charset=utf-8/>Content-Type:text/html;charset=utf-8/>Last-Modified
The Last-Modified entity header field is used to indicate the date and time of the resource’s last modification.
Expires
The Expires entity header field gives the date and time after which the response is considered stale. To allow proxy servers or browsers to update cached pages after a period of time (when revisiting a previously accessed page, loading directly from the cache shortens response time and reduces server load), we can use the Expires entity header field to specify the page expiration time. e.g.: Expires: Thu, 15 Sep 2006 16:23:12 GMT
HTTP/1.1 clients and caches must treat other invalid date formats (including 0) as already expired. e.g.: To make the browser not cache the page, we can also use the Expires entity header field, set to 0. The program in JSP is as follows: response.setDateHeader("Expires","0");
V. Observing the HTTP Protocol Communication Process Using Telnet
Experiment purpose and principle:
Using Microsoft’s Telnet tool, by manually inputting HTTP request information, a request is sent to the server. After the server receives, interprets, and accepts the request, it returns a response, which will be displayed in the Telnet window, thus deepening the intuitive understanding of the HTTP protocol’s communication process.
Experiment steps:
1. Open Telnet
1.1 Open Telnet
Run –> cmd –> telnet
1.2 Enable Telnet local echo
set localecho
2. Connect to the server and send a request
2.1 open www.guet.edu.cn 80 //Note that the port number cannot be omitted
 <<
t www.sina.com.cn 80
HEAD /index.asp HTTP/1.0
Host:www.sina.com.cn
3 Experimental Results:
3.1 The response obtained from request 2.1 is:
HTTP/1.1 200 OK //Request successful
Server: Microsoft-IIS/5.0 //Web server
Date: Thu,08 Mar 200707:17:51 GMT
Connection: Keep-Alive
Content-Length: 23330
Content-Type: text/html
Expries: Thu,08 Mar 2007 07:16:51 GMT
Set-Cookie: ASPSESSIONIDQAQBQQQB=BEJCDGKADEDJKLKKAJEOIMMH; path=/
Cache-control: private
//Resource content omitted
3.2 The response obtained from request 2.2 is:
HTTP/1.0 404 Not Found //Request failed
Date: Thu, 08 Mar 2007 07:50:50 GMT
Server: Apache/2.0.54 <Unix>
Last-Modified: Thu, 30 Nov 2006 11:35:41 GMT
ETag: "6277a-415-e7c76980"
Accept-Ranges: bytes
X-Powered-By: mod_xlayout_jh/0.0.1vhs.markII.remix
Vary: Accept-Encoding
Content-Type: text/html
X-Cache: MISS from zjm152-78.sina.com.cn
Via: 1.0 zjm152-78.sina.com.cn:80<squid/2.6.STABLES-20061207>
X-Cache: MISS from th-143.sina.com.cn
Connection: close
Lost connection to the host.
Press any key to continue…
4. Notes: 1. If input errors occur, the request will not succeed.
2. Header fields are case-insensitive.
3. For a deeper understanding of the HTTP protocol, refer to RFC2616, available at http://www.letf.org/rfc.
4. Developing backend programs requires mastering the HTTP protocol.
VI. Supplementary HTTP Protocol Technologies
1. Basics:
High-level protocols include: File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP), Domain Name System (DNS), Network News Transfer Protocol (NNTP), and HTTP protocol, etc.
There are three types of intermediaries: Proxy, Gateway, and Tunnel. A proxy accepts requests according to the absolute format of the URI, rewriting all or part of the message, and sends the formatted request to the server identified by the URI. A gateway is a receiving agent, acting as an upper layer for some other servers, and can translate requests to the lower-level server protocol if necessary. A tunnel acts as a relay point between two connections without changing the messages. Tunnels are often used when communication needs to pass through an intermediary (e.g., a firewall) or when the intermediary cannot recognize the message content.
Proxy: An intermediate program that can act as both a server and a client, establishing requests for other clients. Requests are processed internally or passed to other servers, potentially with translation. A proxy must interpret and possibly rewrite a request message before sending it. Proxies often serve as client-side portals through firewalls, and can also act as helper applications to handle requests via protocols not completed by the user agent.
Gateway: A server that acts as an intermediary for other servers. Unlike a proxy, a gateway accepts requests as if it were the origin server for the requested resource; the requesting client is unaware it is dealing with a gateway.
Gateways often serve as server-side portals through firewalls, and can also function as protocol translators to access resources stored in non-HTTP systems.
Tunnel: An intermediary program acting as a relay between two connections. Once activated, a tunnel is considered not part of HTTP communication, although it may have been initiated by an HTTP request. A tunnel disappears when both ends of the relayed connection are closed. Tunnels are often used when a portal must exist or an intermediary cannot interpret the relayed communication.
2. Advantages of Protocol Analysis — HTTP Analyzers for Network Attack Detection
Analyzing high-level protocols in a modular fashion will be the future direction of intrusion detection.
Common ports for HTTP and its proxies, such as 80, 3128, and 8080, are specified using the port tag in the network section.
3. HTTP Protocol Content-Length Limit Vulnerability Leading to Denial of Service Attacks
When using the POST method, Content-Length can be set to define the length of data to be transmitted, for example, Content-Length: 999999999. Memory is not released until the transmission is complete. Attackers can exploit this flaw by continuously sending junk data to the web server until its memory is exhausted. This attack method leaves virtually no traces.
http://www.cnpaf.net/Class/HTTP/0532918532667330.html
4. Concepts for Denial of Service Attacks Using HTTP Protocol Characteristics
The server is too busy handling TCP connection requests forged by the attacker to process normal client requests (as the ratio of normal client requests is very small). From the perspective of normal clients, the server appears unresponsive; this situation is known as a SYN Flood attack.
Smurf, TearDrop, etc., utilize ICMP packets to flood and IP fragment attacks. This article uses “normal connection” methods to generate Denial of Service attacks.
Port 19 has been used for Chargen attacks in the past, i.e., Chargen_Denial_of_Service. However! The method they used was to create a UDP connection between two Chargen servers, causing the server to process too much information and go DOWN. Therefore, the conditions to take down a WEB server must be two-fold: 1. Have a Chargen service. 2. Have an HTTP service.
Method: The attacker forges the source IP and sends connection requests (Connect) to N number of Chargen servers. Upon receiving the connection, Chargen returns a character stream of 72 bytes per second (actually faster depending on the network conditions) to the server.
5. HTTP Fingerprinting Technology
The principle of HTTP fingerprinting is roughly the same: recording the subtle differences in how different servers implement the HTTP protocol for identification. HTTP fingerprinting is much more complex than TCP/IP stack fingerprinting because customizing HTTP server configuration files, adding plugins or components makes it easy to change HTTP response information, thus making identification difficult; whereas customizing TCP/IP stack behavior requires modifications to the core layer, making it easier to identify.
It is very simple to make servers return different Banner information. For open-source HTTP servers like Apache, users can modify the Banner information in the source code and restart the HTTP service for it to take effect; for closed-source HTTP servers like Microsoft’s IIS or Netscape, modifications can be made in the Dll file storing the Banner information. Related articles discuss this, so it won’t be elaborated here. Of course, the effect of such modifications is quite good. Another method to obscure Banner information is using plugins.
Common test requests:
1: HEAD/Http/1.0 sends a basic Http request
2: DELETE/Http/1.0 sends disallowed requests, like a Delete request
3: GET/Http/3.0 sends a request with an illegal Http protocol version
4: GET/JUNK/1.0 sends an incorrectly formatted Http protocol request
The Http fingerprinting tool Httprint effectively determines the type of Http server by applying statistical principles and combining fuzzy logic techniques. It can be used to collect and analyze signatures generated by different Http servers.
6. Others: To improve the performance of users’ browsers, modern browsers support concurrent access methods, establishing multiple connections simultaneously when browsing a webpage to quickly obtain multiple icons on the page, thus completing the entire webpage transmission faster.
HTTP 1.1 provides this persistent connection method, and the next-generation HTTP protocol,