Nowe projekty standardów

Dynamiczny rozwój technologii webowej wymusza opracowywanie nowych i uaktualnianie istniejących standardów związanych z technologią WWW . Konsorcjum WWW (W3C) opracowało nowe wersje standardów mających duże znaczenie dla rozwoju Internetu i intrasieci.

Dynamiczny rozwój technologii webowej wymusza opracowywanie nowych i uaktualnianie istniejących standardów związanych z technologią WWW . Konsorcjum WWW (W3C) opracowało nowe wersje standardów mających duże znaczenie dla rozwoju Internetu i intrasieci.

HTTP-NG - nadzieja transakcji internetowych

Kiedy za kilka lat kolejna generacja HTTP pojawi się w oprogramowaniu, wydajność transakcji internetowych powinna się wydatnie poprawić. Rozpowszechniona obecnie wersje protokołu HTTP nie odpowiada w pełni wymaganiom stawianym przez dzisiejsze aplikacje Internetu i intrasieci. Protokół ten nie funkcjonuje najlepiej w przypadku dużych opóźnień transmisji pomiędzy serwerem i klientem, nie wykorzystuje efektywnie pasma i nie obsługuje operacji off-line. Większość internautów to użytkownicy domowi, połączeni z Internetem modemem pracującym (w najlepszym przypadku) z szybkością 28,8 kb/s. HTTP l.x jest prostyrr protokołem typu zlecenie-odpowiedź, nie przystosowanyrr do środowisk, w których jest obecnie najczęściej używany Połączenia trwale w HTTP l.x mogą rozwiązać część tych problemów, ale nie wszystkie: samo funkcjonowanie HTTP wymaga wykonywania wielu nieoptymalnych "rund komunikacyjnych".

Konsorcjum WWW (W3C), świadome tych niedostatków, stworzyło kolejną wersję standardu - HTTP-ng (HTTP Next Generation). W pracach nad nową wersją za cel postawiono sobie istotną poprawę wydajności, wprowadzenie ochrony oraz innych mechanizmów poprawiających jej funkcjonalność. Standard przechodzi proces stabilizacyjny wewnątrz W3C, które przekazało niedawno rezultaty swoich prac nad HTTP-ng do IETF (Internet Engineering Task Force) w celu ich ratyfikacji.

W intrasieciach HTTP-ng powinien zapewnić lepsze użytkowanie pasma i poprawić wydajność. Patrząc jednak realnie na procesy rynkowe, nie należy się spodziewać, że produkty obsługujące HTTP-ng pojawią się wcześniej niż za kilka lat.

Kłopotliwy HTTP

Nowe projekty standardów

Warstwowa architektura HTTP - ng

Obecnie używaną wersją HTTP jest v. 1.1. Koryguje ona niektóre, najbardziej widoczne braki swojej poprzedniczki - HTTP 1.0. Jednak zarówno wersja 1.0, jak i 1.1 nadal są obarczone fundamentalną wadą: zgodnie z tym protokołem za każdym razem, kiedy przeglądarka zechce pobrać obiekt z serwera webowego, musi ustanawiać nowe połączenie. W przypadku WWW obiektem może być dokument HTML, obraz GIF lub inny element strony.

Przeglądarka, zlecając pobranie obiektu webowego, angażuje się w skomplikowaną wymianę zleceń i potwierdzeń z serwerem. Wymiana ta nie jest optymalna co najmniej z dwóch powodów: HTTP jest protokołem dość "gadatliwym", a TCP/IP to protokół z "przesuwnym oknem" (sliding window), zmieniający wielkość przesyłanych pakietów.

W początkach stosowania HTTP jego "gadatliwość" nie miała tak wielkiego znaczenia. Główny dostęp koncentrował się w obrębie miasteczek uniwersyteckich, tak więc "pogawędki protokolarne" nie wprowadzały większego przeciążenia. Jednak z chwilą, gdy Web stał się fundamentem Internetu, obciążenie to nabrało istotnego znaczenia.

Mimo to nadal bardziej problematyczny jest drugi czynnik. Ponieważ TCP/IP jest protokołem z "przesuwnym oknem", to na początku transmisji rozmiar pakietów danych przesyłanych przez zestawione połączenie jest mały, z uwagi na nieznajomość jakości połączenia (Quality of Service). Jeżeli QoS jest kiepska i pakiety muszą być często retransmitowane, to rozmiar pakietu pozo staje mały. W czystym środowisku komunikacyjnym, w którym poziom QoS jest dobry i pakiety nie wymagają powtórzeń TCP/IP zwiększa rozmiar pakietów danych (rozmiar "okna") do maksymalnej, obsługiwanej przez oprogramowanie TCP/IP wielkości. Ponieważ główne transakcje HTTP są relatywnie małe (co najwyżej kilka kilobajtów), a jest ich bardzo dużo ("gadatliwość"), to rozmiar okna rzadkc odpowiada rzeczywistym potrzebom W rezultacie obsługa wielu małych pakie tów (zamiast kilku dużych) jest nieopty malna z punktu widzenia wydajności.

Problem zazwyczaj potęguje fakt powiązania dokumentu z innymi obiektam on-line. Składając stronę webową, przeglądarka żąda przeważnie wykonania wielu małych transakcji w odniesieniu do wielu różnych obiektów. Jednym ze sposobów osiągnięcia przez przeglądarkę lepszej wydajności jest otwieranie wielu połączeń jednocześnie, w celu łącznego odbioru kilku obiektów. Poprawia to co prawda szybkość uzyskiwania odpowiedzi z punktu widzenia użytkownika, jednak nie rozwiązuje zasadniczego problemu architektonicznego.

HTTP-ng radzi sobie z tym problemem umożliwiając przenoszenie wielu zleceń przez pojedyncze połączenie; rozmiar okna może być więc wykorzystany optymalnie.

Nowy model

Model HTTP-ng tworzą trzy warstwy: transportowa, messagingu i aplikacyjna (poprzednia wersja HTTP była jednowarstwowa).

HTTP-ng wysyła wszystkie wiadomości używając warstwy sesyjnej lub transportowej. Zastosowanie warstwy transportowej upraszcza zarządzanie wieloma strumieniami danych. Protokół multipleksacji WWW (o nazwie WebMUX) obsługuje najważniejszą funkcję tej warstwy: podział pojedynczego połączenia na wiele kanałów. Wszystkie wiadomości sterujące, takie jak np. zlecenia GET HTTP, są przesyłane kanałem sterującym, a obiekty (strona HTML, GIFy itp.) są kierowane do oddzielnych kanałów w pojedynczym połączeniu. Funkcją WebMUX jest zarządzanie przepływem danych pomiędzy wieloma adresatami i nadawcami informacji. Połączenie MUX często jest nazywane sesją - w celu odróżnienia go od połączeń TCP/IP. Podobnie port MUX nazywa się kanałem (w odróżnieniu od portu TCP/IP). Grupa kanałów MUX zestawionych przez połączenia TCP/IP do poszczególnych hostów IP jest nazywana punktem końcowym MUX. Pojedynczy punkt końcowy MUX (i wszystkie kanały MUX w tym punkcie końcowym) może być dostępny za pośrednictwem kilku różnych portów TCP/IP. Oznacza to, że port TCP użyty w stosie transportowym nie identyfikuje w sposób jawny zestawu kanałów MUX - zestaw ten jest identyfikowany przez punkt końcowy MUX.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200