Browsed by
Month: September 2015

Metody HTTP

Metody HTTP

W zapytaniu HTTP metoda to umowna nazwa akcji, która powinna zostać wykonana po stronie odbiorcy. Metody HTTP pokrywają zdecydowaną większość przypadków wykonywania wszelkich akcji na zasobach. Ponieważ akcje te mogą być różnie zaimplementowane po stronie serwera, omówimy tutaj założenia przyjęte wobec tych metod, których programista powinien się trzymać podczas implementacji zachowań serwera.

Aby wprowadzić pewne zasady odnośnie użycia metod, standard HTTP ze względu na cechy metod definiuje 2 grupy: metody bezpieczne i metody idempotentne. Przedstawione poniżej cechy obu grup to jedynie zalecenia, ponieważ protokół w żaden sposób nie może zagwarantować, że implementacja metod po stronie serwera spełnia te warunki.

Metody bezpieczne (GET, HEAD)

Są to metody, które nie powinny modyfikować danych, ani mieć żadnych skutków ubocznych.

W rzeczywistości trudno jest zagwarantować, że nawet metoda GET (pobierająca dane) nie będzie modyfikowała absolutnie żadnych danych. Dość częstym wymaganiem jest audyt akcji, który powoduje zapis informacji o każdej operacji wykonywanej na danych, nawet o odczycie. Wskutek tego akcja GET zapisze pewne dane, ale nie będą to główne dane systemu.

Metody idempotentne (GET, HEAD, PUT, DELETE, OPTIONS, TRACE)

Są to metody, które wywołane wiele razy w tych samych warunkach początkowych zawsze będą miały ten sam rezultat.

Poniżej lista wszystkich podstawowych metod HTTP

OPTIONS sprawdzenie udostępnionych metod
GET pobieranie danych
HEAD pobieranie metadanych na temat zapytania
POST wysyłanie danych
PUT dodanie zasobu
DELETE skasowanie zasobu
TRACE używane przy testowaniu połączenia
CONNECT stworzenie tunelu poprzez serwery proxy

Dobrą praktyką jest implementacja metod zgodna z powyższymi wymaganiami mimo że, protokół HTTP nie może w żaden sposób wymóc ich spełnienia.

HTTP pipelining

HTTP pipelining

Jest to technika, która pozwala za pomocą jednego połączenia TCP przesłać wiele zapytań HTTP bez oczekiwania na otrzymanie rezultatu poprzednich wiadomości.

http_pipelining

Dzięki temu jesteśmy w stanie lepiej wykorzystać sieć do transferu informacji. Niestety ograniczeniem mechanizmu HTTP pipelining jest to, że odpowiedzi muszą zostać odebrane w kolejności w jakiej zostały wysłane zapytania. W ten sposób mogą być przetwarzane tylko zapytania idempotentne (nie zmieniające stanu obiektu docelowego). Pozostałe typy zapytań muszą być przetwarzane synchronicznie.
W wersji HTTP/2 protokołu umożliwiono asynchroniczne wykonywanie zapytań na jednym połączeniu, czyli bez konieczności odbioru odpowiedzi w kolejności ustalonej przez porządek zapytań.

Przedstawiona funkcjonalność wymaga oczywiście, żeby zarówno klient jak i serwer ją wspierały. Kolejnym problemem podczas używania HTTP pipeliningu do pobierania stron jest różnorodność domen, a co za tym idzie serwerów, z których pobierane są treści w ramach jednej strony. Są to przypadki, w których nie jest możliwe skorzystanie z tego mechanizmu.

Podobnie jak Persistent connection, zysk (zmniejszenie łącznego czasu operacji) jest widoczny głównie podczas pobierania wielu zasobów na raz.

Źródła:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html
https://developer.mozilla.org/en-US/docs/Web/HTTP/Pipelining_FAQ

Persistent connection

Persistent connection

To mechanizm pozwalający na wielokrotne użycie jednego połączenia do wysyłania requestów do serwera, czyli tłumacząc dosłownie zachowywanie połączeń. Właściwość ta jest szczególnie przydatna przy pobieraniu treści stron www, gdy poza kodem HTML strony, przeglądarka potrzebuje pobrać dodatkowo wszystkie zasoby niezbędne do poprawnego jej wyświetlenia m.in. obrazy, style, skrypty.

requset-persistent

Specyfikacja HTTP 1.1 definiuje, że domyślnie połączenie jest zachowywane, chyba że w requeście będzie ustawiony nagłówek:

Connection: close

W poprzedniej wersji protokołu HTTP 1.0 nie była to wartość domyślna, więc aby wymusić stosowanie mechanizmu Persistent connection należało użyć nagłówka:

Connection: Keep-Alive

Zalety tego mechanizmu:

  • zmniejsza zapotrzebowanie na CPU i pamięć,
  • umożliwia HTTP pipelining,
  • zmniejsza ilość połączeń i redukuje przeciążenia sieciowe,
  • błędy mogą być sygnalizowane bez zamykania połączenia,
  • jest on szczególnie istotny przy połączeniach HTTPS, ze względu na dłuższy czas potrzebny na ustanowienie szyfrowanego połączenia.

Wady:

  • niezamknięcie połączenia po pobraniu ostatniego zasobu blokuje otwieranie połączeń do innych klientów ze względu na ograniczoną ilość zasobów.

Niezamknięcie połączenia może stwarzać zagrożenie ataku polegającego na blokowaniu serwera poprzez przedłużanie czasu życia otwartego połączenia przy równoczesnym otwieraniu dużej ilości takich połączeń. Jest to nazywane atakami typu Slow HTTP DoS. Można im łatwo przeciwdziałać, ustawiając limity długości poszczególnych części wiadomości oraz limity czasu przesyłania.

Mechanizm Persistent connection jest niezwykle przydatny do implementacji mechanizmu long pollingu używanego do symulowania komunikacji typu push z serwerem. Komunikacja typu push polega na wysyłaniu wiadomości z serwera do klienta bez potrzeby uprzedniego wysłania zapytania do serwera. Long pooling polega na wysłaniu przez klienta zapytania do serwera z maksymalnym czasem oczekiwania na odpowiedź. Po upływie zadanego czasu wysyłane jest kolejne zapytanie oczekujące. Gdy zostanie wysłana wiadomość, będzie ona mogła być bez problemu odebrana, gdyż klient oczekiwał na nią. Przykładem biblioteki .NET korzystającej z tego mechanizmu jest SignalR.

Źródła:
http://tools.ietf.org/html/rfc7230#section-6.3

Schemat wiadomości HTTP

Schemat wiadomości HTTP

Nagłówki są to właściwości żądania i odpowiedzi przesyłane wraz z samą wiadomością. Służą one przede wszystkim do sterowania zachowaniem serwera oraz przeglądarki przez nadawcę wiadomości.

Spójrzmy na przykładowe wywołanie zapytania HTTP i na odpowiedź na nie. Na jego podstawie będziemy mogli poznać, do czego służą podstawowe nagłówki w zapytaniach.

Request:

GET index.html HTTP/1.1
 Host: www.wp.pl
 Connection: close
 User-Agent: Mozilla/5.0
 Accept: text/html

http-requestTreść podstawowego zapytania zaczyna się od typu żądania. Najpopularniejsze to POST i GET. W najprostszym ujęciu GET służy do pobierania danych, a POST do wysyłania ich do serwera. Szerzej na ten temat w punkcie metody HTTP.

Kolejnym elementem jest względny adres do zasobów na serwerze. W naszym przypadku odwołujemy się do strony index.html na serwerze wskazanym przez nagłówek Host, a mianowicie www.wp.pl. W tym miejscu może wystąpić również adres wraz z numerem portu.

Na kolejnym miejscu powinniśmy wyspecyfikować wersję protokołu, z której korzystamy.

Od tego momentu można ustawiać potrzebne nam nagłówki wiadomości. Poniżej opiszę tylko te z nich, które zostały użyte w przykładzie, jednak szerzej będą one omówione w poście o nagłówkach HTTP.

  • Host – definiuje adres url i port serwera, z którego pobieramy dane. Jest to część obowiązkowa w każdym żądaniu HTTP
  • Connection – służy do sterowania mechanizmem Persistent connection
  • User-Agent – określa jaka aplikacja wykonała zapytania. Jest to przydatne, jeżeli chcemy po stronie serwera generować treści zależne od aplikacji lub systemu.
  • Accept – pozwala zdefiniować, jakiego typu danych oczekujemy. Zazwyczaj przeglądarki są w stanie odkryć jaki typ danych jest oczekiwany po rozszerzeniach ścieżek adresów URL, jednak ten nagłówek jest częścią mechanizmu uzgadniania typu zawartości. Służy on do zdefiniowania, które formaty są czytelne dla klienta oraz które serwer może obsłuzyć

Response:

Status: HTTP/1.1 200 OK
 Server:Apache
 Content-type:text/html; charset=UTF-8
 Content-Length:39512
 Connection:close

<html>
<head>
   http://jquery-2.1.4.js
</head>
<body>
   <img src="image.png" />
</body>
</html>

W przypadku odpowiedzi od serwera, pierwszą informacją jest status powodzenia operacji wraz z wersją protokołu. Dla uproszczenia przyjmijmy, że status 200 oznacza powodzenie operacji, a wszystkie statusy większe od 400 oznaczają sytuacje błędne. Statusy te pozwalają przekazać wiele informacji począwszy od błędów po stan zasobu po operacji.

Także i tu serwer może ustawić dodatkowe właściwości dla danej odpowiedzi.

  • Serwer – pozwala przedstawić się serwerowi adekwatnie jak w przypadku nagłówka User-Agent w requescie.
  • Connection – działa podobnie jak wcześniej do mechanizmu Persistent connection
  • Content-Type i Content-Length pozwalają na przesłanie informacji o typie/formacie oraz o długości zwracanej treści.

Zawsze po zdefiniowaniu nagłówków, na końcu odpowiedzi znajduje się treść przesłanej wiadomości. W tym przypadku jest to kod HTML żądanej strony.

Wstęp do HTTP

Wstęp do HTTP

Post ten jest początkiem serii opisującej podstawę funkcjonowania obecnie istniejącej sieci.

HTTP (HyperText Transfer Protocol) jest protokołem definiującym jakie wiadomości i w jaki sposób są przekazywane poprzez sieć. Używany jest on głównie do komunikacji typu klient-serwer. W ogólnym ujęciu polega to na tym, że klient wysyła do serwera żądanie wykonania zdefiniowanej akcji na zasobie. Zasobem może być strona www oraz rekord w bazie danych. W ten sposób możemy prosić o pobranie strony lub modyfikację zestawu danych. Typowy schemat komunikacji pokazany jest na poniższym rysunku.

client-server

Przykładowo, gdy klient chce otrzymać zasób z określonego adresu url, otwiera połączenie do serwera. Następnie wysyła żądanie opisujące m.in. w jaki sposób chce otrzymać dane i czeka na odpowiedź ze strony serwera. HTTP jest protokołem bezstanowym. Oznacza to, że pomiędzy kolejnymi żądaniami (requestami) nie są przechowywane żadne informacje. Po otrzymaniu odpowiedzi połączenie z serwerem może być bez problemu zamknięte.

Zasoby HTTP są jednoznacznie identyfikowane w sieci za pomocą adresów URL

urlW najprostszym przypadku żądanie składa się z typu operacji (GET, POST, itp.) i adresu URL. Dodatkowo mogą się w nim znajdować pomocnicze nagłówki, które pozwalają sterować parametrami i zachowaniem requestów. Serwer po przetworzeniu zapytania odsyła do klienta wiadomość zawierającą kod statusu przetworzenia żądania oraz treść odpowiedzi. Także i tutaj mogą być przesyłane dodatkowe informacje za pomocą nagłówków.

Podstawowym przykładem operacji HTTP w sieci web jest żądanie otworzenia strony w przeglądarce. Pyta ona o konkretny adres, otrzymując w odpowiedzi kod strony HTML. Analizując go, może automatycznie wysłać do serwera kolejne zapytania pobierające dodatkowe zasoby: obrazy, skrypty, style, itp. W pokazanym poniżej przykładzie widać, że po pobraniu treści strony index.html, przeglądarka będzie potrzebowała pobrać dodatkowo pliki jquery-2.1.4.js oraz image.png.

http-related

Te zależne zasoby są również pobierane za pomocą protokołu HTTP. Różnią się one typem obiektów, które chcemy pobrać i oczywiście adresem.

request-flow

Kolejnym zastosowaniem protokołu jest operowanie na zasobach REST, czyli zasobach na których operowanie wzoruje się na działaniu zapytań HTTP.