Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Https hurts users far away from the server

antoine.finkelstein.fr

Post reply on HN
Print view View original

121–128 of 128 posts

Re: Https hurts users far away from the server

#121

Post by aanm1988 »

kuschku wrote: post #118
aanm1988 wrote: post #110

> In our case at Hunter, users were waiting on average 270ms for the handshake to be finished. Considering requests are handled in about 60ms on average, this was clearly too much. Why? Did it hurt user engagement? Were people complaining the site was slow?

The question is "is this the best we can do?". If it’s no, then clearly we should improve.

By spending time and effort on things that may not actually matter?

To their credit this post talks about improving the performance, instead of just using it to complain about they can't use https because of a difference in a metric that may or may not actually cause end users any pain.

Re: Https hurts users far away from the server

#122

Post by kuschku »

aanm1988 wrote: post #121
kuschku wrote: post #118

Earlier quoted context omitted.

The question is "is this the best we can do?". If it’s no, then clearly we should improve.

By spending time and effort on things that may not actually matter? To their credit this post talks about improving the performance, instead of just using it to complain about they can't use https because of a difference in a metric that may or may not actually cause end users any pain.

You do realize that every latency you see on residential connections is magnified on mobile or even satellite connections?

If you have a RTT of seconds, 10 additional roundtrips can cost an entire minute.

These things become very noticeable very quickly if the system is in non-perfect environments.

Additionally, even with modern browsers it takes far too long to open a website — it should be 100% instant, less than one or two frames (16 or 33ms). That's not possible, as RTT is usually around 18ms between users and CDN edges, but at least it should be below perceivable delays (100ms).

EDIT:

My best websites hover around 281ms to start of transfer, and 400ms to the site being finished.

That's improvable, but most sites out there take literally half a minute to load.

Now go on a 64kbps connection, and try again. Handshake takes seconds, start of transfer is almost after 30sec, and by the time your website arrives your coffee has gone cold (a few minutes for a google search).

Years ago, Google was usable on dial-up. Now even the handshake takes as long as an entire search used to take. Notice anything?

Re: Https hurts users far away from the server

#123

Post by mfontani »

pbarnes_1 wrote: post #104
mfontani wrote: post #38

Yup, and that's why for thereg we started using Cloudflare's Railgun… with it, the connection to the servers (hosted in the UK) is "bearable"… without, it's abysmal: From a VPS in Sydney, with a Good Enough bandwidth: root@sydney:~# speedtest-cli 2>&1 | grep -e Download: -e Upload: Download: 721.20 Mbits/s Upload: 117.89 Mbits/s … doing the request through Railgun is "quite bearable": root@sydney:~# ./rg-diag -json h…

Did you try CloudFlare without Railgun? That would be interesting.

Sure, let's do just that… from the same location in Sydney; origin server hosting the content is in UK. This domain is on their "free" plan, as it gets hardly any traffic.

  root@sydney:~# ./rg-diag -json https://thereglabs.com/ | grep -e elapsed_time
    "elapsed_time": "0.863677s",
So that's from Sydney to the UK, with https served by Cloudflare. The webapp serving that isn't the sharpest knife in the drawer, but when tested on localhost it replies in 0.015s – the rest is time taken moving bytes across the world.

    root@sydney:~# time curl -sH 'Host: thereglabs.com' -H 'Cf-Visitor: {"scheme":"https"}' http://THE_ORIGIN_SERVER/ -o/dev/null
    real	0m0.821s
… and this is plain HTTP to the origin server: the free plan is great for offloading HTTPS at basically no cost in time added.

We've got another domain on the business plan… so let's try that one.

This is an _image_ request, which is _cached by cloudflare at the edge_:

    root@sydney:~# ./rg-diag -json https://regmedia.co.uk/2016/11/09/hypnotist_magician_smaller.jpg  | grep elapsed_time
    "elapsed_time": "0.239641s",
Lovely, the "local caching" of their CDN helps a ton!

… compared to if we were to request the same file from the ORIGIN_SERVER over HTTP:

    root@sydney:~# ./rg-diag -json http://ORIGIN_SERVER/2016/11/09/hypnotist_magician_smaller.jpg  | grep elapsed_time
    "elapsed_time": "0.704458s",
… but our "origin server" _also_ is likely to have the image in the "memory cache"…

… and that image was likely in their cache; so… let's add a parameter so they _will_ have to ask the origin server:

    $ pwgen 30 2
    Eehacoh2phoo1Ooyengu6ohReWic2I Zeeyoe8ohpeeghie3doyeegoowiCei
There you go… two new randomly generated values…

    root@sydney:~# ./rg-diag -json 'https://regmedia.co.uk/2016/11/09/hypnotist_magician_smaller.jpg?Eehacoh2phoo1Ooyengu6ohReWic2I=Zeeyoe8ohpeeghie3doyeegoowiCei'  | grep elapsed_time
    "elapsed_time": "1.198940s",
Yup, took quite a bit longer than the 200ms it took when the image URL was fully in their cache.

All in all, from the point of view of being able to _easily_ serve people on the other side of the world with a "good enough" (not great, mind you!) response time, both "standard" Cloudflare, the "pro" offering _and specifically_ the "business" offering are just effin AWESOME.

Re: Https hurts users far away from the server

#124

Post by rocqua »

chatmasta wrote: post #70
rocqua wrote: post #66

Earlier quoted context omitted.

Domain validation only requires an HTTP response. They can easily MitM that specific response to fake a certificate for your domain.

Got it. But this only happens once when you apply for the cert (or renew it), correct?

I'm not sure if letsencrypt (or other CAs) are willing to give out multiple DV certs for the same domain. I'd guess they do, so anyone that can MitM you and the CA can get a DV cert.

Re: Https hurts users far away from the server

#125

Post by rocqua »

hedora wrote: post #73
rocqua wrote: post #66

Earlier quoted context omitted.

Domain validation only requires an HTTP response. They can easily MitM that specific response to fake a certificate for your domain.

Yes. This. In particular, the company operating the data center your server is in can reliably do this, and so can the backbone provider they use, and probably the server's local government. The DNS provider that controls your domain can mitm the ca process too (though with a higher chance of detection). The argument for making domain validation yellow (and not red) is that domain validation protects against attacks…

Most of these issues aren't there with DNS based validation (presuming DNS-sec).

Though, that just shifts the potential problem towards anyone in the DNS-sec chain of trust. Most notably, the controller of the TLD (most often a government) and the registrar.

Thing is, those are also an issue with normal (http based) DV. After all, they could also change the A record for the domain they want a cert for.

I believe the current solution to all this is focused on detection rather than prevention (through certificate transparency and similar proposals). The idea being that any organization that isn't trustworthy will only get to pull of this hack once, in a short time frame before having their trust revoked.

Re: Https hurts users far away from the server

#126

Post by valarauca1 »

majewsky wrote: post #109
valarauca1 wrote: post #91

Earlier quoted context omitted.

Yes it is. The number of connections to one host isn't relevant in HTTP2. As ublock is blocking some ~20 connections these are going to different hosts. Connecting to a different host in HTTP2 is no different then HTTP1.1 If your HTTP2 is terminating at MANY boxes within your infrastructure you are failing to understand how HTTP2 works. Connections within a single TLS/TCP/IP connection are free, new TLS/TCP/IP connec…

Come to think of it, it's pretty ironic. For years, admins have been told to move static content to a different domain to trim down the request size (since browsers won't include the cookies for the main site). Now that might reverse, and it might be best to send all HTTP requests to the same server (for large sites: most likely some load balancer or haproxy or whatever) in order to benefit from HTTP/2 multiplexing.

HTTP/2 really seems more like a front end balancing and caching protocol.

Handle your TLS/HTTP2 termination on the same boxes and use HTTP1.1 within the internal network.

Re: Https hurts users far away from the server

#127

Post by JimDabell »

chatmasta wrote: post #63
afandian wrote: post #29

Earlier quoted context omitted.

Vodafone in the UK did this to me.

Vodafone is the worst. Although it's really the U.K. surveillance state that is the problem. When I popped my SIM into my iPhone it forced me to download a configuration profile with a self-signed Vodafone cert, which means they can mitm any connection. I think this is required by the government so they can block adult websites by default? (I've also seen torrent websites also fail silently with misleading "server no…

I don't know why Vodaphone are doing that, but you shouldn't go around telling people that it's because of "the U.K. surveillance state" because other UK ISPs don't do that.

The "server not found" errors sound like DNS blocking, which they can do without MITM.

Re: Https hurts users far away from the server

#128

Post by dalore »

jacquesm wrote: post #72
dalore wrote: post #71

Earlier quoted context omitted.

Adding http2 is easier then reducing the number of requests. And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2.

> And infact reducing the number of requests using things like spritemaps, bundling js and css is actually an antipattern with http2. Those are just ways to lose some of the impact of bloat without addressing the bloat itself. If you address bloat directly it will benefit all users.

If you shard on http2 it will take longer since now it makes multiple ssl connections which have have the ssl handshake.

With http2 it's all multiplexed into one connection. So you have the one ssl connection, but that one connection has multiplexed connections inside it. And since it's one tcp, the tcp sliding window has opened up and is actually faster then opening a new tcp connection.

Post reply on HN