|
QUIC (Quick UDP Internet Connections, pronounced ''quick'') is an experimental transport layer〔 network protocol designed by Jim Roskind〔 at Google, initially implemented in 2012,〔 and announced as experimentation broadened〔 in 2013.〔〔 QUIC supports a set of multiplexed connections between two endpoints over User Datagram Protocol (UDP), and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency, and bandwidth estimation in each direction to avoid congestion. QUIC's main goal is to improve perceived performance of connection-oriented web applications that are currently using TCP.〔 It also provides a venue for rapid iteration of congestion avoidance algorithms, placing control into application space at both endpoints, rather than (the relatively slow to evolve) kernel space. ==Details== As improving TCP is a long-term goal for Google, QUIC aims to be nearly equivalent to an independent TCP connection, but with much reduced latency (goal: 0-RTT connectivity overhead) and better SPDY-like stream-multiplexing support; if QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle). One of the motivations for developing QUIC was that in TCP the delay of a single packet induces head-of-line blocking for an entire set of SPDY streams; QUIC's improved multiplexing support means that only one stream would pause. Round-trip times, roughly defined by the speed of light, are bounded, and as a result the only way to decrease connection latency is to make fewer round-trips. Much of the work on QUIC is concentrated on reducing the number of round trips required when establishing a new connection, including the handshake step, encryption setup, and initial data requests. QUIC clients would, for example, include the session negotiation information in the initial packet. This compression is enhanced by QUIC servers, which publish a static configuration record that is concisely referred to. The client also stores a synchronization cookie it received from the server, enabling subsequent connections to incur zero overhead latency (in the best case).〔 The protocol handles packet loss well; besides packet-level forward error correction,〔 QUIC aligns cryptographic block boundaries with packet boundaries, so the impact of packet loss is even lower. While TCP uses congestion windows to avoid congestion (see: TCP congestion avoidance algorithm), which are unforgiving to multiplexed connections, QUIC has a set of modern techniques under review.〔 Among the techniques being tested are packet pacing (with ongoing bandwidth estimation) and proactive speculative retransmission (sending duplicate copies of the most important packets, such as the ones containing error correction or initial encryption negotiation). QUIC, with its higher level application protocol elements which multiplexes streams (similarly to SPDY), can reduce or compress redundant data transmissions (such as headers). As with SPDY, QUIC benefits greatly from this compression, and is generally able to make numerous HTTP(S) requests within a single initial congestion window. Concerns about UDP connectivity (re: fears that too many users were behind middleboxes which blocked UDP traffic) were mitigated by Chromium connectivity experiments〔 performed before QUIC design〔 and implementation efforts began. For the small percentages of users that have UDP blocked, QUIC automatically falls back to TCP based connectivity. Additionally, when there is a perceived risk of UDP being blocked, high performance implementations, such as Chromium's network stack, race a TCP based connection with a QUIC (UDP) connection, ensuring no latency loss at the application level. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「QUIC」の詳細全文を読む スポンサード リンク
|