#browser #tcp #cross-browser #single-page-application
#браузер #tcp #кроссбраузерный #одностраничное приложение
Вопрос:
Итак, из того, что я могу сказать по TCP-пакетам (которые составляют большую часть трафика, с которым вы будете иметь дело в браузере), они упорядочены, но без верхней границы. Это означает, что в заголовке пакета будет указано «Номер пакета: 6», но не «Номер пакета: 6/180».
Итак, как вы можете указать точную панель загрузки? Вы не можете вычислить текущее / максимальное соотношение, потому что max там отсутствует.
Я спрашиваю это в контексте загрузки большого файла, такого как фильм, в вашу файловую систему или просто получения некоторого двоичного объекта JSON в одностраничном приложении. Как в обоих случаях может работать точная панель загрузки?
Я знаю, что многие СПА-центры используют блесны без явного процента, но некоторые СПА-центры, такие как YouTube и Instagram, используют загрузочные панели.
Комментарии:
1. HTTP-заголовки содержат
Content-Length.2. Означает ли это, что сервер, обслуживающий этот запрос, вычисляет это и помещает в заголовок? Что, если есть несколько сетевых запросов для одного просмотра в SPA? Кроме того, как он узнает, что нужно изменить панель загрузки, ожидая, пока сервер хотя бы ответит на запрос из SPA?
Ответ №1:
На уровне TCP не известна ни длина передаваемого файла, ни даже понятие файла — это всего лишь поток байтов, который, вероятно, будет закрыт некоторое время в будущем. Возможно даже, что по этому потоку байтов передается несколько реальных файлов, но ничего из этого не известно на уровне TCP.
Знания, которые могут быть использованы для некоторых индикаторов выполнения, вместо этого поступают с уровня приложения. При загрузке файла с помощью HTTP (т.Е. протокола, обычно используемого сегодня) сервер в большинстве случаев отправляет Content-length поле в заголовке HTTP, которое показывает конечную длину ответа. Поскольку клиент знает, сколько байтов уже было получено, он может показать процент полученных данных.
Аналогично и для загрузок, когда клиент знает длину данных для загрузки и знает, сколько данных он уже отправил. Обратите внимание, что клиент не знает наверняка, какой объем данных фактически получен. Но механизм TCP гарантирует, что существует также ограниченное окно байтов «в полете» и что клиент сможет отправлять дополнительные данные только после того, как сервер подтвердит достаточное количество предыдущих данных.
Но обратите внимание, что такой индикатор выполнения возможен не во всех случаях. Даже при использовании HTTP серверу не требуется предварительно отправлять длину. Он может просто опустить эту информацию и закрыть TCP-соединение после передачи всех данных. Или он может использовать фрагментированную кодировку передачи, в которой он отправляет данные меньшими порциями с префиксом длины, но конечная длина ответа заранее неизвестна. В этом случае браузер не может отобразить надлежащий индикатор выполнения, поскольку конечная длина неизвестна, поэтому обычно отображается только то, что все еще выполняется некоторая передача, но не то, насколько выполнена передача.
И это только с протоколом HTTP. Но другие прикладные протоколы похожи в том, что может быть заранее известна длина, а может и не быть, и в этом случае некоторый индикатор выполнения может показывать переданный процент, а может и нет.