Showing Page:
1/2
Persistent vs non-persistent HTTP connections
Persistent HTTP Connections
The server must support this first of all, I cannot think of a server which is not supporting
this at the moment. The header used to announce we want a persistent connection is:
Connection: Keep-Alive
The response from the server must contain the same header if the server supports
keep-alive mode (persistent HTTP connections), and also, if we're using the HTTP v1.1,
the server may also return information on how many HTTP requests may be sent via
that same opened TCP stream, and what's the timeout period until the TCP stream
closes if nothing is sent over the wire to the remote server.
In this case, the response looks like so:
Connection: Keep-Alive
Keep-Alive: timeout=10, max=5
Advantages:
faster content delivery, less round-trip time, everything is served via the same
TCP stream which obviously saves lots of time. When adding HTTP pipelining support
to this, things are even faster.
This is also extremely beneficial when it comes to secure delivery using
the SSL protocol, which require extra round-trips (here's a good reply I got on the topic
while working on Loop thing a while ago).
Less CPU usage: we're involving a less amount of low level OS routine calls.
Reduced network congestion: less packets on the line, and more control for
TCP to handle the congestion in a single stream (from RFC 2616 notes on persistent
connections).
Disadvantages:
possible scalability issues: in case of a traffic burst, all the "slots" on the web
server (the connections pool) are kept busy by few users, while everybody else waits for
a server response. This also happens with non-persistent connections as well, however
the time to serve a different HTTP request is lower than with persistent connection,
because there's no time-out period.
no simplicity friendliness: a server serving simple one time files (such as AJAX
requests, basic HTML files with no embedded objects, XML files, update statuses) has
no reason to serve HTTP content via persistent connection, because the one-time
required content can be served using one HTTP request and the client will be gone.
non-CDN friendly: this is something I've been thinking about many times. If
serving content from a CDN which delivers content from multiple web servers for the
Showing Page:
2/2
purpose of increasing the delivery speed (see The Two HTTP Connection Limit issue),
the CDN solution is nilled by not being able to deliver multiple HTTP responses via the
same TCP connection.
Non-persistent HTTP Connections
Advantages:
possibly more scalable: depending on the design of the application and the
usage patterns (like mentioned in the disadvantages for persistent HTTP connections),
more clients can be served if they require content from the server sporadically.
simple server architecture: the server may be a bit faster if it doesn't require
the implementation of the persistent HTTP connections and the pipelining support.
Disadvantages:
possibly less scalable: depending on the type of traffic the server gets, serving
individual HTTP requests on their own TCP stream may quickly starve the server's
resources.
more CPU usage: there are low level operating system routines involved in
opening a new TCP stream for each request. This puts the web server under more
work.
My opinion & suggestion
As you can see, this entry is not supported by any data, I haven't made any benchmark
but these are common thoughts I'm expressing based on my previous reading and
experience with various web applications.
My opinion is you need to know what type of content is the server serving in order to
decide if the persistent connections are required, or if the non-persistent ones are
better. If it's a RESTful A PIprovider serving XML content, obviously the behavior the
clients will be very different from let's say, regular browsers or mobile clients accessing
a web interface.
For the best decision, use the above common sense advice, but if you're not sure, after
the web application is completed and the common front-end optimization practices have
been implemented, benchmarking and observing the web server in production mode,
will reveal the answer.

Unformatted Attachment Preview

Persistent vs non-persistent HTTP connections Persistent HTTP Connections The server must support this first of all, I cannot think of a server which is not supporting this at the moment. The header used to announce we want a persistent connection is: Connection: Keep-Alive The response from the server must contain the same header if the server supports keep-alive mode (persistent HTTP connections), and also, if we're using the HTTP v1.1, the server may also return information on how many HTTP requests may be sent via that same opened TCP stream, and what's the timeout period until the TCP stream closes if nothing is sent over the wire to the remote server. In this case, the response looks like so: Connection: Keep-Alive Keep-Alive: timeout=10, max=5 Advantages: • faster content delivery, less round-trip time, everything is served via the same TCP stream which obviously saves lots of time. When adding HTTP pipelining support to this, things are even faster. This is also extremely beneficial when it comes to secure delivery using the SSL protocol, which require extra round-trips (here's a good reply I got on the topic while working on Loop thing a while ago). • Less CPU usage: we're involving a less amount of low level OS routine calls. • Reduced network congestion: less packets on the line, and more control for TCP to handle the congestion in a single stream (from RFC 2616 notes on persistent connections). Disadvantages: • possible scalability issues: in case of a traffic burst, all the "slots" on the web server (the connections pool) are kept busy by few users, while everybody else waits for a server response. This also happens with non-persistent connections as well, however the time to serve a different HTTP request is lower than with persistent connection, because there's no time-out period. • no simplicity friendliness: a server serving simple one time files (such as AJAX requests, basic HTML files with no embedded objects, XML files, update statuses) has no reason to serve HTTP content via persistent connection, because the one-time required content can be served using one HTTP request and the client will be gone. • non-CDN friendly: this is something I've been thinking about many times. If serving content from a CDN which delivers content from multiple web servers for the purpose of increasing the delivery speed (see The Two HTTP Connection Limit issue), the CDN solution is nilled by not being able to deliver multiple HTTP responses via the same TCP connection. Non-persistent HTTP Connections Advantages: • possibly more scalable: depending on the design of the application and the usage patterns (like mentioned in the disadvantages for persistent HTTP connections), more clients can be served if they require content from the server sporadically. • simple server architecture: the server may be a bit faster if it doesn't require the implementation of the persistent HTTP connections and the pipelining support. Disadvantages: • possibly less scalable: depending on the type of traffic the server gets, serving individual HTTP requests on their own TCP stream may quickly starve the server's resources. • more CPU usage: there are low level operating system routines involved in opening a new TCP stream for each request. This puts the web server under more work. My opinion & suggestion As you can see, this entry is not supported by any data, I haven't made any benchmark but these are common thoughts I'm expressing based on my previous reading and experience with various web applications. My opinion is you need to know what type of content is the server serving in order to decide if the persistent connections are required, or if the non-persistent ones are better. If it's a RESTful A PIprovider serving XML content, obviously the behavior the clients will be very different from let's say, regular browsers or mobile clients accessing a web interface. For the best decision, use the above common sense advice, but if you're not sure, after the web application is completed and the common front-end optimization practices have been implemented, benchmarking and observing the web server in production mode, will reveal the answer. Name: Description: ...
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.
Studypool
4.7
Trustpilot
4.5
Sitejabber
4.4