латентность в интернете что это
Разница между пропускной способностью и латентностью сети
Разница между пропускной способностью и латентностью — это то, что смущает много людей, но если вы профессионал в области ИТ, было бы полезно узнать разницу между ними, потому что рано или поздно вам придется столкнуться с связанной с ней сетевой проблемой. Часть путаницы была создана интернет-провайдерами, всегда рекомендуя увеличить пропускную способность для каждой проблемы, связанной с интернет-скоростью, но, как мы увидим, скорость интернет-соединения не всегда определяется пропускной способностью.
Что такое пропускная способность?
Чтобы понять пропускную способность и задержку, нам нужно иметь четкое определение обеих, поэтому давайте начнем с полосы пропускания. Полоса пропускания — это объем данных, которые могут передаваться из одной точки в другую, обычно измеряемой в секундах. Интернет-провайдеры обычно рекламируют свою полосу пропускания в Интернете, например, 20/20 Мбит/с, что означает, что 20 мегабайт/с данных могут быть загружены или загружены с YouTube в секунду, например. Большинство людей знакомы только с такими параметрами, как мегабайты, гигабайты и т.д., Но интернет-провайдеры все еще используют метрику Megabit, потому что это делает номера более крупными, но на самом деле соединение 20/20 Мбит/с составляет всего около 2 мегабайт. Важно помнить, что пропускная способность — это не скорость. Следовательно, возникает путаница!
Что такое латентность?
Задержка — это время, которое пакет данных принимает для перемещения из одной точки в другую. Другим точным термином для задержки является задержка. Одна важная вещь, которую следует помнить о латентности, состоит в том, что это естественное явление, постулированное Эйнштейном в теории относительности. В нашей вселенной все нужно время для путешествия, даже свет. Таким образом, в Интернете, когда требуется пакет для поездки (например, из центра обработки данных Facebook на ваш компьютер), он называется Latency.
В чем разница между пропускной способностью и задержкой?
Читая определение обоих терминов выше, вы, вероятно, уже заметили разницу между ними, но я дам вам аналогию, чтобы было легче понять это, если вы все еще запутались. Представьте себе шоссе с 4 дорожками, где ограничение скорости составляет 60 миль/ч. Теперь в Интернете пропускная способность — это шоссе, а латентность — ограничение скорости 60 миль в час. Теперь, если вы хотите увеличить количество автомобилей, которые путешествуют по шоссе, вы можете добавить еще несколько дорожек, но поскольку шоссе имеет слишком много кривых и ударов, вы не можете увеличить ограничение скорости, поэтому все автомобили должны путешествовать со скоростью 60 миль в час все еще. Не имеет значения, сколько полос дороги имеет шоссе, машины добираются до места назначения в то же время независимо от размера шоссе!
Почему увеличение пропускной способности увеличивает скорость загрузки, то вы можете спросить, не так ли? Нет, увеличивая пропускную способность, вы увеличиваете пропускную способность, а не скорость. Следуя аналогиям с шоссе, представьте, что транспортные средства, проезжавшие по этой автомагистрали, были все грузовики с кирпичами дома для доставки. Все грузовики должны путешествовать со скоростью 60 миль в час, но как только они добираются до места назначения, а не доставляют 4 груза из кирпича, доставляется 6 грузов, поскольку к шоссе добавлено еще 2 полосы. То же самое происходит, когда вы добавляете пропускную способность к интернет-соединению, емкость увеличивается, но латентность (скорость) остается неизменной.
Что вызывает латентность?
Задержка вызвана расстоянием и качеством среды, через которую проходят интернет-пакеты. Например, латентность через опто-волоконное соединение короче, чем через медный кабель, но латентность через медный кабель короче, чем через спутниковое соединение и т.д. Спутники используют микроволновый спектр для ретрансляции соединений данных из космоса. То, что увеличивает задержку, например, отставание в спутниковых соединениях, — это расстояние, которое пакеты должны перемещать туда и обратно.
Когда возникает латентность?
Большинство людей не замечают и не заботятся о латентности, пока веб-страницы, Netflix, YouTube и другие мультимедийные материалы загружаются быстро. Задержка становится проблемой только при необходимости передачи данных в реальном времени. Например, звонки VOIP, онлайн-встречи лицом к лицу и т.д. Я подсчитал, что любая латентность за пределами 200 мс даст вам проблемы в режиме реального времени. Например, в вызове Skype или VOIP, вы почувствуете заметную задержку, из-за чего практически невозможно провести текучую беседу без перерывов.
Как я могу проверить задержку?
Самый быстрый способ проверить задержку с любого компьютера — использовать протокол ICMP с помощью команды Ping. Например, если я хочу проверить задержку между моим компьютером и центром обработки данных Google, я наберу команду ping google.com:
Как вы можете видеть, средняя задержка между моим компьютером и центром обработки данных Google составляет 48 мс.
Вывод
Надеюсь, ваше понимание между пропускной способностью и задержкой стало более ясным. Если у вас есть какие-либо вопросы, предложения или комментарии, пожалуйста, используйте поле комментариев ниже.
Что такое задержка (латентность) интернета и как ее уменьшить
Главное меню » Сети » Что такое задержка (латентность) интернета и как ее уменьшить
Что такое скорость интернет-соединения и как ее измерить?
Это скорость передачи данных между вашими устройствами и Интернетом, также известная как пропускная способность.
Есть два типа скорости подключения к Интернету:
Скорость подключения зависит от ряда факторов, таких как тип подключения, подключение интернета через спутник,
волоконный или медный кабель, качество линии и расстояние от шкафа.
Скорость интернета измеряется в мегабитах в секунду (Мбит/с) и сокращается до Мбайт, например 10 Мб или 20 Мб. Более того, бит – это наименьшая единица данных, и вы также можете видеть килобиты в секунду (Кбит/с) или КБ.
1 Кбит/с = 1000 бит в секунду
1 Мбит/с = 1000000 бит в секунду
Чем больше у вас мегабит в секунду (Мбит/с), тем выше должна быть скорость интернета:
Если скорость загрузки вашего соединения составляет 80 Мбит/с, а скорость выгрузки – 20 Мбит/с. Используя эту скорость, вы можете загрузить 500 МБ фотографий или медиафайлов за 10 секунд и загрузите файл размером 70 Мб в Интернет в течение 3 секунд. Если хост-сервер основан на выделенном сервере с большой пропускной способностью, это также поможет уменьшить время задержки.
Что такое задержка интернета?
Проще говоря, задержка = задержка. Это время задержки, необходимое для отправки любой информации из одной точки в другую. Если вы учитываете задержку в Интернете, то это действие и ответ пользователя с запрошенного веб-сайта или время приема-передачи от веб-браузера к серверу.
Идеальный уровень задержки при подключении к Интернету равен 0, если не учитывать влияние расстояния и задержек, вызванных оборудованием инфраструктуры Интернета. Это означает, что задержку нельзя полностью удалить вместо минимизации. Задержка напрямую влияет на SEO и снижает производительность веб-сайта, поэтому у пользователя есть максимальные шансы покинуть веб-сайт или приложение.
Как проверить вашу задержку в Интернете?
Если вы пользователь Windows, откройте командную строку, выполнив поиск «cmd» на панели запуска. Откроется черный экран, затем напишите «ping», введите IP-адрес или URL-адрес любого веб-сайта в Интернете и нажмите ввод. Ваш компьютер измеряет минимальное, максимальное и среднее время, необходимое для отправки и получения фрагмента данных на этот конкретный веб-адрес, в миллисекундах (мс).
Если вы ищете ответ на вопрос, какая скорость задержки для Интернета является хорошей, то средняя скорость выше 50 мс считается идеальной скоростью для большинства целей, а скорость ниже 100 мс вызовет проблемы. Какая задержка является хорошей или приемлемой для Интернета? Помните, что от 50 до 100 мсек – это идеальная задержка в Интернете. Также важно смотреть на минимальную и максимальную скорость. Если вы чувствуете большую разницу между минимальной и максимальной скоростью, значит, ваше соединение нестабильно, и данные могут быть полностью потеряны при попытке отправить или получить их. Чтобы убедиться в стабильности интернет-соединения, вам нужно запустить тест несколько раз.
Каковы основные причины задержки в Интернете?
Ниже приведены основные причины, которые напрямую влияют на задержку в Интернете:
Как уменьшить время ожидания в Интернете?
Если вы примените эти методы, перечисленные ниже, то время ожидания в Интернете может быть уменьшено. Когда вы уменьшите задержку сервера, это поможет вам быстрее загружать веб-ресурсы.
1. HTTP/2
Используйте HTTP/2, чтобы минимизировать задержку скорости интернета. Это поможет вам сократить время ожидания сервера за счет минимизации количества циклов передачи от отправителя к получателю с использованием параллельных передач.
2. Меньше внешних HTTP-запросов.
Когда вы уменьшаете количество HTTP-запросов, это применяется не только к изображениям, но и к внешним ресурсам, таким как файлы CSS или JavaScript. В некоторых особых случаях, когда вы ссылаетесь на информацию с любого другого сервера, вы делаете внешний HTTP-запрос, который увеличит скорость задержки веб-сайта в зависимости от скорости и качества вашего ссылающегося сервера.
3. Использование CDN
Используя CDN, ресурсы будут ближе к конечному пользователю за счет кэширования их в нескольких местах в зависимости от их географического положения по всему миру. После того, как все ресурсы кэшированы, пользовательские запросы должны связываться только с ближайшей точкой присутствия для извлечения запрошенных данных вместо того, чтобы каждый раз обращаться к исходному серверу.
4. Использование методов предварительной загрузки.
Предварительная загрузка веб-ресурсов не обязательно снижает скорость интернет-задержки, но улучшает воспринимаемую производительность веб-сайта. Если вы реализовали предварительную выборку, тогда процессы с высокой задержкой происходят в фоновом режиме, когда пользователи просматривают какую-либо конкретную страницу. Итак, когда они нажимают на следующую страницу, поиск DNS уже выполнен, поэтому страница загружается быстрее.
5. Кеширование браузера
Это еще один полезный метод уменьшения задержки в Интернете, потому что браузеры кэшируют определенные ресурсы любого веб-сайта локально, чтобы улучшить скорость задержки, а также уменьшить количество запросов пользователей обратно на сервер.
Вывод
Задержка – неизбежная часть сетевых экосистем, поэтому мы можем минимизировать ее, а не полностью устранять. Однако методы, упомянутые в этой статье, важны для уменьшения задержки веб-сайта и помогают улучшить скорость загрузки страницы для конечных пользователей.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Качество сетей передачи данных. Программные и аппаратные измерения
Я бы хотел опубликовать цикл статей об измерениях характеристик систем связи и сетей передачи данных. Эта статья вводная и в ней будут затронуты лишь самые основы. В дальнейшем планирую более глубокое рассмотрение в стиле «как это сделано».
Покупая продукт или услугу мы часто оперируем таким понятием как качество. Что же такое качество? Если мы обратимся к словарю Ожегова, то там увидим следующее: «совокупность существенных признаков, свойств, особенностей, отличающих предмет или явление от других и придающих ему определенность». Перенося определение на область сетей связи, приходим к выводу, что нам требуется определить «существенные признаки, свойства и особенности», позволяющие однозначно определить отличие одной линии или сети связи от другой. Перечисление всех признаков и свойств обобщаются понятием «метрика». Когда кто-то говорит о метриках сетей связи, он имеет в виду те характеристики и свойства, которые позволят точно судить о системе связи в целом. Потребность в оценке качества лежит большей частью в экономической области, хотя и техническая её часть не менее интересна. Я же попробую балансировать между ними, чтобы раскрыть все самые интересные аспекты этой области знаний.
Всех заинтересовавшихся прошу под кат.
Мониторинг и диагностика систем связи
Как я писал выше, метрики качества определяют экономическую составляющую владения сетью или системой связи. Т.е. стоимость аренды или сдачи в аренду линии связи напрямую зависит от качества этой самой линии связи. Стоимость, в свою очередь, определяется спросом и предложением на рынке. Дальнейшие закономерности описаны у Адама Смита и развиты Милтоном Фридманом. Даже во времена СССР, когда была плановая экономика, а о «рынке» думали, как о преступлении против власти и народа, существовал институт госприемки, как для военных, так и гражданских целей, призванный обеспечить надлежащее качество. Но вернемся в наше время и попробуем определить эти метрики.
Рассмотрим сеть на основе Ethernet, как самой популярной технологии на данный момент. Не будем рассматривать метрики качества среды передачи данных, поскольку они мало интересуют конечного потребителя (разве что материал самой среды иногда бывает интересен: радио, медь или оптика). Самая первая метрика, которая приходит в голову — пропускная способность (bandwidth), т.е. сколько данных мы можем передать в единицу времени. Вторая, связанная с первой,- пакетная пропускная способность (PPS, Packets Per Second), отражающая сколько фреймов может быть передано в единицу времени. Поскольку сетевое оборудование оперирует фреймами, метрика позволяет оценить, справляется ли оборудование с нагрузкой и соответствует ли его производительность заявленной.
Третья метрика — это показатель потери фреймов (frame loss). Если невозможно восстановить фрейм, либо восстановленный фрейм не соответствует контрольной сумме, то принимающая, либо промежуточная система его отвергнет. Здесь имеется ввиду второй уровень системы OSI. Если рассматривать подробнее, то большинство протоколов не гарантируют доставку пакета получателю, их задача лишь переслать данные в нужном направлении, а те кто гарантирует (например, TCP) могут сильно терять в пропускной способности как раз из-за перепосылок фреймов (retransmit), но все они опираются на L2 фреймы, потерю которых учитывает эта метрика.
Четвертая — задержка (delay, latency),- т.е. через сколько пакет отправленный из точки A оказаться в точке B. Из этой характеристики можно выделить еще две: односторонняя задержка (one-trip) и круговая (round-trip). Фишка в том, что путь от A к B может быть один, а от B к A уже совсем другим. Просто поделить время не получится. А еще задержка время от времени может меняться, или “дрожать”,- такая метрика называется джиттером (jitter). Джиттер показывает вариацию задержки относительно соседних фреймов, т.е. девиацию задержки первого пакета относительно второго, или пятого относительно четвертого, с последующим усреднением в заданный период. Однако если требуется анализ общей картины или интересует изменение задержки в течении всего времени теста, а джиттер уже не отражает точно картину, то используется показатель вариации задержки (delay variation). Пятая метрика — минимальный MTU канала. Многие не придают важности этому параметру, что может оказаться критичным при эксплуатации “тяжелых” приложений, где целесообразно использовать jumbo-фреймы. Шестой, и малоочевидный для многих параметр — берстность — нормированная максимальная битовая скорость. По этой метрике можно судить о качестве оборудования, составляющего сеть или систему передачи данных, позволяет судить о размере буфера оборудования и вычислять условия надежности.
Об измерениях
Поскольку с метриками определились, стоит выбрать метод измерения и инструмент.
Задержка
Известный инструмент, поставляемый в большинстве операционных систем — утилита ping (ICMP Echo-Request). Многие ее используют по нескольку раз на дню для проверки доступности узлов, адресов, и т.п. Предназначена как раз для измерения RTT (Round Trip Time). Отправитель формирует запрос и посылает получателю, получатель формирует ответ и посылает отправителю, отправитель замеряя время между запросом и ответом вычисляет время задержки. Все понятно и просто, изобретать ничего не нужно. Есть некоторые вопросы точности и они рассмотрены в следующем разделе.
Но что, если нам надо измерить задержку только в одном направлении? Здесь все сложнее. Дело в том, что помимо просто оценки задержки пригодится синхронизировать время на узле отправителе и узле-получателе. Для этого придуман протокол PTP (Precision Time Protocol, IEEE 1588). Чем он лучше NTP описывать не буду, т.к. все уже расписано здесь, скажу лишь то, что он позволяет синхронизировать время с точностью до наносекунд. В итоге все сводится к ping-like тестированию: отправитель формирует пакет с временной меткой, пакет идет по сети, доходит до получателя, получатель вычисляет разницу между временем в пакете и своим собственным, если время синхронизировано, то вычисляется корректная задержка, если же нет, то измерение ошибочно.
Если накапливать информацию об измерениях, то на основании исторических данных о задержке можно без труда построить график и вычислить джиттер и вариацию задержки — показатель важный в сетях VoIP и IPTV. Важность его связана, прежде всего, с работой энкодера и декодера. При “плавающей” задержке и адаптивном буфере кодека повышается вероятность не успеть восстановить информацию, появляется “звон” в голосе (VoIP) или “перемешивание” кадра (IPTV).
Потери фреймов
Проводя измерения задержки, если ответный пакет не был получен, то предполагается, что пакет был потерян. Так поступает ping. Вроде тоже все просто, но это только на первый взгляд. Как написано выше, в случае с ping отправитель формирует один пакет и отправляет его, а получатель формирует свой собственный о отправляет его в ответ. Т.е. имеем два пакета. В случае потери какой из них потерялся? Это может быть не важно (хотя тоже сомнительно), если у нас прямой маршрут пакетов соответствует обратному, а если это не так? Если это не так, то очень важно понять в каком плече сети проблема. Например, если пакет дошел до получателя, то прямой путь нормально функционирует, если же нет, то стоит начать с диагностики этого участка, а вот если пакет дошел, но не вернулся, то точно не стоит тратить время на траблшутинг исправного прямого сегмента. Помочь в идентификации могла бы порядковая метка, встраиваемая в тестовый пакет. Если на обоих концах стоят однотипные измерители, то каждый из них в любой момент времени знает количество отправленных и полученных им пакетов. Какие именно из пакетов не дошли до получателя можно получить сравнением списка отправленных и полученных пакетов.
Минимальный MTU
Измерение этой характеристики не то чтобы сложно, скорее оно скучно и рутинно. Для определения минимального размера MTU (Maximum transmission unit) следует лишь запускать тест (тот же ping) с различными значениями размеров кадра и установленным битом DF (Don’t Fragmentate), что приведет к непрохождению пакетов с размером кадра больше допустимого, ввиду запрета фрагментации.
Например, так не проходит:
А так уже проходит:
Не часто используемая метрика с коммерческой точки зрения, но актуальная в некоторых случаях. Опять же, стоит отметить, что при асимметричном пути следования пакетов, возможен различный MTU в разных направлениях.
Пропускная способность
Наверняка многим известен факт, что количество переданной полезной информации в единицу времени зависит от размера фрейма. Связано это с тем, что фрейм содержит довольно много служебной информации — заголовков, размер которых не меняется при изменении размера фрейма, а изменяется поле “полезной” части (payload). Это значит, что несмотря на то, что даже если мы передаем данные на скорости линка, количество полезной информации переданной за тот же период времени может сильно варьироваться. Поэтому несмотря на то, что существуют утилиты для измерения пропускной способности канала (например iperf), часто невозможно получить достоверные данные о пропускной способности сети. Все дело в том, что iperf анализирует данные о трафике на основе подсчета той самой «полезной» части, окруженной заголовками протокола (как правило UDP, но возможен и TCP), следовательно нагрузка на сеть (L1,L2) не соответствует подсчитанной (L4). При использовании аппаратных измерителей скорость генерации трафика устанавливается в величинах L1, т.к. иначе было бы не очевидно для пользователя почему при измерении размера кадра меняется и нагрузка, это не так заметно, при задании ее в %% от пропускной способности, но очень бросается в глаза при указании в единицах скорости (Mbps, Gbps). В результатах теста, как правило, указывается скорость для каждого уровня (L1,L2,L3,L4). Например, так (можно переключать L2, L3 в выводе):
Пропускная способность в кадрах в секнду
Если говорить о сети или системе связи как о комплексе линий связи и активного оборудования, обеспечивающего нормальное функционирование, то эффективность работы такой системы зависит от каждого составляющего ее звена. Линии связи должны обеспечивать работу на заявленных скоростях (линейная скорость), а активное оборудование должно успевать обрабатывать всю поступающую информацию.
У всех производителей оборудования заявляется параметр PPS (packets per second), прямо указывающий сколько пакетов способно «переварить» оборудование. Ранее этот параметр был очень важен, поскольку подавляющее число техники просто не могло обработать огромное количество “мелких” пакетов, сейчас же все больше производители заявляют о wirespeed. Например, если передаются малые пакеты, то времени на обработку тратится, как правило, столько же, сколько и на большие. Поскольку содержимое пакета оборудованию не интересно, но важна информация из заголовков — от кого пришло и кому передать.
Сейчас все большее распространение в коммутирующем оборудовании получают ASIC (application-specific integrated circuit) — специально спроектированные для конкретных целей микросхемы, обладающие очень высокой производительностью, в то время как раньше довольно часто использовались FPGA (field-programmable gate array) — подробнее об их применении можно прочитать у моих коллег здесь и послушать здесь.
Бёрстность
Стоит отметить, что ряд производителей экономит на компонентах и использует малые буферы для пакетов. Например заявлена работа на скорости линка (wirespeed), а по факту происходят потери пакетов, связанные с тем, что буфер порта не может вместить в себя больше данных. Т.е. процессор еще не обработал скопившуюся очередь пакетов, а новые продолжают идти. Часто такое поведение может наблюдаться на различных фильтрах или конвертерах интерфейсов. Например предполагается, что фильтр принимает 1Gbps поток и направляет результаты обработки в 100Mbps интерфейс, если известно, что отфильтрованный трафик заведомо меньше 100Mbps. Но в реальной жизни случается так, что в какой-то момент времени может возникнуть «всплеск» трафика более 100Mbps и в этой ситуации пакеты выстраиваются в очередь. Если величина буфера достаточна, то все они уйдут в сеть без потерь, если же нет, то просто потеряются. Чем больше буфер, тем дольше может быть выдержана избыточная нагрузка.
Погрешности измерения
Латентность при загрузке веб-страниц
Пост «Кое-что о весе страницы» вызвал у меня желание написать маленькое дополнение. Многие замечают, что оптимизация размера веб-страниц становится менее актуальной в связи с увеличением пропускных способностей каналов. Рано или поздно все будут сидеть на гигабите, и будет совершенно неважно, весит ваша страница 100Кб или 250. Возможно, так оно и будет. Однако помимо скорости канала есть и другой параметр — задержка или латентность. И если пропускная способность каналов с развитием технологий может вырасти ещё очень сильно, то у латентности существует физический предел: это скорость света в оптоволокне — около 200 тысяч километров в секунду.
Хотя эта скорость очень велика, но всё же недостаточно, чтобы о ней забывать, ведь и планета у нас немаленькая. Wolfram Alpha не зря выдаёт на запросы по расстоянию время прохождения этого расстояния светом в волокне. Пусть у вас стоит сервер в Токио, а клиент пришёл из Рио-де-Жанейро. Если даже эти два города соединить оптоволокном по кратчайшей траектории на поверхности Земли, свет будет идти 86.7 мс.
Что это значит для вас? Предположим, пользователь открывает вашу страницу в браузере, например, из закладок. От того момента, когда он кликнул, до того, когда сигнал дойдёт до сервера, пройдёт минимум 86.7 мс. И ещё столько же, чтобы сигнал дошёл обратно. Ваша страница никак не может загрузиться быстрее 173.4 мс, даже если она мало весит и вообще закэширована клиентом (чтобы узнать, что она не менялась, всё равно придётся спросить сервер).
Казалось бы, 173.4 мс — мелочи жизни. Но не всё так просто. Многим страничкам требуются скрипты, стили и картинки, без загрузки которых страничка нефункциональна. Браузер не может начать всё это загружать, не загрузив сам HTML хотя бы чуть-чуть (ссылки-то на скрипты в HTML). А значит, нам потребуется уже 86.7 мс (запрос HTML) + 86.7 мс (получение HTML) + 86.7 мс (запрос всего остального) + 86.7 мс (получение всего остального) — минимум 346.8 мс.
Конечно, и 346.8 мс можно подождать. Бывает, однако, что для нормального отображения страницы требуется выполнить AJAX-запрос. К примеру, основной информационный блок у вас на странице может автоматически обновляться с сервера по AJAX. Чтобы не усложнять логику сервера, вы его не отдаёте при первоначальной загрузке страницы, а оставляете пустым, но сразу же вызываете функцию обновления. Таких сайтов множество. Скажем, на rts.micex.ru так загружаются индексы, котировки и прочие блоки. Теперь, если вы зашли посмотреть актуальные котировки, вам придётся подождать загрузки HTML, загрузки JS, а затем выполнения AJAX-запроса — минимум 520.2 мс. Полусекундная задержка уже некомфортна хотя, конечно, можно потерпеть.
Бывает однако и так, что некоторая информация подгружается AJAX-запросом, который ждёт результатов выполнения другого AJAX-запроса. Иногда это связано с непродуманностью взаимодействия между клиентом и сервером: чтобы послать следующий запрос, нужна информация из предыдущего. Гораздо чаще это связано с ленью разработчика, который не разобрался с функциями, позволяющими выполнить определённый код после завершения сразу нескольких запросов (или не написал сам таких функций, если предпочитает Vanilla JS), и поэтому просто посылает второй запрос в onreadystatechange первого.
Вот такую чудную картину загрузки демонстрирует стартовая страница одной системы онлайн-банкинга, которой я пользуюсь:
Здесь подгружаются дополнительные ресурсы и скрипты через 9 последовательных AJAX-запросов. Добавим к этому запрос на HTML и запрос скрипта, который всё это добро загружает — получается минимальная задержка при нашей расстановке клиента и сервера в 1.9 секунды. Вот ведь какая штука: хоть терабитный интернет по всей Земле проведите, сделайте бесконечно быстрые сервера и жёсткие диски, а пользователь из Рио-де-Жанейро всё равно будет ждать две секунды из-за кривых программистов.
Даже если предположить, что инженеры научатся посылать сигналы не по поверхности, а сквозь Землю и со скоростью света в вакууме (скажем, пускаем пучок релятивистских нейтрино, а на той стороне ставим детектор), латентность упадёт максимум вдвое. Но, я думаю, раньше интернет на Луну проведут, чем такое сделают. А с Луны такой сайт будет грузиться сами посчитайте, сколько.
Конечно, клиентов с другого конца Земли у вас может быть немного, но ведь и провода лежат не по кратчайшему пути, да и задержки на повторителях и маршрутизаторах вполне осязаемы.