"... where head-of-line blocking in TCP was previously a problem..."
Has anyone ever shared a demo where we can see this occuring with pipelined HTTP/1.1 requests
I have been using HTTP/1.1 pipelining -- using TCP/TLS clients like netcat or openssl -- for many years and I have always been very satisfied with the results
Similar to the demo in the blog post, I am requesting a series of pages of text (/articles/1, /articles/2, etc.)
I just want the text of the article to read, no images or ads. Before I send the requests I put the URLs in the order in which I want to read them. With pipelining, upon receipt I get automatic catenation of the pages into one document. Rarely, I might want to split this into separate documents using csplit.
HTTP/1.1 pipelining gives me the pages in the order I request them and opens only one TCP connection. It's simple and reliable.
If I requested the pages in separate connections, in parallel, then I would have to sort them out as/after I receive them. One connection might succeed, another might fail. It just becomes more work.
TCP blocking is seen the most on mobile data connections. The LTE could be delivering whole megabytes of correct data but if that TCP connection is missing just one packet it must buffer all the rest until it can get that SACK / ACK back to the server and get the missing packet.
If there's congestion, there is a random chance of any packets being dropped, because that's how you signal congestion reliably. If there's neither congestion nor wireless links on the route between you and the server neither this, nor most other performance considerations matter to you, that's nice you're already getting the best possible outcome.
Has anyone ever shared a demo where we can see this occuring with pipelined HTTP/1.1 requests
I have been using HTTP/1.1 pipelining -- using TCP/TLS clients like netcat or openssl -- for many years and I have always been very satisfied with the results
Similar to the demo in the blog post, I am requesting a series of pages of text (/articles/1, /articles/2, etc.)
I just want the text of the article to read, no images or ads. Before I send the requests I put the URLs in the order in which I want to read them. With pipelining, upon receipt I get automatic catenation of the pages into one document. Rarely, I might want to split this into separate documents using csplit.
HTTP/1.1 pipelining gives me the pages in the order I request them and opens only one TCP connection. It's simple and reliable.
If I requested the pages in separate connections, in parallel, then I would have to sort them out as/after I receive them. One connection might succeed, another might fail. It just becomes more work.