[Bloat] Testing Queue models

[Bruce Atherton]

Well, port 80/443 is only the default for Websockets. People running 
standalone WS servers are encouraged to use unique ports.

There are two main reasons to have those defaults though:

1) Webapps that use both HTTP and Websockets, which is after all the 
most common usecase, benefit from having a single server that routes the 
connection reasonably far down in the stack so that maximum reuse of 
code can occur.

2) System administrators in many companies are incredibly resistant to 
opening up new ports. They have to open port 80 and sometimes 443. This 
makes ports 80 and 443 "magic" ports in these environments, the kind 
that are the only ones that third party webapp developers can rely on. 
Sad but that is the way of the world. I say this as a third party webapp 
developer.

On 2/17/2012 6:22 AM, Dave Taht wrote:
> On Wed, Feb 15, 2012 at 2:08 AM, Bruce Atherton<bruce at callenish.com>  wrote:
>>
>> On 2/1/2012 12:46 PM, Dave Taht wrote:
>>> I don't have a whole lot of hope for classification. In fact, I'm kind of
>>> upset that the move away from flash means we are seeing more video streams
>>> on port 80, rather than on the macromedia port...
>>
>> It may be worse than that in the future. Now that Websockets is RFC6455 the
>> nature of traffic on port 80 may change a lot. Roy Fielding was so concerned
>> about it that he asked that a security note be added to the draft spec.
> What we conventionally think about as the need for firewalling and
> threat models is increasingly irrelevant, particularly with the advent
> of new - and standardized, even! - tunneling models like this, as well
> as devices that live on 3g and wireless at the same time, etc.
>
>> No idea what that will mean for your efforts here.
> Running the entire internet through port 80 and 443, and further,
> tunneling new applications through that, rather than using specialized
> and well defined protocols seems like the wrong thing.
>
> I have a rant on this topic that amusingly dates to around the time
> I'd got involved in the bufferbloat effort...
>
> <rant>
> http://nex-6.taht.net/posts/Beating_the_speed_of_light_on_the_web/
> </rant>
>
> It's something of a consequence of nat, and may well be a wedge to try
> and make ipv6 'more right'...
>
> On my very backlogged 'round-to-it' list has been writing an xtables
> module for multi-protocol matching, as the current methods for
> matching protocols (at least in linux) only support a single match,
> and as you add protocols becomes tedious, error prone, and slow.
>
> iptables -I INPUT -p tcp -j ALLOW
> iptables -I INPUT -p udp -j ALLOW
> iptables -I INPUT -p 41 -j ALLOW
> etc.
>
> Better would be something that did a lookup against a 256bit-map
>
> ip6tables -I INPUT -m protocols --protocols
> icmp,tcp,udp,igmp,rdp,dccp,rsvp,gre,esp,ah,ospf,ipip,pim,l2p,isis,sctp,udplite,manet,hip,shim6,wesp
> -J ALLOW
>
> In the hope that this would improve end-to-end connectivity,
> performance, and availability of new stuff in the general case as ipv6
> is rolled out.
>
> Regrettably I haven't got around to writing that bit, nor something
> similar for diffserv....
>
>
>