50 likes | 234 Views
In a mobile first world where delivering a fast and rich mobile experience is critical, application-level optimizations and network-level optimizations are the two ways to improve mobile experience.<br>Instart Logic’s software-defined application delivery platform gives innovative features that provide application level optimizations to accelerate mobile app delivery and improves mobile web experience.<br>Know more about mobile experience solution: http://www.instartlogic.com/products/performance
E N D
THE QUIC AND THE DEAD BY RAGHU VENKAT
With a mobile-first world, delivering a fast and rich mobile experience is critical. Two ways to improve the mobile experience are application-level optimizations and network-level optimizations. The best approach is to do both – optimize the content and structure of an application and the network transport. With Instart Logic'ssoftware-defined application deliveryplatform, we have innovative performance features such as streaming, adaptation, andinterception, which provide application-level optimizations to accelerate mobile app delivery. A number of mobile application delivery companies are only doing network-level optimizations with proprietary protocols over User Datagram Protocol (UDP) that seemingly help to solve the performance challenges in the wireless last mile. Just focusing on network-level optimizations with a proprietary protocol is a half-baked solution that will eventually fade into obscurity once a standard protocol that utilizes UDP is released. Instart Logic has always preferred something more open that may eventually become a standard. We saw Google take the lead on a successor to HTTP/1.1 and do this in a very open way. The ecosystem quickly adopted SPDY and then has embraced most of SPDY in HTTP/2. Like others, we implemented SPDY as soon as it was an open protocol and will be supporting HTTP/2 shortly. Google’s experimental protocol, QUIC,which leverages UDP, shows promising results in its attempt to solve the latency problem inherent in the wireless last mile. Network protocol optimizations are an area ripe for disruption and the emergence of HTTP/2 has been a big leap forward. While HTTP/2 is attempting to solve many of the latency problems by multiplexing, compressing headers, server push, etc., it is still running on top of the legacy TCP standard. TCP is a robust protocol that has been around for decades, but it has several shortcomings specifically related to latency and congestion – three-way handshakes and head-of-line blocking. For congested lossy wireless networks, more needs to be done. One option is to switch from TCP to UDP since UDP is a simple, connectionless protocol that requires no handshakes. However, UDP also has its limitations.
QUIC, short for Quick UDP Internet Connection, is designed to overcome the limitations of UDP by implementing several features needed for HTTP/2 in the application layer on top of UDP. The design goal of QUIC is to replace HTTP over TCP as the default protocol for web content delivered to end users. Among other features, QUIC is designed to have no round trip requests as compared to 1 to 3 requests for TCP+TLS. The first time a QUIC client connects to a server, the client must perform a one round trip handshake to setup the secure connection, but thereafter, the credentials are cached so future round trips are not required. Furthermore, QUIC solves the issue of head of line blocking that is inherent in the TCP protocol (HTTP/2 is also attempting to fix head of line blocking). QUIC can deliver all the received packets to the application without waiting for retransmission. Ultimately, QUIC seeks to provide a real-time performance improvement over TCP with lower latency connections, improved congestion control, and better loss recovery. In early experiments,Google has already seen QUIC outshine TCPby shaving a full second off the Google Search page load times for the slowest 1 percent of connections. YouTube has also seen a remarkable improvement with 30 percent fewer re-buffers when watching videos over QUIC. If it does materialize into a standard, implementation of QUIC could provide a much-needed performance boost for both web and mobile applications. Today, roughly half of all requests served over Chrome are using the QUIC protocol, and it will eventually be the default transport protocol for Google Chrome, accessing both mobile apps and properties. It is only a matter of time before QUIC is available as an iOS and Android SDK and as the default protocol for mobile applications. As the implementation inefficiencies of the QUIC protocol improve, in theory this should provide a substantial boost to the high-latency, lossy wireless last-mile networks where roundtrip matters. With QUIC the likely standard protocol for mobile applications, companies that are betting on short-term proprietary protocols will be a distant memory.