Браузер игнорирует keep-alive?

Question

[user-vova]

Привет! В apache включен keep-alive с timeout 30 сек. Firebug говорит, что браузер делает запрос с заголовком keep-alive, и сервер его добавляет в ответе. Но список открытых соединений говорит обратное. В тестовой странице index.html прописаны 5 img. При переходе на неё открывается 6 соединений, которые живут 30 сек. Т.е. браузер открывает keep-alive соединение для каждого запроса. А должно быть одно соединение для всех запросов. В чем может быть проблема? Тестил в chrome, opera и firefox.

Answer 1

[user-vova]

Stalker_RED,
Fixid,
Wiki: "keep-alive - использование одного TCP-соединения для отправки и получения многократных HTTP-запросов и ответов вместо открытия нового соединения для каждой пары запрос-ответ" На практике для каждой пары запрос-ответ создается новое соединение. Как я понимаю вики, keep-alive как раз создан для того, чтобы в рамках одного соединения осуществить загрузку контента? Если я дурак, то в каких случаях keep-alive пригодится? Решение в комментариях

Comments

[Fixid]

Определение верное, вот только создается не один, а несколько соединений и все keep-alive.
И при загрузке очередного файла, будет переиспользовано существующие соединение или создано новое если нет свободных.
Количество запросов в одном соединении, как правило, ограничено настройками сервера.
И как только выйдет TTL или лимит, соединение надо пересоздавать.
Поэтому и придумали HTTP 2.0 это вечный keep-alive в одном соединении с агрегацией, все как вы хотите.

[user-vova]

Fixid: Спасибо! ИМХО wiki сбивает с толку: "keep-alive - использование одного TCP-соединения для отправки и получения многократных HTTP-запросов..."

Answer 2

[Mercury13]

Это другая штука, имеющая опосредованное отношение к keep-alive. Это загрузка информации в несколько потоков.

Почему шесть соединений, а не пять — другой вопрос. Я бы предположил вот что. Браузер разобрал index.html и увидел там картинку. Создаём новое HTTP-соединение (нешифрованное) — два пинга спустя поехали данные. Задействуем имеющееся — один пинг спустя. С небольшим пингом браузер просто подумал, что быстрее будет вот так. А может, браузер просто туп и если мы укладываемся в количество соединений с одним сервером — создаём новые, да и всё.

А вот то, что все картинки в разных потоках — это верно. Если считать скорость сети «бесконечной», для каждой из них информация пойдёт с запозданием в два пинга. Работай мы в один поток — первая пришла бы с запозданием в 2 пинга, вторая в 3 пинга, третья в 4 пинга… А вот протоколы SPDY и HTTP/2 позволяют сказать: «Дай мне картинки А, Б и В»,— и они все, ОДНИМ СОЕДИНЕНИЕМ, придут с запозданием в два пинга.

Другими словами:
HTTP (все метки времени — когда они были посланы с клиента/приняты клиентом):
К: SYN: (+0 пингов)
С: SYN+ACK (+1 пинг)
К: ACK (+1 пинг)
К: Запрос 1 (+1 пинг)
С: Ответ 1 (+2 пинга)
К: Запрос 2 (+2 пинга)
С: Ответ 2 (+3 пинга)

HTTP2:
К: SYN: (+0 пингов)
С: SYN+ACK (+1 пинг)
К: ACK (+1 пинг)
К: Запросы 1, 2 (+1 пинг)
С: Ответы 1, 2 (+2 пинга)

На реальных «не очень быстрых» соединениях играют роль не только пинги, но и скорость передачи. Тогда картинки начнут появляться не по одной, а по восемь (или сколько там соединений) — это тоже может повлиять на впечатление от браузера. К тому же если случился затор на шлюзе локальной сети — тогда, если одно соединение забарахлит, другие что-то привезут. А если сеть не очень хорошо сконфигурирована — это ещё и ввосьмеро увеличит скорость передачи (реально в начале 2000-х качал в универе 10-мегабайтный драйвер за перемену в 100 потоков).

Я бы посоветовал сделать штук двадцать картинок — и тогда начнётся повторное использование имеющихся соединений.

Answer 3

[Stalker_RED]

А должно быть одно соединение для всех запросов.

с чего вдруг?
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D...