Deployed CDN and HTTP/2.0 but I finally reverted back
CDN(Content Delivery Network)
My sites now have been deployed on KeyCDN.
It happened because one day overseas transfer in China was so bad, only 40kb per second, unfortunately a .js file of LNTU.ORG was so huge so that I have to wait over ten seconds for loading. How terrible.
At beginning I remembered that there are 10GB transfer in my Qiniu account, I put my .js file on Qiniu. The performance was amazing, the duration of this file shortened to less than one second!!
Since that I found CDN was an amazing stuff, but at last I gave up Qiniu because of the stupid ToS and the stupid government.
If you are an individual user, you want to use SSL, ok, just submit a request, and wait for 2 work day. Fuck you, I applied it at Oct 4, and passed at Oct 8. I applied it for another repo on Oct 8 evening (Thursday), and now(Sunday) it still in pending. WTF
What's more, if you want to use your independent domain, first you have to '备案', '备案' means your name and phone and photo and domain name and server IP address must be on record by Chinese government so that they can contact you easily if there are some things on your site they didn't want to see. And independent domain don't support SSL.
Even worse, personal user's service agreement did't contain any overseas network node, and international friends can hardly open my site. Qiniu Fuck Out Away!
So I chose the KeyCDN, they have many network node in the world. $0.04 per GB transfer, and free for pull zone's storage, but $0.45 for a GB storage per month for push zones.
After a free try you must pay at least a $25 billing, you don't need to buy any packages, just pay as you go, the rule still work on the push zone(If your push zone take 512MB space, you should pay $0.45*0.5GB per month, I have confirmed this rule with Costumer Service).
But how to deploy it correctly, that's my thought.
CDN is not a reverse proxy. Never.
Some Chinese CDN provider like Baidu Cloud Speed, Qiniu CDN and ect, blind pursuit of deploying CDN with one click, causing many personal site master to think deploying CDN is easy. It was completely wrong.
Using CNAME method or NS method will cause many strange problems, such as login failed, cookie error, recorded by Google search engine, and more.
The best way to deploy CDN is to deploy as you go.
There are two situations:
- js, css, and other stuff never changed or hardly changed(my blog, resume, and project site)
- js, css, and some avatar changed on real time(my bbs)
For the first situation, I need a push zone to storage my static files, and the push zone can store multi sites' static files. Actually I did do it this way.
For the other situation, I need a independent pull zone, you say login action wouldn't work by using CNAME method ? OK, we can just change the js, css, and avatar url to CDN, so the login action worked perfectly.
All in all, deploy as you go. We just need js files on CDN, so we do it.
Why I dont use CDN afterwards
In the first instance, my site was deployed on DigitalOcean, and thanks to the Chinese government I got a fascinating network route.
In this case, I have to wait more than 8 second for a 500kb js file loading. Why don't you just kill me instead.
So I start to use a CDN, and the performance was amazing, you can read All my sites have been deployed on CDN and HTTP/2.0 for more details. Even it was on a CDN, it still cost nearly 2 second to load fully.
But now, my VPS has been moved to Chinese Mainland, with SPDY and CDN, I found some problems.
If I use a CDN, SSL hand shake would perform twice or more, why I said or more
, let's make a list
- Original server SSL negotiation
- CDN server SSL negotiation
Where is the third negotiation?
Font rendering will be executed at last since we use a modern browser, the same to favicon.
Sometimes the download of font would ask for a new session (I had tested it on Chrome), which means browser would perform another hand shake with server, just like the picture above (the purple part mean SSL hand shake).
How to solve this problem, I don't know, I know HTTP/2.0 (SPDY) was doing some work on HTTP multiplexing, prioritization, and server push. In some ways I think HTTP/2.0 have a better performance on HTTP multiplexing.
So I tried to move the font file to the original server, fortunately, I did it.
With h2 protocol, the last request don't need to create a new SSL connection.
What's more, sometimes I got a strange TTFB delay, over 200ms. The TTFB value is the DNS lookup time + the initial TCP handshake + the time it takes to receive the first HTML header response.
Since I drop using a CDN, the problem never appeared again.
So, if you'd like to share assets to another domain, you are going to lose all of the benefits of SPDY.
That's why I drop the CDN.