ICMP: 두 판 사이의 차이
IT 위키
(→계층) |
(→기능) |
||
| (다른 사용자 한 명의 중간 판 하나는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
'''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol, RFC 792 | '''I'''nternet '''C'''ontrol '''M'''essage '''P'''rotocol, RFC 792 | ||
'''ICMP는 인터넷 프로토콜의 비신뢰적인 특성을 보완하기 위한 프로토콜로 IP 패킷 전송 중 에러 발생 시 에러 발생 원인을 알려주거나 네트워크 상태를 진단해주는 기능을 제공한다.''' | |||
==기능== | ==기능== | ||
*오류보고 : IP가 데이터그램을 폐기할 경우 최초 발신지에게 통보 (수정은 안함) | *오류보고: IP가 데이터그램을 폐기할 경우 최초 발신지에게 통보 (수정은 안함) | ||
*질의 : 라우터나 다른 호스트로부터 간단한 상태 정보 획득 | *질의: 라우터나 다른 호스트로부터 간단한 상태 정보 획득 | ||
==계층== | ==계층== | ||
| 74번째 줄: | 74번째 줄: | ||
*코드 필드엔 데이터그램을 전달 할 수 없었던 이유를 명시한다. | *코드 필드엔 데이터그램을 전달 할 수 없었던 이유를 명시한다. | ||
*ex) 0 : 하드웨어 고장, 2 : 상위 프로토콜 도달 불가, 4 : 단편화 불가 (Don't fragment) | *ex) 0: 하드웨어 고장, 2: 상위 프로토콜 도달 불가, 4: 단편화 불가 (Don't fragment) | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 3 | |Type: 3 | ||
|Code : 0 to 15 | |Code: 0 to 15 | ||
|Checksum | |Checksum | ||
|- | |- | ||
| 87번째 줄: | 87번째 줄: | ||
'''Source Quench Message''' | '''Source Quench Message''' | ||
*IP는 흐름제어 기능이 없기 때문에 발신자 쪽에서 데이터를 너무 빨리 보내면 | *IP는 흐름제어 기능이 없기 때문에 발신자 쪽에서 데이터를 너무 빨리 보내면 오버플로가 발생할 수도 있고, 이럴 경우 데이터그램을 그냥 폐기 | ||
*ICMP는 이를 발신자에게 통보하여 송신을 억제 | *ICMP는 이를 발신자에게 통보하여 송신을 억제 | ||
**(ICMP의 한계) 어느 발신자가 혼잡을 유발하는지 알 수 없다. 따라서 엉뚱한 발신자가 희생될 수도 있다. | **(ICMP의 한계) 어느 발신자가 혼잡을 유발하는지 알 수 없다. 따라서 엉뚱한 발신자가 희생될 수도 있다. | ||
| 98번째 줄: | 98번째 줄: | ||
두가지 경우가 있다. | 두가지 경우가 있다. | ||
*Code = '0' 인 경우, Time to live필드가 0이 되어 데이터그램이 | *Code = '0' 인 경우, Time to live필드가 0이 되어 데이터그램이 폐기된 경우 | ||
*Code = '1' 인 경우, 단편이 지정된 시간내에 도착하지 않아 재조립에 실패한 경우 | *Code = '1' 인 경우, 단편이 지정된 시간내에 도착하지 않아 재조립에 실패한 경우 | ||
| 110번째 줄: | 110번째 줄: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 12 | |Type: 12 | ||
|Code : 0 or 1 | |Code: 0 or 1 | ||
|Checksum | |Checksum | ||
|- | |- | ||
| 125번째 줄: | 125번째 줄: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 5 | |Type: 5 | ||
|Code : 0 to 3 | |Code: 0 to 3 | ||
|Checksum | |Checksum | ||
|- | |- | ||
| 136번째 줄: | 136번째 줄: | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type | |Type | ||
| | |메시지 이름 | ||
|주요목적 | |주요목적 | ||
|- | |- | ||
| 157번째 줄: | 157번째 줄: | ||
'''Echo Request / Reply''' | '''Echo Request / Reply''' | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 8 / 0 | |Type: 8 / 0 | ||
|Code : 0 | |Code: 0 | ||
|Checksum | |Checksum | ||
|- | |- | ||
| 182번째 줄: | 182번째 줄: | ||
'''Timestamp Request / Reply''' | '''Timestamp Request / Reply''' | ||
{| class="wikitable" | {| class="wikitable" | ||
|Type : 13 / 14 | |Type: 13 / 14 | ||
|Code : 0 | |Code: 0 | ||
|Checksum | |Checksum | ||
|- | |- | ||
2022년 5월 26일 (목) 15:53 기준 최신판
Internet Control Message Protocol, RFC 792
ICMP는 인터넷 프로토콜의 비신뢰적인 특성을 보완하기 위한 프로토콜로 IP 패킷 전송 중 에러 발생 시 에러 발생 원인을 알려주거나 네트워크 상태를 진단해주는 기능을 제공한다.
기능[편집 | 원본 편집]
- 오류보고: IP가 데이터그램을 폐기할 경우 최초 발신지에게 통보 (수정은 안함)
- 질의: 라우터나 다른 호스트로부터 간단한 상태 정보 획득
계층[편집 | 원본 편집]
- 3계층과 4계층 사이
- TCP/IP가 계층화가 제대로 이루어지지 않았다는 예시로 언급되는 프로토콜
- IP와 같은 3계층 보단 상위 계층이나 라우터와 같은 3계층 장비에서 처리 가능하여 3계층으로 보기도 함
문제점[편집 | 원본 편집]
- 명확하지 않은 계층
- 신뢰성이 없는 비연결형 데이터그램 방식 (Best Effort)
- 오류제어 메커니즘의 부재. 오로지 폐기만 할 뿐 다른 대응을 하지 않는다.
- 목적지를 찾지 못하면 폐기
- 타임아웃(TTL==0)이 될 경우 폐기
- 재조합 타이머가 만료되면 모든 fragment 폐기
- 라우터나 다른 호스트의 상태정보 수집 불가
ICMP 메시지[편집 | 원본 편집]
전체 메시지 정보는 ICMP 메시지 문서 참조
메시지 포맷[편집 | 원본 편집]
| Type (8bit)
메세지 종류 |
Code (8bit)
오류 원인 코드 |
Checksum (16bit)
자기 자신에 대한 오류 검출 Checksum |
|---|---|---|
| Rest of the header | ||
| Data section | ||
메시지 종류[편집 | 원본 편집]
ICMP Error Report Message
| 메세지 이름 | 주요목적 | Type |
|---|---|---|
| Destination unreachable | 목적지 도달 불가 | 3 |
| Source quench | 혼잡으로 인한 데이터그램 폐기 | 4 |
| Time exceeded | Timeout 또는 TTL == 0 | 11 |
| Parameter problem | IP 패킷이나 헤더 오류 | 12 |
| Redirection | 경로 재지정 필요 | 5 |
Destination unreachable message
- 코드 필드엔 데이터그램을 전달 할 수 없었던 이유를 명시한다.
- ex) 0: 하드웨어 고장, 2: 상위 프로토콜 도달 불가, 4: 단편화 불가 (Don't fragment)
| Type: 3 | Code: 0 to 15 | Checksum |
| Unused (All 0) | ||
| IP header and front 8 bytes of datagram data | ||
Source Quench Message
- IP는 흐름제어 기능이 없기 때문에 발신자 쪽에서 데이터를 너무 빨리 보내면 오버플로가 발생할 수도 있고, 이럴 경우 데이터그램을 그냥 폐기
- ICMP는 이를 발신자에게 통보하여 송신을 억제
- (ICMP의 한계) 어느 발신자가 혼잡을 유발하는지 알 수 없다. 따라서 엉뚱한 발신자가 희생될 수도 있다.
- 혼잡이 해결된 후 속도를 회복시키는 메커니즘이 없다
- Source quench 메세지는 딱 한번만 보내진다.
- 그 뒤로 데이터그램이 계속 날아오더라도 다시 보내지 않고 그냥 데이터그램을 폐기시켜 버린다.
Time Exceeded Message
두가지 경우가 있다.
- Code = '0' 인 경우, Time to live필드가 0이 되어 데이터그램이 폐기된 경우
- Code = '1' 인 경우, 단편이 지정된 시간내에 도착하지 않아 재조립에 실패한 경우
Parameter Problem Message
데이터그램의 헤드에 에러가 있거나 부족한 부분이 있을 경우
- Code = '0' 인 경우, 필드 중에 불명료하거나 빠진 것이 있는 경우이다.
- Code = '1' 인 경우, 옵션의 요구사항이 빠져 있는 경우이다.
- 아래 Pointer 필드에 문제가 있는 바이트의 위치가 들어간다.
| Type: 12 | Code: 0 or 1 | Checksum |
| Pointer | Unused (All 0) | |
| IP header and front 8 bytes of datagram data | ||
Redirection Message
- 라우터가 봤을때 자신이 아닌 다른 라우터를 경유 하는게 최종 목적지로 가는데 유리 할 경우 올바른 경로를 알려 준다.
- ICMP가 전달하는 메세지 중 특별한 경우이다. IP 데이터그램을 폐기시키지 않고 그냥 메세지만 전달한다.
| Type: 5 | Code: 0 to 3 | Checksum |
| IP address of the target router | ||
| IP header and front 8 bytes of datagram data | ||
ICMP Query Message
| Type | 메시지 이름 | 주요목적 |
| 8 / 0 | Echo request / reply | IP 프로토콜 점검, 호스트의 도달 가능성 검사 |
| 13 / 14 | Timestamp request / reply | 두 호스트간 IP 데이터그램의 왕복시간 측정 |
| 17 / 18 | Address mask request / reply | 네트워크 마스크를 모를 경우 라우터에 신청 (거의 안씀) |
| 10 / 9 | Router solicitation / advertise | 라우터 주소와 동작 상태 체크 |
Echo Request / Reply
| Type: 8 / 0 | Code: 0 | Checksum |
| Identifier
어떤 Request 인지 어떤 Request 에 대한 reply 인지 |
Sequence number
몇 번째 Request 인지 몇 번째 Request 에 대한 reply 인지 | |
| Optional data
메시지를 포함시켜 보낼 경우 똑같은 메세지가 돌아오게 된다. | ||
Address Mask Request / Reply
디스크가 없는 호스트가 구동될 때 사용되는 것으로, 현재는 거의 안쓰인다
Timestamp Request / Reply
| Type: 13 / 14 | Code: 0 | Checksum |
| Identifier
어떤 Request 인지 어떤 Request 에 대한 reply 인지 |
Sequence number
몇 번째 Request 인지 몇 번째 Request 에 대한 reply 인지 | |
| Original timestamp (보내는 시간) | ||
| Receive timestamp (응답 메시지에만 기록된다. 발신 메시지에선 그냥 여백) | ||
| Transmit timestamp (응답 메시지에만 기록된다. 발신 메시지에선 그냥 여백) | ||
PING[편집 | 원본 편집]
- ICMP를 사용한 대표적인 프로그램(또는 명령)
- ICMP Echo Reply를 이용
