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 to prawda czy nonsens?
edycja: mówię o ruchu HTTP
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 to prawda czy nonsens?
edycja: mówię o ruchu HTTP
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.
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.
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.
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.
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.