[badminton1]

I was asking myself the same thing. TCP implements many RFCs for congestion control, flow control, etc. Many of them might be redundant if everything is being sent over HTTP (over TCP).

I would use "link conditioner" or a similar tool, simulate packet loss and see how this compares to the other software.

[rpcope1]

http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Even for applications designed to tunnel traffic from the outset (OpenVPN), TCP over TCP is a mess and it's kind of a non-starter for anything that's not a toy (unless you have no other choice, like with certain mobile carriers where path MTU and CGN cause issues).

[noway421]

That's very interesting, thank you. I think there should be a way to control retransmission times on the client that would alleviate that problem. Probably taking out tcp connection out of kernel space and controlling the protocol in user space will allow to control the lower level tcp to work nicely with upper levels. But still, is there a possibility of a meltdown on the routers further down the line which might be controlling tcp connections? They would be routers which are not simply passing the ip packets, but working with the protocol in a more elaborate way though, either deep packet inspection or some other network mechanisms?