I have users that previously used FTP for file transfers across high latency paths to their local server. They have switched to HTTP for these transfers (not by choice) and file transfer perforamance is seriously degraded. The TCP Window Size for the users' servers was optimized for FTP and the network latency.
Depending the implementation of HTTP at the source server (i.e., web service), is it possible that HTTP uses or effects a small/default TCP window size?
No, HTTP and FTP both transfer files via basically pure TCP. The same TCP tuning that worked for FTP should work for HTTP.
The performance problem you're seeing is probably with the HTTP client or server implementations involved; they're probably not using TCP efficiently. For example, good implementations are careful to use rolling buffers to always keep the TCP pipe full. Naive implementations only hand one buffer at a time to TCP, and wait for that one to be fully sent before handing off a new one. That causes the pipe to keep partially draining between buffers, which is one of the worst things you can do for high-latency links. If you had an FTP client or server that made this same mistake, its performance would be just as bad as an HTTP client or server that made this mistake.
Note that this is just one example of how a naive implementation might not be using TCP efficiently; I'm not necessarily saying this is what's going on in your case, but it's a definite possibility.
