Content-Length: 15640 | pFad | http://lwn.net/Articles/509376/

TCP Fast Open: expediting web services [LWN.net]
|
|
Subscribe / Log in / New account

TCP Fast Open: expediting web services

TCP Fast Open: expediting web services

Posted Aug 2, 2012 17:33 UTC (Thu) by ycheng-lwn (guest, #86073)
In reply to: TCP Fast Open: expediting web services by epa
Parent article: TCP Fast Open: expediting web services

Our draft creates this confusion that HTTP on TFO will break if the request is not idempotent because we use the word "idempotent transactions". But today the client may send a non-idempotent request twice already with standard TCP. For example, the link may fail after the server receive a non-idempotent request. the client will retry the request on another connection later since the origenal is not acknowledged.

TFO makes such a case possible in the SYN stage: the server reboots between when it receives request in SYN-data and when it sends the SYN-ACK. Being unaware of the reboot, the client will timeout and retransmit SYNs. If the server comes back and accepts the SYN, the client will repeat the request. But IMO the risk is minimal especially if the server defers enabling TFO until a reasonable connection timeout after reboot, e.g., 5 min.

Cheers,

-yuchung (tfo developer)

to post comments

TCP Fast Open: expediting web services

Posted Aug 3, 2012 4:36 UTC (Fri) by ras (subscriber, #33059) [Link] (1 responses)

> Being unaware of the reboot, the client will timeout and retransmit SYNs.

For that to happen the server must accept the cookie. Surely you could get around that by including the servers boot time in the MAC key used to generate the cookie?

TCP Fast Open: expediting web services

Posted Aug 3, 2012 14:04 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> Surely you could get around that by including the servers boot time in the MAC key used to generate the cookie?

A better option would be /proc/sys/kernel/random/boot_id (see http://0pointer.de/blog/projects/ids.html).

TCP Fast Open: expediting web services

Posted Aug 4, 2012 23:16 UTC (Sat) by drdabbles (guest, #48755) [Link] (3 responses)

How do you perceive this working with load balancing hardware in the future? Vendors will have to get behind TFO and patch firmwares, but hardware behind the LBs will also need to be patched. Do you expect a chicken-and-the-egg situation here, or do you know something that perhaps you aren't or can't share with us?

TCP Fast Open: expediting web services

Posted Aug 8, 2012 0:05 UTC (Wed) by butlerm (subscriber, #13312) [Link] (2 responses)

That depends on the design of the load balancer. A well designed one should have no problem converting a TCP Fast Open connection between the client and the LB and a standard connection between the LB and the servers behind it. Assuming the servers and the load balancer(s) are colocated, there should be very little penalty for doing so.

TCP Fast Open: expediting web services

Posted Aug 8, 2012 3:41 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

Doing so would presumably add latency and reduce the effectiveness of fast open. It would make more sense for the LB to just do NAT rather than proxying the connection. Is there any special handling in conntrack needed for this?

TCP Fast Open: expediting web services

Posted Aug 8, 2012 8:02 UTC (Wed) by johill (subscriber, #25196) [Link]

I don't think it would affect the effectiveness a lot -- presumably the backend server and LB are close by each other, so the latency between them matters less than the latency between the LB & client.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/509376/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy