최대 전송 단위(MTU)

최대 전송 단위(MTU)

컴퓨터 네트워킹에서 MTU(최대 전송 단위)라는 용어는 통신 프로토콜의 주어진 계층이 전달할 수 있는 가장 큰 PDU의 크기(바이트)를 나타냅니다. MTU 매개변수는 일반적으로 통신 인터페이스(NIC, 직렬 포트 등)와 관련하여 나타납니다. MTU는 표준에 의해 고정되거나(이더넷의 경우와 같이) 연결 시 결정될 수 있습니다(일반적으로 지점간 직렬 링크의 경우와 같이). MTU가 높을수록 각 패킷이 더 많은 사용자 데이터를 전달하는 반면 헤더 또는 기본 패킷별 지연과 같은 프로토콜 오버헤드는 고정되어 있기 때문에 효율성이 더 높으며 효율성이 높을수록 대량 프로토콜 처리량이 약간 향상됩니다. 그러나 큰 패킷은 일정 시간 동안 느린 링크를 차지할 수 있으므로 패킷을 따르는 데 더 큰 지연이 발생하고 지연 및 최소 대기 시간이 증가합니다. 예를 들어, 네트워크 계층(따라서 대부분의 인터넷)에서 이더넷이 허용하는 가장 큰 1500바이트 패킷은 약 14.4초 동안 XNUMXk 모뎀을 묶습니다.

경로 MTU 검색
인터넷 프로토콜은 인터넷 전송 경로의 "경로 MTU"를 소스와 대상 사이의 "경로"의 IP 홉 중 가장 작은 MTU로 정의합니다. 다시 말해, 경로 MTU는 조각화를 겪지 않고 이 경로를 통과하는 가장 큰 패킷 크기입니다.

RFC 1191은 두 IP 호스트 간의 경로 MTU를 결정하는 기술인 "경로 MTU 검색"에 대해 설명합니다. 나가는 패킷의 IP 헤더에서 DF(Don't Fragment) 옵션을 설정하여 작동합니다. MTU가 패킷보다 작은 경로를 따라 있는 모든 장치는 이러한 패킷을 삭제하고 해당 MTU가 포함된 ICMP "Destination Unreachable(Datagram Too Big)" 메시지를 되돌려 보내어 소스 호스트가 가정된 경로 MTU를 적절하게 줄일 수 있도록 합니다. MTU가 단편화 없이 전체 경로를 통과할 수 있을 만큼 작아질 때까지 프로세스가 반복됩니다.

불행히도, 네트워크의 수가 증가함에 따라 ICMP 트래픽이 드롭되어(예: 서비스 거부 공격을 방지하기 위해) 경로 MTU 검색이 작동하지 않습니다. 연결이 소량 데이터에 대해 작동하지만 호스트가 한 번에 큰 데이터 블록을 보내자마자 중단되는 경우에 그러한 차단을 종종 감지합니다. 예를 들어, IRC를 사용하면 연결 클라이언트가 최대 ping 메시지를 볼 수 있지만 그 이후에는 응답을 받지 못할 수 있습니다. 이는 많은 환영 메시지가 실제 MTU보다 큰 패킷으로 전송되기 때문입니다. 또한 IP 네트워크에서 소스 주소에서 대상 주소까지의 경로는 다양한 이벤트(로드 밸런싱, 정체, 출력 등)에 대한 응답으로 종종 동적으로 수정됩니다. 이로 인해 경로 MTU가 변경될 수 있습니다(때로는 반복) 전송 중에 호스트가 새로운 안전한 MTU를 찾기 전에 추가 패킷 드롭이 발생할 수 있습니다.

대부분의 이더넷 LAN은 1500바이트의 MTU를 사용하지만(최신 LAN은 점보 프레임을 사용할 수 있으므로 최대 9000바이트의 MTU를 허용함) PPPoE와 같은 경계 프로토콜은 이를 줄입니다. 이로 인해 잘못 구성된 방화벽 뒤에 있는 일부 사이트에 연결할 수 없는 결과가 발생하여 경로 MTU 검색이 적용됩니다. 제어하는 네트워크 부분에 따라 이 문제를 해결할 수 있습니다. 예를 들어 방화벽에서 TCP 연결을 설정하는 초기 패킷의 MSS(최대 세그먼트 크기)를 변경할 수 있습니다.

이 문제는 '차세대 TCP/IP 스택'을 도입한 Windows Vista가 도입된 이후 더 자주 나타났습니다. 이것은 "대역폭 지연 곱과 응용 프로그램 검색률을 측정하여 최적의 수신 창 크기를 지속적으로 결정하고 변화하는 네트워크 조건에 따라 최대 수신 창 크기를 조정하는 수신 창 자동 조정"을 구현합니다.[2] 이것은 다른 운영 체제에서 작동하는 것으로 보이는 이전 라우터 및 방화벽과 함께 실패하는 것으로 나타났습니다. ADSL 라우터에서 가장 흔히 볼 수 있으며 종종 펌웨어 업데이트로 수정할 수 있습니다.

MTU 튜닝의 예인 ATM 백본
때로는 효율성의 관점에서 지원되는 실제 최대 가능한 길이 미만으로 소프트웨어에서 감소된 MTU를 인위적으로 선언하는 것이 더 좋습니다. 이것의 한 예는 IP 트래픽이 ATM(Asynchronous Transfer Mode) 네트워크를 통해 전달되는 경우입니다. 일부 공급자, 특히 전화 통신 배경이 있는 공급자는 내부 백본 네트워크에서 ATM을 사용합니다.

패킷 길이가 48바이트의 배수일 때 ATM을 최적의 효율성으로 사용하는 것이 가능합니다. ATM이 고정 길이 패킷('셀'이라고 함)의 스트림으로 전송되기 때문입니다. 각 패킷은 셀당 48바이트의 총 비용으로 5바이트의 오버헤드와 함께 53바이트의 사용자 데이터 페이로드를 전달할 수 있습니다. 따라서 전송된 데이터 길이의 총 길이는 53 * ncells 바이트이며, 여기서 ncells = 필요한 셀 수 = INT((payload_length+47)/48)입니다. 따라서 총 길이 = (48*n+1) 바이트인 최악의 경우, 페이로드의 마지막 바이트를 전송하기 위해 하나의 추가 셀이 필요하며, 최종 셀은 추가로 53개의 전송된 바이트 47이 소요되며 그 중 패딩이 필요합니다. 이러한 이유로 소프트웨어에서 감소된 MTU를 인위적으로 선언하면 ATM AAL5 총 페이로드 길이가 가능할 때마다 48바이트의 배수가 되도록 하여 ATM 계층에서 프로토콜 효율성을 극대화합니다.

예를 들어, 완전히 채워진 31개의 ATM 셀은 31*48=1488바이트의 페이로드를 전달합니다. 1488이라는 이 수치를 취하고 모든 관련 상위 프로토콜에 의해 기여한 오버헤드를 빼면 인위적으로 감소된 최적의 MTU에 대한 제안된 값을 얻을 수 있습니다. 사용자가 일반적으로 1500바이트 패킷을 전송하는 경우 1489에서 1536바이트 사이를 전송하려면 하나의 추가 ATM 셀 형태로 전송되는 53바이트의 추가 고정 비용이 필요합니다.

PPPoA/VC-MUX를 사용하는 DSL 연결을 통한 IP의 예에 대해 다시 이전과 같이 31개의 ATM 셀을 채우도록 선택하면 1478바이트로 구성된 오버헤드를 고려하여 원하는 최적으로 감소된 MTU 수치 31 = 48*10-10을 얻습니다. 2바이트의 지점간 프로토콜 오버헤드와 5바이트의 AAL8 오버헤드. 이것은 PPPoA로 전달된 31바이트 패킷에서 ATM을 통해 전송된 총 53*1643=1478바이트의 비용을 제공합니다. PPPoA를 사용하여 ADSL을 통해 전송된 IP의 경우 숫자 1478은 IP 헤더를 포함한 IP 패킷의 총 길이가 됩니다. 따라서 이 예에서 총 길이가 1478인 IP 패킷을 보내는 것과 대조적으로 자체적으로 감소된 MTU 1500을 유지하면 IP 패킷 길이가 53바이트 감소하는 비용으로 ATM 계층에서 패킷당 22바이트를 절약할 수 있습니다.

PPPoE/DSL 연결의 최대 MTU는 RFC 1492에 따라 2516입니다. 6바이트는 PPPoE 헤더이므로 1488바이트 페이로드 또는 31개의 전체 ATM 셀을 위한 충분한 공간이 남습니다.

마지막으로 : MTU의 표준 값은 1492입니다.... 브라우징 문제 또는 MSN 연결 문제의 경우 값을 1422 및 1420으로 줄여야 합니다.

참조 : 위키 백과

친애하는