Trwałe połączenie HTTP — HTTP persistent connection

HTTP
Poproś o metody
Pola nagłówka
Kody statusu odpowiedzi
Metody kontroli dostępu do zabezpieczeń
Luki w zabezpieczeniach

Trwałe połączenie HTTP , zwane również HTTP keep-alive lub HTTP connection reuse , to pomysł wykorzystania jednegopołączenia TCP do wysyłania i odbierania wielu żądań /odpowiedzi HTTP , w przeciwieństwie do otwierania nowego połączenia dla każdej pojedynczej pary żądanie/odpowiedź. Nowszy protokół HTTP/2 wykorzystuje ten sam pomysł i rozwija go dalej, umożliwiając multipleksowanie wielu równoczesnych żądań/odpowiedzi w ramach jednego połączenia.

Operacja

HTTP 1.0

W HTTP 1.0 połączenia powinny być zawsze zamykane przez serwer po wysłaniu odpowiedzi.

Od końca 1996 roku twórcy popularnych produktów (przeglądarek, serwerów WWW itp.) korzystających z protokołu HTTP/1.0 zaczęli dodawać nieoficjalne rozszerzenie (do protokołu) o nazwie „keep-alive”, aby umożliwić wielokrotne wykorzystanie połączenia prośby/odpowiedzi.

Jeśli klient obsługuje utrzymywanie aktywności, dodaje do żądania dodatkowy nagłówek: 

Connection: keep-alive

Gdy serwer otrzyma to żądanie i wygeneruje odpowiedź, jeśli obsługuje utrzymywanie aktywności, dodaje również ten sam nagłówek do odpowiedzi. Następnie połączenie nie jest zrywane, lecz pozostaje otwarte. Gdy klient wysyła kolejne żądanie, używa tego samego połączenia.

Będzie to kontynuowane, dopóki klient lub serwer nie uznają, że rozmowa się skończyła i w tym przypadku pomijają "Connection:"nagłówek z ostatniej wysłanej wiadomości lub, lepiej, dodają do niej słowo kluczowe „zamknij”: 

Connection: close

Następnie połączenie jest zamykane zgodnie z określonymi zasadami.

Od 1997 r. różne wersje specyfikacji HTTP/1.1 potwierdzały użycie tego nieoficjalnego rozszerzenia i zawierały kilka zastrzeżeń dotyczących interoperacyjności między HTTP/1.0 (utrzymanie aktywności) a klientami/serwerami HTTP/1.1.

HTTP 1.1

W HTTP 1.1 wszystkie połączenia są uważane za trwałe, chyba że zadeklarowano inaczej. Trwałe połączenia HTTP nie używają oddzielnych komunikatów o podtrzymaniu aktywności, po prostu pozwalają wielu żądaniom na użycie jednego połączenia. Jednak domyślny limit czasu połączenia dla Apache httpd 1.3 i 2.0 wynosi zaledwie 15 sekund i tylko 5 sekund dla Apache httpd 2.2 i nowszych. Zaletą krótkiego limitu czasu jest możliwość szybkiego dostarczenia wielu składników strony internetowej bez zużywania zasobów do uruchamiania wielu procesów serwera lub wątków przez zbyt długi czas.

Keepalive z fragmentarycznym kodowaniem transferu

Keepalive utrudnia klientowi określenie, gdzie kończy się jedna odpowiedź, a zaczyna następna, szczególnie podczas potokowej operacji HTTP. Jest to poważny problem, gdy Content-Lengthnie można go używać z powodu przesyłania strumieniowego. Aby rozwiązać ten problem, HTTP 1.1 wprowadził fragmentaryczne kodowanie transferu, które definiuje last-chunkbit. last-chunkBit jest ustawiony na końcu każdej odpowiedzi tak, że klient wie, gdzie rozpoczyna się kolejna odpowiedź.

Zalety

Zgodnie z RFC 7230, sekcja 6.4 , „klient powinien ograniczyć liczbę jednoczesnych otwartych połączeń, które utrzymuje z danym serwerem”. Poprzednia wersja specyfikacji HTTP/1.1 określała określone maksymalne wartości, ale słowami RFC 7230 „okazało się to niepraktyczne dla wielu aplikacji… zamiast tego… zachowaj ostrożność przy otwieraniu wielu połączeń”. Niniejsze wytyczne mają na celu skrócenie czasu odpowiedzi HTTP i uniknięcie przeciążenia. Jeśli potokowanie HTTP jest prawidłowo zaimplementowane, dodatkowe połączenia nie dają korzyści w zakresie wydajności, a dodatkowe połączenia mogą powodować problemy z przeciążeniem.

Niedogodności

Jeśli klient nie zamknie połączenia po otrzymaniu wszystkich potrzebnych mu danych, zasoby potrzebne do utrzymania otwartego połączenia na serwerze będą niedostępne dla innych klientów. Jak bardzo wpływa to na dostępność serwera i jak długo zasoby są niedostępne, zależy od architektury i konfiguracji serwera.

Również sytuacja wyścigu może wystąpić, gdy klient wysyła żądanie do serwera w tym samym czasie, gdy serwer zamyka połączenie TCP. Serwer powinien wysłać do klienta kod statusu 408 Request Timeout tuż przed zamknięciem połączenia. Gdy klient otrzyma kod statusu 408, po wysłaniu żądania, może otworzyć nowe połączenie z serwerem i ponownie wysłać żądanie. Nie wszyscy klienci ponownie wyślą żądanie, a wielu z nich zrobi to tylko wtedy, gdy żądanie ma idempotentną metodę HTTP .

Używaj w przeglądarkach internetowych

Schemat połączenia wielokrotnego vs. trwałego.

Wszystkie nowoczesne przeglądarki internetowe, w tym Google Chrome , Firefox , Internet Explorer (od 4.01), Opera (od 4.0) i Safari korzystają ze stałych połączeń.

Domyślnie Internet Explorer w wersjach 6 i 7 używa dwóch trwałych połączeń, podczas gdy wersja 8 używa sześciu. Trwałe połączenia wygasają po 60 sekundach braku aktywności, które można zmienić za pośrednictwem rejestru systemu Windows.

W przeglądarce Firefox można dostosować liczbę jednoczesnych połączeń (na serwer, na serwer proxy, łącznie). Trwałe połączenia wygasają po 115 sekundach (1,92 minuty) bezczynności, które można zmienić w konfiguracji.

Zobacz też

  • Potokowanie HTTP , dzięki któremu można wysłać wiele żądań bez oczekiwania na odpowiedź
  • HTTP/2 , który umożliwia nietypowe potokowanie żądań i odpowiedzi, a także predykcyjne wypychanie treści przed żądaniem

Bibliografia

Zewnętrzne linki