네트워크의 터널 높이 제한, MTU. 무조건 크면 효율이 좋을 것 같지만 1,500바이트가 국룰이 된 확률적 이유와 하드웨어의 한계를 분석합니다.
네트워크 통신에서 **MTU(Maximum Transmission Unit)**는 한 번의 전송으로 보낼 수 있는 최대 데이터 패킷의 크기를 의미합니다.
비유하자면 도로 위의 터널 높이 제한이나, 트럭 한 대에 실을 수 있는 최대 적재량과 같습니다. 짐(데이터)이 아무리 많아도 이 제한을 넘겨서 한 번에 보낼 수는 없습니다.
네트워크로 데이터를 보낼 때, 우리는 큰 데이터를 한 번에 보내지 않고 여러 개의 패킷으로 쪼개어 보냅니다. 이때 하나의 패킷이 가질 수 있는 가장 큰 크기가 바로 MTU입니다.
만약 전송하려는 패킷의 크기가 경로상에 있는 라우터의 MTU보다 크다면 어떤 일이 벌어질까요?
라우터는 통행 제한에 걸린 큰 트럭을 발견하면, 짐을 내려서 작은 트럭 여러 대에 나눠 싣습니다. 이를 단편화라고 합니다.
공짜는 없습니다. 패킷을 쪼개고, 목적지에서 다시 순서대로 조립하는 과정에서 라우터와 서버의 CPU 자원이 소모되고, **지연 시간(Latency)**이 발생합니다.
만약 패킷 헤더에 "쪼개지 마시오(Don't Fragment, DF)" 플래그가 설정되어 있다면? 라우터는 쪼개는 대신 패킷을 폐기하고 에러 메시지(ICMP)를 보냅니다. (이것이 블랙홀 현상의 주원인입니다.)
"트럭이 클수록 짐을 많이 나르니 무조건 좋은 거 아닌가?"라고 생각할 수 있습니다. 이론적으로는 맞지만, 현실 네트워크에는 **'확률'**이라는 변수가 존재합니다.
네트워크 역사에서 1,500 Byte는 효율성(Efficiency) 과 반응성(Latency) 사이의 절묘한 타협점입니다.
헤더가 차지하는 비중은 약 2.7%에 불과합니다. 즉, 97.3%의 효율을 내므로 굳이 위험을 감수하고 사이즈를 더 키울 필요가 없다고 판단된 것입니다.
또한, 패킷이 너무 크면 한 패킷이 회선을 점유하는 시간이 길어져(직렬화 지연), VoIP나 게임 같은 실시간 통신에서 **지연(Lag)**을 유발할 수 있습니다.
그럼에도 불구하고 특정 환경에서는 9,000 Byte 크기의 점보 프레임을 사용합니다.
MTU: 1,500 Byte