Czy pobranie skompresowanego pliku zajmuje więcej czasu niż rozpakowanie pliku?
13
Kiedyś przeczytałem gdzieś, że pobranie skompresowanego pliku trwa dłużej niż rozpakowanego pliku o tym samym rozmiarze, ze względu na charakter pliku zip.
Czy mówisz o dwóch plikach tego samego rozmiaru, jeden skompresowany i jeden rozpakowany (np. Każdy 1 MB), czy ten sam plik, który jest skompresowany i nieskompresowany (np. 1 MB i 345 KB)?
Toby Allen,
Powinieneś wziąć pod uwagę szybkość pobierania, a nie czas. W obu przypadkach szybkość jest taka sama ... w końcu pobrałeś ograniczoną liczbę bajtów w danym czasie. Jak sugeruje Toby, pobieranie skompresowanych plików pozwala uzyskać więcej nieskompresowanych danych, co skutecznie zwiększa szybkość nieskompresowanego pobierania.
Nie można skutecznie kompresować danych 2 razy. Tak więc po włączeniu kompresji plik zip o rozmiarze 1 MB zostanie przesłany wolniej niż plik TX o rozmiarze 1 MB.
NB: Zależy to od protokołu przesyłania. FTP lub inne protokoły nie mają wbudowanej kompresji. HTTP ma.
Zwykle tylko nieznacznie. Nie powinieneś gzipować mp3, jpg ani zamków błyskawicznych.
Rich Bradshaw,
1
Jest konfigurowalny dla jakich typów kompresji. Tak więc administrator serwera WWW musi najpierw włączyć kompresję, a następnie wyłączyć kompresję dla dobrze znanych typów.
Christopher
Czy transfer będzie przebiegał wolniej (wolniej nad potokiem), czy pobieranie potrwa dłużej, ponieważ serwer nagrywał cykle ponownego kompresowania (wolniej do potoku)? Nienasycony punkt, ponieważ wynik końcowy jest nadal wolniejszy.
MrChrister
3
To nie jest pytanie, ile czasu zajmuje kompresja / dekompresja danych, ponieważ w większości przypadków połączenie stanowi wąskie gardło. Kompresja HTTP odbywa się na transferach, a nie na samym pliku, więc opóźnienie jest zwiększane tylko przez opóźnienie kompresji transferu, a nie całego pliku. Naprawdę nie ma żadnej wady włączania kompresji http poza zbyt wysokim wykorzystaniem procesora na serwerze. Z drugiej strony wszyscy administratorzy serwera powinni wyłączyć kompresję dla transferów typów plików, które nie kompresują się zbyt dobrze.
Christopher
11
To nieprawda, jeśli pobierasz przez standardowy FTP lub HTTP. W przypadku innych typów połączeń zobacz odpowiedź Christophera .
Zakładając to samo połączenie, szybkość pobierania zależy od rozmiaru pliku.
Pod koniec pobierania może wystąpić opóźnienie, jeśli włączona jest funkcja automatycznego sprawdzania wirusów, ponieważ będzie ona musiała otworzyć i rozpakować plik zip, aby sprawdzić zawartość, a nie móc bezpośrednio sprawdzić plik.
Nie, jeśli na kanale używana jest kompresja (patrz odpowiedź @ Christophera).
fretje
2
Jeśli używasz połączenia PPP (dial-up lub VPN) z kompresją, pliki spakowane mogą pobierać z mniejszą prędkością niż pliki tekstowe ze względu na ich charakter (te pierwsze są już skompresowane, a drugie zostaną skompresowane przez protokół, zwiększając w ten sposób zmierzoną prędkość) .
Ale jeśli porównasz ilość otrzymanych informacji, pobieranie spakowanych plików będzie nadal bardziej wydajne, ponieważ każdy archiwizator plików jest zwykle lepszy od kompresji warstwy łącza. Tak więc skompresowany plik tekstowy zostanie pobrany szybciej niż ten sam plik tekstowy dosłownie, nawet jeśli kompresja nieco zwiększy prędkość pobierania.
musisz zauważyć, że nie ma różnicy w protokole HTTP, ponieważ na serwerze i routerze używają GZIP do skompresowania pakietu, a następnie wysyłają go, jeśli zip lub nie, działają one tak samo.
Jak już wspomniano, ruch HTTP można skompresować, ale nie zawsze.
Być może przeczytałeś to w czasie, gdy ludzie używali modemów telefonicznych zamiast modemów ADSL / kablowych. W tej sytuacji tekst został skompresowany przed wysłaniem lub otrzymaniem, więc plik tekstowy zostałby wysłany szybciej.
Niektórzy z nas nadal używają modemów telefonicznych do uzyskania dostępu do Internetu. :-)
Brian Knoblauch,
0
Nie jestem pewien, czy jest to powiązane, czy nie, ale jeśli pobierzesz jeden skompresowany plik (skompresowany bez kompresji), jest to szybsze niż pobieranie tego samego pakietu, co wiele (rozpakowanych) plików, z powodu narzutu żądania HTTP przed rozpoczęciem pobierania poszczególnych plików.
Praktyczna odpowiedź: celem skompresowania plików jest ułatwienie ich udostępniania (pobierania) innym osobom. Kompresowanie odbywa się za pomocą kompresji, co oznacza „zmniejszanie plików” we wspólnym języku angielskim.
Oprogramowanie komputerowe nie jest idealne i mogą zdarzyć się dziwne przypadki, w których skompresowanie pliku spowodowałoby, że udostępnienie byłoby nieco większe i trudniejsze. Znalezienie tych przypadków krawędzi, w których kompresowanie nie powiedzie się, prawdopodobnie znudzi cię do łez i nie jest warte twojego czasu.
Hipotetyczna odpowiedź: to bardzo skomplikowane. Odpowiedź zależy od programu zip, protokołów transmisji, rozmiaru pliku, typu pliku, a może nawet typu przeglądarki lub oprogramowania antywirusowego działającego na komputerze klienckim. Innymi słowy „to zależy”.
Odpowiedź brzmi „zależy”: W zależności od formatu, który serwer internetowy wybiera do wysłania pliku.
Jeśli serwer wygeneruje odpowiedź z binarnymi bajtami „tak jak jest”, wówczas spakowane i rozpakowane pliki o równej wielkości będą pobierane z tą samą prędkością.
Jeśli serwer wygeneruje odpowiedź w kodowaniu Base64, to zwiększy liczbę bajtów, a skompresowanie pliku zajmie więcej czasu. Większość współczesnych serwerów WWW już tego nie robi, chociaż kilka lat temu było to dość powszechne.
Aby wyjaśnić, format base64 to strumień 6-bitowych wyświetlanych znaków. Oznacza to na przykład, że 6 bajtów binarnych, czyli 6 * 8 = 48 bitów, jest zakodowanych jako 48/6 = 8 znaków. Ogólnie rzecz biorąc, dla n bajtów binarnych liczba wysłanych znaków base64 wynosi (n * 8) / 6. Tak więc wysyłanie n bajtów binarnych jest wolniejsze niż wysyłanie n bajtów tekstowych o 33% (8 podzielone przez 6), ponieważ więcej znaków są wysyłane.
Dotyczy to wiadomości e-mail, ale nie dotyczy wszystkich innych protokołów.
Brian Knoblauch,
To dotyczy http, które było pytaniem. Pobieranie http wykorzystuje kodowanie wieloczęściowe w base64
harrymc,
1
Wątpię w to, czy masz jakieś odniesienia do tego, aby to zrobić?
hasen
1
Nie, http zazwyczaj nie koduje plików binarnych w standardzie base64. Istnieje typ MIME, który deklaruje ten przypadek, ale generalnie jest używany tylko do wiadomości e-mail, w których oczekuje się, że „pakiet” (wiadomość e-mail) w pewnym momencie przejdzie przez połączenie, które nie jest czyste 8-bitowo. Protokół TCP / IP, na którym opiera się HTTP, gwarantuje 8-bitową czystość, a zawartość kodowania MIME tylko marnuje przepustowość.
RBerteig,
1
Serwer wysyłający plik może wybierać spośród kilku formatów. Moja odpowiedź dotyczyła ankiety, którą przeprowadziłem około 5 lat temu. W tym czasie wiele stron generowało wieloczęściowe odpowiedzi do pobrania z kodowaniem przesyłania treści (w odróżnieniu od typu MIME). Według szybkiej kontroli nie jest to już prawdą, a tak naprawdę najnowsze rady RFC dotyczące używania kodowania przesyłania treści w odpowiedziach HTTP. Uważam więc, że prawdziwą odpowiedzią na PO jest: powyższe obliczenia miały miejsce w przeszłości dla niektórych stron internetowych, ale teraz są dość rzadkie. Nie jest to jednak mit miejski.
Odpowiedzi:
Oczywiście, gdy połączenie korzysta z kompresji .
Nie można skutecznie kompresować danych 2 razy. Tak więc po włączeniu kompresji plik zip o rozmiarze 1 MB zostanie przesłany wolniej niż plik TX o rozmiarze 1 MB.
NB: Zależy to od protokołu przesyłania. FTP lub inne protokoły nie mają wbudowanej kompresji. HTTP ma.
źródło
To nieprawda, jeśli pobierasz przez standardowy FTP lub HTTP. W przypadku innych typów połączeń zobacz odpowiedź Christophera .
Zakładając to samo połączenie, szybkość pobierania zależy od rozmiaru pliku.
Pod koniec pobierania może wystąpić opóźnienie, jeśli włączona jest funkcja automatycznego sprawdzania wirusów, ponieważ będzie ona musiała otworzyć i rozpakować plik zip, aby sprawdzić zawartość, a nie móc bezpośrednio sprawdzić plik.
źródło
Jeśli używasz połączenia PPP (dial-up lub VPN) z kompresją, pliki spakowane mogą pobierać z mniejszą prędkością niż pliki tekstowe ze względu na ich charakter (te pierwsze są już skompresowane, a drugie zostaną skompresowane przez protokół, zwiększając w ten sposób zmierzoną prędkość) .
Ale jeśli porównasz ilość otrzymanych informacji, pobieranie spakowanych plików będzie nadal bardziej wydajne, ponieważ każdy archiwizator plików jest zwykle lepszy od kompresji warstwy łącza. Tak więc skompresowany plik tekstowy zostanie pobrany szybciej niż ten sam plik tekstowy dosłownie, nawet jeśli kompresja nieco zwiększy prędkość pobierania.
źródło
musisz zauważyć, że nie ma różnicy w protokole HTTP, ponieważ na serwerze i routerze używają GZIP do skompresowania pakietu, a następnie wysyłają go, jeśli zip lub nie, działają one tak samo.
źródło
Jak już wspomniano, ruch HTTP można skompresować, ale nie zawsze.
Być może przeczytałeś to w czasie, gdy ludzie używali modemów telefonicznych zamiast modemów ADSL / kablowych. W tej sytuacji tekst został skompresowany przed wysłaniem lub otrzymaniem, więc plik tekstowy zostałby wysłany szybciej.
źródło
Nie jestem pewien, czy jest to powiązane, czy nie, ale jeśli pobierzesz jeden skompresowany plik (skompresowany bez kompresji), jest to szybsze niż pobieranie tego samego pakietu, co wiele (rozpakowanych) plików, z powodu narzutu żądania HTTP przed rozpoczęciem pobierania poszczególnych plików.
źródło
Praktyczna odpowiedź: celem skompresowania plików jest ułatwienie ich udostępniania (pobierania) innym osobom. Kompresowanie odbywa się za pomocą kompresji, co oznacza „zmniejszanie plików” we wspólnym języku angielskim.
Oprogramowanie komputerowe nie jest idealne i mogą zdarzyć się dziwne przypadki, w których skompresowanie pliku spowodowałoby, że udostępnienie byłoby nieco większe i trudniejsze. Znalezienie tych przypadków krawędzi, w których kompresowanie nie powiedzie się, prawdopodobnie znudzi cię do łez i nie jest warte twojego czasu.
Hipotetyczna odpowiedź: to bardzo skomplikowane. Odpowiedź zależy od programu zip, protokołów transmisji, rozmiaru pliku, typu pliku, a może nawet typu przeglądarki lub oprogramowania antywirusowego działającego na komputerze klienckim. Innymi słowy „to zależy”.
źródło
Odpowiedź brzmi „zależy”: W zależności od formatu, który serwer internetowy wybiera do wysłania pliku.
Jeśli serwer wygeneruje odpowiedź z binarnymi bajtami „tak jak jest”, wówczas spakowane i rozpakowane pliki o równej wielkości będą pobierane z tą samą prędkością.
Jeśli serwer wygeneruje odpowiedź w kodowaniu Base64, to zwiększy liczbę bajtów, a skompresowanie pliku zajmie więcej czasu. Większość współczesnych serwerów WWW już tego nie robi, chociaż kilka lat temu było to dość powszechne.
Aby wyjaśnić, format base64 to strumień 6-bitowych wyświetlanych znaków. Oznacza to na przykład, że 6 bajtów binarnych, czyli 6 * 8 = 48 bitów, jest zakodowanych jako 48/6 = 8 znaków. Ogólnie rzecz biorąc, dla n bajtów binarnych liczba wysłanych znaków base64 wynosi (n * 8) / 6. Tak więc wysyłanie n bajtów binarnych jest wolniejsze niż wysyłanie n bajtów tekstowych o 33% (8 podzielone przez 6), ponieważ więcej znaków są wysyłane.
źródło