TCP Fast Open: expediting web services [LWN.net]

TCP Fast Open: expediting web services

Posted Aug 2, 2012 9:44 UTC (Thu) by epa (subscriber, #39769)
In reply to: TCP Fast Open: expediting web services by iq-0
Parent article: TCP Fast Open: expediting web services

The article makes it sound like the server's responsibility to make sure its behaviour is idempotent before enabling TFO. For http in particular, a GET request is defined to be idempotent while POST is not, and the client knows which it is sending. So it makes more sense for web servers to always allow TFO, but clients refrain from using it for POST or PUT requests. The web server could add a sanity check, once it receives the data and starts processing the request, that TFO was not used for these request types.

to post comments

TCP Fast Open: expediting web services

Posted Aug 2, 2012 12:16 UTC (Thu) by iq-0 (subscriber, #36655) [Link] (1 responses)

Many 'GET' operations are not necessarily idempotent. The RFC's language is 'SHOULD NOT', which is about the mildest way requirements are described.

The problem is that often different applications run in a big webserver (especially true for massive virtual hosting setups) and that "partially enabling TFO" is not really an option.

The other way round would be for the application to signal that the request is not allowed using TFO, but that would require a retry using non-TFO which is not specced and introduces more latency than is gained using TFO.

The only real solution that is safe would be to invent (yet another) HTTP header that signifies which methods for which paths under the current vhost may be done using TFO initialized connections.
For systems that support TFO for all requests (because they have higher-level guards against duplicate requests) one could simply hint '* /' or something. Only the first connection to such a site must in that case always be made using non-TFO requests.

TCP Fast Open: expediting web services

Posted Aug 9, 2012 13:48 UTC (Thu) by jthill (subscriber, #56558) [Link]

I think just allowing a server to detect whether the connection is still in fast-open state should be enough. If the server sees a non-idempotent request it can make sure the initial ACK has arrived before proceeding. Make it detectable by say making {aio_,}fsync not complete until it's arrived, or fabricating a redundant EPOLLOUT edge.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 12:21 UTC (Thu) by colo (guest, #45564) [Link] (9 responses)

Ah, well yes, in an ideal world... :)

I've seen enough GET-requests with at times far-reaching side effects in the wild that I'm not convinced this will (or should) see widespread adoption, at least not for "ordinary" HTTP servers that aren't serving up static content only or something like that.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 13:16 UTC (Thu) by epa (subscriber, #39769) [Link] (8 responses)

Long ago I worked at ArsDigita where the rule was to avoid form submit buttons as much as possible. So the user management page on a site would have 'delete user' not as a POST form submission, but simply a hyperlink. This was held to make the website look cleaner and feel faster. Then a customer using a 'web accelerator' which eagerly follows links ended up trashing their whole site. The programmer's fault, of course - GET requests should never be used for strongly state-changing operations like deleting data.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 14:04 UTC (Thu) by alankila (guest, #47141) [Link] (7 responses)

Although to be fair, multiple GETs that all attempt to delete the same user aren't a problem here. So maybe the latter request crashes if website developer wasn't careful enough, but the delete itself was idempotent.

I guess cautious people can't turn TFO on unless they validate the software they runs, but now there is going to be a good reason why you want to ensure that software is idempotent-GET safe. I imagine that the vast majority of software is, actually.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 15:19 UTC (Thu) by epa (subscriber, #39769) [Link] (6 responses)

Yes, I was confusing idempotent (makes no difference whether requested once, or many times) with stateless (makes no difference whether requested zero, one, or many times). Ideally GET requests would be not merely idempotent but stateless, which is a stronger property. But that is not needed for TFO.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 16:11 UTC (Thu) by man_ls (guest, #15091) [Link] (5 responses)

That is not required in the RFC, and I am not sure that restful, stateless web services would be even possible. After all, web services are supposed to change state in the server; otherwise what is the point?

TCP Fast Open: expediting web services

Posted Aug 2, 2012 16:32 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (4 responses)

Maybe I don't understand. Internally we have a great many RESTful web services which all work roughly like this:

The client asks if this particular combination of data (provided as GET query parameters) is found in the database overseen by that web service. The server looks in its database (e.g. maybe it's the collection of all voter registration records for a particular country) and if there is a matching record it replies saying what was found and where.

You can run that same request again and get the same exact answer and running it many times or not at all changes nothing‡ so that seems to meet your requirement entirely.

‡ In practice some of the services do accounting, they are incrementing a counter somewhere for every query run and then we use that counter to determine the payment to a third party for the use of their data. But this is no greater deviation from the concept than the usual practice of logging GET requests and anyway most of the services don't do that.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 20:42 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

you are making the assumption that the RESTful web service is read-only.

How can you do a RESTful web service where the client is sending information to the server without causing these sorts of problems?

TCP Fast Open: expediting web services

Posted Aug 3, 2012 2:02 UTC (Fri) by butlerm (subscriber, #13312) [Link]

The normal technique is to mark all non-idempotent requests with a unique id, and keep track of which ones have already been processed. That is practically the only way to get once-only execution semantics.

This could presumably be done (up to a point) at the transport layer with TCP Fast Open by having the initiating endpoint assign a unique identifier to a given user space connection request, attaching the identifier as a TCP option, caching the identifier for some reasonable period on the target endpoint, and throwing away SYN packets with connection identifiers that have already been satisfied. The more general way to do that of course is to do it at the application layer, in addition to anything the transport layer may or may not do.

TCP Fast Open: expediting web services

Posted Aug 3, 2012 15:35 UTC (Fri) by epa (subscriber, #39769) [Link] (1 responses)

I thought that part of making a RESTful web service was deciding which operations are read-only and which affect the state; and splitting them into GET and POST requests accordingly.

TCP Fast Open: expediting web services

Posted Aug 3, 2012 21:16 UTC (Fri) by dlang (guest, #313) [Link]

That depends on how you define REST

many groups make everything a GET request, especially for APIs that are not expected to be used from browsers, but rather called from other applications, especially in B2B type situations.

TCP Fast Open: expediting web services

Posted Aug 2, 2012 17:33 UTC (Thu) by ycheng-lwn (guest, #86073) [Link] (6 responses)

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 original 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)

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.