bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] TCP Fast Open for HTTP


From: Tim Rühsen
Subject: Re: [Bug-wget] TCP Fast Open for HTTP
Date: Thu, 28 May 2015 20:30:36 +0200
User-agent: KMail/4.14.2 (Linux/4.0.0-1-amd64; KDE/4.14.2; x86_64; ; )

Am Donnerstag, 28. Mai 2015, 18:51:52 schrieb Giuseppe Scrivano:
> Hubert Tarasiuk <address@hidden> writes:
> > W dniu 28.05.2015 o 10:26, Giuseppe Scrivano pisze:> Hubert Tarasiuk
> > 
> >> I wouldn't even have an option for --tcp-fast-open and avoid adding such
> >> low level details to the command line.  I would rather go for an env
> >> variable like TCP_FAST_OPEN=1, that wget might honor or not and not
> >> worry where it is not supported.
> > 
> > What do you specifically mean by "not worry where it is not supported"?
> 
> I was just thinking loudly.  We are not going to support it on all
> platforms and I would like that the wget configurations work more or
> less portably.  An alternative would be to just warn the user if it is
> not supported (or even silently skip it).
> 
> After looking at the code, I think we should consider some performance
> numbers before we decide to include TFO in wget, to counter-balance
> the cost of the increased code paths we have to deal with.

Performance numbers:
https://reproducingnetworkresearch.wordpress.com/2014/06/03/cs244-14-tcp-fast-open-2/

In short: the faster the servers are, the higher the bandwidth is and the 
longer the distance (client<->server) is, the more does TFO matter. At least 
the servers are getting faster with time, also the bandwidth increases with 
time.

BTW, an alternative might be QUIC (http://en.wikipedia.org/wiki/QUIC). QUIC 
approaches the same problem (RTT). But it seems far from being standardized 
though there seems support in Apache and Nginx.

>> I would leave away the configure option --enable-tcp-tfo. Instead just use 
the 
>> constants defined in <sys/socket.h>, as Hubert already does.
> Why would you prefer to leave away that option from configure?

I said this because i couldn't imagine that someone wants to compile without 
TFO support, when TFO is supported. But I can't deny Giuseppe's above 
argument, so I am fine with a configure option. It really doesn't hurt.

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]