What is a persistent connection and how does Akamai handle it?
HTTP Persistent Connections allow for re-use of a TCP connection for more than one request. In HTTP 1.1 this is initiated by the client with the Connection header:
GET /index.html HTTP/1.1
GET /index.html HTTP/1.1
If the server supports Persistent Connections, the response will include the Connection header:
After the final body is sent to the client, the TCP socket remains open and a subsequent HTTP request. The main benefits then include:
In short, a persistent connection will improve the network performance for requests and responses to a client (or browser).
Akamai fully supports Persistent Connections. In fact, Akamai will continue to use these persistent connections all the way through Akamai's infrastructure and back to the Origin. In this way, even if clients disconnect, Akamai will still maintain a persistent connection to the origin, thus improving the performance for the next client.
By default Akamai will close persistent connections to the origin after 300s of no activity. Therefore, if you have a load balancer at your origin, it is best to set to timeout to 301s - ensuring that Akamai Edge servers disconnect the connection. (With a value <=300s, you can run the risk of a request being sent to the origin the same time that the origin starts to tear down the tcp socket, thus causing an error)
One last caveat to consider when dealing with persistent connections to your origin infrastructure: a persistent connection may represent more than one real-user. Akamai will re-use existing connections if available for more than one user. This saves on network time and avoids network congestion.
Any Load Balancer deployed at your origin must not assume that a HTTP Persistent Connection is bound to a single user. The Load Balancer should inspect the HTTP cookies for each request before forwarding the request to an appropriate web server. Failing to do this will result in inbalanced traffic on your origin web servers. Most Load Balancer vendors provide a mechanism to handle this such as F5's OneConnect policy.
Thanks for the comprehensive answer. A quick followup question on this. How do we authoritatively test if the Origin supports PCONN and if yes, for how long. We've seen that the Connection header is sometimes misleading.
If the origin replies with a 'Connection' header then it is declaring that it does support a persistent connection. However, as you allude to, the connection timeout duration is unknown. The timeout could be anything from 0s to ∞ and is set by the application server.
A quick and dirty test is to use telnet (assuming HTTP) and time the response.
This will use the 'time' command to give you a measurable number. If you get a 400 or 500 error the connection may be dropped immediately so make sure it is a valid response (200, 404, etc)
The more complicated way would be to spin up wireshark and watch the tcp connections from your browser to the origin server.
May I know what would happen if pconn is 360s, but not 301s? I thought Akamai server would close the connection before the origin server. Could it cause any 500 error on Akamai Edge server? Many thanks for your explanations.
The reason PCONN at Origin load balancer/ webserver has to be greater than Akamai is because it will help cleaner closure of the connection. We do not want the Origin to close the connection first and interrupt any data flow on the channel
Hence any value about 300 seconds is ideal (can be 301, 302 or 360). The 500 status code (if generated) could have a different reason than persistent connection being closed.
Adding to Arthi's reply, Setting pconn to 360s on your origin will not cause 500 error. If there are any 500 error, they may happen due to many other reasons.
If you set up pconn to 360s instead of 301s, your origin server will keep TCP connection in memory for 59s additional time. During that 59s duration, Akamai will not send any request on that TCP connection. If a new request comes from same edge server to origin in that 59s duration, the edge server will open a new TCP connection. At the same time Origin will now have 2 TCP connection open from same edge server. The 1st TCP connection will be closed on origin after 59s seconds and 2nd will still remain in memory to serve to other request.
As an example, if we think about 25 Akamai edge server opening TCP connection with origin periodically, Origin may end with keeping unused TCP connection in memory for additional 59s. If the origin has hard limit on opened TCP connection, the origin server may start refusing connection and may stop responding to Akamai Edge server upon reaching that limit. To make sure, origin is not holding any unused TCP connection for longer, we recommend you to set it to 301 seconds so that before origin closes the TCP connection, Akamai will close the connection and Akamai edge server will never go forward to origin on closed origin connection.
Hi Harsh and Maran,
Many thanks for your explanations. We are going to update our pcon settngs to 501s. We hope it will fix the issue we encountered.
Just a little correction here.
Everytime our persistent connection is terminated on Akamai , we will close out the connection with a Fin/Rst.
Pcon value on Origin greater than Akamai will not have impact on the end user/Akamai. They will not observe any kind of error.
5XX errors refers to an failure between Akamai and Origin ,which can be observed due to multiple reasons e.g network connect timeout , origin closing out a connection. It may or may not be related to pcon .
I would recommend opening a ticket with Ccare with the complete reference number , allowing us to confirm the exact root and work with you for permanent fix .
Hope this helps.
Thanks. We also suspected something wrong between Akamai and Origin server. We submitted a ticket and Akamai support recommended us to change our pconn settings to 501s.
Do persistent connections also work for mutual authentication scenarios from end user where the client certificate is forwarded in a header by Akamai?
Retrieving data ...