From: Bruce Atherton <bruce@callenish.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Testing Queue models
Date: Fri, 17 Feb 2012 13:55:24 -0800 [thread overview]
Message-ID: <4F3ECCCC.3060009@callenish.com> (raw)
In-Reply-To: <CAA93jw4jx8bwa1m2LQEQKGmAHHv-f+Sxq+Dj7vP5Bhtxu68eoA@mail.gmail.com>
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@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....
>
>
>
prev parent reply other threads:[~2012-02-17 21:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-01 17:12 Dave Taht
[not found] ` <A8F77CC3-7B92-4979-A631-2921E66F1E95@gmx.de>
[not found] ` <CAA93jw50eQHiQHGh0V1z6vT1vxfo3ShJL8TAOprdCOiYHZAq3Q@mail.gmail.com>
2012-02-01 19:17 ` Sebastian Moeller
2012-02-01 19:49 ` Dave Taht
2012-02-01 20:08 ` Justin McCann
2012-02-01 20:38 ` Dave Taht
2012-02-01 20:46 ` Dave Taht
2012-02-15 2:08 ` Bruce Atherton
2012-02-17 14:22 ` Dave Taht
2012-02-17 21:55 ` Bruce Atherton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F3ECCCC.3060009@callenish.com \
--to=bruce@callenish.com \
--cc=bloat@lists.bufferbloat.net \
--cc=dave.taht@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox