TCP 패킷의 최소 크기는 얼마입니까?

9

여기에 게시 :

http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

"브라우저가 할 수있는 가장 작은 다운로드는 1K 바이트입니다."

네트워크를 통한 패킷의 최소 크기 때문입니까? 그렇지 않은 경우, 이것이 실제로 사실 인 경우 그 이유는 무엇입니까?

— Andy Hume
소스

2

혼동을 피하려면 표준 용어를 고집하십시오. "패킷"은 IP 수준 용어입니다. "IP 패킷"이나 "TCP 패킷"도 아니고 "이더넷 패킷"도 아닙니다.

— vtest

당신이 인용 한 문장 ( "브라우저에서 할 수있는 가장 작은 다운로드는 1K 바이트입니다.")은 사실이 아닙니다. 최소 다운로드 크기는 없습니다. 그리고 거기에있는 동안 ~이다. 최소 TCP / IP 패킷 크기 (@ DMA57361에 설명되어 있음)는 확실히 1KB가 아닙니다.

— Piskvor

20

패킷 여기에 모호한 용어가 있습니다. 전송할 때 다른 요소를 참조하기 위해 오용되기 때문입니다. 당신의 데이터가 무엇에 싸여 있는지 볼 수 있고, 당신이 의미하는 바를 볼 수 있고, 당신이 원했던 대답을 얻었을 것입니다 :

1 바이트의 데이터를 전송한다고 가정합니다. ¹ 인터넷을 통해 TCP / IP 모델 .

그만큼 데이터 응용 프로그램 수준에서 시작되며 하위 수준의 머리글에 줄 바꿈하여 전달할 수 있어야합니다.

먼저 데이터가 TCP 세그먼트 이것은 20 바이트의 헤더를 추가합니다 (최소 크기는 21 바이트).
이것은 우리를 수송 수준으로 만든다.

이것은 다음에 래핑됩니다. IP 패킷 , 20 바이트의 다른 헤더를 추가합니다 (최소 크기는 41 바이트).
이제 우리는 인터넷 수준에 있습니다.
이 랩핑은 새 라우터가 데이터를 새 서브넷으로 전달할 때마다 변경됩니다.

이것은 링크로 싸여있다. 틀 사용되는 링크 유형에 따라 사용되는 프레임 유형에 따라 머리글 및 바닥 글 크기가 달라지는 일부 유형의
이것은 링크 수준에 있습니다.
이 배치는 두 엔티티간에 전송 될 때마다 변경됩니다.

마지막으로 물리적 전송 (예 : 케이블, 전파 등의 전기 신호).

다음은 위키 피 디아에서 제공되는 유익한 이미지입니다. TCP / IP 모델 무슨 일이 일어나고 있는지 시각적으로 설명하는 데 도움이되는 페이지 :

Data encapsulation using UDP/IP

Connection via layers in the TCP/IP model

^{1. 0 바이트를 보낼 수 있을지도 모르지만 체크하지 않은 것 같습니다. 사실 1 바이트가 허용되는지는 확인하지 못했습니다.}

— DMA57361
소스

4

올바르지 않으므로 다운로드에 필요한 최소 크기는 없습니다. 웹 서버에 작은 파일을 만들고 wireshark를 사용하여 파일을 다운로드 할 때 네트워크 트래픽을 볼 수 있습니다.

표준 이더넷 패킷의 최소 크기는 64 바이트입니다.

— shapr
소스

3

그것의 얼굴에, 당신이 인용하는 블로그 게시가 잘못되었습니다. HTTP에는 "최소 다운로드 크기"가 없습니다. (그리고 최소한의 패킷 크기에 대한 이론 또한 올바르지 않습니다.)

그러나 이것에 대한 진실이 있습니다. 다운로드하는 파일의 크기가 충분히 작 으면 HTTP 응답 메시지 (파일 및 HTTP 응답 헤더로 구성)가 단일 네트워크 패킷에 적합하다는 것입니다. 이 경우 브라우저는 응답을 보내기 위해 두 개 이상의 패킷을 보낸 경우보다 파일을 빨리 가져올 수 있습니다.

응답에서 하나의 패킷을 사용하면 패킷이 삭제되고 다시 보내야 할 확률이 적어지고 TCP / IP 흐름 제어 창이 패킷 확인을 위해 여분의 왕복 지연을 추가하지 않을 가능성이 커집니다. )

송수신되는 패킷의 최대 크기 (MTU)는 이더넷의 경우 1500 바이트입니다. IP 및 TCP 오버 헤드와 일반적인 HTTP 응답 헤더의 크기를 고려하면 응답의 첫 번째 패킷에 파일 데이터가 1K 남겨 둘 수 있습니다. 따라서 블로거의 논평에서 진실의 곡식.

— Stephen C
소스

웹 페이지 및 관련 리소스 (이미지, JS, CSS)가 아닌 해당 이미지 하나만 다운로드한다면 어쨌든 킵 얼라이브와 파이프 라이닝을 사용하므로 TCP 오버 헤드 및 패킷 크기는 훨씬 덜 관련이 있습니다. 당신 이 특별한 경우에 맞습니다 (하나의 이미지 만 다운로드 함). 그러나 그 빈도는 얼마나 자주 발생합니까? 블로거는 각 HTTP 요청이 자체 TCP 연결을 필요로하는 1999 년에 붙어있는 것 같습니다.

— Piskvor

1

그것은 당신이 생각하는 것보다 더 나쁩니다.

느린 페이지 로딩은 브라우저가 1x1 픽셀을 800000 번 렌더링하는 데 문제가 있기 때문입니다 (예 : 브라우저 창을 1000x800로 설정). 몇 년 전, 아마도 1999 년에, 나는 16x16을 '가장 빠른'x 타일링을위한 가장 작은 것으로 규정 한 기사를 읽었습니다. 물론 렌더링이 다를 수 있습니다.

블로그 게시물을 읽는다면 실제로 불만은 느린 페이지 로딩에 관한 것입니다. 다운로드 속도가 느리지 않습니다. 흥미로운 토론 이었지만 패킷과 관련이 없습니다.

그래서 아마도 그 질문은 다시 말해야합니다.

— mockman
소스

이 경우 블로그 게시물을 완전히 오해했을 수도 있습니다. 핵심은 다음과 같습니다. "브라우저에서 수행 할 수있는 가장 작은 다운로드는 1K 바이트 [따라서 이미지 크기를 1K로 조정]입니다. 나는 "... 당신이 1K 바이트를 전송하고 있기 때문에, 당신의 이미지가 50 바이트 밖에 없다"(이것은 명백한 난센스입니다)라고 읽었습니다. 여기에있는 문제는 " size "둘 다 픽셀 크기 과 바이트 수의 경우, 과 그들을 모으고. 귀하의 설명은 의미가 있지만 이미지의 바이트 수와 관련이 없습니다 (블로그의 내용과는 반대).

— Piskvor

블로그 게시물을 다시 읽은 후, 그는 세 번째 단락이 모순되는 것처럼 코스를 벗어난 것처럼 보입니다.

— mockman

당신의 코멘트를 다시 읽은 후에 ... 그의 의도는 오프닝 단락에서 제기 된 문제를 해결하는 것입니다. 그러나 그는 실수로이 문제를 패킷 크기로 간주하고 그 나머지 부분에 패킷을 소비합니다. 내 대답은 느린 페이지 로딩의 이유를 설명했다. 다른 사람들이 지적했듯이, 패킷 특성은 원인이 아닙니다.

— mockman