I tried to ping several servers, and the speed rang from 7ms to 300ms
I looked at a log of a download client, it seems it only send 1 HTTP request per session. So as I understand only the initial HTTP request will take longer for slow PINGs. After that stage, everything else is the same.
But this raise the question how HTTP stays on top of TCP. Does the web server send out TCP packages once it gets the first HTTP request? or it will wait previous packages delivery comfirmation before sending more? (sound like a UDP then).
Bahahahahaha.... A ping of more than 60ms is unacceptable for a FPS?... Good luck playing on a server that isnt geographically near you... Bahahahahahahaha...
Sorry... Couldnt resist.
Actually it ends up being what the user is used to. Back when I was on dialup, I frequently played Unreal Tournament Instagib CTF with a ping of over 500ms, and I did quite well. I now regularly play Onslaught, DM & CTF on UT2k4 servers with pings in the 50s-200 and I do fine. Playing on a 500ms server does take a little getting used to though.
Most people (that I've talked to) are comfortable in the 50-150ms range but can deal with 200ms for a FPS.
In the end though, I'd be more concerned about packet loss than ping. I've played on a server with a 40ms ping, but a 30% packet loss. Talk about murder to play on.
The answer to your question:
Depends on application. From what I've read, some network hardware gives ping a lower priority so its not a deciding factor on the general speed of other traffic. That is if they don't have ping "disabled".
When a web page is pulled from a server, every graphic, the HTML, and all page compents are requested via multiple connections. Therefore, you would be dealing with the ping response time more than once per page unless the page is completely text-based.
Also, while ping and transfer rates are not ALWAYS related, many times if you are receiving a high ping from a server, you will also see a lower throughput while downloading.
TCP/IP encapsulates HTTP data just as the ethernet protocol encapsulates TCP/IP data. The web server does not really send out "TCP packages".. it sends out and accepts HTTP protocol commands and outputs text and binary data OVER TCP/IP. A new TCP/IP connection is established per each HTTP request (actually one connection to the server and then one conncetion back from the server). HTTP is "stateless" (meaning it does not wait for a response or ACK.. acknowledgement), while TCP (and not IP) does.
John says is true, however, the HTTP/1.1 protocol allows for a bit of state in that, once connected, you're allowed a short time to grab other things before the connection is terminated.
So, if you grab a web page, the same connection will be used to grab all embedded images etc without the issue of tearing down and reconnecting all the time, which means that a high ping is not really a problem for web pages.
The round-trip time will determine how large your TCP window can grow, depending on various parameters on both client and server as well. That will directly affect effective overall throughput for large transfers.
HTTP is stateless as it carries no HTTP-related information between connections. It makes a connection, makes a call, then closes the connection. Repeat as necessary. No call has any information shared between them. (which is why you need cookies to hold that state between calls).
TCP is stateful, but only for purposes of holding the connection open. Not for any application that might use that connection.