| |||||||||||||
But supporting SCTP has to start somewhere ? Why?But supporting SCTP has to start somewhere ? Why?Posted Nov 25, 2009 23:55 UTC (Wed) by foom (subscriber, #14868)In reply to: But supporting SCTP has to start somewhere ? Why? by smurf Parent article: Reducing HTTP latency with SPDY Because when people say "XXX is broken because of NAT", they actually mean "XXX is broken because of stateful connection tracking and filtering". They just say "NAT" because stateful connection tracking and filtering is an integral part of NAT, and NAT is the most use. Of course it's possible to do a the connection-tracking without the address rewriting, but the important thing to note it is not any less complex, and causes no fewer problems. It still prevents you from having an end-to-end internet. You still want to have protocol-specific parsing in order to find "related" connections which should be allowed through. (e.g. with FTP). You'd still need a protocol like uPNP or NAT-PMP in order to advise the firewall to open a hole for things like BitTorrent. There's almost no advantage at that point versus actually having a NAT.
(Log in to post comments)
But supporting SCTP has to start somewhere ? Why? Posted Nov 26, 2009 7:57 UTC (Thu) by smurf (subscriber, #17840) [Link]
>> There's almost no advantage at that point versus actually having a NAT.
Sure there is.
You avoid starving the router of TCP (or SCTP) ports. You avoid having to mangle TCP packets because they happen to contain addresses. You avoid IP address based "one-connection-per-client" limits on servers.
In short, you can use simpler servers and routers. Which translates to fewer bugs and less power-hungry CPUs.
|
|||||||||||||