CloudFlare Now Supports WebSockets | Hacker News Reader

CloudFlare Now Supports WebSockets

blog.cloudflare.com

171 pointsjgrahamc32 comments

I'm a super big fan of CloudFlare and I especially appreciate when a CEO / Co-founder of a successful company stays so close to it's customers by writing a detailed blog post about features/problems they achieved/solved.

And I can confirm that he really did write this blog post (it wasn't ghost written). A few folks internally checked it for accuracy, but Matthew does like to stay on top of the technical details.

After all, we are selling a technical product.

Thanks, that's kind of you to say. One of my favorite parts of my job is I am surrounded by really smart engineers who I constantly learn new things from. In this case, Marek spent a bunch of time with me walking through the innards of how Linux sets up a socket. Was a lot of fun to learn about and write up. If you want an even more technical post on the subject, you should check out his blog:

https://idea.popcount.org/2014-04-03-bind-before-connect/

That was a great read. Nice job.

You mean he didn't just tell you to go read Beej's guide [0]?

Joking aside, I really enjoy reading Cloudflare's blog posts. I know they don't just pop into existence without some serious effort. Thanks for taking them seriously.

[0] http://beej.us/guide/bgnet/

Definitely appreciate this a lot. I am sure he gets it reviewed by a few people who are closer to the metal.

This is a great way for him to be on top of all the technology that goes in his extremely technical company. Moreover, him understanding the details from the engineers, then writing a blog post about it, and then getting it reviewed by the engineers ensures that the blog post will be understandable for the customers, who are likely to be at (or slightly below) his level of understanding of this technology, not the engineers who actually implemented the thing.

Something seems off on the second code example under "Safely Reusing Ports". `s.connect()` is inside the try/except block, which is great, except that both cases in the `except` re-raise something, which means the loop will only ever execute once. Am I misreading that?

Not that that takes anything away from the functionality, of course. CloudFlare is great and I'm excited to see that they're offering web socket support.

Thanks for pointing that out. It's a problem with the indentation of the pseudo-Python code in our blog editor. I've fixed it.

Thanks! Now it makes much more sense.

Isnt't websocket used mainly for event based communication to clients ? That would seem like something absolutely impossible to cache or proxy, not because of the technology itself but because the content seems almost specific every time. What would the be the business case for using cloudflare with websockets ?

People want to protect all their public 'web' IPs using CloudFlare. That means they have to be able to protect anything that uses WebSockets, so we have to proxy it. Now we do.

Right. I had a site using CloudFlare and it was inconvenient having to have a bypass rule for a subdomain (ws.example.com) for WebSocket and having everything else on the main domain.

Thanks, i completely forgot about the dos aspect.

As I understand it Cloudflare doesn't cache non-asset traffic (like html pages) by default unless you put it on a whitelist on a paid plan. I think the business case is to protect against DDOSes by having Cloudflare route the traffic off your origin servers.

You can setup a PageRule (basically an exception) on any plan level and tell us to cache an entire page (including HTML) if you use the "cache everything" option. This is available at the free level also. With the paid level plans you get more PageRules, but at the free level you still get 3 PageRules.

With "cache everything" used correctly (to ensure you're not accidentally telling us to cache something like a login form CloudFlare can easily handle 98%+ of all requests for your high traffic pages.

Thanks. I should have looked at your pricing/features page before I commented. I was looking there last week and only 1/2 remembered correctly.

No worries. Just wanted to mention. :)

PageRules are extremely powerful. Using "cache everything" can also make a huge difference is setup correctly.

Uncacheable content can still benefit from a CDN, by connecting to a local edge node and having the rest of the traffic go over the CDN's internal network.

http://www.cloudflare.com/railgun

There could be a huge benefit for someone who wants to send websocket frames to say, 100,000 clients. You can't do that with a single server; you'd run out of ports (reuse aside). You'd also have a lot of load on one server. At the cost of a little latency to the true event, you can increase performance and scalability dramatically by sending the event to just a few intermediaries that then broadcast the event to a subset of clients.

I don't think this feature functions as a fanout mechanism.

FWIW, we provide this at Fanout.io. Our service is able to act as a passthrough proxy for WebSockets, not as a DDoS protection service like CloudFlare, but to handle large one->many deliveries as you describe. You can publish a message once, and it can be injected downstream into any number of open connections.

> There could be a huge benefit for someone who wants to send websocket frames to say, 100,000 clients. You can't do that with a single server; you'd run out of ports (reuse aside).

You would not run out of ports, as long as your clients have some IP diversity. Connections must be unique with the key being the 5-tuple: {Protocol, SourceAddr, SourcePort, DestAddr, DestPort}. If you have one server listening on one port, each client address can theoretically have 65535 connections (in practice, you're unlikely to find a client that will allocate their ports well enough to use all the ports).

Assuming your websockets are mostly idle, handling 100k connections for one server doesn't really need that big of a server either, see WhatsApp blog post about 2.2 million connections on one server in 2012: http://blog.whatsapp.com/196/1-million-is-so-2011 Caveats: dual 6-core westmere cpu, 100 G ram, normal connection count is lower per server; connections are mostly idle; some tuning required. See also 2.8 M connections documented on page 16 of Erlang Factory presentation: http://www.erlang-factory.com/upload/presentations/558/efsf2...

To compound on everything said here: traditionally, you would either have a set of load balancers, or set of web servers, taking requests directly from clients. If someone wanted to DDoS you, they hit the public IPs of these machines. It can be nearly impossible to mitigate a large enough attack to the point of restoring normal service. You'd most likely be forced to switch to entirely new IPs for a long enough attack event. CloudFlare, in general, accomplishes their DDoS protection by having a super large, geographically redundant network that absorbs the attack before passing legitimate traffic on to your servers.

This problem isn't strictly related to HTTP requests - it's really anything running on your servers. If the request is able to get past firewalls, switches, routers, to your machine, it has a chance to eat up resources, and ultimately take down that server / service. WebSockets are being used more and more for event-based communications, as you mentioned, providing real-time updates instead of relying on polling, or long polling hacks. Thus, they're just as viable of an attack vector as directing an attack at port 80. This is where the intermediate layer, provided by CloudFlare, comes into play.

The caching aspect of CloudFlare is an important, but separate aspect of their service.

CloudFlare, in general, accomplishes their DDoS protection by having a super large, geographically redundant network that absorbs the attack before passing legitimate traffic on to your servers.

That's part of the answer. But also we do very high packet rate filtering using stuff like this: http://blog.cloudflare.com/bpf-the-forgotten-bytecode

I simply opted to call out your network because that is the mechanism that hides the origins, despite the other layers of protection provided by software running at the edge. :)

Like Cloudflare alot. I've dropped web sockets in favor of SSE personally, but I've been very happy with their caching so far even on the free plan.

If my vague memory is correct, using SO_REUSEADDR can (at least theoretically) cause (undetectable) TCP issues. If a connection on a particular (source address, source port, destination address, destination port) tuple is closed locally and then another connection is opened on the same tuple _before_ the TTL time has passed, the new connection may receive (sans error) data which was intended for the old connection (again, IIRC).

Wouldn't the sequence numbering differ?

Yea at least given modern ISN generation mechanisms I would think it would. Back when I was looking at it, the typical means of ISN generation may have been more naive?

I'm also hazy on the exact fail case...it may also have had something to do with a FIN message getting lost, though I would think that would also be handled by the sequence number.

I skimmed the article looking for information regarding IPv6 support. Is it possible for a client to establish an IPv4 socket to CloudFlare and then CloudFlare talk to my server over IPv6?

Yes, we support that.

That's awesome. Thank you!

I'm thinking of using something like this: https://github.com/sstur/node-websocket-tunnel to allow access to StackMonkey instances by way of an IPv4 route if the customer doesn't have IPv6 enabled on their network.

Reply on news.ycombinator.com