It is not difficult to realize that we need to build faster protocols. Protocols able to handle the today's Internet.
TCP has made remarkable work until now and will do for many years ahead but TCP was developed in a totaly different scenario.
Companies has made huge effort trying to make things better. To delivery much better experience for users. And in this scenario, Google came with a brend new protocol called QUIC (Quick UDP Internet Connection).
Before deep dive in QUIC, it is important discus about another protocol also developed by Google, this one called SPDY. As mentioned before, http 1.1 is no longer indicated for today's Internet. It was developed in a time where web pages were static, load from one only source and one domain. Today´s web page are load from about 80 differents sources and about 30 domain. The web page is a big mosaic and each piece coming from one point of the world. Sure enough, to handle all of it is necessary a very smart and high performance protocol.
In this scenario Google has developed SPDY. The main goal of SPDY and QUIC is reduce Latency. It is all about latency. SPDY is a application protocol that works compressing,multiplexing and prioritizing data.
According to Google's SPDY definition, "SPDY is a multiplexed stream protocol currently implemented over TCP. Among other things, it can reduce latency by sending all requests as soon as possible (not waiting for previous GETs to complete)"
But, there's a problem here. As mentioned SPDY run over TCP and TCP has some characteristic that is not in accordance with the goal of SPDY low latency.
TCP has a known behavior called Head-of-Line Blocking. Since TCP only provides only a single serialized stream interface, if one packet is lost it will interfere in the entire SPDY communication. SPDY multiplex many stream over TCP connection but Head-of-Line Blocking cancels it.
A good example of this scenario can be seeing bellow:
If the red packet is lost, all other flows must wait.
To overcome this and others issues, QUIC comes to the scene. With QUIC, the above scenario has changed completely:
From now one, the improvement allowed by SPDY shows up. If the red packet is lost, the whole flow does not suffer anymore.
QUIC run over UDP for good reason. UDP does not perform three way hand shake as TCP. Its nature makes it fast. As QUIC aims to zero RTT it is impossible to run over TCP.
The following figure shows that concept:
With QUIC, Google aims the following goals. Those goals were taken from "QUIC: Design Document and Specification Rationale".
1-Widespread deployability in today’s Internet.
This is not easy to achieve. As we may know, Google can't perform any change in the Internet structure. SPDY and QUIC must be transparent on the Internet. Otherwise it will be blocked along the firewalls and router out there.
Perform change in TCP/UDP/IP headers only can be made by regulatory entities and it takes lots of years. Furthermore, the adoption of this changes can take even more time. Those protocol lives inside all kernel around the world and it is really complicate to get all those kernel upgraded.
2. Reduced head-of-line blocking due to packet loss
As we saw above, this is possible with QUIC.
3. Low latency (minimal round-trip costs, both during setup/resumption, and in
response to packet loss)
This is the main objective of the protocol
4. Improved support for mobile, in terms of latency and efficiency
5. Congestion avoidance support comparable to, and friendly to, TCP
6. Privacy assurances comparable to TLS
7. Reliable and safe resource requirements scaling
8. Reduced bandwidth consumption and increased channel status responsiveness
9. Reduced packet-count
10. Support reliable transport for multiplexed streams
11. Efficient demux-mux properties for proxies
12. Reuse, or evolve, existing protocols at any point where it is plausible to do so,
without sacrificing our stated goals
By achieving those goals, Google will have built a much more fast Internet. I doubt anyone has courage to say Google will fail in building such huge accomplishment. Considering the past and present of this remarkable company, we must wait nothing but the whole Internet structure transformed forever. As network engineer, we need to understand those protocols and any other to come to stay ahead of our time. Google has already proved its capacity in transform the way we live.
This is a "Quick" overview about this very interesting protocol. I'd like to go deeper and maybe perform some practical demonstration. But we can continue in another article.
What do you think about it ? Will Google really going to change the whole Internet by developing protocols like QUIC and SPDY ?
Is it possible a future where we will have Google Apps, Google operational System, Google Internet protocol and Google world wide network ?
It is really scary , isn't it ?
No comments:
Post a Comment