jak przesyłane są dane w Internecie?

wiadomość w butelce

Jeśli uważnie śledzisz bloga, na pewno post o adresach URL jest przeczytany. Wiesz z niego czym one są, jak są zbudowane i do czego wykorzystywane. Jak sama nazwa wskazuje adres odnosi się tylko do miejsca znajdowania się konkretnego zasobu. Czy zastanawiałeś się jednak, w jaki sposób wchodzi się w interakcję ze stroną internetową lub np. pobierany jest obrazek? Wykorzystuje się do tego wiadomości http, które są tematem dzisiejszego wpisu.

Czym są wiadomości HTTP

Zacznijmy od wyjaśnienia czym one w ogóle są. To tekstowe komunikaty używane do wymiany informacji między serwerem, a korzystającym z niego, nazywanego klientem. W tym miejscu warto zaznaczyć, że wyróżniane są dwa rodzaje wiadomości. Wysyłane przez klienta, to żądanie http (ang. HTTP request). Serwer w rezultacie wysłania requestu zwraca odpowiedź HTTP (ang. HTTP response). Na takim rozwiązaniu oparta jest duża część wymiany danych w całym Internecie . Przykład: wpisujesz adres URL w przeglądarkę -> ładuje się witryna (żądanie – odpowiedź). Podajesz hasło do wyszukania w Google – zwracane są wyniki. Wypełniasz formularz rejestracyjny i potwierdzasz przyciskiem –masz założone konto w serwisie. Mógłbym tak długo, ale niezależnie jak różne były by to przypadki, wiadomości zawsze mają identyczną strukturę, a różnią się jedynie treścią.
No właśnie. Żądania i odpowiedzi HTTP, aby mogły być używane na globalną skalę muszą posiadać ujednolicony format. Omówmy więc jego elementy.

wiadomości http

Elementy wiadomości HTTP

Linia początkowa

Linia początkowa (ang. start line) zawiera podstawowe informacje o wiadomości. Różni się ona
w zależności od typu.

Dla requestu składa się z:
1. Metody
2. Adresu URL
3. Wersji protokołu

W przypadku response wyróżniamy:
1. Wersję protokołu
2. Kod odpowiedzi
3. Nazwa odpowiadająca kodowi

Metody http

Zacznijmy od żądania. Możesz zastanawiać się czym są wyżej wspomniane metody http – już wyjaśniam. To czasownik lub rzeczownik opisujący rodzaj akcji, jaką chcemy wykonać na zasobie znajdującym się na serwerze.

Poniżej umieszczam listę metod wraz z objaśnieniem:
1. GET – ta metoda powinna jedynie zwracać informacje o danym zasobie i NIE wprowadzać żadnych zmian. Przykładem może być wspomniane Google. Podając frazę do wyszukania nie modyfikujesz niczego, a jedynie pobierasz informacje – wyniki odpowiadające hasłu, które wpisałeś.
2. HEAD – działa podobnie jak GET. Różnicą jest to, że nie zwraca żadnego ciała requestu (czym jest ciało dowiesz się z dalszej części artykułu)
3. POST – wykorzystywana do wprowadzania danych. Wysłanie takiego żądania może skutkować np. wysłaniem nowych danych do bazy, wcześniej wspomnianym utworzeniem konta, czy umieszczeniem zdjęcia na portalu społecznościowym.
4. PUT – służy do modyfikowania całych zasobów. Przykładem może być zmiana hasła dostępu do istniejącego już konta, pod warunkiem przekazania całego modelu zawierającego hasło, który zostanie podmieniony w miejsce starego.
5. PATCH – ta metoda używana jest do wprowadzania częściowych zmian w zasobie. W swoim działaniu jest bardzo podobna do PUT, z tą różnicą, że PATCH podmienia tylko zmienione wartości. Trzymając się powyższego przykładu: w przypadku PATCH wymagane byłoby podanie jedynie informacji dotyczących hasła.
6. DELETE – jak mówi nazwa, usuwa zasób wskazany przez adres URL.
7. CONNECT – metoda, której raczej nie będziesz używał w swojej karierze programisty webowego. Gdyby jednak, pamiętaj, że służy ona do otworzenia połączenia między klientem a serwerem.
8. OPTIONS – używane do wymiany informacji dotyczących opcji połączeń z serwerem.
9. TRACE – wykorzystywane do testowania, zwraca wysłaną wiadomość z powrotem.

Mamy już wszystkie informacje, dotyczące linii startowej HTTP Requestu, praktycznym przykładem takiej linii może być:

GET http://www.test.com HTTP/1.1
POST https://www.google-analytics.com/collect HTTP/1.1

Kody odpowiedzi http

Wróćmy jeszcze do odpowiedzi HTTP. Warto tutaj wspomnieć o kodach HTTP. Służą one do wymiany informacji dotyczących rezultatu wykonania żądania, pomiędzy klientem a serwerem. Każdy kod to trzycyfrowa liczba. Pierwsza cyfra komunikuje z jakiego typu odpowiedzią mamy do czynienia:

a) 1XX – to tzw. kody informacyjne

Przykłady:
    100 Continue – informacja o tym, aby dalej wysyłać żądanie
    110 Connection Timed Out – serwer zbyt długo nie odpowiadał, żądanie zostało przerwane

b) 2XX – kody powodzenia – wysyłane, gdy request został poprawnie obsłużony

    200 OK – operacja przebiegła pomyślnie
    201 Created – utworzono dokument wysłany przez klienta
    204 No Content – request obsłużony poprawnie, nie było potrzeby zwracać dodatkowych danych

c) 3XX – kody przekierowania- zobaczysz go gdy wyślesz poprawne żądanie, ale z pewnych przyczyn nie może zostać obsłużony.

    300 Multiple Choices – istnieje więcej niż jeden sposób obsługi żądania, komputer nie może sam zdecydować, które ma wykonać, więc nie wykonuje żadnego
    305 Use Proxy – do wykonania tego requestu należy użyć serwera proxy

d) 4XX – kody błędu klienta – te zostaną zwrócone, gdy błąd będzie leżał po stronie klienta

    400 Bad Request – wysłano niepoprawne żądanie
    401 Unauthorized – użytkownik nie ma uprawnień dostępu do zasobu, wymagana jest autoryzacja
    404 Not Found – serwer nie znalazł informacji o żądanym zasobie

e) 5XX – kody błędu serwera – wysyłane gdy coś stanie się na serwerze. Może to być nieobsłużony błąd w aplikacji lub uszkodzenie jakiegoś urządzenia, które powoduje przerwę w pracy witryny, przykłady:

   500 Internal Server Error – wystąpił nieoczekiwany błąd, który uniemożliwił obsługę requestu
    501 Not Implemented – ten błąd można otrzymać gdy istnieje możliwość odpytania serwera o zasób, ale nie ma implementacji w kodzie aplikacji

Mała dygresja: wiadomości http swojego czasu były często występującym elementem w internetowych memach, przykłady:

http://refugeeks.com/wp-content/uploads/2014/04/100-Continue-600x480.jpg

http://refugeeks.com/wp-content/uploads/2014/04/200-OK-600x480.jpg

http://refugeeks.com/wp-content/uploads/2014/04/202-accepted-600x480.jpg

http://refugeeks.com/wp-content/uploads/2014/04/204-No-Content-600x480.jpg

źródło: http://refugeeks.com

Skoro znamy wszystkie elementy linii początkowej odpowiedzi HTTP, zostało jeszcze przedstawić jej przykłady:

HTTP/1.1 200 OK
HTTP/1.1 404 Not Found

Okej! Trochę nam to zajęło, ale omówiliśmy pierwszą linie wiadomości HTTP. Oczywiście na tym nie koniec. Kolejnym elementem są nagłówki.

Nagłówki

Nagłówek (ang. header) to informacja przekazywana w formacie klucz: wartość. Jedną z ich właściwości jest tzw. case sensitivity, więc należy zwracać uwagę na wielkość wpisywanych znaków, ponieważ header Accept i accept są rozróżniane przez serwer jako dwa osobne. Aktualnie istnieje wiele nagłówków używanych przez programistów. Wartość każdego z nich zależy od jego nazwy. Przykłady:
Accept – wysyłany przez klienta zrozumiały format danych, w jakim powinny być one zwrócone po przetworzeniu przez serwer. Dla danych w formacie JSON, będzie to: application/json.
Host – domena, do której wysyłane jest żądanie
Date – data, która reprezentuje czas, w którym została wysłana wiadomość
Do 2012 roku stosowano powszechną praktykę dodawania prefiksu X do nazw nagłówków. Aktualnie jednak odchodzi się od tej konwencji. Warto wiedzieć, że nadal spotkać można aplikacje wymagające takich headerów.

Pusta linia

Tuż po headerach, których w wiadomości można umieścić dowolną ilość, występuje tzw. pusta linia (ang. blank line). Jej zadaniem jest wyraźne zaznaczenie zakończenia sekcji zawierającej nagłówki.

Ciało wiadomości

Ostatnim elementem wiadomości HTTP jest jej ciało (ang. body). Zawiera ono wszystkie pozostałe informacje potrzebne do obsłużenia żądania lub zwrócone w odpowiedzi. W praktyce sprowadza się to do serializacji i deserializacji obiektów obsługiwanych przez kod programu. Warto wspomnieć, że nie wszystkie requesty (np. GET, HEAD, DELETE, OPTIONS) mogą posiadać ciało. Podobnie jest z odpowiedziami, te z kodem, np.: 201, 204 nie wymagają zwracania dodatkowych danych.

To już wszystkie podstawowe informacje dotyczące wiadomości HTTP. Na koniec warto przedstawić całość w jednym kawałku, tak abyś miał ogólny pogląd na jej zawartość:

żądanie

request

odpowiedź

response

Jeśli doczytałeś do końca artykułu, a dodatkowo masz za sobą także wpis o adresach URL, to gratulacje. Opanowałeś podstawową wiedzę dotyczącą protokołu http. To także kolejny krok na drodze do opanowania buishido programisty! Jeżeli artykuł Ci pomógł, proszę przekaż go dalej w mediach społecznościowych, aby mógł pomóc większej ilości osób – przyciski do tego służące masz poniżej.

Zapraszam także do komentowania, daj znać, czy po lekturze tego posta dowiedziałeś się czegoś nowego i czy wiedza ta czymś Cię zaskoczyła.

Please follow and like us:

3 Replies to “jak przesyłane są dane w Internecie?”

  1. Pytanie do rozważenia:
    Jaka cecha protokołu HTTP(S) sprawia, że potrzebne są ciasteczka?

    1. Dziękuję za komentarz Tomku. Z pewnością masz na myśli bezstanowość. Nie umieściłem tutaj tej informacji z racji tego, że wpis, jak i cały blog, kierowany jest do osób dopiero zaczynających swoją przygodę z programowaniem. Zależy mi więc na porcjowaniu wiedzy i przedstawieniu jej w sposób maksymalnie zrozumiały dla osób nowych w temacie. W miarę rozwoju bloga, konsekwentnie zwiększam poziom trudności, tak aby razem z blogiem rozwijali się jego czytelnicy – kandydaci na programistów 🙂 Niemniej jednak dziękuję Ci za komentarz, na pewno przygotuję kiedyś wpis także o cechach samego protokołu HTTP(S). Pozdrawiam 🙂

      1. Poprawnie 😉

        Co do Twojej argumentacji, to jest ona niepoprawna w mojej opinii. Osobom świeżym, nowym należy właśnie pokazać esencję problematyki, tak aby zrozumienie było głębokie oraz pełne. Jak się dobrze zastanowisz, to ta bez-stanowość nie jest zarezerwowana dla HTTP(S), ona pojawia się często w informatyce. Chodzi o to, aby mieć tego świadomość. Jeśli miałeś styczność z programowaniem w paradygmacie funkcyjnym to świetnie rozumiesz co mam na myśli.

Dodaj komentarz

This site uses Akismet to reduce spam. Learn how your comment data is processed.