Это другая штука, имеющая опосредованное отношение к 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 потоков).
Я бы посоветовал сделать штук двадцать картинок — и тогда начнётся повторное использование имеющихся соединений.
Простой
Средний
Средний
