Google chce przyśpieszyć Sieć za pomocą QUIC
SPDY — stworzony przez Google'a protokół sieciowy, modyfikujący sposób, w jaki odbywa się komunikacja po HTTP przez wprowadzenie priorytetów połączeń, multipleksingu, wymuszenia szyfrowania TLS i kompresji nagłówków — okazał się wielkim sukcesem. Jego obsługę oprócz Chrome zapewnia Firefox, Opera oraz najnowszy Internet Explorer 11, a wśród witryn, które włączyły SPDY na swoich serwerach WWW, można wymienić (oprócz Google) Twittera, Facebooka i Wordpress.com. Co zaś najważniejsze, SPDY stał się podstawą dla nowej wersji protokołu HTTP 2.0. Przyśpieszania Internetu jednak nigdy za wiele, dlatego koncern skupia się obecnie na rozwoju QUIC (Quick UDP Internet Connection) — eksperymentalnego protokołu sieciowego, który ma pozwolić na znaczne zmniejszenie opóźnień w komunikacji między serwerem a przeglądarką, w szczególności skrócenie czasu przejścia w obie strony (round-trip time).
Osoby korzystające z Google Chrome z kanałów developer i Canary otrzymały właśnie aktualizacje, które wprowadzają do przeglądarki obsługę QUIC. Użytkownicy nie powinni zauważyć żadnej różnicy, oczywiście poza krótszym czasem ładowania stron — twierdzi Jim Roskind z Google. Choć jednak prace nad implementacją po stronie klienta i serwera trwały przez kilka ostatnich miesięcy, koncern zdaje sobie sprawę z faktu, że warunki panujące w świecie rzeczywistym diametralnie różnią się od laboratoryjnych. Musimy wypróbować QUIC w realnych sytuacjach — zapowiada Roskind.
Zaproponowanych zmian jest wiele, ale najważniejszą z nich jest budowa nowego standardu na bazie protokołu UDP, który w przeciwieństwie do TCP pozwala na wysyłanie datagramów do innych hostów bez wcześniejszej konieczności ustanawiania połączeń. Dzięki temu ma się skrócić czas potrzebny do nawiązania komunikacji, choć Google zaznacza, że QUIC ma być równie niezawodny, co powszechnie stosowany TCP. W przeciwieństwie do swojego pierwowzoru, QUIC wyposażony jest w mechanizm korekcji błędów, który zmniejszy zapotrzebowanie na ponowną transmisję utraconych pakietów. Protokół ma być także równie bezpieczny, co TLS/SSL. Podczas pracy nad SPDY nauczyliśmy się, że jeśli nie będziemy szyfrować ruchu, pośrednicy z pewnością (umyślnie lub przez przypadek) wtrącą swoje trzy grosze — wyjaśnia Roskind. Ponadto QUIC umożliwiać ma też uruchamianie znanych z TCP mechanizmów kontroli przepływu i zapobiegania przeciążeniom na połączeniach UDP, oddając aplikacjom kontrolę nad ruchem sieciowym.
Dlaczego Google zdecydowało się na rozbudowę UDP zamiast stworzyć cały protokół od podstaw? Podawana przez koncern przyczyna jest prozaiczna — po prostu pośrednicy często blokują w sieciach ruch, który nie odbywa się za pomocą TCP lub UDP. Zmiany jednak są konieczne, dlatego Roskind, łowca skróceń czasu przejścia w obie strony w Google, tak tłumaczy konieczność wprowadzenia QUIC-a: pomimo rosnącego pasma transferu, czas przejścia w obie strony się nie zmniejsza – jest w końcu związany z prędkością światła. W przewidywalnej przyszłości pozostanie wysoki, szczególnie w sieciach mobilnych. Aby zwiększyć wydajność sieci, musimy ograniczyć liczbę przejść tam i z powrotem, a to jest bardzo trudne dla protokołów bazujących na TCP.