Google's SPDY Incorporated Into Next-Gen HTML, Offers TCP Enhancements
Google's efforts to improve Internet efficiency through the development of the SPDY (pronounced "speedy") protocol got a major boost today when the chairman of the HTTP Working Group (HTTPbis), Mark Nottingham, called for it to be included in the HTTP 2.0 standard. SPDY is a protocol that's already used to a certain degree online; formal incorporation into the next-generation standard would improve its chances of being generally adopted.
SPDY's goal is to reduce web page load times through the use of header compression, packet prioritization, and multiplexing (meaning combining multiple requests into a single connection). By default, a web browser opens an individual connection for each and every page request, which can lead to tremendous inefficiencies.
SPDY's performance as compared to HTTP
Whether or not the proposal will pass is up in the air. HTTPbis's original task was to draft and approve the HTTP 1.1 standard; taking on HTTP 2.0 is a significant addition.Argument Debate over the proposal broke out almost immediately, including challenges to the name HTTP 2.0 as being too similar to the admittedly loathed "Web 2.0." As one commenter noted: "Well, if we announce one year, maybe we'll manage to succeed in 3."
Google has also fielded a proposal to accelerate and streamline the venerable TCP protocol. TCP grew out of a paper written in 1974 by Vint Cerf and Bob Kahn, and, like nearly everything from that decade, it's not aged all that well. Google's research shows that web browsers typically retrieve content through "several dozen parallel TCP connections. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable."
Google engineer Yuchung Cheng suggests that the situation could be significantly improved by reducing the initial timeout period (the period of time before a packet is determined to be lost and retransmitted) from 3s to 1s and adopting the TCP Fast Open standard. Google claims that using TCO could reduce web page load times by 10% on average and "over 40% in many situations."
Cheng also recommends increasing the TCP initial congestion window from three to 10 packets. The "initial congestion window" is the number of packets that can be outstanding at the beginning of a web transaction. The advantage of slow start is that it limits network congestion by limiting the amount of unacknowledged packets that can pile up in response to a short-lived connection. The disadvantage is that the majority of network requests are often short-lived. Google's proposed change would improve performance for short-lived connections but have a minimal impact on the chances of losing a packet.
One of the most significant questions raised about Google's proposed TCP optimizations is how they'd affect users in areas where Internet connectivity is less than ideal, and what sort of fallback options might be available to deal with these scenarios. Improving page load latencies and lowering network congestion are both important, but there needs to be a way to maintain connectivity when connecting over weak wireless or even satellite.
SPDY's goal is to reduce web page load times through the use of header compression, packet prioritization, and multiplexing (meaning combining multiple requests into a single connection). By default, a web browser opens an individual connection for each and every page request, which can lead to tremendous inefficiencies.
Whether or not the proposal will pass is up in the air. HTTPbis's original task was to draft and approve the HTTP 1.1 standard; taking on HTTP 2.0 is a significant addition.
Google has also fielded a proposal to accelerate and streamline the venerable TCP protocol. TCP grew out of a paper written in 1974 by Vint Cerf and Bob Kahn, and, like nearly everything from that decade, it's not aged all that well. Google's research shows that web browsers typically retrieve content through "several dozen parallel TCP connections. This strategy overcomes inherent TCP limitations but results in high latency in many situations and is not scalable."
Google engineer Yuchung Cheng suggests that the situation could be significantly improved by reducing the initial timeout period (the period of time before a packet is determined to be lost and retransmitted) from 3s to 1s and adopting the TCP Fast Open standard. Google claims that using TCO could reduce web page load times by 10% on average and "over 40% in many situations."
Cheng also recommends increasing the TCP initial congestion window from three to 10 packets. The "initial congestion window" is the number of packets that can be outstanding at the beginning of a web transaction. The advantage of slow start is that it limits network congestion by limiting the amount of unacknowledged packets that can pile up in response to a short-lived connection. The disadvantage is that the majority of network requests are often short-lived. Google's proposed change would improve performance for short-lived connections but have a minimal impact on the chances of losing a packet.
One of the most significant questions raised about Google's proposed TCP optimizations is how they'd affect users in areas where Internet connectivity is less than ideal, and what sort of fallback options might be available to deal with these scenarios. Improving page load latencies and lowering network congestion are both important, but there needs to be a way to maintain connectivity when connecting over weak wireless or even satellite.
