인터넷 환경에서 네트워크 계층의 데이터 전송 프로토콜로 이용되는 IP는 호스트 주소 표기, 패킷 분할에 관한 기능ㅇ르 지원하지만, 단대단 형식의 오류 제어나 흐름 제어 기능을 제공하지 않는다.
IP프로토콜로서 라우터 간의 수신 패킷을 중계할 때는 Best Effort라는 원칙에 따라 전송하는데, 이 방식은 전송 패킷이 수신 호스트에 100% 도착하는 것을 보장하지 않는다. 따라서 IP프로토콜에서 제공하지 않는 전송 오류 문제를 상위 계층에서 고려해야 한다.
- 비 연결형 서비스를 제공한다.
- 패킷을 분할/병합하는 기능을 수행하기도 한다.
- 데이터 체크섬은 제공하지 않고, 헤더 체크섬만 제공한다.
- Best Effort 원칙에 따른 전송 기능을 제공한다.
IP헤더 구조
헤더 필드를 연관된 종류 별로 묶어 설명
DZ/ECN
DS와 ECN 필드가 도입되기 전에는 8비트의 Service Type(DS+ECN)필드로 정의되어 우선 순위, 지연, 전송률, 신뢰성 등의 값을 지정할 수 있었다. Service Type 필드는 IP프로토콜이 사용자에게 제공하는 서비스의 품질에 관련된 내용을 표현하는데, 각 비트 값의 의미는 아래와 같다.
각 비트의 값
비트번호 | 0 | 1 |
0~2 | 우선순위(111)가장 높음 | // |
3 | 보통의 지연 | 낮은 지연 |
4 | 보통의 전송률 | 높은 전송률 |
5 | 보통의 신뢰성 | 높은 신뢰성 |
6~7 | 예약 | // |
차등 서비스 개념이 도입되면서 Service Type 필드는 6비트의 DS 필드와 2비트의 ECN 필드로 새로 정의되었다. 이는 인터넷에서 다양한 트래픽 요구 조건을 필요로 하는 서비스들에 대하여 서로 다른 수준의 Qos를 지원하기 위함이다.
DS를 사용하기 위해 사전에 서비스 제공자와 서비스 이용자 사이에 서비스 등급에 대한 합의가 이루어지며, 동일한 DS 값을 갖는 트래픽들은 동일한 서비스 등급으로 처리된다. 이러한 처리 과정은 라우터에 의하여 이루어지므로 기존 응용 프로그램들을 변경할 필요가 없다.
DS 코드 포인트라고도 하는 DS 필드 값은 차등 서비스의 기준이 되는 레이블 값으로 64개의 트래픽 클래스를 정의할 수 있다. DS 서비스는 비교적 단순한 원리에 의하여 차등화된 서비스를 제공하지만 내부적인 처리 과정은 복잡한 구조에 의하여 이루어진다.
패킷분할
IP프로토콜은 상위 계층에서 내려온 전송 데이터가 패킷 하나로 전송 하기에 너무 크면 분할해 전송하는 기능을 제공
패킷분할과 관련된 필드
- Identification(식별자 혹은 구분자) : IP헤더의 두 번째 워드에는 패킷 분할과 관련된 정보를 포함한다. 이중 Identification 필드는 송신 호스트가 지정하는 패킷 구분자 기능을 수행한다. IP프로토콜이 분할한 패킷들에 동일한 고유 번호를 부여함으로써, 수신 호스트가 Identification 번호가 같은 패킷을 다시 병합할 수 있도록 해준다. 패킷을 분할하지 않으면 패킷을 전송할 때 마다 이 필드 값을 하나씩 증가시킨다.
- DF(Don't Fragment) : 패킷이 분할되지 않도록 한다. 즉, 값을 1로 지정하면 패킷 분할을 막을 수 있다. 수신 호스트가 분할되어 입력된 패킷들을 병합하는 기능이 없을 때 사용한다. 따라서 중간 경유 네트워크에서는 자신이 처리 가능한 패킷의 크기보다 큰 IP 패킷에 DF 필드가 설정되어 있으면 분할 기능을 수행하지 않고 패킷을 버린다.
- MF(More Fragment) : 분할된 패킷을 전송할 때는 여러개의 분할 패킷이 연속해서 전송되므로 MF 필드 값을 1로 지정하여, 분할 패킷이 뒤에 계속됨을 표시해주어야 한다. 분할 패킷 중 마지막 패킷은 MF 비트를 0으로 지정하여 분할 패킷이 더 없음을 표시한다.
- Fragment Offset(분할 옵셋) : 패킷 분할이 이루어지면 12비트의 Fragement Offset 필드를 사용한다. 저장되는 값은 분할된 패킷의 내용이 원래의 분할 전 데이터에서 위치하는 상대 주소 값이다. 값은 8바이트의 배수이므로, Fragment Offset 값이 64라면 원래 데이터에서 64*8 - 512번째에 위치한다.
주소 관련 필드
Source Address는 송신 호스트의 IP주소이고, Destinamtion Address는 수신 호스트의 IP주소이다. ip주소 체계는 크게 다섯 종류이다.
클래스 A, B, C는 유니캐스팅에서 이용하고, 클래스 D는 멀티 캐스팅에서 이용한다. 클래스 E는 향후의 새로운 응용 환경을 위하여 점정적으로 예약된 클래스이다.
클래스 A, B, C는 주소를 network와 host 필드로 구분해 관리함으로써 클래스 별로 네트워크 크기에 따라 주소 관리를 다르게 한다.
network 네트워크 주소이다. 전 세계적으로 유일한 번호가 모든 컴퓨터 네트워크에 할당된다. 현재 이 주소의 할당은 NIC에서 담당한다.
host:네트워크 주소가 결정되면 하위의 호스트 주소를 의미하는 host 비트값을 개별 네트워크 관리자가 할당한다. 클래스 A는 host비트의 크기가 크기 때문에 규모가 큰 네트워크에서 사용하고 클래스 C는규모가 작은 네트워크에서 사용한다.
기타 필드
- Version Number : IP프로토콜의 버전 번호이다. 현재 인터넷 환경에서 사용하는 IP프로토콜은 버전 4이다. IP프로토콜의 새로운 버전인 IPv6와 구분하기 위해 기존 IP프로토콜을 IPv4로 표현하기도 한다.
- Header Length : IP 프로토콜의 헤더 길이를 32비트 워드 단위로 표시한다. 일반 패킷을 전송하는 경우에 헤더의 Options, Padding필드가 빠지므로 IP헤더의 최소 크기는 5이다.
- Packet Length : IP헤더를 포함하여 패킷 전체 길일ㄹ 나타낸다. 필드의 크기는 이상적인 최댓값으로, IP프로토콜에서 지원하는 패킷의 최대 크기는 2^16-1바이트이다. 그러나 이는 이상적인 최댓값으로, IP프로토콜에서 65,535바이트의 IP패킷을 전송해도 대두분 데이터 링크 계층에서 분할해 전송한다. 따라서 실제 환경에서도 IP프로토콜은 IP패킷을 더 작은 단위로 만든다. IP패킷의 크기는 일반적으로 8,192바이트를 넘지않는다.
- Time To Live : 패킷 전송 과정에서 패킷이 올바른 목적지를 찾지 못하면 수신 호스트에 제대로 도착하지 않고 네트워크 내부에서 떠돈다. 이런 현상을 방지하려고 Time To Live 필드를 사용한다. 송신 호스트가 패킷을 전송하기 전에 네트워크에서 생존할 수 있는 시간을 지정하고, 각 라우터에서는 패킷이 지나갈 때마다 필드 값을 감소시키면서 패킷을 중개한다. 임의의 라우터에서 Time To Live 값이 0으로 감소하면 패킷은 자동으로 버려지고, 패킷 송신 호스트에 ICMP 오류 메시지가 전달된다.
- Transport(전송 프로토콜): IP프로토콜에 데이터 전송을 요구한 전송 계층의 프로토콜을 가리킨다. 전송 계층의 TCP 세그먼트와 UDP 데이터그램, 네트워크 계층의 ICMP 패킷은 모두 IP 패킷의 데이터를 의미하는 페이로드 부분에 캡슐화 되어 전송된다. 왼쪽의 숫자는 Transport 필드 값을 의미하며, TCP = 6, UDP = 17, ICMP = 1의 값이 저장된다. 따라서 패킷 수신자는 페이로드 내부에 어느 프로토콜 정보가 있는지 판단할 수 있다.
- Header Checksum : 전송 과정에서 발생할 수 있는 헤더 오류를 검출하는 기능으로, 데이터의 오류는 검출하지 않는다. 이와 달리 계층 4 프로토콜인 TCP, UDP 헤더는 데이터와 헤더 오류를 모두 검출한다. 체크섬 계싼 과정은 다음과 같다. 먼저 HeaderChecksum 필드의 비트 값을 모두 0으로 설정한 후, 전체 헤더가 16비트 워드의 연속이라 가정하고 1의 보수 합을 수행한다. 이 값을 체크섬으로 하여 패킷을 전송하고 수신 호스트는 1의 보수 합을 계산하여 계산 결과가 모두 1이면 전송 과정에 오류가 없다고 판단한다. 전송 과정에 오류가 발생하면 해당 패킷을 버리고, 이를 복원하는 일은 상위 계층에서 담당한다. IP헤더 값은 라우터의 중개 과정을 거치는 동안에 계속 변경되므로 라우터를 거치는 과정에서 체크섬을 검증하고 재계산 하는 과정이 반복적으로 이루어진다.
- Options : 네트워크 관리나 보안처럼 특수 용도로 이용할 수 있다.
- Padding : IP헤더의 크기는 32비트 워드의 크기가 배수가 되도록 설계되어 있다. 필드의 전체 크기가 이 조건에 맞지 않으면 이 필드를 사용해 조정할 수 있다.
패킷 분할
다양한 유형의 네트워크를 통해 패킷을 중개하려면, IP프로토콜이 패킷을 각 네트워크에서 처리하기 편한 크기로 분할해야 한다.
ex) x.25 프로토콜에서 프레임의 크기와 이더넷에서의 프레임 크기는 다르다. 따라서 상위 계층에서 더 큰 데이터 전송을 요구하면 IP프로토콜에서 패킷 분할 과정을 먼저 수행해 전송한다.
분할의 필요성
하부 계층의 관점에서 보면, TCP에서 설정되는 논리적인 가상 연결은 여러 종류의 네트워크를 거쳐서 설정된다. 그러나 TCP 프로토콜은 패킷 전송 과정에 위치하는 네트워크 유형에 따라 패킷의 크기를 조절하기가 쉽지 않으므로 IP프로토콜에서 이 기능을 수행해야 한다.
- 맨 밑에 위치한 데이터 링크 계층 프로토콜의 프레임은 크기가 프로토콜 마다 다르다. 따라서 상위 계층에서 내려온 데이터를 계층 2의 프레임 틀에 담을 수 있도록 IP프로토콜에서 분할 과정을 거친 후에 전송하고, 수신 측에서는 이를 다시 합치는 병합 작업을 수행한다.
- IP프로토콜의 분할 기능은 전송 경로에 위치한 라우터에 의해 수행된다. 라우터의 좌우에 연결된 LAN이 서로 다를 수 있기 때문에 데이터 링크 계층에 위치한 프레임 크기가 프로토콜마다 달라진다. 따라서 데이터를 수신한 이후에 패킷을 중개하는 방향에 위치한 LAN에 맞도록 프레임을 분할해주어야 한다.
분할의 예
IP프로토콜의 패킷 분할 과정은 IP헤더를 제외한 전송 데이터의 크기는 380바이트이고, 패킷은 최대 크기가 128바이트라고 가정하였다. Fragment Offset필드를 계산해야 하는데, 이 값에 8을 곱한 크기가 분할 전의 데이터 위치이다. 패킷 전체의 최대 크기인 128바이트에서 헤더인 20바이트를 빼면 108바이트가 되므로 분할 패킷에 보관할 수 있는 데이터의 최대 크기는 108을 8로 나눈 몫(정수값) * 8 = 104바이트이다. 따라서분할된 패킷의 개수는 4개(390을 108로 나눈 몫 + 1)이 며, 각 패킷의 Fragment Offset 필드 값은 0, 13, 26, 39가 된다.
분할 패킷인 분할1, 분할 2, 분할 3은 데이터 크기 104바이트에 헤더 크기 20 바이트를 더해 124가 되므로 패킷 전체 크기 Packet Length = 124바이트이다. 마지막 분할 패킷은 전체 데이터의 크기 380에서 세개의 분할 패킷 크기 3*104를 빼면 68바이트의 여분을 얻을 수 있는데, 이 값에 헤더 크기인 20바이트를 더해 Packet Length = 88바이트이다.
분할한 패킷의 Identification 필드에는 동일한 번호를 부여해야 한다. MF 필드는 마지막 패킷만 제외하고 1을 지정해 분할 패킷이 이어지고 있음을 표시해주어야 한다.
DHCP 프로토콜
특정 네트워크를 관리하는 네트워크 관리자는 개별 호스트들에 수동으로 고정 IP 주소를 할당할 수 있다. 그러나 P 주소 부족 등의 사유로 DHCP를 사용하여 자동으로 할당할 수도 있다. 이렇게 IP 주소를 여러 컴퓨터가 공유해서 사용하면 더 적은 수의 IP 주소 만으로도 시간 분할 방식으로 인터넷에 접속할 수 있다.
자동으로 할당 가능한 IP주소는 DHCP 서버가 관리하는 풀에 저장되어 관리되며, 클라이언트로부터 IP주소 요청이 오면 풀에서 하나의 IP주소를 할당한다. 이후 사용이 끝나면 다시 IP주소 풀로 반환되어 다른 호스트가 사용할 수 있다.
DHCP 메시지
IP주소를 원하는 클라이언트 DHCP 서버에 요청 메시지를 전송하고 서버는 이에 대한 응답 메시지를 회신한다. 이 때 사용하는 DHCP 메시지의 형식은 아래와 같다.
- OPcode : 요청 메시지는 1을 지정하고, 응답 메시지는 2를 지정한다.
- HardwareType : 이더넷 등과 같이 하위 계층의 하드웨어 유형을 지정한다.
- Hardware Length : 하드웨어 주소의 길이를 지정한다.
- HopCount : 패킷이 전달되는 최대 홉의 수를 지정한다.
- Transtion Identifier : 클라이언트의 요청이 있을 때 지정하는 임의의 숫자이며, 서버는 지정된 번호르 응답한다. DHCP 메시지는 브로드캐스팅 방식으로 전송되기 때문에 클라이언트와 서버 간의 논리적인 세션을 형성하는 목적으로 사용한다.
- Time Elapsed : 클라이언트가 부팅된 이후의 경과 시간을 지정한다.
- Flag : 현재 첫 번째 비트만 사용되며, 유니 캐스트인지 멀티 캐스트인지를 구분한다.
- Client IP Address : 클라이언트가 자신의 IP 주소를 지정한다. 주소를 보면 0으로 표시한다.
- Your IP Address : 서버가 응답 메시지로 권고 해주는 클라이언트의 IP 주소이다.
- Serve IP Address : 서버의 IP 주소를 지정하는데, 모르는 경우는 0으로 표시한다.
- Gateway IP Address : 클라이언트의 하드웨어 주소를 지정하며, 크기는 Hardware-Length필드에 표시된다.
- Serve Name : 서버의 도메인 네임을 지정하며 크기는 64바이트이다.
- Boot File Name : 추가 정보를 보관하고 있는 파일 경로명을 지정하며, 크기는 128바이트이다.
- Options : 필요한 추가정보를 지정하며, 크기는 64바이트이다.
DHCP 프로토콜의 동작 과정에 필요한 주요 메시지의 종류
Options필드에 의하여 구분된다. DHCP 메시지는 UDP 데이터 그랩에 캡슐화되어 전송되며, 클라이언트의 포트 번호는 68, DHCP 서버의 포트 번호는 67이다.
- DHCP DISCOVER : 클라이언트가 DHCP 서버를 찾기 위해 전송하는 브로드캐스트 메시지이며, Transtion Identifier에 특정한 값을 지정한다. 클라이언트 IP 주소 값이 없으므로 하부의 IP 프로토콜 송신자의 IP 주소는 0, 0, 0, 0으로 지정한다. 클라이언트가 DHCP 서버의 IP 주소를 모르므로 수신자의 IP 주소는 브로드 캐스팅 주소인 255.255.255.255로 지정한다.
- DHCP OFFER : 클라이언트의 DHCP DISCOVER 메시지에 대한 응답으로 DHCP 서버가 응답하는 메시지이며, YourIPAddress 필드에 권고하는 IP 주소를 지정하고 Server IP Address 필드에는 서버의 IP 주소를 지정한다. 아직 클라이언트의 IP 주소가 결저오디지 않았으므로 IP 패킷은 브롣캐스팅 형식으로 전송된다.
- DHCP_REQUEST : 클라이언트는 여러 서버로부터 다수의 DHCP_OFFER를 받을 수 있기 때문에 이 중에서 적장한 IP 주소를 선택해야 한다. 그리고 이 주소를 권고한 DHCP 서버에 DHCP_REQUEST 메시지를 전송하여 권고한 주소를 사용한다고 알려준다.
- DHCP_AKC : 클라이언트가 DHCP_REQUEST 메시지를 받은 DHCP 서버는 권고한 IP 주소가 최종적으로 사용 가능한지 판단한다. 사용 가능하면 DHCP_ACK 메시지를 전송한다.
- DHCP_NAK : DHCP 서버는 동일한 IP 주소를 여러 클라이언트에 권고할 수 있다. 따라서 다른 클라이언트가 IP 주소를 선잠한 경우 DHCP 메시지를 사용하여 클라이언트가 DHCP 서버로부터 IP주소를 얻을 수 있다.
DHCP 프로토콜의 동작 과정
먼저 클라이언트가 DHCP_DISCOVER메시지를 전송하고 이어서 DHCP 서버로부터 211.223.201.99로 권고된 IP 주소를 받는다. 세번째의 DHCP_REQUEST메시지를 이용하여 권고된 IP주소를 사용하겠다는 의사 표시에 대하여 DHCP 서버로부터 긍정 응답을 받고 있다.
DHCP 메시지와 UDP 와 IP프로토콜로 캡슐화 되어 전송되는 과정
UDP 프로토콜 캡슐화
UDP 헤더에서 보는 것처럼 DHCP 서버의 포트번호는 67이고, 클라이언트는 68을 사용한다. IP헤더에는 IP주소를 표기해야 하는데, 목적지 IP 주소를 255.255.255.255로 지정하여 브로드 캐스팅을 전송을 하고 있다. DHCP_DISCOVER 메시지를 전송하는 송신자의 IP주소는 없으므로 0.0.0.0을 지원한다.
Reference
쉽게 배우는 데이터 통신과 컴퓨터 네트워크
'CS > Network' 카테고리의 다른 글
[Chapter 8] 네트워크 계층(이동 IP 프로토콜) (0) | 2025.02.14 |
---|---|
[Chapter 8] 네트워크 계층(IPv6 헤더 구조) (0) | 2025.02.14 |
[Chapter 7] IP 프로토콜(라우팅 프로토콜) (0) | 2025.02.13 |
[Chapter 7] IP 프로토콜(연결형 서비스와 비연결형 서비스) (0) | 2025.02.13 |
[Chapter 6] 데이터 링크 계층(HDLC 프로토콜) (0) | 2025.02.13 |