Чи потрібно довше завантажувати заархівований файл, ніж розпакований файл?

13

Одного разу я десь прочитав, що завантажувати заархівований файл потрібно довше, ніж незакріплений файл такого ж розміру, що обумовлено характером zip-файлу.

Це правда чи нісенітниця?

редагувати: я говорю про трафік HTTP

download zip

— джао
джерело

1

Над яким протоколом?

— innaM

4

Ви говорите про два файли однакового розміру, один із блискавками та один розпакований (наприклад, кожен 1 МБ) або той самий файл, який стискається та не стискається (наприклад, 1 МБ та 345 КБ)?

— Тобі Аллен

Ви повинні врахувати швидкість завантаження, а не час. В обох випадках швидкість однакова ... врешті-решт ви завантажили обмежену кількість байтів за певний проміжок часу. Як натякає Тобі, завантаження стислих файлів у кінцевому підсумку отримує більше даних, що не стискаються, що ефективно збільшує вашу нестиснену швидкість завантаження.

— KFro

21

Коли для з'єднання використовується стиснення , то, звичайно.

Ви не можете ефективно стискати дані 2 рази. Таким чином, коли стиснення увімкнено, поштовий файл розміром 1 Мб передаватиметься повільніше, ніж 1 МБ файлу txt.

NB: Це залежить від протоколу передачі. FTP або інші протоколи не мають вбудованої компресії. HTTP має.

— Крістофер
джерело

Зазвичай лише трохи. Ви не повинні gzip mp3, jpg або zip.

— Багатий Бредшоу

1

Налаштовується, для яких типів стискати. Тому адміністратору веб-сервера належить спочатку включити компресію, а потім відключити компресію для відомих типів.

— Крістофер

Чи передаватиметься повільніше (повільніше над трубою) чи завантажуватиметься довше, оскільки цикл спалених серверів перезаписується (повільніше на трубу)? Точка, яка сприймає ніт, оскільки кінцевий результат все-таки повільніше завантажується.

— MrChrister

3

Це не питання про те, скільки часу потрібно для стиснення / декомпресії даних, оскільки в більшості випадків з'єднання є вузьким місцем. Стиснення http робиться на передачах, а не на самому файлі, тому затримка збільшується лише затримкою стиснення передачі, а не всім файлом. Насправді немає недоліків включення http-компресії, крім занадто високого використання процесора на сервері. З іншого боку, всі адміністратори сервера повинні відключити стиснення для передачі типів файлів, які не дуже добре стискаються.

— Крістофер

11

Це неправда, якщо ви завантажуєте через стандартний FTP або HTTP. Інші типи з'єднання див. У відповідь Крістофера .

Якщо припустити те саме з'єднання, швидкість завантаження визначається розміром файлу.

У кінці завантаження може виникнути затримка, якщо ввімкнено автоматичну перевірку вірусів, оскільки для перевірки вмісту доведеться відкривати та розпаковувати zip-файл, а не мати можливість безпосередньо перевіряти файл.

— ChrisF
джерело

2

Не, якщо на каналі використовується стиснення (див. Відповідь @ Крістофера).

— fretje

2

Якщо ви використовуєте з'єднання PPP (комутований або VPN) для стиснення, файли, що завантажуються, можуть завантажуватись з меншою швидкістю, ніж текстові файли через їх характер (перші вже стиснуті, а другі будуть стиснуті протоколом, таким чином збільшуючи виміряну швидкість) .

Але якщо ви порівнюєте кількість отриманої інформації, завантаження файлів, що зберігаються в zip, все одно буде більш ефективною, оскільки будь-який архіватор файлів зазвичай перевершує стиснення на рівні посилання. Таким чином, текстовий файл, що знаходиться на блискавці, завантажується швидше, ніж той самий текстовий файл дослівно, навіть якщо стиснення трохи збільшує швидкість завантаження.

— Бендер
джерело

0

ви повинні помітити, що це не має різниці в протоколі HTTP, оскільки в сервері та маршрутизаторі вони використовують GZIP для поштового пакетів, а потім надсилають для цього, якщо ви поштовуєте чи не, вони діють однаково.

— Am1rr3zA
джерело

0

Як уже згадувалося, трафік HTTP можна стискати, але це не завжди.

Ви, можливо, читали це в той час, коли люди використовували телефонні модеми замість моделей adsl / cable. У цій ситуації текст перед надсиланням чи отриманням стискався, тому ваш текстовий файл був би надісланий швидше.

— seanyboy
джерело

2

Деякі з нас досі використовують телефонні модеми для доступу до Інтернету. :-)

— Брайан Кноблауш,

0

Не впевнений, що це пов’язано чи ні, але якщо ви завантажите один заархівований файл (зіштовхується без стиснення), це швидше, ніж завантажувати той самий пакет, що й декілька (нерозпаковані) файлів, через накладні звернення HTTP, необхідні перед початком завантаження кожного окремого файлу.

— хасен
джерело

0

Практична відповідь: мета завантаження файлів - полегшити обмін (iedownload) з іншими людьми. Zipping працює за допомогою стиснення, що означає "скорочення файлів" у загальній англійській мові.

Комп'ютерне програмне забезпечення не є досконалим, і можуть бути дивні випадкові випадки, коли перетягування файлу зробить його трохи більшим і складнішим для спільного доступу. Виявлення цих крайових випадків, коли застібка не вдається, напевно набридає вас сльозами і не вартує вашого часу.

Гіпотетична відповідь: Це дуже складно. Відповідь залежатиме від zip-програми, протоколів передачі, розміру файлу, типу файлу, можливо, навіть типу браузера чи антивірусного програмного забезпечення, що працює на клієнтському комп'ютері. Іншими словами, "це залежить".

— CDeanMartin
джерело

-2

Відповідь насправді "це залежить": Залежно від формату, який веб-сервер обирає для надсилання файлу.

Якщо сервер генерує відповідь з двійковими байтами як-є, то блискавки та нерозпаковані файли однакового розміру завантажуватимуться з однаковою швидкістю.

Якщо сервер генерує відповідь при кодуванні Base64, то це збільшує кількість байтів, і завантажений файл, який триває, займе більше часу. Більшість сучасних веб-серверів уже не роблять цього, хоча це було досить поширеним кілька років тому.

Для пояснення, формат base64 - це потік 6-бітових символів, що відображаються. Це означає, наприклад, що 6 двійкових байтів, що мають 6 * 8 = 48 біт, кодуються як 48/6 = 8 символів. Загалом, для n двійкових байтів кількість відправлених символів base64 становить (n * 8) / 6. Тож надсилання n двійкових байтів повільніше, ніж надсилання n текстових байтів на 33% (8 поділено на 6), тому що більше символів відправляються.

— harrymc
джерело

1

Це справедливо для повідомлень електронної пошти, але не справедливо для всіх інших протоколів.

— Брайан Кноблауш,

Це дійсно стосується http, до чого було питання. http для завантаження використовує багаточастинне кодування в base64

— harrymc

1

Я якось сумніваюся в цьому, чи маєте ви посилання на це, щоб його створити?

— hasen

1

Ні, http, як правило, не base64 кодує двійкові файли. Існує тип mime, щоб оголосити цей випадок, але він, як правило, використовується лише для електронної пошти, коли є сподівання, що "пакет" (повідомлення електронної пошти) в якийсь момент пройде через з'єднання, яке не є 8-бітним чистим. Протокол TCP / IP, на якому лежить HTTP, гарантовано буде 8-бітним чистим, а вміст, що кодує mime, лише втратить пропускну здатність.

— RBerteig

1

Сервер, що надсилає файл, може обрати один з декількох форматів. Моя відповідь стосувалася опитування, яке я робив близько 5 років тому. У той час досить багато сайтів генерували багатозахисні відповіді на завантаження вмісту Content-Transfer-Encoding (на відміну від типу mime). Згідно швидкої перевірки, це вже не так, а насправді остання порада RFC щодо використання Content-Transfer-Encoding у відповідях http. Тож я вважаю, що реальна відповідь на ОП: такий розрахунок раніше був для деяких веб-сайтів, але зараз це досить рідко. Однак це не міський міф.

— harrymc