UDP에서 MTU는 65535이지만 이더넷은 1500 바이트 이상의 프레임 크기를 허용하지 않습니다.


11

100Mbps의 고속 이더넷을 사용하고 있으며, 프레임 크기가 1500 바이트 미만 (교과서에 따른 페이로드의 경우 1147 바이트)입니다. 즉, 메시지 크기가 65507 바이트 인 UDP 패킷을 보내고받을 수있었습니다. 이는 패킷 크기가 65507 + 20 (IP 헤더) + 8 (UDP 헤더) = 65535임을 의미합니다.

프레임의 페이로드 크기 자체가 최대 1472 바이트 (내 교과서에 따라) 인 경우 IP의 패킷 크기가 여기의 65535보다 클 수 있습니까?

발신자 코드를 다음과 같이 사용했습니다.

char buffer[100000];
for (int i = 1; i < 100000; i++)
{
    int len = send (socket_id, buffer, i);
    printf("%d\n", len);
}

수신자 코드

while (len = recv (socket_id, buffer, 100000))
{
     printf("%d\n". len);
}

그 관찰 send returns -1i > 65507recv인쇄 또는 패킷을 수신 maximum of length 65507.

답변:


11

UDP 데이터 그램은 MTU 크기와 거의 관련이 없으며 위에서 언급 한 최대 64K까지 원하는만큼 크게 만들 수 있습니다. 큰 데이터 그램보다 큰 크기의 점보 프레임을 사용하는 한 전체 패킷으로 전송할 수도 있습니다.

그러나 점보 프레임은 프레임이 통과 할 모든 장비에서 지원해야하며 이로 인해 문제가 발생합니다. 실용적인 목적으로 이더넷 프레임은 가장 일반적인 전송 크기이며, MTU는 약 1500 바이트입니다. 1500은 계속 진행되지만 항상 그런 것은 아닙니다. 기본 MTU (대부분 이더넷으로 표시됨)보다 큰 UDP 데이터 그램을 만들면 조용히 여러 1500 바이트 프레임으로 나뉩니다. 이 트래픽을 tcpdump하면 MTU 경계에서 여러 개의 패킷이 깨져서 조각 번호와 함께 더 많은 조각 플래그가 설정됩니다. 첫 번째 패킷에는 조각 번호가 0이고 더 많은 조각이 설정되고 마지막 패킷에는 0이 아닌 조각 번호가 있으며 더 많은 조각이 설정되지 않습니다.

왜 신경써? 실제로 구현 세부 사항이 중요합니다. 조각화는 더 이상 큰 문제가 아니라 알아야 할 네트워크의 성능을 저하시킬 수 있습니다. 거대한 데이터 그램 크기가 사용 된 경우 조각이 손실되면 전체 데이터 그램을 다시 보내야합니다. 똑같이 많은 양으로 오늘날에는 이것이 완벽하게 달성 가능한 양이므로 재 조립시 프레임을 잘못 연결시킬 수 있습니다. 하나의 조각이 하나의 방화벽에 있고 다른 조각이 다른 방화벽에 있으면 트래픽이 불완전한 상태로 떨어질 수 있습니다.

따라서 통신해야하는 인프라가 가까운 (동일한 서브넷 닫기) 점을 지정해야하는 경우를 제외하고 MTU 크기 조각화보다 더 큰 UDP 데이터 그램을 생성하지 마십시오. 점보 프레임이 좋은 옵션 일 수 있습니다.


'more fragments flag'에 대한 좋은 정보. UDP 헤더 또는 IP 헤더에있는 플래그입니까?
John Jesus

참고 : 일부 OS는 데이터가 조각화되면 UDP를 전송하지 않습니다. IE Linux docBy default, Linux UDP does path MTU (Maximum Transmission Unit) discovery. This means the kernel will keep track of the MTU to a specific target IP address and return EMSGSIZE when a UDP packet write exceeds it.
Rahly

2

IP 계층은 패킷을 송신 측에서 조각화 한 다음 UDP로 전달하기 전에 수신 측에서 다시 조립합니다. UDP 계층에서는 실제로 패킷이 조각화되었음을 알 수 없습니다. Wireshark 와 같은 패킷 캡처 도구를 사용하는 경우 컴퓨터가 MTU로 제한된 IP 패킷을 수신하고 있음을 확인할 수 있습니다.


1

TCP / IP 스택이 필요에 따라 패킷을 조각화하도록 허용하면 개별 패킷을 보내는 것보다 오버 헤드가 훨씬 적습니다.


1
TCP / IP가 조각화되어 재 조립되고 있음을 의미합니까? 그렇다면 왜 사람들이 수신자 측에서 코드를 재 조립해야하는지 항상 말하는가? 나는 현재 조각화를 관찰하지는 않았지만 이것을 말하고 심지어 그것을 받아들이는 많은 포럼을 보았습니다.

OSI 모델에 도전하는 사람들에게는 답에 좀 더 자세한 내용을 추가 할 수 있습니까?
Robert Harvey

이것이 숙제인지 아닌지를 알 수 없기 때문에 나는 조금 엉망이었습니다. UDP는 배달을 보장하지 않기 때문에 패킷 조각이 삭제되면 전체 패킷이 손실됩니다. UDP 위에서 안정적인 전송을 원한다면이 모든 것을 직접 처리해야합니다. 그러나 스트리밍 프로토콜 (또는 스트리밍과 같은 경로를 사용하는 NFS over UDP)을 수행하는 경우 필요한 경우 긴 지연 후에 단순히 해당 패킷을 삭제하거나 더 큰 패킷을 재전송하는 오버 헤드가 적습니다. 프로토콜 기능 및 프로토콜 오버 헤드에 대한 요구의 균형을 맞춰야합니다.
geekosaur

1

UDP는 MTU에 대해 아무것도 모릅니다. UDP 패킷의 크기는 8에서 65535 바이트입니다. UDP 아래의 프로토콜 계층은 특정 크기의 패킷을 보내거나 너무 큰 경우 오류가 발생하여 해당 패킷을 보내지 않을 수 있습니다.

UDP 아래 계층은 일반적으로 IP, IPv4 또는 IPv6입니다. IP 패킷의 크기는 20 (IPv4) / 40 (IPv6)에서 65535 바이트 사이이며 UDP와 동일한 최대 크기입니다. 그러나 IP는 조각화 라는 메커니즘을 지원합니다 . IP 패킷의 크기가 아래 계층이 전송할 수있는 것보다 큰 경우 IP는 단일 패킷을 조각이라는 여러 패킷으로 분할 할 수 있습니다. 모든 프래그먼트는 실제로 자체 IP 패킷을 가지며 (자체 IP 헤더를 가짐) 또한 자체적으로 목적지로 전송됩니다. 수신 된 데이터를 다음 상위 계층 (예 : UDP)으로 전달하기 전에 모든 프래그먼트를 수집하고 전체 패킷을 다시 빌드하는 것이 대상의 작업입니다.

이더넷 프로토콜은 페이로드가 46에서 1500 바이트 사이 인 프레임 만 전송할 수 있습니다 (예외는 있지만이 응답 범위를 벗어남). 페이로드 데이터가 46 바이트보다 작은 경우,이 값은 46 바이트로 채워집니다. 페이로드 데이터가 1500 바이트를 초과하면 인터페이스가이를 거부합니다. 이 경우 패킷을 조각화하기로 결정하는 것은 이제 IP 계층에 달려 있으므로 1500 바이트를 초과하는 조각은 발생하지 않으며이 특정 연결에 대해 조각화가 비활성화되거나 금지 된 경우 다음 상위 계층에 오류를보고합니다.

조각화는 일반적으로 피해야합니다.

  • 발신자 측에서 리소스를 낭비합니다.
  • 수신자 측에서 자원을 낭비합니다.
  • 동일한 양의 페이로드 데이터에 대한 프로토콜 오버 헤드가 증가합니다.
  • 단일 조각이 손실되면 전체 패킷이 손실됩니다.
  • 단일 조각이 손상된 경우 전체 패킷이 손상됩니다.
  • 재전송의 경우 모든 조각을 재전송해야합니다.

그렇기 때문에 TCP는 프레임 크기를 지능적으로 채택하여 패킷을 조각화하기 위해 IP가 필요하지 않습니다. 이는 패킷을 조각화하는 IP를 금지하여 수행 할 수 있으며, IP가 패킷이 너무 커서 전송되지 않는다고보고하면 TCP는 더 이상 오류가보고되지 않을 때까지 프레임 크기를 줄이고 다시 시도합니다.

UDP의 경우 UDP는 "멍청한"프로토콜이기 때문에 응용 프로그램 자체의 작업이 될 것입니다. UDP에는 자체의 관리 논리가 없으므로 매우 유연하고 빠르며 간단합니다.

IP 표준에 따라 모든 IP 호스트가 IP 패킷을 수신 할 수 있어야하므로 항상 전송 가능한 것으로 믿을 수있는 유일한 UDP 크기는 576-8 바이트 UDP 헤더 및-20 (v4) / 40 (v6) 바이트 IP 헤더입니다. 총 크기는 576 바이트입니다. 해당 크기 이상의 패킷을 수락 할 수없는 경우 프로토콜 구현이 표준을 준수하지 않습니다. 그러나 표준에서는 조각화없이 576이라고 말하지 않으므로 576 바이트 IP 패킷조차도 두 호스트간에 조각화 될 수 있습니다.

조각화없이 전송할 수있는 유일한 패킷 크기는 IPv4의 경우 24 바이트, IPv6의 56 바이트입니다. 조각의 가장 작은 IP 헤더는 20/48 바이트 (v4 / v6)이고 조각의 크기는 4/8 이상이어야합니다. 바이트 (v4 / v6) 페이로드 데이터. 따라서, 이러한 크기의 패킷을 전송할 수없는 IP 계층 아래의 전송 시스템은 IP 트래픽을 전송하는 데 사용할 수 없습니다.

IPv6 헤더에는 40 바이트 만 있다고 언급하기 전에, 맞습니다. 그러나 IPv4 헤더와 달리 표준 IPv6 헤더에는 조각화를위한 헤더 필드가 없습니다. 패킷을 조각화해야하는 경우 조각화 확장 헤더를 IPv6 기본 헤더 아래에 추가해야하며이 확장 헤더의 길이는 8 바이트입니다. 또한 IPv4와 달리 IPv6의 조각화 오프셋은 4 바이트 단위가 아닌 8 바이트로 계산되므로 IPv6의 경우 조각은 8 바이트의 배수 인 페이로드 만 전송할 수 있습니다.


0

"프레임의 페이로드 크기 자체가 최대 1472 바이트 (교과서에 따라) 인 경우 IP의 패킷 크기가 여기의 65535보다 클 수있는 방법은 무엇입니까?"

UFO (UDP Fragmentation Offload)라는 오프로드 기능 때문입니다. 링크를 참조하십시오 .

ethtool -k ethX 및 ethtool -K ethX를 통해 오프로드 기능을 각각 확인하고 토글 할 수 있습니다.


0

발신 프레임을 모니터링하는 경우 네트워크 어댑터가 세그먼트 오프로드를 지원하고 활성화 될 수 있습니다. 세그먼트 오프로드가 활성화되면 네트워크 카드 자체가 네트워크 스택이 아닌 적절한 크기로 패킷 / 프레임 세그먼트를 처리합니다. 이렇게하면 컴퓨터의 CPU가 다른 작업을 수행하여 성능이 향상됩니다. 리눅스에서 "ethtool -k [device]"는 오프로드 플래그를 보여줍니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.