10. MTU/MSS, ICMP 개요

저번 IP에 이어서

 

Header Checksum

헤더의 오류를 검증하기 위해 사용

계산방식은 간단한데, 각 필드에 있는 모든 값을 더해서 나오는 값을 적는다

즉, version 필드 ~ 목적지 IP 필드까지의 값을 전부 더해서 Checksum에 적는 것

더하는 기준은 Byte를 기준으로 연산되며, 자릿수를 초과한 값은 초과한 값 만큼 다시 더한다

 

재미있는 점은 프로토콜마다, 헤더 종류마다 Checksum 방식이 전부 다르다

위 기준은 IP 헤더를 기준으로 체크썸을 구하는 방법이며, TCP, UDP 같은 경우는 방법이 다 다르다는 것

 

MTU와 MSS

우리가 생각하는 것보다 MTU는 상당히 중요하게 작용한다.

Maximum Transfer Unit, 즉 네트워크 기기가 전송할 수 있는 최대 전송 단위로, 랜카드가 전송할 수 있는 최대 전송 크기란 것.

보통의 사람들은 Ethernet 환경이므로 1500 바이트로 통용되고 있으나, 다양한 환경을 고려해야 한다.

 

단편화는 MTU가 큰 쪽에서 작은 쪽으로 이동하면서 이루어지는 작업으로, 주로 3, 4계층에서 이루어진다.

통상적으로 MTU가 큰 쪽은 3계층, MTU가 작은 쪽은 4계층인데, 3계층에서 4계층으로 넘어가면서 단편화가 이루어진다.

즉, 3계층에서 단편화가 이루어진다는 것.

이렇게 되면 문제가, 3계층은 경로 지정(Routing)하기도 바빠 죽겠는데 라우팅까지 처리해야하니 부하가 걸려 처리속도가 느려지는 문제가 발생한다.

이에 딱히 할 것 없는 4계층에서 단편화를 시켜 부하를 조금이라도 덜어보자는 아이디어다.

 

이것은 UDP의 데이터 전송 방식이다.

7계층에서 만들어진 4000byte짜리 데이터에 UDP는 헤더 붙이고 그냥 끝낸다. 즉, 단편화를 하지 않는 것.

따라서 3계층에서 데이터프레임에 맞게 단편화가 진행된다.

따라서 UDP는 단편화를 사용하지 않으므로, 단편화를 생각해야하는 것은 TCP로 초점을 맞춰야한다.

 

4계층에서 단편화를 시키려면 TCP가 전송할 수 있는 크기를 잴 수 있는 새로운 단위가 필요하다.

이에 나온 단위가 MSS(Maximum Segment Size)다.

 

MSS는 말 그대로 TCP, 4계층에서 전송할 수 있는 세그먼트 데이터의 최대 크기를 나타내며,

이 수치를 넘어가는 세그먼트는 단편화가 진행되어 쪼개진다.

MSS를 구하는 공식은 다음과 같다.

IP, TCP 헤더를 전부 신경쓰는 MTU와는 다르게, MSS는 오로지 페이로드 된 데이터 크기만 신경쓴다.

반대로 말하면, MTU 크기에서 IP 헤더 크기와 TCP 헤더 크기를 빼면 그게 MSS다.

IP, TCP 헤더는 상황에 따라서 크거나 줄어들 수 있으며(최소 20byte ~ 최대 60byte) 이에 따라 MSS값도 바뀐다.

즉, 장비의 고정적인 성능 수치인 MTU와는 달리 상황에 따라 크기가 변하는 가변적인 값이다.

단, MSS는 IP 정보는 포함하지 않는다.

 

 

 

이것은 TCP의 데이터 전송 방식이다.

UDP와는 다른 점이 있는데, 7계층에서 만들어진 4000byte짜리 데이터가 MSS 수치를 넘었다.

때문에 4계층에서는 이를 1400 크기에 맞춰 단편화를 진행하며, 쪼개진 각 세그먼트 앞에 각각 헤더가 붙는다.

쪼개진 세그먼트들은 MTU(1500 byte)를 넘지 않으므로, 3계층으로 넘어갈 때 단편화되지 않고 넘어간다.

 

ICMP

Internet Control Message Protocol, 인터넷 제어 메세지 프로토콜

탄생 이유는 IP 프로토콜의 불완전한 신뢰성과 비연결성을 보완하기 위해서 나왔다.

본디 IP 프로토콜은 송신 시스템과 수신 시스템 사이의 패킷을 최적의 경로로 통해 전달하는 것이 주된 목적으로,

데이터가 정확하게 전달되었는지 확인하지 않고(신뢰성이 없음),

세션 또한 맺지 않고 그냥 데이터를 전송(비연결형)하는 프로토콜이다.

즉, 에러 발생 원인이나 진단 기능 및 상황 정보를 전혀 지원하지 않는다는 의미로, 신뢰성에 있어 매우 불안정함을 의미한다.

이러한 점을 보완하기 위해, 상황 정보 및 에러 진단을 위한 프로토콜이 ICMP다.

3계층 프로토콜이 ICMP는 한가지 고민이 있는데, 바로 붙어야할 곳을 찾기가 애매하다는 것.

3계층 프로토콜이 관여하려면 4계층에서 단편화가 끝난 상태로 오게 될텐데, 헤더를 붙이기엔 프레임 헤더가 이미 있다.

때문에 ICMP라는 헤더 정보를 전달할 다른 방법을 모색해야 한다.

이에 고안한 방법이, IP data에 ICMP 메시지를 심어서 보내는 것.

때문에 저런 구조가 나오게 된다.

 

ICMP Message

ICMP 메시지에는 크게 2가지 종류가 있는데, 오류 보고 메시지와 질의 메시지로 나뉜다.

오류 보고 메시지(Error Reporting Message)는 용어 그대로 오류 보고를 목적으로 하는 메시지로, 주로 IP 패킷을 처리하는 도중에 발생한 문제를 보고하는 용도다.

질의 메시지(Query Message)는 오류 정보 전달을 목적으로 하는 메시지로, 주로 다른 호스트로부터 네트워크 정보를 획득하거나, 네트워크 문제를 진단할 때 사용하는 용도다.

 

상술했듯, ICMP Message는 IP 데이터 필드 안에 추가되어 전송된다.

즉, ICMP의 헤더에 해당하는 정보는 IP Protocol 필드를 살펴봐야한다는 뜻

실제로 Wireshark등으로 캡쳐 시 IP 데이터 필드 위에 ICMP가 딱 붙어서 전송되는 것을 확인할 수 있다.

ICMP Message는 Type과 Code 두개로 구분하는데, 아래를 따른다

물론 이걸 전부 외울 필요는 없고, 필요한 것만 간추린다면

이정도가 될 것이다. 특히, 타입 3번과 11번은 밥 먹듯이 나오는 ICMP로, 꼭 기억해두자

 

이를 테스트 해보는 실습을 해보자

이 컴퓨터에 할당되어 있는 네트워크 게이트웨이에게 ping 요청을 보낸다. 이 때, Wireshark를 켜 놓은 상태로 ping을 보낸다.

ICMP로 필터링을 걸면, 이렇게 8개의 핑이 잡히는데,

ICMP를 정상적으로 적재하고 있는 모습을 확인할 수 있다.

 

 

이번엔 옵션으로 크기를 변경하여 전송해보자

이 ping의 크기는 4000바이트로, 일반 MTU사이즈 1500 byte보다 훨씬 더 큰 크기다.

때문에 IP단에서 단편화가 이루어지면서 전송이 될 것을 유추할 수 있다.

실제로 데이터가 여러개로 나뉘어서 전송되는 것을 확인할 수 있으며

실제 데이터 또한 1480byte(MTU 1500byte - Header 20byte)로 정상적으로 보내진 것을 확인할 수 있다.

 

 

Tracert 명령어는 3번의 ping으로 RTT값을 구해 각 경로를 구하는 명령어로,

RTT 값과 경로의 IP 값을 볼 수 있는 것이 특징이다.

 

TTL을 제한한 상태로 전송해보자

TTL을 6으로 설정한 후 ping을 날려보면, 64 라우터가 중간에 TTL이 만료되었다고 응답이 온다

Wireshark 또한 해당 패킷이 잡혔으며,

오류 코드 11/0으로 잡혀있는 것을 확인할 수 있다.