7 ms·
Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
- sdan 7y agoLooks I don't need Cloudflare anymore XD.
- xmichael999 7y agoYes, it's "almost" comical. The advantage of having a CDN with a pop in every city, vs. just having 3 or 4 well placed POP's around the world will be marginal once HTTP3 is broadly supported.
- viraptor 7y agoI honestly can't tell if this is a serious take or sarcasm. I hope the latter...
- KirinDave 7y agoWhy do you say this?
- kizer 7y agoAside from lowering latency, a big "edge footprint" also naturally load-balances and allows for more specialized localization, from what I can think of off the top of my head. I don't have much practical experience here so correct me if my speculation is off, anyone.
- vasilia 7y agoHow about 0-RTT replay attack protection?
- regecks 7y agoWell, "ssl_early_data" is opt-in. If you enable it on a virtualhost, then you also need to look at the "Early-Data" request header in your backend and make a decision there. e.g. process GET requests, otherwise send HTTP 425 Too Early. It does seem a bit unsafe. An administrator might opt-in because they copy-pasted it from a tutorial, and not understand or pay attention to the second part.
- vasilia 7y agoI think it will be better to fully disable early data for people without full control of DC's network equipment. I don't know why Cloudflare made a decision about using headers and Too Early response. They have full control of their POPs. It will be better to measure RTT and use UDP based KV storage with tickets only for clients with high RTT. So for clients with RTT higher then access to KV storage it will be better to issue tickets, for other clients it will be better to drop early data and use full handshake. Currently, I'm working on a project with the same idea.
- tialaramex 7y ago> It will be better to measure RTT To measure RTT you need to perform a round trip. Hence the name. But the _whole point_ of this feature is to avoid incurring the cost of an extra round trip if possible.
- vasilia 7y agoThere is no need to send extra data to measure RTT. On the TCP handshake SYN/ACK you already know RTT. Linux kernel provides this info in tcp_info data structure.
- cafxx 7y agoYay! Nothing better than to put something that screams "bleeding edge" to handle all your traffic. YOLO, amirite? update: I love the unexplained downvotes, can't help but feel that as there's no argument they can make against what I wrote they are implicitly acknowledging that the point I made is, as it happens, correct.
- midev 7y agoI'll explain it, if you'd like. Correct, no one is making an argument against what you said, because everyone understands that point. For most people, it doesn't need to be said. No one is ripping out production infrastructure and replacing it with this image. There's no comment anywhere suggesting it. What you're doing is called "preaching to the choir". You're trying to be a contrarian to show everyone how smart and mature you are. Yolo, amirite? But not you! You're thoughtful and have experience and know not to do this! You're still running Debian Stable! But really, this is just a cool Show HN project, posted on a Sunday night, and no one cares about your thoughts on the risk of bleeding edge. So they downvote and move on.
- cafxx 7y agoThanks for the labels. Appreciated how you put me in my rightful place. Sorry if I'm being such a joy killer. I guess I've been witness to too many failures for not feeling to call this out before someone gets burned. Oh right, but no one needs to be told to be careful, right... No one is here to learn anything, as we all already know everything. Makes you wonder what's the point of showing something new in the first place. And please spare me the "no-one suggested to replace prod infra with this". Does the readme say anywhere "experimental, not for prod use"?
- midev 7y ago> Sorry if I'm being such a joy killer. I guess I've been witness to too many failures for not feeling to call this out before someone gets burned. But you didn't do it in a constructive way. You did it in a condescending way to make yourself appear better. Yolo, amirite? You could have had a constructive comment, explaining the level of support of various technologies, their maturity within nginx, etc. All of that would have been beneficial, discussing real world implications of things. > Oh right, but no one needs to be told to be careful, right... No one is here to learn anything, as we all already know everything. Makes you wonder what's the point of showing something new in the first place. No, some people need to be told to be careful. You didn't do that, though. You jerked yourself off. Likewise, the point of showing something new is to get real feedback. Again, which you didn't provide. > And please spare me the "no-one suggested to replace prod infra with this". Does the readme say anywhere "experimental, not for prod use"? You're the reason the iron needs to say "Do not iron while wearing clothes"
- djsumdog 7y agoI haven't been following the TLS1.3 development. What is the current state of SNI encryption? Is it possible to encrypt the name of the host you're trying to connect to?
- viraptor 7y agoThat's eSNI and I believe it's part of 1.3: https://tools.ietf.org/html/draft-ietf-tls-esni-04 https://tools.ietf.org/html/draft-ietf-tls-esni-04 Not sure what's the implementation status though.
- CaliforniaKarl 7y agoUnfortunately, it’s not part of TLS 1.3 yet. The link you posted is the right one, but it’s to the Internet-Draft. This is the step prior to becoming an RFC, where revisions are stored for everyone (including implementors) to use. So (for example) when you hear someone saying “I support TLS 1.3 Draft 8”, that means they support version 8 of the Internet-Draft. Once this is finalized and becomes an RFC, you’ll see it updated here: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ (and I’m sure someone here will post about it!)
- tialaramex 7y agoNo, it isn't part of TLS 1.3 At the point where the last drafts of TLS 1.3 were shaping up, Eric (Rescorla)'s initial ideas for how to achieve eSNI had failed and the extant draft was only a problem statement. It basically said: Here is what eSNI needs to achieve in our opinion, we don't know how to do that Between that point and when TLS 1.3 was published, several people brainstormed a proof of concept for how to actually make it work, which so far led to the draft you've linked. The eSNI draft is defined as an extension to TLS 1.3 but - since the whole point is to deny snoopers information about who we're talking to - if we have to "fall back" to not doing eSNI because the server isn't compatible then we lost. Cloudflare and Firefox devs cooperate to implement drafts of eSNI, so if you have a recent Firefox and a site which has opted into Cloudflare's trial of this feature, then it works for you, but the drafts definitely will change further and you should not go building anything based on this draft that you aren't able to support updating to future drafts or abandon altogether weeks or months from now.
- ricardbejarano 7y agoYou may find my NGINX image[1] interesting. There's some features you could easily add to yours in order to make it a better overall image. [1] https://github.com/ricardbejarano/nginx https://github.com/ricardbejarano/nginx
- SomeOldThrow 7y agoFor non technical users why ia this interesting?
- proverbialbunny 7y agoIt's not. But if you work on libraries that transfer http data around, this could be used to help test http/3 support.
- mnutt 7y agoI'm just curious, is there a reason not to use a multi-stage docker build here? There are a ton of build steps, and it seems pretty tedious to have to start from scratch every time while developing the image without any layer caching.
- ranadeep 7y agoHi, my main task this weekend was to get it fully working. I will break down the steps over this week to utilize cache layers. I will try to get it done hopefully this week or by the weekend depending on work. Thanks a lot for your feedback.
- techntoke 7y agoMight I suggest you use Skaffold for this task, which can work with regular Docker as well.
- chung1905 7y agoWhile developing an image, I use layers as much as possible. But usually, when the image is finished, I prefer to minimize the number of layers, it saves some (or little) storage (I think it will not > 10%).
- londons_explore 7y agoFewer layers also performs better in the final image. Things like listing a directory get very slow with thousands of layers.
- Leace 7y agoI suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario. This pattern of concatenating commands to have a minimal image is a workaround from times when multi-stage builds were not available.
- anfilt 7y agoI think 0-RTT is just bad idea security wise.
- tialaramex 7y agoGood news, any participants under your control can (and so should) refuse to do 0RTT. Clients can choose never to send early data and servers can choose to always reject it, everything still works. At the API layer reject any libraries or tools that try to foist this on you, many today either don't do 0RTT or correctly offer it as a separate API call for those willing to pay a price in terms of Replay resistance.
- anfilt 7y agoThat's even more concerning that there are libraries that hide such a thing. There is gonna be instances that bites someone hard where said replay is not idempotent.
- w-ll 7y agoOT: musl is pronounced like 'muscle' or do you spell it out 'm-u-s-l'
- cafxx 7y agoI would suggest highlighting the experimental nature of the repo, especially if someone reaches it without going through HN. I've read the catchy "All built on the bleeding edge. Built on the edge, for the edge." but IMO it doesn't really sound like a warning that this may not be suitable for serious production use.
- fulafel 7y agoFrom WP I get the impression that the work-in-progress now called HTTP/3 was not necessarily designed supposed to supplant HTTP/2: > On 28 October 2018 in a mailing list discussion, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Groups, made the official request to rename HTTP-over-QUIC as HTTP/3 to "clearly identify it as another binding of HTTP semantics to the wire protocol ... so people understand its separation from QUIC" Any opinions on how things are likely to play out?
- sseth 7y agoI believe this is the separation of the transport layer protocol (QUIC) from the application layer protocol (HTTP/3). QUIC can be seen as a replacement for TCP. HTTP over QUIC then becomes HTTP/3 - with improvements in latency and head-of-line blocking over HTTP/2. So in that sense it will supplant HTTP/2 as QUIC gets adopted more widely.
- LeonM 7y agoI've played around with the nginx cloudflare patches and quiche, and it all seems to work just fine in my lab setup. I don't like having to apply third party patches to any mission critical software such as nginx. So I'll wait until nginx releases official support for linking the quiche library, like they did with brotli.
- zegvold 7y agoI did exactly this 3 days ago, forked from fholzer/docker-nginx-brotli our work looks very much the same See https://github.com/githubcdr/docker-nginx-brotli https://github.com/githubcdr/docker-nginx-brotli
- The_rationalist 7y agoAre there any benchmarcks of http3? I would like to see how it compare vs http2 h2 + tcp fast open
- jwr 7y agoThis is great, and I'll be using it for development! However, I've been looking for something a bit more predictable, and yet still modern, for production use. I do not know why Brotli support isn't included in every nginx image at this point.