JavaRush /Blog Java /Random-PL /Część 3. Protokoły HTTP/HTTPS

Część 3. Protokoły HTTP/HTTPS

Opublikowano w grupie Random-PL
Materiał ten stanowi część serii „Wprowadzenie do rozwoju przedsiębiorstwa”. Poprzednie artykuły: Cześć! Dzisiaj zrozumiemy protokoły HTTP i HTTPS. Ale najpierw wyjaśnijmy jedną kwestię: mówimy o protokołach przesyłania danych w sieci w warstwie aplikacji modelu OSI. Jak pamiętacie, model OSI omawialiśmy w jednym z poprzednich artykułów. A jeśli nie pamiętasz, to tutaj . Część 3. Protokoły HTTP/HTTPS - 1

Co to jest protokół przesyłania danych

Tak nazywa się ogólnie przyjęta umowa, dzięki której twórcy różnych usług przesyłają informacje w jednej formie. Na przykład, korzystając z przeglądarki Google Chrome, możesz uzyskać informacje zarówno z Facebooka, jak i Twittera, ponieważ programiści przesyłają je za pomocą standardowego protokołu HTTP, a Twoja przeglądarka może je przetworzyć. Jednolite zasady są również bardzo wygodne dla samych programistów po stronie serwera: istnieje wiele bibliotek, które mogą konwertować informacje za Ciebie i wysyłać je przy użyciu wymaganego protokołu. HTTP został pierwotnie pomyślany jako protokół do przesyłania stron HTML. Tak było przez długi czas, ale obecnie programiści często przesyłają za jego pośrednictwem zarówno ciągi znaków, jak i pliki multimedialne. Ogólnie rzecz biorąc, protokół ten jest wszechstronny i elastyczny, a także naprawdę łatwy w użyciu. Teraz zastanówmy się, jak to zrobić.

Struktura HTTP

Warto od razu zaznaczyć, że protokół HTTP składa się wyłącznie z tekstu. Cóż, nas najbardziej interesuje struktura, w której ten tekst się mieści. Każda wiadomość składa się z trzech części:
  1. Linia startowa — definiuje dane serwisowe.
  2. Nagłówki - opis parametrów wiadomości.
  3. Treść wiadomości (Body) - dane wiadomości. Należy oddzielić od nagłówków pustą linią.
Za pomocą protokołu HTTP można wysłać żądanie do serwera (żądanie) i otrzymać odpowiedź z serwera (odpowiedź). Żądania i odpowiedzi mają nieco inne parametry.

Jak wygląda proste żądanie HTTP

GET / HTTP/1.1
Host: javarush.com
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
Linia startowa zawiera:
  • GET – metoda żądania;
  • / — ścieżka żądania (ścieżka);
  • HTTP/1.1 - wersja protokołu przesyłania danych.
Potem przychodzą nagłówki:
  • Host – host, do którego kierowane jest żądanie;
  • User-Agent to klient wysyłający żądanie.
Brak treści wiadomości. W żądaniu HTTP wymagana jest tylko linia początkowa i nagłówek hosta. Teraz spójrzmy na wszystko w porządku. Żądanie HTTP musi zawierać jakąś metodę. W sumie jest ich dziewięć: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT. Najpopularniejsze to GET i POST. Na początku wystarczą te dwie metody. GET - żąda treści z serwera. Dlatego żądania z metodą GET nie mają treści komunikatu. Ale jeśli to konieczne, możesz wysłać parametry ścieżką w tym formacie: https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 Tutaj: javarush .com — host, /send — ścieżka żądania, ? — separator wskazujący, że po nim znajdują się parametry żądania. Na końcu parametry są wymienione w formacie klucz=wartość, oddzielone ampersandem. POST - publikuje informacje na serwerze. Żądanie POST może przesłać różne informacje: parametry w formacie klucz=wartość, JSON, kod HTML, a nawet pliki. Wszystkie informacje przekazywane są w treści wiadomości. Na przykład:
POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: javarush.com

{
  "Id": 12345,
  "User": "John"
}
Żądanie jest wysyłane do javarush.com/user/create/json, wersja protokołu to HTTP/1.1. Accept określa, jakiego formatu odpowiedzi oczekuje klient, Content-Type określa, w jakim formacie wysyłana jest treść wiadomości. Długość treści - liczba znaków w treści. Żądanie HTTP może zawierać wiele różnych nagłówków. Więcej szczegółów można znaleźć w specyfikacji protokołu .

Odpowiedzi HTTP

Po otrzymaniu żądania serwer przetwarza je i wysyła odpowiedź do klienta:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>
Linia początkowa odpowiedzi zawiera wersję protokołu (HTTP/1.1), kod stanu (200), opis stanu (OK). Nagłówki wskazują rodzaj i długość treści. Treść odpowiedzi zawiera kod HTML, który przeglądarka wciągnie na stronę HTML.

Kody stanu odpowiedzi

Z treścią wiadomości i nagłówkami wszystko jest jasne, ale warto powiedzieć kilka słów o kodach statusów. Kody statusu odpowiedzi składają się zawsze z trzech cyfr, a pierwsza cyfra kodu wskazuje kategorię odpowiedzi:
  • 1xx - informacyjny. Żądanie zostało odebrane, serwer jest gotowy do kontynuowania;
  • 2xx – udało się. Żądanie zostało przyjęte, zrozumiane i przetworzone;
  • 3xx - przekierowanie. Aby przetworzyć żądanie, należy wykonać następujące kroki;
  • 4xx - błąd klienta. Żądanie zawiera błędy lub jest niezgodne z protokołem;
  • 5xx - błąd serwera. Serwer nie był w stanie przetworzyć żądania, chociaż zostało ono poprawnie utworzone;
Druga i trzecia cyfra kodu szczegółowo określają odpowiedź. Na przykład:
  • 200 OK — żądanie zostało przyjęte i pomyślnie przetworzone;
  • 201 Utworzono — żądanie zostało przyjęte i pomyślnie przetworzone, co spowodowało utworzenie nowego zasobu lub jego instancji;
  • 301 Przeniesiony na stałe – żądany zasób został przeniesiony na stałe, a kolejne żądania do niego muszą następować pod nowym adresem;
  • 307 Temporary Redirect – zasób został tymczasowo przeniesiony. Na razie możesz uzyskać do niego dostęp za pomocą automatycznego przekierowania;
  • 403 Zabronione – żądanie jest jasne, ale wymagana jest autoryzacja;
  • 404 Not Found – serwer nie znalazł zasobu pod tym adresem;
  • 501 Nie zaimplementowano – serwer nie obsługuje funkcji odpowiedzi na to żądanie;
  • 505 Wersja HTTP nieobsługiwana — serwer nie obsługuje określonej wersji protokołu HTTP.
Oprócz kodu statusu odpowiedzi wysyłany jest także opis statusu, dzięki czemu można intuicyjnie zrozumieć, co oznacza dany status. Protokół HTTP jest bardzo praktyczny: udostępnia dużą liczbę nagłówków, za pomocą których można ustawić elastyczną komunikację pomiędzy klientem a serwerem. Wszystkie nagłówki żądań i odpowiedzi, metody żądań i kody stanu odpowiedzi nie mogą być uwzględnione w jednym artykule. W razie potrzeby możesz przeczytać oficjalną specyfikację protokołu , która opisuje wszystkie niuanse. Protokół HTTP jest zwykle używany na porcie 80, więc gdy zobaczysz adres kończący się na porcie 80, możesz mieć pewność, że dostęp do niego powinien być dostępny za pośrednictwem protokołu HTTP. Wraz z rozwojem technologii i aktywnym przepływem danych osobowych w Internecie, musieliśmy pomyśleć o tym, jak zapewnić dodatkową ochronę informacji, które klient przesyła na serwer. W rezultacie powstał protokół HTTPS.

Jaka jest różnica między HTTPS a HTTP

HTTPS jest składniowo identyczny z protokołem HTTP, to znaczy używa tych samych linii początkowych i nagłówków. Jedyne różnice to dodatkowe szyfrowanie i domyślny port (443) . HTTPS jest szyfrowany pomiędzy HTTP a TCP, czyli pomiędzy warstwą aplikacji i transportu. Jeśli zapomniałeś o co chodzi, zajrzyj do artykułu o modelu OSI . Nowoczesnym standardem szyfrowania jest TLS. Nie będziemy zagłębiać się w ten temat, ale pamiętajmy, że szyfrowanie następuje zanim informacja dotrze do warstwy transportowej . HTTPS szyfruje absolutnie wszystkie informacje z wyjątkiem hosta i portu, do którego wysyłane jest żądanie. Aby przełączyć serwer tak, aby korzystał z protokołu HTTPS zamiast HTTP, nie musimy zmieniać kodu serwera. Ta funkcja jest włączona w kontenerach serwletów, o czym będziemy mówić w kolejnych artykułach. To wszystko na dzisiaj. Jednak poczekaj. Aby wykryć żądania HTTP, otwórz przeglądarkę Google Chrome, naciśnij klawisz F12 i wybierz kartę Sieć. Tutaj będą wyświetlane wszystkie żądania i odpowiedzi wysłane/odbrane przez Twoją przeglądarkę. Część 4. Podstawy Mavena Część 5. Serwlety. Pisanie prostej aplikacji internetowej Część 6. Kontenery serwletów Część 7. Wprowadzenie do wzorca MVC (Model-View-Controller) Część 8. Pisanie małej aplikacji uruchamianej w trybie spring-boot
Komentarze
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION