Wer bisher eine Bedrohung seitens Firmen wie Google sah, der wird durch einen Satz wie: "Google will das http-Protokoll abschaffen und durch ein eigenes ersetzen"....
Sicherlich nicht ruhiger schlafen. -
http://blog.chromium.org/2009/11/2x-faster-web.html
"das ganze Internet in Googles Hand"... von Suchmaschine über Browser, Email, Talk.... Bis hinunter zum Protokoll, dass die Kommunikation ermöglicht...
-beim tippen dieser paar Zeilen wird mir auch (als Fan) etwas unwohl...
Obwohl technisch einleuchtend, denn:
(...)
However, even using multiple connections, SPDY fares better than HTTP today. There are several reasons: a) it's sending about 40% fewer packets. This just makes it much less vulnerable to loss. b) Losing a SYN packet in TCP is disproportionately expensive. As per the TCP spec, the client must wait 3 seconds before retransmitting the first SYN. This is an *enourmous* amount of time. While HTTP opens up to 6-8 connections per domain (meaning 6-8 SYN packets), SPDY uses 1. In a random loss world, this means SPDY has fewer of these disproportionately expensive delays. c) TCP is actually pretty good (when using SACK) at keeping throughput high in the presence of packet loss. This is largely thanks to TCP's fast-retransmit algorithm. Because SPDY more efficiently uses the channel and more often has continued data flowing, it is able to hit fast-retransmit cases much more frequently than HTTP can, where only a single request flows at a time. (...)
Sicherlich nicht ruhiger schlafen. -
http://blog.chromium.org/2009/11/2x-faster-web.html
"das ganze Internet in Googles Hand"... von Suchmaschine über Browser, Email, Talk.... Bis hinunter zum Protokoll, dass die Kommunikation ermöglicht...
-beim tippen dieser paar Zeilen wird mir auch (als Fan) etwas unwohl...
Obwohl technisch einleuchtend, denn:
(...)
However, even using multiple connections, SPDY fares better than HTTP today. There are several reasons: a) it's sending about 40% fewer packets. This just makes it much less vulnerable to loss. b) Losing a SYN packet in TCP is disproportionately expensive. As per the TCP spec, the client must wait 3 seconds before retransmitting the first SYN. This is an *enourmous* amount of time. While HTTP opens up to 6-8 connections per domain (meaning 6-8 SYN packets), SPDY uses 1. In a random loss world, this means SPDY has fewer of these disproportionately expensive delays. c) TCP is actually pretty good (when using SACK) at keeping throughput high in the presence of packet loss. This is largely thanks to TCP's fast-retransmit algorithm. Because SPDY more efficiently uses the channel and more often has continued data flowing, it is able to hit fast-retransmit cases much more frequently than HTTP can, where only a single request flows at a time. (...)
