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

Sign up for free end-to-end testing training

Learn how to create end-to-end tests for your applications from the beginning to mobile testing
Name
Email address

GET YOUR EMAIL UPDATES

Get great contents delivered straight to your inbox everyday, just a click away, Sign Up Now.
Name
Email address