SSL handshake latency and HTTPS optimizations.

文章出处：http://www.semicomplete.com/blog/geekery/ssl-latency.html

At work today, I started investigating the latency differences for similarrequests between HTTP and HTTPS. Historically, I was running with the assumptionthat higher latency on HTTPS (SSL) traffic was to be expected since SSL handshakesare more CPU intensive. I didn't really think about the network consequences ofSSL until today.

It's all in the handshake.

TCP handshake is a3-packet event. The client sends 2 packets, the server sends 1. Best case,you're looking at one round-trip for establishing your connection. We can showthis empirically by comparing ping and tcp connect times:

% fping -q -c 5 www.csh.rit.eduwww.csh.rit.edu : xmt/rcv/%loss = 5/5/0%, min/avg/max = 112/115/123

Average is 115ms for ping round-trip. How about TCP? Let's ask curl how long tcp connect takes:

% seq 5 | xargs -I@ -n1 curl -so /dev/null -w "%{time_connect}\n" http://www.csh.rit.edu0.1170.1160.1170.1160.116

There's your best case. This is because when you (the client) receive the 2ndpacket in the handshake (SYN+ACK), you reply with ACK and consider theconnection open. Exactly 1 round-trip is required before you can send your httprequest.

What about when using SSL? Let's ask curl again:

% curl -kso /dev/null -w "tcp:%{time_connect}, ssldone:%{time_appconnect}\n" https://www.csh.rit.edutcp:0.117, ssldone:0.408# How about to google?% curl -kso /dev/null -w "tcp:%{time_connect}, ssldone:%{time_appconnect}\n" https://www.google.comtcp:0.021, ssldone:0.068

3.5x jump in latency just for adding SSL to the mix, and this is before we sentthe http request.

The reason for this is easily shown with tcpdump. For this test, I'll usetcpdump to sniff https traffic and then use openssl s_client to simply connectto the http server over ssl and do nothing else. Start tcpdump first, then runopenssl s_client.

terminal1 % sudo tcpdump -ttttt -i any 'port 443 and host www.csh.rit.edu'...terminal2 % openssl s_client -connect www.csh.rit.edu:443...Tcpdump output trimmed for content:# Start TCP Handshake00:00:00.000000 IP snack.home.40855 > csh.rit.edu.https: Flags [S] ...00:00:00.114298 IP csh.rit.edu.https > snack.home.40855: Flags [S.] ...00:00:00.114341 IP snack.home.40855 > csh.rit.edu.https: Flags [.] ...# TCP Handshake complete.# Start SSL Handshake.00:00:00.114769 IP snack.home.40855 > csh.rit.edu.https: Flags [P.] ...00:00:00.226456 IP csh.rit.edu.https > snack.home.40855: Flags [.] ...00:00:00.261945 IP csh.rit.edu.https > snack.home.40855: Flags [.] ...00:00:00.261960 IP csh.rit.edu.https > snack.home.40855: Flags [P.] ...00:00:00.261985 IP snack.home.40855 > csh.rit.edu.https: Flags [.] ...00:00:00.261998 IP snack.home.40855 > csh.rit.edu.https: Flags [.] ...00:00:00.273284 IP snack.home.40855 > csh.rit.edu.https: Flags [P.] ...00:00:00.398473 IP csh.rit.edu.https > snack.home.40855: Flags [P.] ...00:00:00.436372 IP snack.home.40855 > csh.rit.edu.https: Flags [.] ...# SSL handshake complete, ready to send HTTP request. # At this point, openssl s_client is sitting waiting for you to type something# into stdin.

Summarizing the above tcpdump data for this ssl handshake:

• 12 packets for SSL, vs 3 for TCP alone
• TCP handshake took 114ms
• Total SSL handshake time was 436ms
• Number of network round-trips was 3.
• SSL portion took 322ms (network and crypto)

The server tested above has a 2048 bit ssl cert. Running 'openssl speed rsa' onthe webserver shows it can do a signature in 22ms:

                  sign    verify    sign/s verify/srsa 2048 bits 0.022382s 0.000542s     44.7   1845.4

Anyway. The point is, no matter how fast your SSL accelerators (hardwareloadbalancer, etc), if your SSL end points aren't near the user, then yourfirst connect will be slow. As shown above, 22ms for the crypto piece of SSLhandshake, which means 300ms of the SSL portion above was likely networklatency and some other overhead.

Once SSL is established, though, it switches to a block cipher (3DES, etc)which is much faster and the resource (network, cpu) overhead is pretty tiny bycomparison.

Summarizing from above: Using SSL incurs a 3.5x latency overhead for eachhandshake, but afterwards it's generally fast like plain TCP. If you acceptthis conclusion, let's examine how this can affect website performance.

Got firebug? Open any website. Seriously. Watch the network activity. How manyHTTP requests are made? Can you tell how many of those that go to the samedomain use http pipelining (or keepalive)? How many initiate new requests eachtime? You can track this with tcpdump by looking for 'syn' packets if you want(tcpdump 'tcp[tcpflags] == tcp-syn').

What about the street wisdom for high-performance web servers? HAProxy's sitesays:

"If a site needs keep-alive, there is a real problem. Highly loaded sitesoften disable keep-alive to support the maximum number of simultaneousclients. The real downside of not having keep-alive is a slightly increasedlatency to fetch objects. Browsers double the number of concurrent connectionson non-keepalive sites to compensate for this."

Disabling keep-alive on SSL connections means every single http request isgoing to take 3 round-trips before even asking for data. If your server is100ms away, and you have 10 resources to serve on a single page, that's 3seconds of network latency before you include SSL crypto or resource transfertime. With keep alive, you could eat that handshake cost only once instead of10 times.

Many browsers will open multiple simultaneous connections to any givenwebserver if it needs to fetch multiple resources. Idea is that parallelismgets you more tasty http resources in a shorter time. If the browser openstwo connections in parallel, you'll still incur many sequential SSL handshakesthat slow your resource fetching down. More SSL handshakes in parallel meanshigher CPU burden, too, and ultimately memory (per open connection) scales morecheaply than does CPU time - think: above, one active connection cost 22ms oftime (most of which is spent in CPU) and costs much more than that connectionholds in memory resources and scales better (easier to grow memory than cpu).

For some data, Google and Facebook both permit keep-alive:

% URL=https://s-static.ak.facebook.com/rsrc.php/zPET4/hash/9e65hu86.js% curl  -w "tcp: %{time_connect} ssl:%{time_appconnect}\n" -sk -o /dev/null $URL -o /dev/null $URLtcp: 0.038 ssl:0.088tcp: 0.000 ssl:0.000% URL=https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js% curl  -w "tcp: %{time_connect} ssl:%{time_appconnect}\n" -sk -o /dev/null $URL -o /dev/null $URLtcp: 0.054 ssl:0.132tcp: 0.000 ssl:0.000

The 2nd line of output reports zero time spent in tcp and ssl handshaking.Further, if you tell curl to output response headers (curl -D -) you'll see"Connection: keep-alive". This is data showing that at least some of big folkswith massive qps are using keep alive.

Remember that new handshakes are high cpu usage, but existing SSL connectionsgenerally aren't as they are using a cheaper block cipher after the handshake.Disabling keep alive ensures that every request will incur an SSL handshakewhich can quickly overload a moderately-used server without SSL accelerationhardware if you have a large ssl key (2048 or 4096bit key).

Even if you have SSL offloading to special hardware, you're stillincuring the higher network latency that can't be compensated by fasterhardware. Frankly, in most cases it's more cost effective to buy a weaker SSLcertificate (1024 bit) than it is to buy SSL hardware - See Google's Velocity 2010 talk on SSL.

By the way, on modern hardware you can do a decent number of SSL handshakes persecond with 1024bit keys, but 2048bit and 4096bit keys are much harder:

# 'openssl speed rsa' done on an Intel X5550 (2.66gHz)rsa 1024 bits 0.000496s 0.000027s   2016.3  36713.2rsa 2048 bits 0.003095s 0.000093s    323.1  10799.2rsa 4096 bits 0.021688s 0.000345s     46.1   2901.5

Fixing SSL latency is not totally trivial. The CPU intensive part can behandled by special hardware if you can afford it, but the only way sure way tosolve network round-trip latency is to be closer to your user and/or to work onminimizing the total number of round-trips. You can be further from your usersif you don't force things like keep-alive to be off, which can save you moneyin the long run by letting you have better choices of datacenter locations.