압축 파일보다 압축 파일을 다운로드하는 데 시간이 더 걸립니까?

13

압축 파일의 특성으로 인해 같은 크기의 압축 해제 파일보다 압축 파일을 다운로드하는 데 시간이 더 걸린다는 것을 한 번 읽었습니다.

이것이 사실입니까 아니면 말이되지 않습니까?

편집 : 나는 HTTP 트래픽에 대해 말하고있다

download zip

— 야오
소스

1

어떤 프로토콜로?

— innaM

4

동일한 크기의 압축 파일과 압축 해제 압축 파일 (예 : 각 1MB) 또는 압축 및 압축되지 않은 동일한 파일 (예 : 1MB 및 345KB)의 두 파일에 대해 이야기하고 있습니까?

— Toby Allen

시간이 아닌 다운로드 속도를 고려해야합니다. 두 경우 모두 속도는 동일합니다. 결국 주어진 시간에 제한된 수의 바이트를 다운로드했습니다. Toby 힌트와 마찬가지로 압축 파일을 다운로드하면 결국 더 많은 데이터가 압축되지 않아 압축되지 않은 다운로드 속도가 효과적으로 증가합니다.

— KFro September

21

연결이 compression을 사용 하는 경우 물론입니다.

데이터를 2 번 효율적으로 압축 할 수 없습니다. 따라서 압축이 설정되어 있으면 1MB zip 파일이 1MB txt 파일보다 느리게 전송됩니다.

NB : 전송 프로토콜에 따라 다릅니다. FTP 또는 다른 프로토콜에는 기본 제공 압축 기능이 없습니다. HTTP가 있습니다.

— 크리스토퍼
소스

보통은 약간만. mp3, jpg 또는 zip을 압축하지 않아야합니다.

— Rich Bradshaw

1

압축 할 유형을 구성 할 수 있습니다. 따라서 웹 서버 관리자는 먼저 압축을 활성화 한 다음 잘 알려진 유형의 압축을 비활성화해야합니다.

— Christopher

서버에서 구운 사이클이 다시 압축 (파이프 속도가 느려짐)되어 전송 속도가 느려지거나 (파이프에서 느리게) 다운로드하는 데 시간이 더 오래 걸립니까? 최종 결과가 여전히 다운로드 속도가 느려서 까다로운 점입니다.

— MrChrister

3

대부분의 경우 연결이 병목 현상이기 때문에 데이터를 압축 / 압축 해제하는 데 걸리는 시간은 문제가되지 않습니다. http 압축은 파일 자체가 아닌 전송에서 수행되므로 대기 시간은 전체 파일이 아닌 전송 압축 대기 시간에 의해서만 증가합니다. 서버에서 너무 높은 CPU 사용량 이외의 다른 http 압축을 사용하는 것에 대한 단점은 없습니다. 반면에 모든 서버 관리자는 압축이 잘되지 않는 파일 형식의 전송에 대해서는 압축을 해제해야합니다.

— Christopher

11

표준 FTP 또는 HTTP를 통해 다운로드하는 경우에는 사실이 아닙니다. 다른 연결 유형에 대해서는 Christopher의 답변을 참조하십시오 .

동일한 연결을 가정하면 다운로드 속도는 파일 크기에 따라 결정됩니다.

자동 바이러스 검사를 사용하도록 설정 한 경우 파일을 직접 확인하지 않고 내용을 확인하기 위해 zip 파일을 열고 압축을 풀어야하므로 다운로드가 끝날 때 지연 될 수 있습니다.

— 크리스프
소스

2

채널에 압축이 사용 된 경우 (@Christopher의 답변 참조)

— fretje

2

압축과 함께 PPP (전화 접속 또는 VPN) 연결을 사용하는 경우 압축 파일은 그 특성상 텍스트 파일보다 속도가 느리게 다운로드 될 수 있습니다. 전자는 이미 압축되어 있고 후자는 프로토콜에 의해 압축되어 측정 속도가 증가합니다. .

그러나 수신 한 정보의 양을 비교해도 압축 파일을 다운로드하는 것이 여전히 효과적입니다. 파일 아카이버는 일반적으로 링크 계층 압축보다 우수하기 때문입니다. 따라서 압축 된 다운로드 파일이 약간 증가하더라도 압축 된 텍스트 파일은 동일한 텍스트 파일보다 자연스럽게 다운로드됩니다.

— 다리
소스

0

서버와 라우터에서 GZIP를 사용하여 패킷을 압축 한 다음 압축하거나 그렇지 않은 경우 동일하게 작동하기 때문에 HTTP 프로토콜에 차이가 없음을 알아야합니다.

— Am1rr3zA
소스

0

이미 언급했듯이 HTTP 트래픽은 압축 될 수 있지만 항상 그런 것은 아닙니다.

사람들이 adl / cable 모뎀 대신 전화 모뎀을 사용했을 때 이것을 읽었을 것입니다. 이 경우 텍스트를 보내거나 받기 전에 텍스트가 압축되었으므로 텍스트 파일이 더 빨리 전송되었습니다.

— 시니 보이
소스

2

우리 중 일부는 여전히 인터넷에 전화 모뎀을 사용합니다. :-)

— Brian Knoblauch

0

관련이 있는지 여부는 확실하지 않지만 압축 파일없이 압축 된 하나의 파일을 다운로드하는 경우 각 개별 파일을 다운로드하기 전에 필요한 HTTP 요청 오버 헤드로 인해 여러 개의 압축되지 않은 파일과 동일한 패키지를 다운로드하는 것보다 빠릅니다.

— Hasen
소스

0

실용 답변 : 파일을 압축하는 목적은 다른 사람들과 파일을 쉽게 공유 (예 : 다운로드)하는 것입니다. 압축은 압축에 의해 작동하며, 이는 일반적인 영어로 '파일 축소'를 의미합니다.

컴퓨터 소프트웨어는 완벽하지 않으며 파일을 압축하면 파일 크기가 약간 커지고 공유하기 어려운 이상한 경우가있을 수 있습니다. 압축이 실패하는 이러한 최첨단 사례를 발견하면 눈물을 흘릴 수 있으며 시간이 가치가 없습니다.

가설 : 매우 복잡합니다. 답은 zip 프로그램, 전송 프로토콜, 파일 크기, 파일 유형, 심지어 클라이언트 컴퓨터에서 실행되는 브라우저 유형 또는 바이러스 백신 소프트웨어에 따라 다릅니다. 즉, "의존한다"

— CDeanMartin
소스

-2

대답은 실제로 "의존"입니다. 웹 서버가 파일을 전송하도록 선택한 형식에 따라 다릅니다.

서버가 이진 그대로 바이트로 응답을 생성하면 동일한 크기의 압축 및 압축 해제 된 파일보다 동일한 속도로 다운로드됩니다.

서버가 Base64 인코딩으로 응답을 생성하면 바이트 수가 증가하고 압축 파일을 다운로드하는 데 시간이 더 걸립니다. 대부분의 최신 웹 서버는 몇 년 전에 널리 퍼져 있었지만 더 이상 그렇게하지 않습니다.

설명을 위해 base64 형식은 6 비트 표시 가능 문자 스트림입니다. 즉, 6 * 8 = 48 비트 인 6 개의 이진 바이트는 48 / 6 = 8 자로 인코딩됩니다. 일반적으로 n 이진 바이트의 경우 전송되는 base64 문자 수는 (n * 8) / 6입니다. 따라서 n 이진 바이트 전송은 문자 수가 많기 때문에 n 텍스트 바이트를 33 % (8을 6으로 나눈 값) 전송하는 것보다 느립니다. 전송됩니다.

— 해리
소스

1

전자 메일 메시지에는 해당되지만 다른 모든 프로토콜에는 해당되지 않습니다.

— Brian Knoblauch

그것은 http를위한 것입니다. HTTP 다운로드 64 기수에서 여러 부분으로 인코딩 사용

— harrymc

1

나는 이것을 의심하고 있습니다. 백업에 대한 언급이 있습니까?

— hasen sep

1

아니, http는 일반적으로 바이너리 파일을 base64로 인코딩하지 않습니다. 이 경우를 선언하는 MIME 유형이 있지만 일반적으로 "패킷"(이메일 메시지)이 어느 시점에서 8 비트가 아닌 연결을 통과 할 것으로 예상되는 이메일에만 사용됩니다. HTTP가있는 TCP / IP 프로토콜은 8 비트로 깨끗하며 MIME 인코딩 콘텐츠는 대역폭 만 낭비합니다.

— RBerteig

1

파일을 보내는 서버는 여러 형식 중에서 선택할 수 있습니다. 내 대답은 약 5 년 전에 한 설문 조사와 관련이 있습니다. 당시에는 상당수의 사이트에서 MIME 유형과 달리 Content-Transfer-Encoding을 사용하여 다운로드 멀티 파트 응답을 생성하고있었습니다. 빠른 검사에 따르면, 이것은 더 이상 사실이 아니며 실제로는 HTTP 응답에서 Content-Transfer-Encoding을 사용하는 것에 대한 최신 RFC 조언입니다. 따라서 OP에 대한 진정한 대답은 위의 계산이 과거에는 일부 웹 사이트의 경우와 같았지만 지금은 매우 드 believe니다. 그러나 도시 신화가 아닙니다.

— harrymc