问题
Update 2013-04-25:
This is a popular question that is getting more attention than it probably should. In order to stop the spread of misinformation please read the following paragraphs and the accompanying article first:
Speed should not be a factor in deciding whether to use HTTPS or HTTP. If you need HTTPS for any part of your site (log-ins, registration, credit cards, etc), you absolutely need HTTPS for all of it, all the time.
Please read SSL is not about encryption by Troy Hunt for the reasons why.
I'm considered running my entire e-commerce website under https. I decided to run a crude benchmark to measure the download time of a 156KB image through https vs http because I had read that https is burdened with additional overhead from the encryption process.
Benchmark was performed using Firefox's Firebug simply by transcribing the "Waiting" and "Receiving" times (all other times are 0) to Excel from the Net panel when downloading the image from an empty cache.
My results were unexpected:
http: 11.233 seconds
Waiting Receiving Total
1.56 0.88 2.44
1.55 0.101 1.651
1.53 0.9 2.43
1.71 0.172 1.882
1.9 0.93 2.83
https: 9.936 seconds
Waiting Receiving Total
0.867 1.59 2.457
0.4 1.67 2.07
0.277 1.5 1.777
0.536 1.29 1.826
0.256 1.55 1.806
[Obvious] Observations from benchmark:
- The server response is faster but the download time is slower for https than http.
- https is faster overall by a significant amount (~10%).
Can anyone explain why this would happen?
Do you think a document (html,css,javascript) will give different results?
Does anyone have a better method of benchmarking downloads?
Here is the test image:
[test image removed]
Additional Information:
- The website is on a shared hosting account through Godaddy.com.
- If you are going to be so kind as to run your own benchmark don't add the "www" subdomain...I use the root for static content anyway.
- Uses IIS7 in Integrated Pipeline Mode.
Edit: benchmark for 1px GIF (35 bytes) below:
http: 2.666 seconds
Waiting Receiving Total
0.122 0.31 0.432
0.184 0.34 0.524
0.122 0.36 0.482
0.122 0.34 0.462
0.126 0.64 0.766
https: 2.604 seconds
Waiting Receiving Total
0.25 0.34 0.59
0.118 0.34 0.458
0.12 0.34 0.46
0.182 0.31 0.492
0.134 0.47 0.604
Results: https is still faster; though trivially in this case.
If anyone sees a flaw in my benchmark let me know so I can post better results.
So, on Godaddy shared hosting at around 6:00pm on my specific server content served over https is faster than over http.
回答1:
If you look at your times http has bigger waiting time and smaller receiving time. https on the other hand has smaller waiting time and bigger receiving time. I would interpret this as the http port on the shared hosting server is more busy, thus a request stays longer in the queue until is accepted by the server. Once accepted, the requests is transferred faster than https. On the https port there is less traffic on the server so the request is serviced faster but takes longer to transfer.
For any https vs. http comparison you'll have to take into account the bigger time to handshake each request for https compared with http. You should see worsening when doing many small requests.
回答2:
You may also want to take into account that HTTPS documents will almost never be cached anywhere except the users browser, so you might find that while there's little difference to an individual user, an HTTP document can be significantly quicker for large numbers of people sharing a cache. (It's still quite common in some places for ISPs to put their customers through a shared proxy cache)
If it's something that you don't mind users sharing, of course.
回答3:
I think the faster performance you're seeing over HTTPS isn't a fluke.
Notice two things about your results:
- HTTP is always faster on the first "total" result, but slower in subsequent totals.
- The HTTPS results are more consistent.
Modern load balancers typically enable compression while SSL is in use to aid performance. While it's true that the initial SSL handshake incurs substantial latency, the mechanisms used to maintain the session (the "resumed handshake" and symmetric encryption instead of asymmetric encryption) add only negligible latency. As a result, unless your sessions are short, you get more performance benefit from the compression than you lose from the session maintenance.
The conventional wisdom that SSL incurs substantial latency is out of date (unless your sessions are quite short). Some Google engineers wrote an article explaining how some previous assumptions about SSL are no longer true.
回答4:
https works as follows: First a 4-way handshake is performed (at least if i remember correctly it was 4way), here client and server agree on the symmetric encryption algorithm used later on and exchange certificates (containing public keys).
They exchange a session (key for the symmetric enc later) using publickey crypto.
Now they send messages encrypted with the session key and some encryption algorithm (3des, aes, rc4, rc5, etc). Since symmetric encryptions are not that expensive operations the differences in download time are not that big.
The fact that you have less waiting time is because you probably have less traffic on http port or less traffic at the time you did the https request compared to the http requests.
So to optimize performance you should use as few https connections as possible since the handshake is a relative expensive procedure.
回答5:
Are you accessing your site through a proxy? If so, you may be seeing better performance because the proxy is being bypassed or reduced to just using handling the initial CONNECT requests.
A proxy could be checking and caching content when you use HTTP - leading to reduced performance.
回答6:
The whole difference in speed is most likely due to GoDaddy enforcing HTTP Compression on their servers in an effort to conserve bandwidth, but this is something that doesn't always occur with the HTTPS style connection as it is newer and better optimized to start.
来源：https://stackoverflow.com/questions/1468648/https-vs-http-speed-comparison