Re: HTTbis spec size, was: Rechartering HTTPbis

On Mon, Feb 06, 2012 at 07:26:22PM +0000, Poul-Henning Kamp wrote:
> In message <CA+9kkMAj1vnTsxe7OLRVHSMZmDF5F=u1MQ8oniLgd_TppXiQ1g@mail.gmail.com>
> , Ted Hardie writes:
> >2012/2/5 Henrik Nordstr=F6m <henrik@henriknordstrom.net>:
> 
> >So, two of the transports you list above (UDP and DTLS) are unreliable; is
> >reliability not a transport property you expect for HTTP message exchanges?
> >[...]
> >Of course you can build reliability on top of unreliable transports,
> 
> Lets try to be a bit more exacting with our vocabulary, shall we ?
> 
> TCP is not "reliable" any more than UDP is, many TCP connections
> fail, both during establishment and later.
> 
> What TCP offers is "we'll hide all the retransmissions and pretend
> to be much more reliable than the underlying network" which is often
> convenient.

I'd say there are different classes of problems with TCP. It's more
reliable under most common conditions and can be worse than UDP sometimes
(eg: high loss rate, multiple congestion controls stacked on top of each
other etc). But FWIW TCP is generally known as a "reliable" transport
mechanism.

> But for many HTTP-purposes, UDP would be good enough:  You send the
> request and either you get a reply or you do not.  That isn't very
> different from a TCP connection breaking.

I think this is what UPNP looks like, I've already caught many HTTP-looking
requests over UDP multicasts.

> Obviously, HTTP over UDP would be very exposed to DoS, so it should
> probably be confined to behind firewalls and other walled gardens,
> but I can certainly see the utility for a number of cases.

For small static files (eg: favicon.ico), UDP is much better suited than
TCP, one packet in each direction and let the client retry if it does not
get the response. You can extend the principle with content ranges where
the client asks to retransmit what it did not get. For the server it's
very convenient, no state to keep, everything runs at wire speed, no timeout
issues, no SYN_RECV nor CLOSE_WAIT states, etc... It's simply limited to a
very specific usage which might still cover most of the web's requests.

Regards,
Willy

Received on Monday, 6 February 2012 20:19:37 UTC