Назад | Перейти на главную страницу

apache2 keepalive и открытие tcp-соединения

IP-пакет содержит полезную нагрузку, такую ​​как информация HTTP, которая, в свою очередь, содержит информацию html. IP-пакет инкапсулируется в сегмент TCP, который обнаруживает проблемы при передаче по сети, запрашивает повторную передачу потерянных данных, восстанавливает неупорядоченные данные и помогает минимизировать перегрузку сети. Это делается так, что получатель TCP отвечает сообщением подтверждения при получении данных. Отправитель поддерживает таймер с момента отправки пакета и повторно передает пакет, если таймер истекает до того, как сообщение было подтверждено.

Процесс, в котором отправитель TCP отправляет свой первоначальный запрос, когда получатель TCP получает свой последний сегмент и переупорядочивает данные, выполняется ли все это в одном TCP-соединении? Или для каждой передачи и подтверждения требуется несколько TCP-соединений?

Причина, по которой я спрашиваю, состоит в том, что в apache2 есть декларативное приложение KeepAlive. Я не совсем понимаю это. если установлено значение «Вкл.», KeepAlive позволит каждому соединению оставаться открытым для обработки нескольких запросов от одного и того же клиента. Но разве каждое соединение не будет оставаться открытым до тех пор, пока получатель TCP не получит все сообщение, которое может быть целым html-документом?

Когда вы посещаете страницу, необходимо загрузить несколько элементов. У вас есть главная страница, но у вас также есть CSS, JS, изображения и т. Д. Для HTTP / 1.0 для каждого запроса требуется одно соединение: клиент запускает соединение, отправляет HTTP-запрос, сервер отвечает заголовками HTTP, затем содержимое и затем закрывает соединение. Это необходимо повторить для каждого извлекаемого элемента, что требует нескольких TCP-соединений.

Чтобы упростить задачу, существовало неофициальное расширение KeepAlive для HTTP / 1.0, которое при включении заставляло серверную сторону сохранять соединение открытым в течение определенного периода времени (например, 2 секунды) после того, как он завершил отправку ответа. За это время клиент, поддерживающий пакеты Keepalive, может отправить второй запрос в том же TCP-соединении. Затем третий и т. Д. До определенного предела. Это расширение стало стандартом для HTTP / 1.1 и называется постоянными соединениями. Чтобы это можно было использовать, клиентская сторона должна явно запросить это в заголовках.

Параметр KeepAlive, который вы видите там, будет включать сообщения поддержки активности для HTTP / 1.0 или отключать их для HTTP / 1.1 (в зависимости от выбранного вами варианта). Основываясь на этом: http://httpd.apache.org/docs/2.2/mod/core.html#keepalive, по умолчанию он включен для HTTP / 1.1 и отключен для HTTP / 1.0.

Но разве каждое соединение не будет оставаться открытым до тех пор, пока получатель TCP не получит все сообщение, которое может быть целым html-документом?

Да, но без KeepAlive он закроется после отправки этого документа. С KeepAlive он позволит клиенту отправить следующий запрос без разрыва и установки другого TCP-соединения.

Если у вас есть клиент, который запрашивает два элемента, вот что происходит без KeepAlive:

  1. Клиент запрашивает TCP-соединение
  2. Сервер принимает TCP-соединение
  3. Клиент запрашивает URI
  4. Сервер отвечает - надеюсь, отправив полное содержимое URI
  5. Клиент отключается
  6. Сервер закрывает сокет
  7. Клиент запрашивает TCP-соединение
  8. Сервер принимает TCP-соединение
  9. Клиент запрашивает второй URI
  10. Сервер отвечает - надеюсь, отправив полное содержимое URI
  11. Клиент отключается
  12. Сервер закрывает сокет

Вот то же самое, но с KeepAlive:

  1. Клиент запрашивает TCP-соединение
  2. Сервер принимает TCP-соединение
  3. Клиент запрашивает URI
  4. Сервер отвечает - надеюсь, отправив полное содержимое URI
  5. Клиент запрашивает второй URI
  6. Сервер отвечает - надеюсь, отправив полное содержимое URI
  7. Клиент отключается
  8. Сервер закрывает сокет

Как вы можете видеть, во втором примере отпали накладные расходы на разрыв и установление нового TCP-соединения. Для сервера с большой нагрузкой, со страницами, содержащими множество URI, это может значительно снизить накладные расходы.