개방형 인터넷에서 점보 프레임 (MTU 최대 9k)이 현실적입니까?

더 큰 이더넷 프레임을 활용할 수있는 응용 프로그램이 있습니다. 이론적으로 아웃 바운드 패킷 수를> 50 %, 심지어 66 %까지 줄일 수 있습니다.

또한 응용 프로그램 서버를 새로 설치하기 위해 후보 호스팅 회사와 네트워킹 요구 사항을 지정하는 중입니다. 클라이언트 연결이 점보 프레임의 이점을 얻는 것을 최소한으로 제한하지 않는 것이 좋습니다.

그러나 이것이 얼마나 현실적인가? 우리가 제어 할 수있는 네트워크 세그먼트를 가정 할 때 일반적인 질문은 점보 프레임 친화적입니다 (스위치는 큰 MTU 가능, ICMP MTU 경로 발견 허용 등) .

• 공용 인터넷을 통해 점보 프레임을 보내는 것이 현실적입니까?
• 공용 인터넷을 통해 점보 프레임을 지원하려는 끊임없는 네트워킹 문제가 발생합니까?
• 내가 고려하지 않은 다른 문제가 있습니까?

여기서 핵심은 네트워크의 작은 세그먼트를 제어하고 큰 MTU를 활성화 할 수 있지만 패킷이 인터넷을 통과하는 경로를 제어 할 수 없으며 패킷이 통과 할 라우터의 구성을 제어 할 수 없다는 것입니다. 대부분의 인터넷 라우터는 1500 이상으로 구성되어 있지 않으므로이 솔루션으로 많은 운을 얻지 못할 것입니다. 더구나, 때로는 더 큰 패킷이 점보 프레임을 지원하지 않는 라우터에 의해 실제로 삭제되므로 점보 프레임을 인터넷에 보내려고하면 실제로 상황이 더 나빠질 것입니다.

점보 프레임은 내부 네트워크, 특히 스트리밍 또는 iSCSI를 수행하는 네트워크에 적합합니다.

1. 인터넷에 대한 귀하의 의견이 단일 기관을 통해 귀하에게 제공되지 않는 한, 귀하가이 문제에 대해 매우 구체적으로 언급 한 다음 동일하게 제어 가능한 종점에 도달하게되면 트래픽이 '손상되지 않은'운송되지 않을 확률이> 99.9 %입니다 JF를 유지하십시오. 그 이유는 JF가 이더넷 사양이고 모든 인터넷이 이더넷이 아니기 때문에 분해, 재 조립, 운송 및 재 패킷 화되기 때문입니다.
2. 문제-아마, 아마 첫날에는 문제가 발생할 수 있지만, 일단 문제가 발생하면 작동하는 것이 좋습니다.
3. 난 당신이 서버에서 클라이언트로 체인의 모든 부분을 완벽하게 제어하지 않는 한 내가 즉,이 작업을 얻을, 가장 낮은되지 가장 높은 공통 분모를 고려 내 시스템을 설계하는 유혹 할 거라고 말을 한 후 다른 방법으로 주위를 조정하지를 .

다른 사람들이 위에서 말했듯이 대답은 현재 아니오입니다.

또한 점보 프레임을 지원하지 않는 한 공급자 업 링크의 MTU를 고려하면 시작하기 전에 운이 좋지 않습니다.

많은 3 차 교육 네트워크 (AARNET, JANET, Internet2)는 네트워크에서 엔드 포인트를 지원하는 점보 프레임을 제공합니다. 그 네트워크에서 사람들에게 서비스를 제공하고 있다면 그만한 가치가 있다고 제안합니다.

내 경험에 따르면 점보 프레임은 일반적으로 응용 프로그램 서버와 데이터베이스 서버 간의 전용 링크로 제한됩니다. 더 복잡한 것에 대한 비 호환 가능성 유형의 수는 놀랍습니다.