Co to jest HTTP/3 — informacje na temat szybkiego nowego protokołu opartego na protokole UDP?

TL; DR

W listopadzie 2018 r. w Bangkoku spotkała się grupa zadaniowa ds. inżynierii internetowej (IETF) i przyjęto nowy projekt internetowy. Protokół transportowy QUIC, następca HTTP/2, został przemianowany na HTTP/3.

HTTP/3 opiera się na protokole User Datagram Protocol (UDP) i jest już używany przez znane firmy internetowe, takie jak Google i Facebook. Jeśli używasz Chrome i łączysz się z usługą Google, prawdopodobnie używasz już QUIC.

Nowa wersja protokołu HTTP korzysta z prostego, niskopoziomowego protokołu UDP i definiuje wiele nowych funkcji, które były w poprzednich wersjach protokołu HTTP w warstwie TCP. Zapewnia to sposób rozwiązywania ograniczeń w istniejącej infrastrukturze internetowej.

Pierwsze wyniki są obiecujące, a po wygaśnięciu Internet Draft przez IETF, w sierpniu 2021 roku, możemy spodziewać się promowania HTTP/3 jako nowego standardu HTTP trzeciej generacji.

Postęp HTTP/3 w 2022 r.

Niektórzy twierdzą, że głód przemysłu internetowego na większą prędkość i mniejsze opóźnienia jest dorównywany tylko głodowi Google Chrome na większą ilość pamięci RAM.

Kilka lat temu opublikowaliśmy artykuł o HTTP/2, standardzie, który według W3Techs osiągnął obecnie około 45% wskaźnik przyjęcia na świecie. Według Can I Use jest również obsługiwany przez wszystkie nowoczesne przeglądarki internetowe. A jednak oto jesteśmy, pisząc artykuł o kolejnej wersji protokołu, HTTP/3.

HTTP/3 jest, w momencie pisania tego tekstu, projektem lub identyfikatorem internetowym IETF, co oznacza, że ​​jest obecnie rozważany przez Internet Engineering Task Force – międzynarodowy organ ds. standardów internetowych , odpowiedzialny za zdefiniowanie nadchodzącego standardu internetowego. oraz promowanie uzgodnionych standardów protokołów internetowych, takich jak TCP, IPv6, VoIP, Internet rzeczy itp.

Jest to ciało otwarte, które jednoczy branżę webową i ułatwia dyskusję o kierunku, w jakim zmierza internet. Obecnie faza „Internet Draft” HTTP/3 jest ostatnią fazą przed promocją ofert do poziomu Request-for-Comments (lub RFC), które możemy uznać, dla wszystkich intencji i celów, za oficjalne definicje protokołów internetowych.

Chociaż HTTP/3 nie jest jeszcze oficjalnym protokołem internetowym, wiele firm i projektów już zaczęło dodawać obsługę HTTP/3 do swoich produktów.

Obsługa przeglądarki internetowej dla HTTP/3

Na froncie przeglądarki internetowej Chrome v87, Firefox v88 i Edge v87 mają domyślnie włączony protokół HTTP/3. Dla użytkowników Safari, opcja włączenia HTTP/3 została dodana do Safari Technology Preview v104. Jednak obsługa HTTP/3 nie jest obecnie dostępna w stabilnej wersji Safari.

Obsługa bibliotek dla HTTP/3

Dla programistów, którzy chcą wykorzystać technologie HTTP/3, wiele popularnych bibliotek dodało już obsługę HTTP/3. Ponieważ HTTP/3 jest nadal w fazie Internet Draft, podczas pracy z jedną z poniższych bibliotek upewnij się, że jesteś na bieżąco z najnowszymi aktualizacjami.

• Python – http3 i aioquic
• Rdza – quiche, neqo i quinn
• C – nghttp3 i lsquic
• Idź – quicgo
• JavaScript – Node.js

Obsługa infrastruktury dla HTTP/3

Po stronie infrastruktury Cloudflare jest liderem dzięki obsłudze HTTP/3 w całej swojej sieci brzegowej. Oznacza to, że witryny z włączoną opcją Cloudflare mogą korzystać z ulepszeń bezpieczeństwa i wydajności HTTP/3 bez dodatkowej pracy.

W Kinsta wszystkie hostowane przez nas witryny są chronione przez naszą bezpłatną integrację z Cloudflare. Oprócz zapory ogniowej na poziomie korporacyjnym i ochrony przed atakami DDoS klienci Kinsta mają również dostęp do protokołu HTTP/3!

Aby sprawdzić, czy Twoja witryna obsługuje protokół HTTP/3, możesz użyć narzędzia do testowania HTTP/3 firmy Geekflare. Po prostu wpisz swoją domenę i naciśnij przycisk „Sprawdź HTTP/3”, a narzędzie poinformuje Cię, czy Twoja witryna obsługuje protokół HTTP/3.

Jeśli Twoja witryna obsługuje protokół HTTP/3, powinieneś zobaczyć komunikat podobny do poniższego. Ponieważ kinstalife.com jest hostowany na Kinsta, HTTP/3 jest w pełni obsługiwany dzięki naszej integracji z Cloudflare.

Możesz także użyć inspektora przeglądarki, aby sprawdzić obsługę HTTP/3. W tym przykładzie użyjemy najnowszej wersji przeglądarki Google Chrome, która obsługuje protokół HTTP/3.

Aby otworzyć inspektora, kliknij prawym przyciskiem myszy stronę i kliknij "Sprawdź" i przejdź do zakładki "Sieć". W kolumnie „Protokół” możesz zobaczyć protokół HTTP używany do połączenia. Połączenia HTTP/2 są wyświetlane jako „h2”, podczas gdy połączenia HTTP/3 są wyświetlane jako „h3-XX” (XX odnosi się do określonej wersji roboczej HTTP/3). Jak widać na poniższym obrazku, kinstalife.com obsługuje połączenia przez „h3-29”, co oznacza „HTTP/3 Draft 29”.

Teraz, gdy omówiliśmy obecny stan HTTP/3, przyjrzyjmy się bliżej niektórym różnicom między HTTP/2 a HTTP/3!

Trochę tła – zaczęło się od HTTP/2

Protokół HTTP/2 przyniósł kilka poważnych ulepszeń dzięki nieblokującym pobieraniom, potokom i wypychaniu serwerów, co pomogło nam przezwyciężyć pewne ograniczenia podstawowego protokołu TCP. Pozwoliło nam to zminimalizować liczbę cykli żądanie-odpowiedź i uzgadniania.

HTTP/2 umożliwił pushowanie więcej niż jednego zasobu w jednym połączeniu TCP – multipleksowanie. Zyskaliśmy również większą elastyczność w kolejności pobierania statycznych, a nasze strony nie są już ograniczone liniową progresją pobierania.

W praktyce oznacza to, że teraz jeden duży zasób javascriptu niekoniecznie jest równy dławikowi dla wszystkich pozostałych zasobów statycznych oczekujących na swoją kolej.

Dodaj do tego kompresję nagłówka HTTP/2 HPACK i domyślny binarny format przesyłania danych, a w wielu przypadkach mamy znacznie wydajniejszy protokół.

Główne implementacje przeglądarek wymagały od witryn internetowych implementacji szyfrowania — SSL — aby móc czerpać korzyści z HTTP/2 — i czasami wiązało się to z obciążeniem obliczeniowym, które powodowało niezauważalne zwiększenie szybkości. Zdarzały się nawet przypadki, w których użytkownicy zgłaszali spowolnienie po przejściu na HTTP/2.

Powiedzmy tylko, że wczesne dni przyjęcia tej wersji nie były dla słabych serca.

W implementacji Nginx brakowało również funkcji server-push, polegającej na module. A moduły Nginx nie są zwykłymi modułami Apache, które można po prostu skopiować — NGINX musi zostać z nimi ponownie skompilowany.

Chociaż niektóre z tych problemów zostały już rozwiązane, jeśli przyjrzymy się całemu stosowi protokołów, zobaczymy, że podstawowe ograniczenie leży na niższym poziomie, niż odważył się zaryzykować HTTP/2.

Aby to omówić, przeanalizujemy dzisiejszy stos protokołów internetowych od jego dolnej warstwy do górnej. Jeśli chcesz dowiedzieć się więcej o tle HTTP/2, zapoznaj się z naszym najlepszym przewodnikiem po HTTP/2.

Protokół internetowy (IP)

Protokół internetowy (IP) definiuje dolną część całej topologii internetowej. To ta część internetowego stosu, która, można śmiało powiedzieć, naprawdę nie podlega negocjacjom bez zmiany wszystkiego, w tym wymiany całej infrastruktury sprzętowej, od routerów po serwery, a nawet maszyny użytkowników końcowych.

Tak więc, chociaż może nastąpić przegląd protokołu, tak daleko idące przedsięwzięcie nie jest obecnie na horyzoncie, głównie dlatego, że nie wymyśliliśmy realnej, przełomowej, ale kompatybilnej wstecz alternatywy.

Możemy prześledzić początki protokołu IP w 1974 roku, do artykułu opublikowanego przez Instytut Inżynierów Elektryków i Elektroników, którego autorami byli Vint Cerf i Bob Cahn. Szczegółowo opisuje pakiety wysyłane przez sieć, kierując je przez adresy IP i zdefiniowane numerycznie adresy węzłów w sieci/sieciach. Protokół określał format tych pakietów, czyli datagramów – ich nagłówki i ładunek.

Po definicji RFC 760 z 1980 roku, IETF zaakceptował definicję powszechnie stosowaną do dziś, w swoim Request For Comments 791. Jest to czwarta wersja protokołu, ale można powiedzieć, że jest to pierwsza wersja produkcyjna.

Używa adresów 32-bitowych, co ogranicza liczbę adresów do około 4 miliardów. To ograniczenie wyjaśnia tajemnicę, dlaczego niebiznesowi użytkownicy Internetu otrzymują „dynamiczne adresy IP” od swoich dostawców usług internetowych, a statyczny adres IP jest uważany za „wartość dodaną” i często podlega dodatkowym opłatom.

Reglamentują.

Nie minęło dużo czasu, zanim zdano sobie sprawę, że 32-bitowe adresy to za mało, a niedobór się zbliżał, więc opublikowano wiele RFC, próbując sobie z tym poradzić. Chociaż te rozwiązania są dziś szeroko stosowane i stanowią część naszego codziennego życia, prawdopodobnie można bezpiecznie powiedzieć, że są to hacki.

Zapisz się do newslettera

Chcesz wiedzieć, jak zwiększyliśmy ruch o ponad 1000%?

Dołącz do ponad 20 000 innych osób, które otrzymują nasz cotygodniowy biuletyn z poufnymi wskazówkami dotyczącymi WordPressa!

Zapisz się teraz

Protokół internetowy w wersji 6 lub IPv6 pojawił się jako sposób na rozwiązanie tych ograniczeń, w tym stopniowe przejmowanie poprzedniej wersji. Został on opracowany jako projekt dokumentu standardowego dla IETF w 1998 roku i został podniesiony do standardu internetowego w 2017 roku.

Podczas gdy przestrzeń adresowa IPv4 była ograniczona 32-bitową długością adresu, standardowi IPv6 przyznano 128 bitów, czyli 3,4 * 10 ^ 38 możliwych adresów. To powinno nam wystarczyć na jakiś czas.

Według Google i łączności IPv6 wśród jej użytkowników, adopcja IPv6 wynosi nieco ponad 35% w czerwcu 2021 r.

IP to podstawowa warstwa stosu internetowego, definiująca najbardziej podstawowe rzeczy, bez gwarancji dostarczenia, integralności danych czy uporządkowania przesyłanych pakietów. Sam w sobie jest zawodny. Format nagłówka protokołu IPv4 zapewnia sumę kontrolną nagłówka, której węzły transmisyjne wykorzystują do weryfikacji integralności nagłówka. Różni się to od wersji IPv6, która opiera się na warstwie łącza znajdującej się pod spodem, dzięki czemu działa szybciej.

Zrozumienie roli TCP i UDP

Teraz nadszedł czas, aby zbadać, gdzie HTTP/3 pasuje do TCP i UDP.

TCP

Podczas gdy IP jest podstawową warstwą całej naszej dzisiejszej komunikacji online, TCP (protokół kontroli transmisji) jest częścią wyższego poziomu pakietu protokołów internetowych, zapewniającą niezawodność potrzebną do korzystania z Internetu, poczty i przesyłania plików (FTP) – dla warstw aplikacji/protokołów internetowych.

Obejmuje to wieloetapowe ustanawianie połączenia, z uzgadnianiem, gwarantowaną kolejnością pakietów i retransmisją utraconych pakietów. Zapewnia informację zwrotną (potwierdzenia) dostarczenia do nadawcy i tak dalej. Istnieje również obliczanie sumy kontrolnej w celu wykrycia błędów.

Wszystkie te rzeczy wskazują na wiele kroków, które sprawiają, że TCP jest niezawodnym protokołem, co czyni go podstawą najbardziej znanych usług internetowych, z których obecnie korzystamy.

Jego specyfikacja datowana na 1974 (RFC 675) i 1981 (RFC 793) nie uległa znaczącym zmianom do dnia dzisiejszego.

Niezawodność zapewniana przez TCP nie jest jednak bez kosztów. Koszty wszystkich objazdów wymaganych przez uściski dłoni, informacje zwrotne na temat dostawy, gwarancje zamówień i sumy kontrolne, które można uznać za słabe i zbędne. Dzięki temu TCP stał się wąskim gardłem współczesnego stosu protokołów. HTTP/2 osiągnął poziom poprawy szybkości, który można osiągnąć oprócz TCP.

UDP

User Datagram Protocol (UDP) jest również jedną z części pakietu Internet Protocol Suite, którego specyfikacja sięga 1980 roku (RFC 768).

Jest to, jak sama nazwa wskazuje, bezpołączeniowy protokół oparty na datagramach. Co oznacza, że ​​nie ma uścisków dłoni i nie ma gwarancji zamówienia lub dostawy. Oznacza to, że wszelkie możliwe kroki zapewniające dostarczanie, integralność danych i inne rzeczy są pozostawione warstwie aplikacji. Oznacza to, że aplikacja oparta na protokole UDP może dobierać strategie, które zastosuje w zależności od konkretnego przypadku, lub może ewentualnie wykorzystać elementy warstwy łącza, takie jak sumy kontrolne, w celu uniknięcia narzutów.

Ponieważ UDP jest szeroko rozpowszechniony, podobnie jak TCP, umożliwia osiągnięcie ulepszeń bez konieczności aktualizacji oprogramowania układowego na szerokiej gamie urządzeń podłączonych do Internetu lub znaczących zmian w systemach operacyjnych.

Wdrażanie nowych protokołów jest utrudnione przez wiele zapór ogniowych, translacji NAT, routerów i innych urządzeń pośredniczących, które pozwalają jedynie na wdrażanie protokołu TCP lub UDP między użytkownikami a serwerami, do których muszą dotrzeć. – wyjaśniono HTTP/3

Ten wątek w Hacker News może pomóc nam w zrozumieniu powodów, dla których warto zbudować nową wersję HTTP na istniejącym stosie sieciowym, zamiast wymyślać ją na nowo (chociaż jest w tym coś więcej).

Specyfikacja formatu pakietu UDP jest raczej minimalna, jego nagłówek składa się z portu źródłowego, portu docelowego, długości w bajtach nagłówka pakietu i danych pakietu oraz sumy kontrolnej. Suma kontrolna może służyć do weryfikacji integralności danych zarówno dla nagłówka, jak i części danych pakietu.

Suma kontrolna jest opcjonalna, gdy podstawową warstwą protokołu jest IPv4 i obowiązkowa w przypadku protokołu IPv6. Do tej pory UDP był używany do takich rzeczy, jak synchronizacja zegara systemów komputerowych (NTP), aplikacje VoIP, strumieniowanie wideo, system DNS i protokół DHCP.

SZYBKO i HTTP/3

QUIC (Quick UDP Internet Connections) został po raz pierwszy wdrożony przez Google w 2012 roku. Na nowo definiuje granice warstw sieciowych, opierając się na protokole UDP niższego poziomu, redefiniując uścisk dłoni, funkcje niezawodności i funkcje bezpieczeństwa w „przestrzeni użytkownika”, unikając potrzeby aktualizowanie jąder systemów ogólnodostępnych w Internecie.

Podobnie jak w przypadku HTTP/2, postępu, który został zapoczątkowany przez Google SPDY lub szybki, HTTP/3 ponownie będzie opierał się na tych osiągnięciach.

Chociaż protokół HTTP/2 zapewnił nam multipleksowanie i łagodził blokowanie nagłówka wiersza, jest on ograniczony przez protokół TCP. Możesz użyć jednego połączenia TCP dla wielu strumieni zmultipleksowanych razem w celu przesyłania danych, ale gdy jeden z tych strumieni utraci pakiet, całe połączenie (i wszystkie jego strumienie) są zakładnikami, że tak powiem, dopóki TCP nie zrobi swojego zadania ( retransmituje utracony pakiet).

Oznacza to, że wszystkie pakiety, nawet jeśli są już wysłane i czekają w buforze węzła docelowego, są blokowane do momentu ponownego przesłania utraconego pakietu. Daniel Stenberg w swojej książce o http/3 nazywa to „blokadą nagłówka opartego na TCP”. Twierdzi, że przy 2% utracie pakietów użytkownicy będą lepiej radzić sobie z HTTP/1, z sześcioma połączeniami, które zabezpieczają to ryzyko.

QUIC nie jest tym ograniczony. Dzięki QUIC opartemu na bezpołączeniowym protokole UDP koncepcja połączenia nie ma ograniczeń TCP, a awarie jednego strumienia nie muszą wpływać na resztę.

Jak ujął to Lucas Pardue z Cloudflare:

Koncentrując się na strumieniach UDP, QUIC osiąga multipleksowanie bez konieczności korzystania z jednego połączenia TCP. QUIC buduje swoje połączenie na wyższym poziomie niż TCP. Nowe strumienie w połączeniach QUIC nie są zmuszane do czekania na zakończenie pozostałych. Połączenia QUIC czerpią korzyści również z wyeliminowania narzutu na uzgadnianie TCP, co zmniejsza opóźnienia.

Ludzie z Cisco nakręcili interesujący film wyjaśniający trójstronny uścisk dłoni TCP:

Chociaż QUIC eliminuje funkcje niezawodności TCP, nadrabia to ponad warstwą UDP, zapewniając retransmisję pakietów, zamawianie i tak dalej. Google Cloud Platform wprowadziła obsługę QUIC dla swoich systemów równoważenia obciążenia w 2018 r. i odnotowała poprawę średniego czasu ładowania strony o 8% na całym świecie i nawet o 13% w regionach, w których opóźnienia są większe.

Pomiędzy Google Chrome, YouTube, Gmail, wyszukiwarką Google i innymi usługami, Google był w stanie wdrożyć QUIC na niezłym kawałku Internetu, bez czekania na IETF. Inżynierowie Google twierdzą, że w 2017 r. 7% ruchu internetowego było już realizowane przez QUIC.

Wersja QUIC firmy Google skupiała się tylko na transporcie HTTP przy użyciu składni HTTP/2. Osoby z IETF (osoby odpowiedzialne za standaryzację QUIC) zdecydowały, że wersja QUIC przeznaczona dla IETF powinna być w stanie przenosić więcej niż tylko HTTP. Na razie jednak wszelkie prace nad protokołami innymi niż HTTP przez QUIC są wstrzymane.

Jeszcze jedną rzeczą, na którą zdecydowała grupa robocza IETF, jest to, że standardowa wersja będzie używać szyfrowania TLS 1.3 zamiast niestandardowego rozwiązania Google. TLS 1.3, w porównaniu ze starszymi wersjami, również przyczynia się do szybkości protokołu, ponieważ jego uzgadnianie wymaga mniej połączeń w obie strony. Kinsta obsługuje TLS 1.3 na wszystkich naszych serwerach i na naszej sieci CDN Kinsta.

Obecnie Google nadal używa własnej wersji QUIC w swoim produkcie, kierując swoje prace rozwojowe w kierunku standardów IETF. Większość innych graczy internetowych opiera się na wersji IETF (oba różnią się między sobą innymi aspektami poza szyfrowaniem).

Jeśli otworzymy Chrome Dev Tools i załadujemy niektóre produkty Google, takie jak Gmail, w kolumnie Protokół na karcie Sieć, zobaczymy, że wiele zasobów jest ładowanych za pośrednictwem Google w wersji protokołu QUIC. Dotyczy to również produktów Google, takich jak Analytics, Menedżer tagów Google itp.

Cloudflare opublikował bardzo obszerną aktualizację dotyczącą postępów w standaryzacji.

Chociaż UDP zapewnia QUIC i HTTP/3 pewne nieodłączne zalety, to także niesie ze sobą pewne wyzwania.

TCP był głównym protokołem od lat, podczas gdy UDP nie, więc systemy operacyjne i stos oprogramowania nie są ogólnie zoptymalizowane. W konsekwencji, w przypadku QUIC obciążenie/wymagania procesora są znacznie wyższe, według niektórych szacunków, dwukrotnie większe niż w przypadku HTTP/2.

Optymalizacje sięgają głęboko do jądra systemów operacyjnych i różnych routerów i oprogramowania sprzętowego. Ten przewodnik po tuningu Red Hata może rzucić więcej światła na ten temat dla tych, którzy są bardziej zaawansowani technicznie.

Można powiedzieć, że QUIC próbuje przeprojektować funkcje TCP na podstawie bardziej minimalistycznego i bardziej elastycznego protokołu.

Połączenia QUIC, o których wspominaliśmy wcześniej, łączą TLS i transportowe uścisk dłoni. Po ustanowieniu są identyfikowane za pomocą unikalnych identyfikatorów CID (identyfikatorów połączeń). Identyfikatory te są zachowywane przy zmianach adresów IP i mogą pomóc w zabezpieczeniu nieprzerwanego pobierania, na przykład przy zmianie z 4G na Wi-Fi. Jest to istotne, zwłaszcza że coraz więcej ruchu w Internecie odbywa się na urządzeniach mobilnych. Mogą pojawić się pytania, czy ten element został wymyślony przez Google, aby ułatwić lepsze śledzenie użytkowników w różnych połączeniach i dostawcach Internetu.

Protokół TLS jest obowiązkowy i ma na celu utrudnienie urządzeniom znajdującym się w środku manipulowania lub podsłuchiwania ruchu. Dlatego nierzadko zdarza się, że dostawcy i dostawcy zapór sieciowych, tacy jak Cisco, postrzegają protokół UDP jako problem i zapewniają sposoby jego wyłączenia. Pośrednikom trudniej jest kontrolować i nadzorować lub filtrować ruch QUIC.

Strumienie QUIC są przesyłane przez połączenia QUIC, jednokierunkowe lub dwukierunkowe. Strumienie mają identyfikatory identyfikujące inicjatora i określają, czy strumień jest jednokierunkowy, czy dwukierunkowy, a także służą do sterowania przepływem w strumieniu.

Podczas gdy QUIC jest protokołem warstwy transportowej, HTTP jest warstwą wyższą, protokołem warstwy aplikacji lub protokołem aplikacji.

Ponieważ zgodność wsteczna ma ogromne znaczenie, IETF promował implementację HTTP/3 i uwzględni w odpowiedzi starą wersję (HTT1 lub HTTP/2). Będzie zawierać nagłówek, który informuje klienta, że ​​HTTP/3 jest dostępny, wraz z informacjami o porcie/hoście, jak opisano w RFC 7838.

Różni się to od protokołu HTTP/2, w którym transport może być negocjowany w ramach uzgadniania TLS. Ale ponieważ IETF prawie przyjął oparty na QUIC protokół HTTP/3 jako kolejny standard, możemy oczekiwać, że klienci sieci Web będą coraz częściej przewidywać obsługę protokołu HTTP/3. Klienci mogą buforować dane z poprzednich połączeń HTTP/3 i łączyć się bezpośrednio (zero-round-trip lub 0-RTT) podczas kolejnych wizyt na tym samym hoście.

Streszczenie

Są tacy, którzy uważają, że skoro standard HTTP/2 nie został jeszcze w pełni przyjęty, może być za wcześnie na szerokie poparcie dla HTTP/3. To słuszny punkt, ale, jak wspomnieliśmy, ten protokół był już testowany i wdrażany na dużą skalę. Google zaczął go testować już w 2015 roku, a Facebook w 2017 roku.

W 2022 r. mamy obsługę HTTP/3 w głównych przeglądarkach, takich jak Google Chrome i Brave. Na froncie infrastruktury serwery internetowe, takie jak Litespeed i Nginx, mają działające implementacje HTTP/3, podczas gdy dostawcy sieci, tacy jak Cloudflare, wdrożyli już pełną obsługę HTTP/3.

W tej chwili protokół HTTP/3 nadal znajduje się w fazie Internet Draft, a najnowsza wersja ma wygasnąć w sierpniu 2021 roku. Ten rok będzie ekscytujący, ponieważ możemy spodziewać się, że główni dostawcy oprogramowania zaczną wdrażać nowe standard.