Quic Brief Introduction

QUIC, the quick UDP Internet Connection, similar to SPDY, is also designed to be extended by Google on top of existing saved protocols and is designed to reduce network latency. Before I introduced Spdy information, spdy work in the application layer, and here the Quic work in the transport layer. Although Quic's name implies that it resembles a modified UDP protocol, its goal is to optimize or replace the TCP protocol that is used in a link-oriented application.

Due to the constant speed of light and the extra overall factor of leaving the network busy (due to the fact that we are taking a partial, the goal is local optimization, so the overall factor belongs to the higher level of research), then on the network, arbitrarily determine the round-trip delay between the two Rtts (round Times) is basically fixed, so the only way to reduce the latency of a single connected network is to make it possible to create a connection with as few rtts as necessary. From this demand can be seen, for the TCP protocol itself, it is very difficult to achieve the corresponding optimization, on the one hand, TCP is required by the handshake protocol, congestion control and so on fixed its necessary number of Rtts, and on the one hand is due to TCP implementation in the operating system protocol stack, Changing the actual user's operating system must be quite difficult.

Quic attempts to address issues that Spdy cannot cover. The first is the TCP blocking, followed by the congestion of TCP congested valves, that is, the spdy advantage caused by these two points can not be fully played. This is very good understanding, we know that Spdy is running on the TCP protocol, assuming the bottleneck in the TCP layer, then the upper level to do more optimization is useless.

In addition, Spdy's SSL/TLS also brings two performance issues: 1, resuming a disconnected session will introduce an additional handshake, which is purely the design of the SSL/TLS protocol, not security or any other particular reason. 2, the resolution of the historical packets needs to be done sequentially, which will result in a greater delay in delay packets. As a result, Quic has been designed to be similar to TLS encryption, which avoids the use of SSL/TLS and reduces the overhead associated with it.

Prior to this, Googleproject has proposed some solutions to these detailed problems. For example, TCP Fast Open (TFO) can be used to reduce the rtts that connect to the same server that was once visited. Quic is a blend of these old solutions, as well as some new solutions to focus on a single application scenario, from the same server, using a TLS encrypted connection that carries multiple streams of data to the Web application service.

Simply put, the goal of Quic is to provide a link-oriented service on top of the UDP protocol. Well, it sounds good, although I am not clear about the details, but it seems to understand the meaning is to be specific to the scene, combined with the traditional TCP and UDP each of the advantages of the two, one by one.

Http://blog.chromium.org/2013/06/experimenting-with-quic.html

http://lwn.net/Articles/558826/

reprint Please keep address:http://lenky.info/archives/2013/08/06/2337 or http://lenky.info/?p=2337

Quic Brief Introduction