Почему первый сетевой вызов занимает больше времени, чем последующие?

Question

Я пытаюсь понять это поведение, когда первый сетевой вызов занимает более чем вдвое больше последующих. Я знаю, что разрешение DNS не займет более 5-50 мс, и это происходит только при первом вызове. Учитывая эту информацию, не должно быть большой разницы во времени, необходимом для первого звонка и последующих звонков.

Я проверил это поведение с некоторыми известными URL-адресами в отдельных окнах инкогнито для каждого с отключенным кэшем и прикрепил несколько скриншотов, чтобы поддержать мое наблюдение ниже. Может кто-нибудь помочь мне понять это поведение?

Примечание: показания принимаются при подключении к Интернету на полной скорости

Заранее спасибо

Answer 1

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

При наведении курсора на «блоки» водопада вы получите данные о времени:

Вот краткий справочник для каждого из этапов (из Google Developers ):

• Queuing . Браузер ставит запросы в очередь, когда:
  • Есть запросы с более высоким приоритетом.
  • Для этого источника уже открыто шесть TCP-соединений, что является пределом. Относится только к HTTP / 1.0 и HTTP / 1.1.
  • Браузер ненадолго выделяет место в кеше диска
• стойловое . Запрос может быть приостановлен по любой из причин, описанных в очереди.
• DNS Lookup . Браузер разрешает IP-адрес запроса.
• Согласование прокси . Браузер согласовывает запрос с прокси-сервером.
• Запрос отправлен . Запрос отправляется.
• Подготовка ServiceWorker . Браузер запускает сервисного работника.
• Запрос в ServiceWorker . Запрос отправляется работнику сервиса.
• Ожидание (TTFB) . Браузер ожидает первый байт ответа. TTFB означает время до первого байта. Это время включает в себя 1 обратная задержка и время, необходимое серверу для подготовки ответ.
• Загрузка содержимого . Браузер получает ответ.
• Получение Push . Браузер получает данные для этого ответа через HTTP / 2 Server Push.
• Чтение Push . Браузер читает ранее полученные локальные данные.

Так в чем же разница между первым и последующим запросами в традиционном сценарии HTTP / 1.1?

• DNS Lookup : может потребоваться больше времени для разрешения DNS для первого запроса. Последующие запросы будут обрабатываться намного быстрее с использованием кэша DNS браузера.
• Ожидание (TTFB) : При первом запросе необходимо установить TCP-соединение с сервером. Благодаря механизму поддержания активности HTTP последующие запросы к тому же серверу будут повторно использовать существующее TCP-соединение, чтобы предотвратить повторное TCP-квитирование, что сокращает время прохождения в три раза по сравнению с первым запросом.
• Загрузка контента : из-за медленного запуска TCP первому запросу потребуется больше времени для загрузки контента. Поскольку последующие запросы будут повторно использовать TCP-соединение, при увеличении размера окна TCP содержимое будет загружаться намного быстрее, чем первый запрос.

Таким образом, как правило, последующие запросы должны быть намного быстрее, чем первый запрос. На самом деле это приводит к общей стратегии оптимизации сети: используйте для своего сайта как можно меньше доменов.

HTTP / 2 даже вводит мультиплексирование для лучшего повторного использования одного TCP-соединения. Вот почему HTTP / 2 даст повышение производительности в современном мире переднего плана, где мы развернем тонны небольших ресурсов на серверах CDN.

Answer 2

После нескольких экспериментов я обнаружил, что Content Download ( шаги запроса браузера ) часть запроса ускоряется в 1,5-2 раза Это выглядит как причина TCP Slow Start algorithm

Как говорится:

современные браузеры либо открывают несколько соединений одновременно, либо повторно используют одно соединение для всех файлов, запрашиваемых с определенного веб-сервера

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

Кроме того, @Vishal Vijay сделал хорошее дополнение:

Выполнение первоначального установления соединения с сервером занимает много времени (DNS Lookup + Начальное соединение + SSL). Браузеры создают постоянные соединения для HTTP-запросов и оставляют их открытыми в течение некоторого времени. Если в течение этого времени поступит какой-либо запрос на тот же домен, браузер попытается повторно использовать это соединение для более быстрого ответа.