MTU / MRU 문제는 정확히 무엇이며, 원인 및 해결 방법은 무엇입니까?

관련 명령과 같은 원인은 일반적으로 부당하게 여러 급하게 제안 "마술 치료"와 "MTU / MRU 문제"로 식별 느린 응답하지 않는 인터넷 연결을 동결 매달려의 경우, (상황에 일반적으로 유효하지 않거나 적용 할)에서 iptables또는 ifconfig, 기타 " MTU를 TSS에 고정시킵니다. "

내가 알고 싶은 것은 MTU / MRU 문제가 정확히 무엇인지, 연결 속도와 대기 시간에 영향을 미치는 이유, 문제가 해결되는 방법에 대해 지식 적으로 접근하고 싶기 때문에 치료 방법 (알고있는 최신 방법), 마술처럼 아닙니다.

이것은 약간 복잡한 질문이므로 기본 사항부터 시작하겠습니다. 이 모든 것을 이미 알고 있다면 용서하십시오.

MTU는 컴퓨터 인터페이스가 전송할 최대 데이터 패킷 인 최대 전송 단위입니다. 이더넷의 경우 기본값은 1500 바이트입니다. 이더넷 프레임은 일반적으로 최대 1522-1542 (계산 대상에 따라 다름)까지 허용되며 헤더 정보를 위해 추가 공간이 '예약'됩니다.

연결마다 기능이 다를 수 있습니다. MTU가 1500보다 약간 작은 인터넷 링크를 통해 실행하는 것이 일반적입니다. 이는 일반적으로 추가 헤더 정보를 사용하거나 '표준'이더넷 이외의 매체를 사용하는 링크 때문입니다 (대부분의 인터넷은 실제로는 ATM / SoNet 연결). 일반적으로 이러한 링크가 발생하는 트래픽은 여러 조각으로 나뉘어 전송됩니다.

이것이 일반적이며 IP가 발명 될 당시 였기 때문에 ICMP 프로토콜의 책임 중 일부는 MTU와 관련된 문제를 전달하는 것이 었습니다. 어떤 이유로 든 패킷을 분리하여 전달할 수 없으면 ICMP를 사용하여 문제를 송신 컴퓨터로 다시 전달합니다. 보내는 컴퓨터는 적절한 조치를 취하여 정보를 작은 덩어리로 나누며 모든 사람이 행복합니다. 이 전체 프로세스는 뒤에서 처리됩니다. A의 제대로 작동 네트워크 는 MTU 설정을 깨끗이 할 필요는 결코 없다 .

마지막 문장의 한정자는 키커입니다. 자동화 된 프로세스가 고장 나는 세 가지 일반적인 이유가 있습니다.

1. 고장난 구현-어느 시점에서 소프트웨어가 제대로 작동하지 않습니다. 사람들이 인터넷의 관련 표준을 따라야한다는 법은 없으며, 표준을 위반하는 회사는 대개 저렴합니다.
2. 관리 상 장애가있는 구현-의도가 좋은 사람들은 실제로 자신이하는 일을 모르기 때문에 소프트웨어를 깰 수 있습니다. 나는 개인적으로 사람들이 ICMP.0.0 패킷에만 사용한다고 생각하기 때문에 사람들이 ICMP를 차단하는 것을 보았습니다 (에코, 대부분의 사람들은 ping유틸리티에 의해 이것을 알고 있습니다 ).
3. 이 '정상적인'과정을 완전히 벗어난 다른 이유. 대부분의 경우 이는 연결이 매우 손실되어 짧은 패킷 만 연결을 통해 안정적으로 (또는 많은 재시도 횟수없이) 만들 수 있음을 의미합니다. 일부 초기 DSL 및 케이블 모뎀에는 이와 같은 문제가있었습니다. 그 전에는 전화 품질이 좋지 않은 전화선과 공격적인 회선 코딩을 사용할 때 전화 접속에 이와 같은 문제가 발생했습니다.

게으른 기술자 / 회사는 왜 흔한 일입니까? 위에서 설명한 문제 중 하나를 해결하는 것보다 작은 MTU로 연결을 핸디캡하는 것이 거의 보편적으로 '더 쉬워'입니다. 위에서 언급했듯이 요즘 모든 사람이 MTU를 망칠 필요는 없습니다 (점보 프레임을 사용하는 것으로 생각할 수있는 한 가지 예외는 있지만 여기서 논의하지는 않습니다). 어쨌든 올바른 치료법은 근본적인 문제를 파악하고 해결하는 것입니다. 증상이 아닌 질병을 치료하는 전형적인 사례.

MTU는 연결에 어떤 영향을 줍니까? 데이터를 작은 조각으로 자르면 각 조각이 특히 신뢰할 수없는 연결을 통해 대상에 도달 할 가능성이 높아집니다. 그러나 크기가 작을수록 전송되는 데이터 당 더 많은 오버 헤드가 있습니다. 이는 유효 연결 속도가 감소 함을 의미합니다. MTU가 실제로 작은 경우 실질적으로. 헤더 및 조각화 / 재 조립 프로세스의 추가 처리 및 오버 헤드로 인해 지연 시간이 미미할 것으로 예상되지만 지연 시간이 영향을받을 수 있습니다.

업데이트 : - --clamp-mss-to-pmtu
개인적으로 나는 MTU에 대해 결코 신경 쓰지 않았습니다. 나는 내가 약간 완벽 주의자라는 것을 인정하고 이와 같은 추악한 해킹을 받았을 때 나는 항상 문제의 근원을 찾아서 고칠 수 있었다. 이를 위해 iptables옵션 --clamp-mss-to-pmtu은 저에게 생소합니다. 이 핵을 사용하는 것은 매우 일반적이며, 대부분의 상황에서 매우 보증되지 않는 것 같습니다. 위의 문제 중 하나를 보완하는 것은 여전히 ​​해킹입니다. iptables (8)에 대한 Linux 맨 페이지에서 인용합니다.

이 대상은 'ICMP Fragmentation Needed (ICMP 조각화 필요)'또는 'ICMPv6 Packet Too Big'패킷을 차단하는 범죄적인 뇌파 ISP 또는 서버를 극복하는 데 사용됩니다.

맨 페이지의 상대적으로 열악한 언어는 RFC를 따르지 않는 (그리고 시도하거나 보상하려는 노력을 기울이지 않는) ISP 및 네트워크가 얼마나 많은 경멸을 나타내는지를 나타냅니다.

VPN에서 UDP 사용과 관련하여 VPN의 오버 헤드를 최소화하고 기존 엔드 포인트가 세션 정보를 관리 할 수 ​​있도록하는 것이 가장 일반적이었습니다. VPN이 세션을 처리하는 방법을 알 수있는 방법이 없으므로 작업을 알고있는 응용 프로그램에 맡기는 것이 가장 좋습니다.

많은 최신 VPN 터널링 프로토콜은 GRE 및 L2TP와 같은 낮은 수준 (더 적은 오버 헤드)으로 구축됩니다. 또는 SSTP 또는 SSH와 같이 더 높은 수준으로 터널링됩니다 (일반적으로 제한 방화벽과의 호환성 또는 기타 이유로). 전송 메커니즘으로 UDP가 점차 대체됩니다.

업데이트 2 : -MTU / ICMP 문제 진단
따라서 MTU / ICMP 문제가 있다고 생각하고 확신합니다. 이 프로세스에는 두 가지 기본 단계가 있습니다. 지시 사항은 Linux 또는 BSD 상자에 대한 것이지만 거의 모든 OS에 맞게 조정할 수 있습니다.

1. ICMP Ping 대상 (예 : Google.com, Yahoo.com, Facebook.com 등)을 선택하십시오. 다음 명령으로 핑을 시도하십시오 ping -c 2 -s 1472 -D google.com..
   • 이렇게 해야 성공. 성공하지 못하면 "패킷을 조각화해야합니다"를 반환해야합니다. 이 중 하나라도 해당되면 중지하십시오. 연결이 제대로 작동합니다.
   • 이렇게해도 아무 것도 반환되지 않거나 "시간 초과"메시지가 표시되면 문제가있는 것입니다.
2. 끊어진 연결의 경우 : run traceroute -F google.com 1472. 어떤 홉이 고장 났는지 알려줍니다. 참고 : CPE가 추적 경로 요청에 응답하지 않는 것이 일반적이므로 첫 번째 홉이 응답하지 않는 경우 경고하지 마십시오.
   • 마지막으로 응답 한 홉이 마지막으로 올바르게 작동하는 것입니다.
   • 그들 중 누구도 응답하지 않으면 CPE 또는 DSL 회선입니다 (조금 까다로울 수 있지만 현대적이면 거의 CPE가 아닙니다). 참고 : 연결이 제대로되면 traceroute가 성공적으로 완료됩니다.

참고 : 요즘 어떤 ISP가 PPTP를 사용합니까?! 그것은 구식이며 쓸모없는 과거의 폭발입니다. 최소한 PPPoE를 사용해야합니다. 그러나 MAC과 세그먼트로 모뎀을 승인하는 것이 훨씬 쉬울 것입니다 (ISP와 고객 모두에게 더 쉬움).