The standard HTTP timeout seems to be 30 seconds, if the server does not respond at all. But what is the "standard" timeout if a server is responding, but sending the response very slowly? When does the client give up? When it reaches a certain time between packets? Never?
HTTP does not standardize on a timeout; nothing prevents clients from waiting forever. Some clients may do an application-level timeout of 30 seconds, but my Firefox, for example, shows network.http.response.timeout as 300 seconds.
The lack of standard applies even more to slow responses. For example, various scanning and reverse proxies employ trickling techniques to drip feed a few bytes to the client to prevent it from timing out while they do heavy processing. Usually 100 bytes or so every ten seconds suffices, though of course it's very much ad-hoc (see also comment above on lack of standard).
Related
I'm doing HTTP GET-requests from mobile devices (so network connection usually is not reliable) and wondering what would be a better approach:
Try 1 request with a timeout of 60 sec or
Try 3 requests each with a timeout of 20 secs
Or any other combination of retries/timeouts. I don't know if a HTTP/TCP connection actually can be stalled so a retry would be a good thing. I don't transfer a lot of data (< 1 kB) and are wondering what approach usually yields to a faster response time?
As long as it's an idempotent operation, it should be OK to retry more frequently in theory.
(a GET should never have any side effect at all, to be honest.)
It might still put unnecessary load on the server, and delayed responses to multiple retransmits of the request may saturate the downlink and make the situation worse.
In interactive applications I find an honest "it's taking longer than normal" notification with a user-triggerable "retry" the best: The user has the option to press the "retry" button after exiting the tunnel or building that was causing a short network outage.
Conversely out in the woods with constantly low throughput, they will learn to ignore the notification and wait patiently.
I am optimizing my web server settings to handle large number of concurrent users and one of the problems I'm running into is deciding whether or not to disable HTTP Keep-Alive.
I am using CDN for all the images on the site so when my HTML page is requested I am downloading approximately 5 files (js, css, etc) on first load... and then only HTML on each successive load.
Other then that, the only thing I have is HTTP POST update invoke on every second (resulting JSON is typically less than 1KB).
So, with these constrains - would you think that disabling HTTP Keep-Alive on the server would be a good idea? Would that improve the number of concurrent users server can handle?
(By the way, I've reduced KeepAliveTimeout/ConnectionTimeout to 15 seconds in the IIS 7.5 settings)
From what you are describing, you are making a call per client per second. So all boils down to how much it takes to serve the request. If let's say, it takes 100ms to serve the request. So what that means is Http Keep-Alive of 15 seconds will be have 15 calls accommodated w/o re-establishing connection but connection was actual active (or being used) only for 1.5 seconds - rest of the time, you are actually blocking some client/connection (assuming there is any client). W/o keep alive, you can probably accommodate 8-9 times more concurrent clients.
However all said, you have to look at actual parameters to make decision. How many concurrent clients you are likely to have and what is the response time etc. The best way is to do simulation/load testing to measure the performance. Because if your server is going to handle the anticipated max concurrent user load with keep-alive, you can very well keep keep alive.
BTW, also see this related question on SO: http keep-alive in the modern age
In an embedded device, What is a practical amount time to allow idle HTTP connections to stay open?
I know back in the olden days of the net circa 1999 internet chat rooms would sometimes just hold the connection open and send replies as they came in. Idle timeouts and session length of HTTP connections needed to be longer in those days...
How about today with ajax and such?
REASONING: I am writing a transparent proxy for an embedded system with low memory. I am looking for ways to prevent DoS attacks.
My guess would be 3 minutes, or 1 minute. The system has extremely limited RAM and it's okay if it breaks rare and unpopular sites.
In the old days (about 2000), an idle timeout was up to 5 minutes standard. These days it tends to be 5 seconds to 50 seconds. Apache's default is 5 seconds. With some special apps defaulting to 120 seconds.
So my assumption is, that with AJAX, long held-open HTTP connections are no longer needed.
How about allowing idle HTTP connections to remain open unless another communication request comes in? If a connection is open and no one else is trying to communicate, the open connection won't hurt anything. If someone else does try to communicate, send a FIN+ACK to the first connection and open the second. Many http clients will attempt to receive multiple files using the same connection if possible, but can reconnect between files if necessary.
I always knew web browsers could do parallel downloads. But then the other day I heard about pipelining. I thought pipelining was just another name for parallel downloads, but then found out even firefox has pipelining disabled by default. What is the difference between these things and how do work together?
As I under stand it, "parallel downloads" are requests going out on multiple sockets. They can be to totally unrelated servers but they don't have to be.
Pipelining is an HTTP/1.1 feature that lets you make multiple requests on the same socket before receiving a response. When connecting to the same server, this reduces the number of sockets, conserving resources.
I think this MDC article explains HTTP pipelining pretty darn well.
What is HTTP pipelining?
Normally, HTTP requests are issued sequentially, with the next request being issued only after the response to the current request has been completely received. Depending on network latencies and bandwidth limitations, this can result in a significant delay before the next request is seen by the server.
HTTP/1.1 allows multiple HTTP requests to be written out to a socket together without waiting for the corresponding responses. The requestor then waits for the responses to arrive in the order in which they were requested. The act of pipelining the requests can result in a dramatic improvement in page loading times, especially over high latency connections.
Pipelining can also dramatically reduce the number of TCP/IP packets. With a typical MSS (maximum segment size) in the range of 536 to 1460 bytes, it is possible to pack several HTTP requests into one TCP/IP packet. Reducing the number of packets required to load a page benefits the internet as a whole, as fewer packets naturally reduces the burden on IP routers and networks.
HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required to not fail if a client chooses to pipeline requests. This obviously has the potential to introduce a new category of evangelism bugs, since no other popular web browsers implement pipelining.
I recommend reading the whole article since there's more than what I copied into my answer.
At work, we have a client-server system where clients submit requests to a web server through HTTP. The server-side processing can sometimes take more than 60 seconds, which is the proxy timeout value set by our company's IT staff and cannot be changed. Is there a way to keep the HTTP connection alive for longer than 60 seconds (preferably for an arbitrarily long period of time), either by heartbeat messages from the server or the client?
I know there are HTTP 1.1 persistent connections, but that is not what I want.
Does HTTP have a keep-alive capability, or would this have to be done at the TCP level through some sort of socket option?
This should get you started.
Assuming you control both sides of the system, you can fake it by sending data back and forth periodically to keep the session from idling out -- most browsers won't terminate a connection as long as data is moving.
As a general suggestion, though, you're much better off re-designing the system so that the client submits a job request and then periodically queries (via Ajax) to see if it's completed. The Ajax queries can delay a while and the server can respond either when it has an affirmative status, or when the timeout period is near to elapsing. If the status-update request times out for some reason (timing errors or whatnot), the client simply re-submits it with no harm done and no visible disruption from the user's perspective.
Just have your server send a trickle of no-op data while it's doing the processing - if the result is in HTML, then something like:
<!-- keepalive -->
sent every 10 seconds should do.