Принцип реализации длинного соединения HTTP

1. Определение длинного HTTP-соединения и короткого соединения

• длинное HTTP-соединение

  • После того, как браузер сделает сеанс HTTP-доступа к серверу, он не закроет соединение напрямую, а сохранит его в течение определенного периода времени по умолчанию, затем соединение будет использоваться снова при следующем доступе браузера.

  • существуетHTTP/1.1В версии соединение по умолчанию длинное соединение, можем пройтиConnection: keep-aliveполе для указания.

• Короткое HTTP-соединение

  • Каждый раз, когда браузер выполняет операцию HTTP с сервером, устанавливается новое соединение.
  • существуетHTTP/1.0По умолчанию короткая ссылка в версии

2. Природа длинных HTTP-соединений

Суть протокола HTTP — это протокол прикладного уровня в семиуровневой эталонной модели OSI.Когда сеть обменивается данными, заголовок инкапсулируется протоколом верхнего уровня, а затем инкапсулируется как часть данных протокола нижнего уровня.На практике мы часто связываемся с набором протоколов TCP./IP, то есть транспортный уровень использует протокол TCP, а сетевой уровень использует протокол IP. Следовательно, длинное соединение протокола HTTP по существу является длинным соединением TCP.

2.1 Обзор установления соединения TCP

Мы упомянули TCP выше, поэтому для обзора две стороны связи должны установить соединение через «трехстороннее рукопожатие» при общении.Процесс рукопожатия примерно показан на рисунке 1:

                                 图1. TCP建立连接

Тогда мы можем ясно видеть из приведенного выше рисунка, что и сервер, и клиент установилиTCBБлок управления передачей, вот что мы делаемsocketМесто, где осуществляется управление подключением при программировании, здесь мы сначала отмечаем этоTCB, в следующей статье мы подробно расскажем о LinuxTCBКак осуществляется управление подключением.

2.2 Обзор TCP-соединения

Изучив установление TCP-соединения, давайте взглянем на четыре волны TCP, как показано на рисунке 2:

                                 图2. TCP释放连接

Освобождение TCP-соединения зависит от того, кто активно закрыл связь, а кто пассивно закрыл, чтобы определить их соответствующие состояния.Чтобы узнать конкретное содержание, вы все равно можете обратиться к «Подробному объяснению TCP/IP», которые здесь повторяться не будут.

2.3 Длинное TCP-соединение

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

2.3.1 Механизм поддержания активности TCP

• Зачем нужен механизм поддержания активности?

  • Первый пункт, естественно, является темой нашей статьи.С помощью механизма поддержания активности мы можем гарантировать, что соединение между двумя взаимодействующими сторонами не будет разорвано.
  • Второй момент заключается в том, что в других случаях, если у клиента или сервера есть ошибка или время простоя, то этот механизм проверки активности может быть использован для обнаружения проблемы с сетевым взаимодействием, а затем ошибочное соединение может быть разорвано.

• механизм поддержания активности

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

  Вышеизложенное является лишь кратким введением на принципиальном уровне, согласно литературе [1], мы можем изучить подробное содержание:

  • Если в данном соединении нет никаких действий в течение двух часов, сервер отправляет клиенту тестовый сегмент. Хост клиента должен находиться в одном из следующих 4 состояний.
    • Состояние 1: клиентский хост все еще работает и доступен с сервера. TCP-ответ клиента нормальный, и сервер знает, что другая сторона работает правильно. Сервер сбрасывает таймер проверки активности через два часа. Если через это соединение проходит трафик приложения до истечения двухчасового таймера, таймер сбрасывается через 2 часа после обмена данными.
    • Состояние 2: Произошел сбой клиентского хоста, и он выключается или перезагружается. В любом случае TCP клиента не ответил. Сервер не сможет получить ответ на запрос и истечет время ожидания через 75 секунд. Всего сервер отправляет 10 таких запросов, каждый с интервалом в 75 секунд. Если сервер не получает ответа, он считает клиентский узел закрытым и разрывает соединение.
    • Состояние 3: произошел сбой клиентского хоста, и он был перезапущен. Затем сервер получит ответ на свой запрос проверки активности, но этот ответ является сбросом, в результате чего сервер разорвет соединение.
    • Состояние 4: клиентский хост работает нормально, но подчиненный сервер недоступен. Это то же самое, что и состояние 2, потому что TCP не может определить разницу между состоянием 4 и состоянием 2, все, что он может найти, это то, что не было получено тестового ответа.

• практическое применение

  Тогда мы понимаем, что в теории длинное TCP-соединение реализуется механизмом keep-alive, но механизм keep-alive не является содержимым протокола TCP, указанного в RFC, поэтому иногда на машинах, не поддерживающих keep-alive, живой механизм, нам часто нужно Давайте сначала посмотрим, поддерживается ли он на уровне ядра.Если он не поддерживается, вам нужно реализовать эту функцию самостоятельно на уровне приложения.

  Здесь мы рассмотрим параметры поддержания активности TCP, связанные с Linux.

  • tcp_keepalive_time, единица измерения: секунда, указывает время простоя соединения перед отправкой тестового пакета, по умолчанию 7200 с.
  • tcp_keepalive_intvl, единица измерения: секунда, указывающая интервал между двумя пакетами обнаружения, по умолчанию 75 с.
  • tcp_keepalive_probes, единица, секунда, указывающая количество обнаружений, по умолчанию 9

  Далее, если нам нужно написать свой собственный механизм сердцебиения на прикладном уровне, то нам нужен какой-то другой контент. Я также планирую объяснить эту часть в другой статье. В конце концов, в сегодняшнем распределенном мире множество микросервисов Связь между двумя и реестр также включает в себя механизм сердцебиения, так что мы выроем здесь дыру и опишем его отдельно позже.

2.3.2 Сравнение длинного и короткого соединения TCP

• короткая ссылка TCP

  • преимущество
    • Короткие ссылки не занимают память сервера, и количество подключений, которые может обработать сервер, будет больше
  • недостаток
    • Соединение устанавливается только тогда, когда есть фактические ресурсы для передачи данных.Тогда, после того, как клиент отправляет данные и разрывает соединение, когда сервер отправляет данные клиенту, отправка сообщения в реальном времени не может быть достигнута.
    • Частые установление и разрыв соединений потребляют много ресурсов ЦП и пропускной способности сети.

• TCP длинное соединение[2]

  • преимущество

    • Обе стороны связи могут обеспечить характер передачи и приема данных в режиме реального времени с гарантией механизма поддержания активности.

  • недостаток

    • Так как сервер должен поддерживать эту связь с клиентом все время, так как он является stateful, системных ресурсов может не хватить, когда приходит большое количество одновременных запросов на подключение.

  • Когда вам нужна длинная связь

    • Когда серверу необходимо активно отправлять ресурсы клиенту
    • Когда клиент и сервер часто обмениваются данными
    • Когда клиент не работает или находится в автономном режиме, серверу необходимо выполнить некоторую обработку.

  • Проблемы, которые необходимо учитывать при проектировании длинного TCP-соединения

    • дефолтkeep-aliveВремя относительно долгое, и обычному бизнесу может не понадобиться такое долгое время.
    • socket proxyЭто приведет к аннулированию поддержки активности TCP: многие прокси-приложения могут только пересылать данные приложения TCP, но не могут пересылать пакеты внутри протокола TCP.

    Эти проблемы должны быть реализованы в обнаружении сердцебиения.Чтобы реализовать механизм сердцебиения, обратитесь к последующим статьям.

    ---

Reference

[1] Подробное объяснение протокола TCP/IP, том 1

[2]blog.CSDN.net/QQ_41453285…

[3]woo woo Краткое описание.com/afraid/ah 697 oh 504 no…

Примечание: цитирование было разрешено первоначальным автором.