This is also not discussing the problem that ISPs allow (relayed) amplification attacks because they don't think it's their responsibility to track where traffic comes from and where traffic is supposed to go whereas I would disagree on that. ![]() Server administrators then face the decision to either drop the mobile world completely or be faced with a situation where a couple malicious actors can take down their infrastructure with simple methods like even a slowloris or a SYN flood attack. The reason why servers on the web are so easily DDoS-able is because of long-lived connection defaults among most higher-level protocol implementations.and because ISPs all over the globe intentionally throttle initial connections by up to 30-60 seconds for the initial SYN/SYN-ACK when their "flatrates" run out on mobile networks. The issue I have with it: It's showing how the problem can be solved for systems that you are in control of, but not for systems (clients) that you aren't in control of. This article is nice and it shows clearly what kind of problems servers for TCP-based infrastructure on the internet have to face. Or maybe those things are mostly just saving mics when the latency over the wire is millis. Many of those things can make servers more efficient but that might not be necessary if many servers are needed at lots of edge locations with each server not needing efficiency. ![]() Maybe the hardware is more expensive than underutilisation or hard to source or buggy or user space networking just doesn’t improve things much. I’m sure cloudflare have reasons for it though. The main advantage would be having more control over their system and the ability to avoid a lot of unnecessary overhead from syscalls or apis, but there could be other advantages like NIC TLS (though this can also be accessed through the kernel as kernel TLS). I would have expected their main products (ie being a CDN) to use more specialised network cards and userspace networking (eg the final function they give for UDP does a ton of syscalls, and for tcp it still does several) with a non-BSD api. I think one thing that weakly surprised me about the article was that cloud flare seem to be mostly using standard BSD sockets apis and, presumably, the kernel interface to the network cards. Running out of ports may affect short-lived connections too: by default when you (the client) close a connection, it goes into a ‘TIME_WAIT’ state that locks up the quadruple for (by default) 2 minutes to protect new connections with that quadruple getting packets that were meant for the previous connection. ![]() The problem with bind before connect is that the OS thinks you might call listen after bind instead of connect and listen requires the src port/ip to be unique. A few things that weren’t mentioned in detail or which I skimmed over without noticing:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |