Как работает http keep-alive?

Хранилища были добавлены в HTTP, чтобы в основном уменьшить существенные служебные данные быстрого создания и закрытия соединений сокетов для каждого нового запроса . Ниже приведено краткое описание того, как он работает в HTTP 1.0 и 1.1:Как работает http keep-alive?

HTTP 1.0 Спецификация HTTP 1.0 на самом деле не вникает в то, как Keep-Alive должен работать. В основном, браузеры, которые поддерживают Keep-Alive добавляет дополнительный заголовок к запросу как:

Connection: Keep-Alive Когда сервер обрабатывает запрос и генерирует ответ, он также добавляет заголовок ответ: соединения : Keep-Alive. Когда это будет сделано, соединение сокета будет не закрыто, как раньше, но остается открытым после отправки ответа. Когда клиент отправляет другой запрос, он повторно использует одно и то же соединение. Соединение будет продолжать использоваться до тех пор, пока клиент или сервер не решит, что разговор завершен, и один из них отключает соединение.

Вышеуказанное объяснение comes from here. Но я не понимаю одну вещь

Когда это будет сделано, то соединение с сокетом не закрыта, как и раньше, но остаются открытыми после отправки ответа.

Как я понимаю, мы просто отправляем пакеты tcp, чтобы делать запросы и ответы, как это помогает socket connection и как он работает? Нам по-прежнему приходится отправлять пакеты, но как он может каким-то образом установить постоянное соединение? Это кажется нереальным.

источник

2013-12-24 good_evening

@JakeGould: Спасибо за редактирование. Я думаю, что это уместно, аналогичные вопросы были заданы раньше. Например: http://stackoverflow.com/questions/1480329/what-exactly-does-a-persistent-connection-mean, но они не объясняют, как это «соединение сокетов» действительно работает. –

@good_evening Это старый вопрос, назад, чем такой вопрос был в порядке. Как JakeGould предложил попробовать Server Fault или [networkengineering.se]. –

Я думаю, что здесь более уместно, чем на сбое сервера, поскольку он просто просит объяснений технологии, которая может помочь программистам. – PSIXO

Накладные расходы при установлении нового TCP-соединения (поиск DNS, рукопожатие TCP, рукопожатие SSL/TLS и т. Д.). Без поддержания работоспособности каждый HTTP-запрос должен установить новое TCP-соединение, а затем закрыть соединение после отправки или получения ответа. Постоянное обновление позволяет повторно использовать существующее TCP-соединение для нескольких запросов/ответов, тем самым избегая всех этих накладных расходов. Именно это делает соединение «постоянным».

В HTTP 0.9 и 1.0, по умолчанию сервер закрывает свой конец TCP-соединения после отправки ответа клиенту. Клиент должен закрыть свой конец TCP-соединения после получения ответа. В HTTP 1.0 (но не в 0.9) клиент может явно запросить сервер не закрывать его конец соединения, включив в запрос заголовок Connection: keep-alive. Если сервер согласен, он включает заголовок Connection: keep-alive в ответе и не закрывает его конец. Затем клиент может повторно использовать одно и то же TCP-соединение для отправки следующего запроса.

В HTTP 1.1, keep-alive поведение по умолчанию, если клиент явно не запрашивает сервер, чтобы закрыть соединение, включив Connection: close заголовок в своем запросе, или сервер принимает решение включает в себя Connection: close заголовок в своем ответе.

источник

2013-12-24 16:46:19

Спасибо. Это то, что я не совсем понял, почему TCP-соединение сложно создать. Что еще, кроме «DNS-запросов», «рукопожатие TCP», «рукопожатие SSL/TLS» должно быть выполнено? –

+11

Ничего. Но сами по себе DNS, TCP и SSL не являются легкими системами, каждый из которых требует времени и ресурсов для выполнения своих соответствующих шагов до следующего выполнения. DNS должен разрешить имя хоста для IP-адреса до того, как TCP-соединение может быть выполнено. TCP должен выполнить трехстороннее рукопожатие для создания нового соединения до того, как будет выполнен сеанс SSL. SSL включает несколько рукопожатий для обмена криптографической информацией взад и вперед. Чем меньше раз вам приходится выполнять эти шаги между данной клиентской/серверной парой, тем быстрее HTTP-запросы могут быть отправлены и отправлены. –

Я проигнорировал, потому что это объясняет концепцию сохранения чего-то живого, что довольно очевидно только из названия вещи. На самом деле это не объясняет, как функционирует механизм. –

Вы можете понять это так:

HTTP использует TCP как транспорт. Перед отправкой и приема пакетов с помощью TCP,

Клиент должен отправить запрос на CONNECT
Сервер отвечает
передача Передача данных осуществляется
Соединение закрыто.

Однако, если мы используем функцию keep-alive, соединение не закрывается после получения данных. Соединение остается активным.

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

источник

2013-12-24 16:43:57

Это действительно сетевой вопрос, но в конце концов это может быть уместно.

Путаница возникает из-за различия между ориентированными на пакет и ориентированными на потоки соединениями.

Интернет часто называют сетью «TCP/IP». На низком уровне (IP, Интернет-протокол) Интернет ориентирован на пакет. Хосты отправляют пакеты другим хостам.

Однако, помимо IP, мы имеем TCP (протокол управления передачей). Вся цель этого уровня Интернета состоит в том, чтобы скрыть пакетно-ориентированный характер базового носителя и представить соединение между двумя хостами (хосты и порты, если быть более правильными) как поток данных, аналогичный файлу или труба. Затем мы можем открыть сокет в OS API для представления этого соединения, и мы можем рассматривать этот сокет как дескриптор файла (буквально FD в Unix, очень похожий на файл HANDLE в Windows).

Большинство остальных протоколов клиент-сервер Интернета (HTTP, Telnet, SSH, SMTP) накладываются поверх TCP. Таким образом, клиент открывает соединение (сокет), записывает свой запрос (который передается как один или несколько карманов в базовом IP) в сокет, считывает ответ сокета (и ответ может содержать данные из нескольких IP-пакетов как хорошо), а затем ... Тогда выбор заключается в том, чтобы открыть соединение для следующего запроса или закрыть его. Pre-KeepAlive HTTP всегда закрывал соединение. Новые клиенты и серверы могут держать его открытым.

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

Небольшой недостаток может заключаться в том, что сервер теперь должен сообщить клиенту, где заканчивается ответ. Сервер не может просто отправить ответ и закрыть соединение. Он должен сказать клиенту: «читать 20 КБ, и это будет конец моего ответа». Таким образом, размер ответа должен быть заранее известен сервером и передан клиенту как часть протокола более высокого уровня (например, Content-Length: в HTTP). В качестве альтернативы сервер может отправить разделитель для указания конца ответа - все зависит от протокола выше TCP.

источник

2013-12-24 16:59:02 Arkadiy

У HTTP есть несколько способов прекратить ответ, в зависимости от формата ответа (простой против chunked vs MIME). «Content-Length» не всегда используется/возможно. –

Мне очень нравится этот ответ, он не подходит для вопроса, но то, что вы написали в своем ответе, это то, что я искал. И чтобы сделать это не просто благодарственное письмо, да. Content-Length не всегда применим, но есть другие способы рассказать клиенту, где заканчивается ответ, и это важно, так как вы теряете возможность «Прочитать все, что потом», поддерживая соединение открытый. – PSIXO

Давайте сделаем аналогию. HTTP состоит в отправке запроса и получении ответа. Это похоже на то, чтобы задать кому-то вопрос и получить ответ.

Проблема в том, что вопрос и ответ необходимо пройти через сеть. Для связи через сеть используется TCP (сокеты). Это похоже на использование телефона, чтобы задать вопрос кому-то и ответить на этот вопрос.

HTTP 1.0 состоит, при загрузке страницы, содержащей 2 изображения, например, в

сделать телефонный звонок
Попросить страницы
получить страницу
закончить телефонный звонок
сделать телефонный звонок
попросить первое изображение
получить первое изображение
конца телефонного звонка
сделать телефонный звонок
попросить второе изображение
получить второе изображение
конца телефонного звонка

сделать телефонный звонок и окончанием это требует времени и ресурсов. Управляющие данные (например, номер телефона) должны проходить через сеть. Было бы более эффективным сделать один телефонный звонок, чтобы получить страницу и два изображения. Это то, что позволяет сохранить жизнь. С Keep-Alive, выше становится

сделать телефонный звонок
запросить страницу
получить страницу
задать для первого изображения
получить первое изображение
спросить для второго изображения
получить второе изображение
завершить телефонный звонок

источник

2013-12-24 17:00:10

Спасибо, да, я это понимаю. Но как мы можем заставить его работать только с «одним телефонным звонком»? Что происходит между клиентом и сервером на первом этапе («сделать телефонный звонок»)? –

Первый этап: http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment. То, что происходит после продиктовано протоколом HTTP. Сервер ожидает HTTP-запрос и отвечает с ответом HTTP. Затем он ожидает другой запрос и т. Д. –

Как работает http keep-alive?

ответ

Смежные вопросы