Однажды я где-то читал, что скачивание заархивированного файла занимает больше времени, чем заархивированного файла того же размера, что связано с характером zip-файла.
Это правда или ерунда?
редактировать: я говорю о трафике HTTP
8 ответов
21
Когда соединение использует сжатие, тогда, конечно.
Вы не можете эффективно сжимать данные 2 раза. Поэтому, когда сжатие включено, почтовый файл размером 1 МБ будет передаваться медленнее, чем текстовый файл размером 1 МБ.
Примечание: это зависит от протокола передачи. FTP или другие протоколы не имеют встроенного сжатия. HTTP имеет.
11
Это неправда, если вы скачиваете через стандартный FTP или HTTP. Для других типов подключения см . Ответ Кристофера.
При условии того же соединения скорость загрузки определяется размером файла.
Может быть задержка в конце загрузки, если у вас включена автоматическая проверка на вирусы, так как для проверки содержимого потребуется открыть и распаковать zip-файл, а не проверить файл напрямую.
2
Если вы используете соединение PPP (удаленного доступа или VPN) со сжатием, заархивированные файлы могут загружаться с меньшей скоростью, чем текстовые файлы из-за их природы (первые уже сжаты, а последние будут сжаты по протоколу, что увеличит измеренную скорость) ,
Но если вы сравните объем получаемой информации, загрузка заархивированных файлов все равно будет более эффективной, поскольку любой файловый архиватор обычно превосходит сжатие на канальном уровне. Таким образом, сжатый текстовый файл будет загружен быстрее, чем тот же самый текстовый файл, даже если сжатие немного увеличивает скорость загрузки.
0
Вы должны заметить, что он не имеет различий в протоколе HTTP, потому что на сервере и в маршрутизаторе они используют GZIP для архивирования пакета, а затем отправляют его, если вы архивируете или нет, они действуют одинаково.
0
Не уверен, связано ли это или нет, но если вы загружаете один заархивированный файл (сжатый без сжатия), это быстрее, чем загружать тот же пакет, что и несколько (разархивированных) файлов, из-за накладных расходов HTTP-запроса, необходимых перед началом загрузки каждого отдельного файла.
0
Как уже упоминалось, HTTP-трафик может быть сжат, но это не всегда.
Возможно, вы читали это в то время, когда люди использовали телефонные модемы вместо adsl/ кабельных модемов. В этой ситуации текст был сжат перед отправкой или получением, поэтому ваш текстовый файл был бы отправлен быстрее.
0
Практический ответ: цель архивирования ваших файлов состоит в том, чтобы облегчить их передачу (iedownload) другим людям. Сжатие работает путем сжатия, что означает «сжатие файлов» на обычном английском языке.
Компьютерное программное обеспечение не идеально, и могут быть странные крайние случаи, когда архивирование файла сделало бы его немного больше и сложнее поделиться. Обнаружение этих крайних случаев, когда архивирование не удастся, наверняка приведет вас к слезам и не стоит вашего времени.
Гипотетический ответ: это очень сложно. Ответ будет зависеть от почтовой программы, протоколов передачи, размера файла, типа файла, возможно, даже от типа браузера или антивирусного программного обеспечения, запущенного на клиентском компьютере. Другими словами, «это зависит».
-2
Ответ на самом деле "зависит": в зависимости от формата, который веб-сервер выбирает для отправки файла.
Если сервер генерирует ответ с двоичными байтами «как есть», то заархивированные и разархивированные файлы одинакового размера будут загружаться с одинаковой скоростью.
Если сервер генерирует ответ в кодировке Base64, он увеличивает количество байтов, и заархивированный файл загружается дольше. Большинство современных веб-серверов больше этого не делают, хотя это было довольно распространенным явлением несколько лет назад.
Для пояснения, формат base64 - это поток 6-битных отображаемых символов. Это означает, например, что 6 двоичных байтов, которые имеют размер 6 * 8 = 48 бит, кодируются как 48/6 = 8 символов. Обычно для n двоичных байтов количество отправляемых символов base64 равно (n * 8) / 6. Таким образом, отправка n двоичных байтов происходит медленнее, чем отправка n текстовых байтов на 33% (8 делится на 6), поскольку отправляется больше символов.