컴퓨터네트워크 중간고사 대비용 정리

인터넷 프로토콜 및 아키텍처 심층 분석 보고서: 중간고사 대비

제 1부: 인터넷의 기초와 아키텍처

1장: 인터넷 아키텍처의 이해 (1-2차시)

1. 서론: 인터넷의 개념과 설계 철학

'인터넷(Internet)'은 단어의 어원('inter-'는 사이를, 'net'은 네트워크를 의미)에서 알 수 있듯이 '네트워크들의 네트워크(network of networks)'로 정의됩니다. 인터넷이 해결하고자 하는 근본적인 문제는 5G, Wi-Fi, 유선 이더넷처럼 서로 다른 기술로 구성된 네트워크 간의 비호환성입니다. 하나의 네트워크에 속한 호스트가 다른 기술을 사용하는 네트워크의 호스트와 통신할 수 있도록 하는 것이 인터넷 아키텍처의 핵심 과제이며, 이 원리를 이해하는 것이 전체 구조를 파악하는 첫걸음입니다.

네트워크 간의 비호환성을 해결하는 방법은 크게 두 가지로 나뉩니다. 첫 번째는 모든 네트워크 기술 쌍에 대해 번역기(translator)를 두는 방식이며, 두 번째는 모든 기술이 공통으로 이해할 수 있는 중간 매체(common middleware)를 사용하는 방식입니다. 인터넷은 후자의 방식을 채택했으며, 이 공통 미들웨어가 바로 인터넷 프로토콜(IP)입니다. 이 두 접근 방식의 차이점은 시험에 자주 출제되는 개념이므로 반드시 숙지해야 합니다.

접근 방식	번역기(Translator) 기반	공통 미들웨어(IP) 기반
개념	모든 네트워크 기술 쌍 (A↔B, A↔C, B↔C) 사이에 직접적인 변환기를 구현	모든 네트워크 기술이 공통의 중간 프로토콜(IP)로 변환
확장성	네트워크 기술의 수가 n개일 때, O(n²)의 복잡도를 가짐. 새로운 기술 추가 시 기존 모든 기술과의 변환기가 필요하여 확장성이 매우 낮음	새로운 기술은 IP와의 변환기만 구현하면 되므로 확장성이 우수
구현	각 기술 쌍에 맞는 하드웨어/소프트웨어 직접 구현	서로 다른 네트워크를 연결하는 IP 라우터(게이트웨이) 를 통해 구현됨

이러한 개념은 우편 시스템(Postal System) 에 비유할 수 있습니다. 전 세계 국가들은 서로 다른 주소 체계와 우편 봉투를 사용하지만, 국제 우편을 보낼 때는 영어 또는 불어로 주소를 특정 위치에 기재하는 공통의 약속(Common Data Format)을 따릅니다. 일단 목적지 국가에 도착하면, 그 나라의 우체부가 자국어 주소를 보고 배달을 완료하는 것처럼, 인터넷에서도 각기 다른 네트워크를 거칠 때마다 계층적인 처리(Layered Processing)가 이루어집니다.

이러한 배경 속에서 DARPA 인터넷 프로토콜은 다음과 같은 7가지 핵심 설계 목표를 가지고 개발되었습니다. 이 목표들은 중요도 순으로 나열되어 있으며, 인터넷의 근본적인 특성을 결정했습니다.

• 1. 생존성 (Survivability): 군사적 목적에서 출발했기에 최우선 목표는 일부 네트워크나 게이트웨이가 파괴되더라도 통신이 중단되지 않는 것이었습니다. 이를 위해 종단 간 원칙(End-to-End Principle) 과 운명 공유(Fate Sharing) 라는 개념이 도입되었습니다. 이 원칙에 따라, 통신 연결 상태(state) 정보는 중간 네트워크 노드(게이트웨이)가 아닌, 오직 통신 당사자인 양 끝단의 호스트에만 저장됩니다. 따라서 중간 경로에 장애가 발생해도 상태 정보는 보존되며, 다른 경로로 통신을 재개할 수 있습니다. 중간 노드들은 단순히 패킷을 목적지로 전달할 뿐, 특정 통신 세션을 기억하지 않는 '상태 없는(stateless)' 구조를 가집니다.
• 2. 다양한 서비스 유형 지원 (Multiple Service Types): 인터넷은 실시간 전화 통화, 비디오 스트리밍, 파일 전송(FTP), 인스턴트 메시징 등 다양한 특성을 가진 서비스를 지원해야 했습니다. 예를 들어, 실시간 전화는 지연에 민감하지만 약간의 데이터 손실은 감수할 수 있는 반면, 파일 전송은 데이터 손실에 매우 민감합니다. 이처럼 상이한 요구사항을 단일 전송 프로토콜(예: TCP)만으로는 모두 만족시킬 수 없었기에, 다양한 전송 프로토콜(TCP, UDP 등)을 지원하는 구조가 필요했습니다.
• 3. 다양한 네트워크 수용 (Accommodate Variety): 인터넷은 이더넷, Wi-Fi, 5G 등 기존에 존재하거나 미래에 등장할 그 어떤 네트워크 기술이라도 수용할 수 있어야 했습니다. 이는 "IP over anything, anything over IP"라는 원칙으로 요약됩니다. 모든 것을 IP 위에서 동작시키고, IP는 어떤 기술 위에서도 동작할 수 있게 하는 것입니다. 이로 인해 프로토콜 스택은 가운데 IP 계층이 잘록한 모래시계 형태, 즉 '좁은 허리(Narrow Waist)' 구조를 갖게 되었습니다. 이 구조는 혁신을 촉진했지만, '좁은 허리의 저주(The Curse of the Narrow Waist)' 라는 단점도 낳았습니다. 핵심인 IP 계층 자체를 바꾸기가 극도로 어려워져, IPv4의 주소 고갈 문제를 해결하기 위해 등장한 IPv6로의 전환이 수십 년째 더디게 진행되는 원인이 되었습니다.
• 4. 분산 관리 (Distributed Management): 인터넷은 중앙 관리 기관 없이 분산된 방식으로 관리될 수 있어야 했습니다. 이를 위해 단일 관리 주체에 의해 운영되는 네트워크 집단을 자율 시스템(Autonomous System, AS) 으로 정의했습니다. 각 AS는 독립적으로 내부 네트워크를 관리하며, AS 간의 연결은 외부 라우팅 프로토콜(Exterior Routing Protocol, ERP) 인 BGP(Border Gateway Protocol) 를 통해 이루어집니다.
• 5. 비용 효율성 (Cost-Effectiveness): 인터넷은 기존 전화망보다 비용 효율적이어야 했습니다. 이를 위해 패킷 교환(Packet Switching) 방식을 채택했습니다. 이는 전통적인 전화망의 회선 교환(Circuit Switching) 방식과 대조됩니다.
• 6. 용이한 호스트 연결 (Easy Host Attachment): 사용자가 새로운 장치를 인터넷에 쉽게 연결할 수 있어야 합니다. 이는 DHCP 등을 통한 자동 설정(Autoconfiguration) 기능으로 구현됩니다. 사용자가 네트워크에 접속하면 IP 주소, DNS 서버 주소 등의 필요 정보가 자동으로 할당되어 복잡한 설정 없이 즉시 인터넷을 사용할 수 있습니다.
• 7. 책임성 (Accountability): 사용된 자원의 양을 측정하고 과금(billing)하거나 사업자 간 사용료를 정산할 수 있어야 했습니다. 이는 상업적 운영을 위해 필수적인 기능으로, SNMP나 NETCONF와 같은 프로토콜이 자원 사용량을 모니터링하는 데 사용됩니다.

인터넷의 핵심 교환 방식인 패킷 교환과 전통적인 전화망의 회선 교환은 다음과 같은 차이점을 가집니다.

특징	패킷 교환 (Packet Switching)	회선 교환 (Circuit Switching)
연결 설정	연결 설정 과정 없음 (Store and Forward 방식)	통신 시작 전 고정된 경로 설정 필요
링크 유형	공유 (Shared Link)	전용 (Dedicated Link)
대역폭 사용	가용한 대역폭을 효율적으로 공유 (낭비 적음)	통신 시간 동안 대역폭 독점 (미사용 시 낭비)
지연 시간	가변적 (Variable Delay), 네트워크 혼잡도에 따라 변동	일정 (Constant Delay)
주요 사용 사례	인터넷	전통적인 전화망

결론적으로, 1장에서 여러분이 반드시 이해해야 할 핵심은 인터넷이 '상태 없는(stateless)' 중간 노드와 '지능적인(intelligent)' 종단 노드로 구성된 확장 가능한 아키텍처라는 점입니다. 이는 RFC1958 문서에 요약된 바와 같이 '연결성(connectivity)이 목표이고, IP가 그 도구이며, 지능은 종단(end-to-end)에 있다'는 원칙으로 귀결됩니다. 이상적으로는 인터넷 계층에 단 하나의 프로토콜(IP)만 존재하여 호환성을 극대화해야 하지만, IPv4에서 IPv6로의 전환과 같은 현실적인 이유로 현재는 두 개 이상의 프로토콜이 공존하고 있습니다. 이러한 고수준의 아키텍처 원칙은 통신 과정을 체계적으로 이해하기 위한 구체적인 계층화 모델로 형식화됩니다.

2. 프로토콜 계층화 모델: OSI 7계층과 TCP/IP 4계층

네트워크 통신이라는 복잡한 문제를 해결하기 위해, 인터넷 아키텍처는 '분할 정복(divide and conquer)' 전략에 기반한 프로토콜 계층화(Protocol Layering) 를 사용합니다. 이는 거대한 통신 과정을 여러 개의 단순하고 독립적인 작업으로 나누고, 각 작업을 별도의 프로토콜이 담당하도록 하는 방식입니다. 여기서 프로토콜이란 통신을 위해 송신자, 수신자, 그리고 모든 중간 장치가 따라야 하는 규칙의 집합으로, 다음 세 가지 핵심 요소를 정의합니다.

1. 메시지 포맷 (Message Format): 주고받는 데이터의 구조 (예: 헤더 형식)
2. 메시지 순서 (Message Order): 메시지를 주고받는 절차 (예: TCP의 3-way handshake)
3. 수신 시 행동 (Actions upon message reception): 특정 메시지를 받았을 때 수행해야 할 동작

계층 간의 통신은 서비스 접근점(Service Access Point, SAP) 을 통해 이루어지며, 각 계층에서 처리하는 데이터 단위를 프로토콜 데이터 유닛(Protocol Data Unit, PDU) 이라고 합니다. 상위 계층은 SAP를 통해 하위 계층에 서비스를 요청하고 데이터를 전달하며, 하위 계층은 이 데이터를 받아 자신의 헤더를 붙여 새로운 PDU를 만들어 다음 계층으로 전달합니다.

프로토콜 계층화는 다음과 같은 장단점을 가집니다.

• 장점: 각 프로토콜이 독립적인 모듈로 작동하여 수정 및 업데이트가 용이하며, 프로토콜 내부 구현을 몰라도 서비스를 사용할 수 있습니다(블랙박스화).
• 단점: 여러 계층으로 기능이 나뉘면서 동일한 작업(예: 오류 검사, 보안)이 중복될 수 있고, 전체적인 복잡도가 증가할 수 있습니다.

이러한 계층화 개념을 설명하는 대표적인 두 가지 모델이 있습니다.

ISO OSI 7계층 모델은 국제표준화기구(ISO)가 제정한 개념적 모델로, 통신에 필요한 기능들을 7개의 추상적인 계층으로 나누어 정의합니다. 이는 실무 구현 지침이라기보다는 '어떻게'가 아닌 '무엇을' 구현해야 하는지에 대한 이상적인 프레임워크를 제공한다는 점에서 중요합니다.

계층	PDU	핵심 기능
7. 응용 (Application)	데이터(Data)	사용자가 직접 상호작용하는 프로토콜 (예: HTTP, FTP, SMTP) 제공
6. 표현 (Presentation)	데이터(Data)	데이터의 표현 방식(인코딩), 암호화(Encryption), 압축(Compression) 담당
5. 세션 (Session)	데이터(Data)	데이터 전송의 시작, 종료, 동기화 등 통신 상태 관리
4. 전송 (Transport)	세그먼트(Segment)	프로세스 대 프로세스(Process-to-Process) 통신을 담당하며, 종단 간 신뢰성 있는 데이터 전송 보장
3. 네트워크 (Network)	패킷(Packet)	전체 인터넷 망에서 노드 대 노드(Node-to-Node) 통신을 담당. IP가 이 계층의 핵심 프로토콜
2. 데이터 링크 (Data Link)	프레임(Frame)	단일 링크(Single-link) 내에서의 통신을 담당. 프레임 정의 및 물리 주소(Naming/Addressing) 지정
1. 물리 (Physical)	비트(Bit)	비트(Bit) 단위의 물리적 전송을 담당. 비트를 심볼로 인코딩하고 전기적, 기계적 특성을 정의

TCP/IP 4계층 모델은 실제 인터넷에서 사용되는 프로토콜들의 집합(Internet Protocol Suite)을 설명하는 실용적인 모델입니다.

• 응용 계층 (Application Layer): HTTP, FTP, SMTP, DNS 등
• 전송 계층 (Transport Layer): TCP, UDP
• 네트워크/인터넷 계층 (Network/Internet Layer): IP, ICMP
• 링크 계층 (Link Layer): 이더넷, Wi-Fi, ARP 등

이 두 계층화 모델은 네트워크 통신을 이해하고 설계하는 데 필수적인 개념적 프레임워크 역할을 합니다. 다음 장에서는 이 프레임워크 내에서 각 계층이 어떻게 대상을 식별하고 주소를 지정하는지에 대해 자세히 살펴보겠습니다.

제 2부: 네이밍, 주소 지정 및 접근 방식

2장: 계층별 네이밍 및 주소 지정 체계 (3차시)

1. 서론: 계층화된 주소 지정의 중요성

TCP/IP 프로토콜 스택의 각 계층은 고유한 네이밍(naming) 및 주소 지정(addressing) 체계를 가집니다. 응용 계층의 사람이 읽기 쉬운 도메인 이름부터 링크 계층의 물리적인 하드웨어 주소에 이르기까지, 각 계층은 자신의 역할에 맞는 식별자를 사용합니다. 이처럼 관심사를 계층별로 분리하는 것은 인터넷의 모듈성과 확장성을 유지하는 근본적인 설계 원칙입니다.

• 응용 계층 (Application Layer):
  • 사용자 친화적인 식별자인 도메인 이름(Domain Name) 이나 URI(Uniform Resource Identifier) 를 사용합니다. 이를 통해 사용자는 복잡한 숫자 주소를 외울 필요 없이 'www.ietf.org'와 같은 직관적인 이름으로 리소스에 접근할 수 있습니다.
  • URI의 구문은 scheme ":" hier-part ["?" query] ["#" fragment] 형태로 정의됩니다. 예를 들어 http://www.ietf.org/rfc/rfc2396.txt에서 http는 스킴(scheme), www.ietf.org는 호스트(hier-part의 일부)를 나타냅니다.
  • 이러한 사람이 읽을 수 있는 이름은 DNS(Domain Name System) 를 통해 컴퓨터가 이해할 수 있는 기계 친화적인 IP 주소로 변환됩니다.
• 전송 계층 (Transport Layer):
  • 이 계층의 주소는 특정 호스트 내의 '어떤 응용 프로그램(프로세스)'인지를 식별합니다. 주소 단위는 엔드포인트(Endpoint) 라고 하며, 이는 <IP 주소, 포트 번호>의 쌍으로 구성됩니다.
  • TCP는 신뢰성 있는 연결 지향 서비스를 제공하며, 통신 세션을 4개의 값으로 구성된 4-튜플(4-tuple) 로 식별합니다: <로컬 IP 주소, 로컬 포트 번호, 원격 IP 주소, 원격 포트 번호>. 이 네 가지 값이 모두 일치해야 동일한 연결로 간주됩니다. 이 개념은 시험에 반드시 출제되므로 정확히 암기해야 합니다.
  • UDP는 비신뢰성 데이터그램 서비스를 제공하며, 단일 로컬 엔드포인트(<로컬 IP, 로컬 포트>)만을 사용하여 주소를 지정합니다. 데이터를 보낼 때는 매번 목적지 엔드포인트를 명시해야 합니다.
• 네트워크 계층 (Network Layer - IP):
  • 핵심 주소 단위는 IP 주소입니다. 이 계층의 주된 역할은 라우팅 알고리즘을 통해 패킷이 최종 목적지까지 도달하기 위한 다음 경로, 즉 넥스트 홉(Next Hop) 을 결정하는 것입니다.
  • 여기서 학생들이 가장 혼동하는 지점은 IP 계층이 링크 계층에 전달하는 상대방 주소가 패킷의 최종 목적지(peer IP address)가 아니라, 다음 단계에서 패킷을 수신할 넥스트 홉의 링크 계층 주소(peer link layer address) 라는 점입니다. 또한, IP 모듈 자체가 IP 주소를 갖는 것이 아니라, 호스트의 각 네트워크 인터페이스가 IP 주소를 갖는다는 점을 명확히 이해해야 합니다.
  • IP 모듈이 패킷을 수신하면 다음 절차를 따릅니다.
    1. 패킷의 목적지 IP 주소가 자신의 인터페이스 중 하나와 일치하는지 확인합니다.
    2. 일치하면, IP 헤더의 '프로토콜 번호' 필드(TCP는 6, UDP는 17)를 보고 해당 전송 계층 프로토콜(TCP 또는 UDP)로 패킷을 올립니다.
    3. 일치하지 않고, 해당 노드가 게이트웨이(라우터)라면 포워딩 테이블을 참조하여 넥스트 홉으로 패킷을 전달(forwarding)합니다.
    4. 일치하지도 않고 게이트웨이도 아니면, 패킷을 폐기(discard)합니다.
• 데이터 링크 계층 (Data Link Layer):
  • 데이터 링크 계층의 프레임은 일반적으로 목적지 주소 / 소스 주소 / 타입 / 데이터 / 프레임 체크 시퀀스로 구성됩니다.
  • 여기서 목적지 및 소스 주소 필드에는 링크 계층 주소(예: 이더넷의 MAC 주소)가 포함됩니다. '타입' 필드는 상위 계층 프로토콜이 무엇인지를 나타내며, IP의 경우 이 값은 16진수로 0x0800입니다.

이 계층화된 주소 체계에서 IP 주소 룩업(lookup)은 목적지 IP 주소의 네트워크 프리픽스(network prefix) 를 확인하여 이루어집니다. 만약 목적지의 네트워크 프리픽스가 자신과 같다면, 목적지는 동일한 로컬 네트워크 상에 있는 것입니다. 다르다면, 패킷을 외부 네트워크로 보내기 위해 기본 게이트웨이(default gateway) 로 전달해야 합니다.

이 과정에서 필수적인 프로토콜이 바로 주소 결정 프로토콜(Address Resolution Protocol, ARP) 입니다. 바로 위에서 설명한 네트워크 계층의 '넥스트 홉' 결정이 이론이라면, ARP는 로컬 링크 상에서 그 이론을 현실로 만들어주는 실질적인 메커니즘입니다. ARP는 동일한 로컬 네트워크 상에서 넥스트 홉의 IP 주소를 해당 장치의 물리적인 링크 계층 주소로 변환하는 역할을 수행합니다. 즉, IP 주소는 알지만 그 주소에 해당하는 하드웨어 주소를 모를 때, ARP가 "이 IP 주소를 가진 사람의 하드웨어 주소는 무엇입니까?"라고 물어보고 답을 얻어내는 것입니다.

이처럼 각 계층의 주소 지정 개념을 이해했다면, 다음으로는 프로그래머가 이러한 네트워크 통신 기능을 실제로 응용 프로그램에 구현하기 위해 사용하는 표준 인터페이스인 소켓 API에 대해 알아볼 차례입니다.

3장: 네트워크 소켓 API (4차시)

1. 서론: 네트워크 프로그래밍의 관문, 소켓 API

네트워크 소켓 API(Network Socket API)는 프로그래머가 네트워크를 인식하는 응용 프로그램을 만들 수 있도록 운영체제가 제공하는 표준화된 함수 집합입니다. 소켓 API는 복잡한 TCP/IP 스택의 내부 동작을 추상화하여, 프로그래머가 간단한 시스템 호출(system call)을 통해 네트워크 통신을 관리할 수 있게 해주는 관문 역할을 합니다.

소켓 API의 핵심 함수들은 다음과 같습니다. 각 함수는 통신 과정에서 특정한 역할을 수행합니다.

• int socket(int domain, int type, int protocol)
  • 목적: 통신을 위한 엔드포인트, 즉 '소켓'을 생성합니다.
  • 주요 파라미터:
    • domain: 프로토콜 체계(Protocol Family)를 지정합니다. IPv4의 경우 AF_INET을 사용합니다.
    • type: 서비스 유형을 지정합니다. 연결 지향형 TCP의 경우 SOCK_STREAM을, 비연결형 UDP의 경우 SOCK_DGRAM을 사용합니다.
    • protocol: 사용할 구체적인 프로토콜을 지정합니다. 보통 0으로 두면 type에 맞는 기본 프로토콜(TCP의 경우 IPPROTO_TCP, UDP의 경우 IPPROTO_UDP)이 자동으로 선택됩니다.
  • 역할: 이 함수는 네트워크 통신의 시작점으로, 성공 시 소켓을 가리키는 파일 디스크립터(정수 값)를 반환합니다.
• bind()
  • 목적: 생성된 소켓에 특정 로컬 IP 주소와 포트 번호를 할당(연결)합니다.
  • 역할: 주로 서버 측에서 사용됩니다. 서버는 클라이언트가 접속할 수 있도록 잘 알려진 특정 포트 번호(예: HTTP 서버의 80번 포트)를 사용해야 하므로, bind()를 통해 소켓을 해당 주소와 포트에 고정시킵니다.
• connect()
  • 목적: TCP 클라이언트가 서버에 연결을 요청하고 수립합니다.
  • 역할: 클라이언트가 connect()를 호출하면, 운영체제는 지정된 서버의 IP 주소와 포트로 TCP 연결(3-way handshake)을 시도합니다. 이때 클라이언트 측의 로컬 IP 주소와 포트 번호는 일반적으로 운영체제에 의해 자동으로 할당됩니다. 클라이언트는 특정 출발지 포트 번호에 얽매일 필요가 없으므로, 운영체제가 사용 가능한 임시 포트(ephemeral port)를 할당하도록 하는 것이 일반적입니다. 이는 서버의 잘 알려진 포트(well-known port)와 명확히 대조됩니다.
• listen()
  • 목적: TCP 서버가 들어오는 연결 요청을 받아들일 준비가 되었음을 운영체제에 알립니다.
  • 역할: 이 함수를 호출한 소켓은 '수동' 소켓이 되어 클라이언트의 연결 요청을 대기합니다. backlog 파라미터는 연결이 수락되기 전까지 대기할 수 있는 클라이언트의 최대 수를 지정합니다.
• accept()
  • 목적: listen()으로 대기 중인 TCP 서버가 실제 클라이언트의 연결 요청을 수락합니다.
  • 역할: accept() 함수는 대기 큐에서 연결 요청을 하나 꺼내어 새로운 연결을 수립하고, 이 연결 전용의 새로운 소켓을 생성하여 그 파일 디스크립터를 반환합니다. 기존의 listen() 소켓은 계속해서 다른 클라이언트의 연결을 기다립니다.
• send() / sendto()
  • 목적: 데이터를 전송합니다.
  • 역할:
    • send(): connect() 또는 accept()를 통해 연결이 수립된 TCP 소켓에서 사용됩니다. 목적지가 이미 정해져 있으므로 데이터만 보내면 됩니다.
    • sendto(): 비연결형인 UDP 소켓에서 사용됩니다. 매번 데이터를 보낼 때마다 목적지 주소를 명시해야 합니다.
• close()
  • 목적: 통신을 종료하고 소켓과 관련된 시스템 자원을 해제합니다.
  • 역할: 데이터 전송이 끝나면 이 함수를 호출하여 연결을 정상적으로 종료합니다.

TCP 통신에서 서버와 클라이언트의 일반적인 소켓 함수 호출 순서는 다음과 같습니다.

1. TCP 서버의 호출 순서
   1. socket(): 소켓 생성
   2. bind(): 특정 IP와 포트에 소켓 바인딩
   3. listen(): 클라이언트 연결 대기 시작
   4. accept(): 클라이언트 연결 수락 (새로운 통신용 소켓 생성)
   5. send() / recv(): 데이터 송수신
   6. close(): 연결 종료
2. TCP 클라이언트의 호출 순서
   1. socket(): 소켓 생성
   2. connect(): 서버에 연결 요청
   3. send() / recv(): 데이터 송수신
   4. close(): 연결 종료

지금까지 소켓 API가 통신을 '어떻게' 수행하는지에 대한 프로그래밍 인터페이스를 살펴보았습니다. 다음 장에서는 통신의 '무엇'을 식별하는지, 즉 응용 프로그램 수준의 네이밍과 이를 IP 주소로 변환하는 핵심 서비스인 DNS에 대해 더 깊이 탐구하겠습니다.

4장: 애플리케이션 네이밍과 DNS의 기초 (5차시)

1. 서론: 식별자와 위치 지정자

네트워크에서 '주소(address)'는 종종 두 가지 개념을 포함합니다. 하나는 '그것이 누구인가 또는 무엇인가'를 나타내는 식별자(Identifier) 이고, 다른 하나는 '그것이 어디에 있는가'를 나타내는 위치 지정자(Locator) 입니다. 예를 들어, 이메일 주소 user@domain.com에서 'user' 부분은 수신자의 식별자 역할을 하고, 'domain.com' 부분은 이메일 서버의 위치 지정자 역할을 합니다. 마찬가지로 URL http://www.ietf.org/rfc/rfc2396.txt에서 www.ietf.org는 서버의 위치 지정자, /rfc/rfc2396.txt는 해당 서버 내 파일의 식별자입니다.

인터넷 스택의 주소 체계는 뚜렷한 계층 구조를 보입니다. 응용 계층에서는 사람이 이해하기 쉬운 텍스트 기반의 주소(도메인 이름, 이메일 주소 등)를 사용하는 반면, 그 아래의 전송, 네트워크, 링크 계층에서는 기계가 처리하기 용이한 이진(binary) 주소(포트 번호, IP 주소, MAC 주소 등)를 사용합니다.

이러한 계층적 네이밍 시스템의 좋은 예로 국제 전화번호(ITU-T E.164) 표준을 들 수 있습니다. 이 구조를 이해하면 DNS의 계층적 구조를 파악하는 데 도움이 됩니다.

• 지리적 번호 (Geographic Number) 구조:
  • 국가 코드 (Country Code, CC): 특정 국가나 지역을 식별합니다 (예: 한국 82).
  • 국가 목적지 코드 (National Destination Code, NDC): 국가 내의 특정 지역이나 네트워크를 식별합니다 (예: 서울 02).
  • 가입자 번호 (Subscriber Number, SN): 최종 가입자를 식별합니다.
• 이동통신 번호 (Mobile Number) 구조:
  • 모바일 국가 코드 (Mobile Country Code, MCC): 국가를 식별합니다 (예: 한국 450).
  • 모바일 네트워크 코드 (Mobile Network Code, MNC): 통신 사업자를 식별합니다 (예: KT 04, SKT 05, LGU+ 06).
  • 모바일 스테이션 번호 (Mobile Station Number, MSN): 실제 가입자 번호(010-XXXX-XXXX)를 의미합니다. 우리가 휴대폰으로 본인 인증을 할 때 통신사(KT, SKT 등)를 선택해야 하는 이유가 바로 이 MNC 값을 채워 완전한 국제 식별 번호를 구성하기 위함입니다.

자, 이제 인터넷의 핵심 네이밍 시스템인 도메인 이름 시스템(Domain Name System, DNS) 에 대해 알아봅시다. 초창기 인터넷에서는 모든 호스트의 이름과 IP 주소 매핑 정보가 단 하나의 텍스트 파일(HOSTS.TXT)에 저장되었습니다. 네트워크가 폭발적으로 성장함에 따라 이 중앙 관리 방식은 심각한 확장성 문제에 부딪혔고, 이를 해결하기 위해 분산된 계층적 데이터베이스 시스템인 DNS가 개발되었습니다.

DNS의 핵심 설계 목표는 다음과 같습니다.

• 응용 프로그램 독립성 (Application Independence): DNS는 단순히 도메인 이름을 IP 주소로 변환하는 것 외에도, 다양한 종류의 정보를 저장할 수 있습니다. 각 정보에 '타입(type)' 태그(예: A, MX, CNAME)를 붙여, 웹 브라우저, 이메일 클라이언트 등 여러 응용 프로그램이 필요한 정보를 질의하고 얻을 수 있도록 합니다.
• 통신 시스템 독립성 (Communication System Independence): DNS는 하위 통신 프로토콜에 의존하지 않습니다. 따라서 IPv4와 IPv6 환경 모두에서 동일하게 작동하며, 미래에 새로운 네트워크 프로토콜이 등장하더라도 유연하게 대응할 수 있습니다.

DNS 네임스페이스의 구체적인 명세는 다음과 같습니다.

• 계층적 트리 구조: 네임스페이스는 루트(root) 노드에서 시작하는 트리 구조를 가집니다.
• 레이블(Label): 트리의 각 노드에는 0~63 옥텟(octet, 8비트) 길이의 레이블이 붙습니다. 이 레이블들을 점(.)으로 연결하여 도메인 이름을 형성합니다 (예: www.korea.ac.kr).
• 내부 표현: 내부적으로 레이블은 [길이 옥텟] + [문자열] 형태로 표현됩니다. 예를 들어 'korea'는 [0x05]korea와 같이 저장됩니다.
• 절대(Absolute) vs. 상대(Relative) 이름: 도메인 이름 끝에 점(.)이 있으면 루트부터의 전체 경로를 의미하는 '절대 이름'(www.korea.ac.kr.)이고, 점이 없으면 로컬 시스템 설정에 따라 완성되는 '상대 이름'입니다.
• 최대 길이: 전체 도메인 이름의 길이는 255 옥텟을 초과할 수 없습니다.
• 대소문자 미구분: 도메인 이름은 대소문자를 구분하지 않습니다 (WWW와 www는 동일하게 취급).

하나의 리소스는 여러 개의 이름을 가질 수 있습니다. 이 중 가장 기본이 되는 이름을 정식 이름(Canonical Name) 이라고 하고, 나머지를 별칭(Alias) 이라고 합니다. DNS에서는 CNAME 레코드 타입을 사용하여 별칭을 정식 이름에 매핑합니다.

네임스페이스의 최상위에는 최상위 도메인(Top-Level Domain, TLD) 이 존재합니다. TLD는 .com, .org와 같은 일반 최상위 도메인(gTLD) 과 .kr, .jp와 같은 국가 코드 최상위 도메인(ccTLD) 으로 나뉩니다. 또한, IP 주소를 도메인 이름으로 거꾸로 변환(reverse mapping)하는 특수 목적으로 .ARPA 도메인이 사용됩니다.

최근에는 '한글.kr'과 같이 영문 외의 문자를 사용하는 국제화 도메인 이름(Internationalized Domain Names, IDN) 이 등장했으며, 각 국가나 언어별로 허용되는 문자 집합은 IDN 테이블에 정의되어 있습니다.

지금까지 DNS의 기본 개념과 구조를 살펴보았습니다. 다음 장에서는 DNS가 실제로 어떻게 동작하는지, 즉 네임 서버, 리졸버, 리소스 레코드의 역할과 쿼리 메커니즘에 대해 더 깊이 파고들겠습니다.

5장: DNS의 동작 원리 및 쿼리 메커니즘 (6-7차시)

1. 서론: 분산 데이터베이스로서의 DNS

도메인 이름 시스템(DNS)은 전 세계에 흩어져 있는 수많은 서버들이 협력하여 운영되는 거대한 분산 데이터베이스 시스템입니다. DNS의 설계는 데이터의 즉각적인 업데이트나 일관성 보장보다는, 도메인 이름을 IP 주소로 빠르게 변환(lookup) 하는 것에 최우선 순위를 둡니다. 이를 위해 한 번 조회한 결과를 일정 시간 동안 저장해두는 로컬 캐싱(local caching) 을 광범위하게 사용합니다.

DNS는 크게 세 가지 주요 구성 요소로 이루어집니다.

1. 도메인 네임스페이스 (Domain Name Space): 앞서 설명한 계층적인 트리 구조의 데이터 자체입니다.
2. 네임 서버 (Name Servers): 이 데이터베이스의 일부를 저장하고 관리하는 서버 프로그램입니다.
3. 리졸버 (Resolvers): 사용자(클라이언트)의 요청을 받아 네임 서버에 질의(query)하는 클라이언트 측 프로그램입니다.

네임 서버는 특정 존(Zone), 즉 전체 도메인 네임스페이스의 특정 부분(예: korea.ac.kr 하위의 모든 도메인)에 대한 권한(Authority) 을 가집니다. 신뢰성을 높이기 위해 하나의 존은 여러 대의 중복 서버(redundant servers)에 의해 관리될 수 있습니다. 존 내부의 모든 데이터는 관리자가 텍스트 형식으로 작성하는 마스터 파일(master file) 에서 비롯됩니다.

존 내부의 데이터는 리소스 레코드(Resource Record, RR) 라는 단위로 저장됩니다. RR은 다음과 같은 표준 필드로 구성됩니다.

필드	설명
owner	이 RR이 속한 도메인 이름 (예: www.korea.ac.kr)
type	리소스의 종류 (예: A, CNAME, MX)
class	프로토콜 군. 거의 항상 인터넷을 의미하는 IN이 사용됨
TTL	Time To Live. 이 레코드가 캐시에 저장될 수 있는 최대 시간(초)
RDATA	실제 데이터. type에 따라 형식이 다름 (예: A 타입은 IPv4 주소)

인터넷(IN 클래스)에서 주로 사용되는 RR TYPE은 다음과 같습니다. 이 표는 시험에 자주 등장하므로 각 레코드의 용도를 명확히 알아두어야 합니다.

타입	전체 이름	RDATA 설명
A	Address	도메인 이름에 해당하는 32비트 IPv4 주소를 저장
CNAME	Canonical Name	별칭(Alias)을 정식 이름(Canonical Name)으로 매핑
MX	Mail Exchange	해당 도메인의 이메일을 처리하는 메일 서버의 이름과 우선순위를 저장
NS	Name Server	해당 존에 대한 권한을 가진 네임 서버의 이름을 저장
PTR	Pointer	IP 주소에 해당하는 도메인 이름을 저장 (역방향 조회에 사용)
SOA	Start of Authority	해당 존의 시작을 알리며, 존 관리 정보(관리자 이메일, 버전, 갱신 주기 등)를 포함

존은 하위 도메인에 대한 관리를 다른 네임 서버에 위임할 수 있는데, 이 위임 지점을 컷(cut) 이라고 합니다. 부모 존은 자식 존을 담당하는 네임 서버의 정보(NS 레코드)를 가지고 있습니다. 만약 위임받은 자식 존의 네임 서버 이름이 그 자식 존 내에 속해 있다면(예: ns1.example.com이 example.com 존을 관리), 부모 존은 ns1.example.com의 IP 주소(A 레코드)를 추가로 가지고 있어야 합니다. 이 추가 정보를 글루 데이터(glue data) 라고 하며, 이는 순환 참조 문제를 막기 위해 필수적입니다.

DNS 쿼리 방식은 크게 두 가지로 나뉩니다.

• 반복적 쿼리 (Iterative Query): 이것이 기본(default) 방식입니다. 리졸버(클라이언트)가 네임 서버에 질의하면, 해당 서버는 자신이 아는 최선의 정보, 즉 더 정확한 정보를 줄 수 있는 다른 네임 서버의 주소(referral)를 알려줍니다. 그러면 리졸버는 다시 그 다른 네임 서버에 직접 질의해야 합니다. 이 과정을 최종 답을 얻을 때까지 반복합니다.
• 재귀적 쿼리 (Recursive Query): 리졸버가 네임 서버에 재귀적 쿼리를 요청하면, 그 네임 서버는 리졸버를 대신하여 필요한 모든 반복적 쿼리를 수행하고 최종 결과만을 리졸버에게 돌려줍니다. 이 모드는 쿼리 메시지의 RD(Recursion Desired) 비트를 1로 설정하여 요청하며, 서버는 응답 메시지의 RA(Recursion Available) 비트를 통해 재귀적 쿼리 지원 가능 여부를 알립니다.

DNS 메시지는 다음과 같은 다섯 개의 섹션으로 구성됩니다.

• 헤더 (Header): 메시지의 전반적인 정보를 담습니다.
• 질문 (Question): 서버에게 묻는 질문 내용(도메인 이름, 타입 등)을 담습니다.
• 답변 (Answer): 질문에 대한 직접적인 답이 되는 RR을 담습니다.
• 권한 (Authority): 권한 있는 다른 네임 서버를 가리키는 NS 레코드를 담습니다.
• 추가 정보 (Additional): 답변이나 권한 섹션의 정보를 보조하는 RR(예: 네임 서버의 IP 주소)을 담습니다.

DNS 헤더의 주요 필드는 다음과 같습니다.

• QR: 0이면 쿼리, 1이면 응답.
• Opcode: 쿼리의 종류 (0은 표준 쿼리).
• AA: Authoritative Answer. 응답하는 서버가 해당 도메인에 대한 권한을 가질 경우 1로 설정.
• TC: TrunCation. 메시지가 너무 길어 잘렸음을 의미.
• RD: Recursion Desired. 클라이언트가 재귀적 쿼리를 원할 경우 1로 설정.
• RA: Recursion Available. 서버가 재귀적 쿼리를 지원할 경우 1로 설정.
• RCODE: 응답 코드. 0이면 오류 없음.
• 4개의 COUNT 필드: 질문, 답변, 권한, 추가 정보 섹션에 포함된 레코드의 수를 각각 나타냅니다.

DNS는 통신에 UDP와 TCP를 모두 사용합니다. 일반적인 쿼리는 오버헤드가 적은 UDP (포트 53)를 사용하는 것이 선호됩니다. 하지만 응답 메시지의 크기가 512바이트를 초과하거나, 존 전체 데이터를 전송(zone transfer)해야 하는 경우에는 신뢰성 있는 TCP가 사용됩니다.

DNS 응답 예시를 분석해보면, USC-ISIC.ARPA의 A 레코드(IP 주소)를 묻는 쿼리에 대한 응답에서 Answer 섹션은 두 개의 RR을 포함할 수 있습니다. 첫 번째는 USC-ISIC.ARPA가 C.ISI.EDU의 별칭임을 알리는 CNAME 레코드이고, 두 번째는 그 정식 이름인 C.ISI.EDU의 IP 주소를 담고 있는 A 레코드입니다. 이처럼 DNS는 사용자가 원하는 정보를 효율적으로 얻을 수 있도록 관련 정보를 함께 제공합니다.

결론적으로, DNS는 응용 계층의 사람이 읽을 수 있는 이름을 기계가 이해하는 주소로 변환해주는 인터넷의 필수적인 번역 서비스입니다. 이제 다음 부에서는 이 IP 주소와 그 하위 계층의 주소 지정 방식에 대해 본격적으로 다루겠습니다.

제 3부: 핵심 네트워크 프로토콜

6장: 전송 계층 및 네트워크 계층 주소 지정 (IPv4) (8차시)

1. 서론: IP 주소와 포트 번호의 결합

전송 계층과 네트워크 계층은 긴밀하게 협력하여 통신을 완성합니다. 네트워크 계층이 호스트 대 호스트(host-to-host) 통신을 위한 IP 주소를 제공한다면, 전송 계층은 특정 호스트 내의 응용 프로그램 프로세스를 식별하기 위한 포트 번호를 제공합니다. 이 둘의 조합, 즉 <IP 주소, 포트 번호>는 특정 호스트의 특정 응용 프로그램을 가리키는 완전한 주소인 엔드포인트(endpoint) 를 형성합니다.

전송 계층(Transport Layer) 주소 지정의 세부 사항은 다음과 같습니다.

• 주소 구조: TCP 통신 세션은 4개의 값으로 구성된 4-튜플(4-tuple) 로 식별됩니다: <로컬 IP 주소, 로컬 포트 번호, 원격 IP 주소, 원격 포트 번호>. 반면, UDP 통신은 단일 로컬 엔드포인트(<로컬 IP, 로컬 포트>)로 식별됩니다.
• 유사 IP 헤더 (Pseudo IP Header): TCP와 UDP는 데이터 무결성을 검사하기 위한 체크섬(checksum)을 계산할 때 실제 데이터뿐만 아니라 '유사 IP 헤더'라는 가상의 헤더 정보를 포함합니다. 이 헤더에는 IP 헤더에서 가져온 출발지/목적지 IP 주소, 프로토콜 번호, 그리고 TCP/UDP 길이가 포함되어, 패킷이 올바른 목적지에 정확한 프로토콜로 전달되었는지를 추가로 검증하는 역할을 합니다.
• 프로토콜 번호: IANA(Internet Assigned Numbers Authority)는 상위 계층 프로토콜을 식별하기 위해 고유 번호를 할당합니다. 대표적으로 ICMP는 1번, TCP는 6번, UDP는 17번입니다.
• 포트 번호 범위: IANA는 16비트 포트 번호 공간(0~65535)을 세 가지 범위로 나누어 관리합니다.

포트 범위 유형	숫자 범위 (10진수)	설명
시스템 포트 (Well-known Ports)	0 ~ 1023	잘 알려진 특정 서비스를 위해 IANA가 할당한 포트 (예: HTTP 80, FTP 21)
사용자 포트 (Registered Ports)	1024 ~ 49151	특정 응용 프로그램을 위해 IANA에 등록하여 사용하는 포트 (예: 보조 HTTP 8080)
임시 포트 (Ephemeral Ports)	49152 ~ 65535	동적/사설 포트로, 클라이언트가 연결을 시작할 때 운영체제가 동적으로 할당하는 임시 포트

이제 네트워크 계층(Network Layer)의 IPv4 주소 지정에 대해 살펴보겠습니다.

• 주소 할당(Allocation) vs. 배정(Assignment): 주소 블록이 IANA나 지역 인터넷 레지스트리(RIR)에서 인터넷 서비스 제공자(ISP)에게 넘어가는 것을 '할당'이라 하고, ISP가最终 사용자에게 주소를 주는 것을 '배정'이라고 구분합니다.
• 클래스 기반 주소 지정 (Classful Addressing): 초기의 IPv4 주소 체계는 주소의 첫 몇 비트를 보고 네트워크 부분과 호스트 부분을 구분하는 클래스(A, B, C, D, E) 기반이었습니다.

클래스	시작 비트	네트워크 프리픽스 길이	첫 옥텟 10진수 범위
A	0	8 bits	0 ~ 127
B	10	16 bits	128 ~ 191
C	110	24 bits	192 ~ 223
D	1110	해당 없음	224 ~ 239 (멀티캐스트용)
E	1111	해당 없음	240 ~ 255 (예약됨/사용 불가)

• 서브네팅 (Subnetting): A, B, C 클래스 할당 방식은 심각한 주소 낭비 문제를 낳았습니다. 예를 들어, 수백 개의 호스트만 필요한 조직이 65,000개 이상의 주소를 갖는 B 클래스를 통째로 할당받는 것은 매우 비효율적이었죠. 이 문제를 해결하기 위해 등장한 것이 바로 서브네팅입니다. 서브네팅은 할당받은 하나의 큰 네트워크를 주소 마스크(address mask) 를 이용해 여러 개의 작은 하위 네트워크(subnet)로 나누어 효율적으로 관리하는 기술입니다. 이는 다양한 기술 사용, 물리적 거리 제한, 혼잡 완화, 지리적 분리 등의 이유로 필요했습니다.
• 슈퍼네팅 (Supernetting): B 클래스 주소가 고갈되자, 여러 개의 연속된 C 클래스 주소 블록을 하나로 묶어 더 큰 네트워크처럼 사용하는 슈퍼네팅이 임시 해결책으로 등장했습니다. 이는 주소 집약(aggregation)을 통해 라우팅 테이블의 크기를 줄이는 효과도 가져왔습니다.

클래스 없는 인터도메인 라우팅 (CIDR)

클래스 기반 주소 지정 방식의 문제점들(B 클래스 고갈, 라우팅 테이블 급증, IPv4 주소 고갈)을 근본적으로 해결하기 위해 CIDR(Classless Inter-Domain Routing) 가 도입되었습니다.

• CIDR 표기법: CIDR은 클래스 개념을 폐기하고, IP 주소 뒤에 슬래시(/)와 네트워크 프리픽스의 비트 길이를 명시하는 방식을 사용합니다 (예: 162.152.161.179/24). 이는 주소 마스크가 255.255.255.0임을 의미하며, 처음 24비트가 네트워크 부분임을 명확히 합니다.
• 최장 프리픽스 일치 (Longest Prefix Matching): CIDR 환경에서 라우터는 패킷의 목적지 주소와 라우팅 테이블의 여러 항목을 비교하여, 네트워크 프리픽스 부분이 가장 길게 일치하는 경로로 패킷을 전송합니다. 이는 라우팅의 가장 기본적인 규칙입니다.

특수 IPv4 주소

특정한 목적을 위해 예약되었거나 사용에 제약이 있는 IPv4 주소들이 있습니다.

• 0.0.0.0: "이 네트워크 상의 이 호스트"를 의미합니다. 일반적으로 호스트가 자신의 IP 주소를 아직 할당받지 못한 초기화 단계(예: DHCP 요청)에서 출발지 주소로만 사용될 수 있습니다.
• 255.255.255.255: 제한된 브로드캐스트(Limited Broadcast) 주소입니다. 이 주소를 목적지로 하는 패킷은 동일한 로컬 링크 내의 모든 호스트에게 전송되며, 라우터를 넘어가지 않습니다.
• {<네트워크-프리픽스>, -1}: 지향성 브로드캐스트(Directed Broadcast) 주소입니다. 특정 네트워크(프리픽스로 지정된) 내의 모든 호스트에게 보내는 브로드캐스트입니다 (예: 192.168.1.255는 192.168.1.0/24 네트워크 전체에 보내는 브로드캐스트). 하지만 현재는 보안상의 이유(예: Smurf 공격)로 대부분의 라우터에서 이 기능을 비활성화합니다.
• 127.0.0.0/8: 루프백(Loopback) 주소 범위입니다. 호스트가 자기 자신과 통신하기 위해 사용하며(주로 127.0.0.1), 이 주소를 가진 패킷은 네트워크 외부로 나가지 않습니다.

사설 주소 공간 (RFC1918)

IPv4 주소 고갈 문제를 완화하기 위해, 인터넷에 직접 연결되지 않는 내부 네트워크(private network)에서 자유롭게 사용할 수 있는 사설 주소 공간이 예약되었습니다.

• 10.0.0.0/8 (10.0.0.0 ~ 10.255.255.255)
• 172.16.0.0/12 (172.16.0.0 ~ 172.31.255.255)
• 192.168.0.0/16 (192.168.0.0 ~ 192.168.255.255)

이 주소들은 인터넷 상에서 라우팅되지 않으므로, 사설 주소를 사용하는 호스트가 공용 인터넷과 통신하기 위해서는 반드시 공인 IP 주소로 변환해주는 NAT(Network Address Translation) 기술이 필요합니다.

지금까지 정적인 IP 주소의 구조와 할당 원칙을 살펴보았습니다. 다음 장에서는 이러한 주소를 호스트에 동적으로 자동 할당해주는 프로토콜인 DHCP에 대해 알아보겠습니다.

7장: 동적 호스트 설정 (BOOTP & DHCP) (9차시)

1. 서론: IP 주소의 자동 할당

네트워크에 연결되는 장치가 늘어나고 이동성이 중요해지면서, 각 장치에 수동으로 IP 주소를 설정하는 것은 비효율적이고 오류 발생 가능성이 높습니다. 이러한 관리 부담을 줄이고 사용자 편의성을 높이기 위해 IP 주소 및 기타 네트워크 설정을 자동으로 구성해주는 프로토콜이 필요해졌습니다. 그 초기 형태가 BOOTP이며, 이를 확장하여 강력한 기능을 제공하는 것이 바로 DHCP입니다. DHCP는 BOOTP와 하위 호환성을 유지하며 오늘날 가장 널리 사용됩니다.

부트스트랩 프로토콜 (BOOTP)

BOOTP는 본래 디스크가 없는 워크스테이션이 부팅 시 자신의 IP 주소와 부팅 이미지 파일의 위치를 서버로부터 받아오기 위해 설계되었습니다. 이 과정은 두 단계로 구성되지만, 현재는 주로 IP 주소 할당을 위한 첫 번째 단계만 사용됩니다.

• 동작 방식: 클라이언트-서버 모델을 기반으로 하며, UDP 프로토콜을 사용합니다. 클라이언트는 포트 68번, 서버는 포트 67번을 사용합니다.
• 메시지 포맷: 요청(Request)과 응답(Reply) 메시지가 동일한 포맷을 공유하는 단순한 구조를 가집니다.

필드	기능
op	동작 코드. 1은 요청(BOOTREQUEST), 2는 응답(BOOTREPLY).
xid	트랜잭션 ID. 요청과 응답을 짝짓기 위해 클라이언트가 생성하는 임의의 값.
ciaddr	클라이언트 IP 주소. 클라이언트가 이미 주소를 알고 있을 경우 사용, 모를 경우 0.0.0.0.
yiaddr	'당신의' IP 주소. 서버가 클라이언트에게 할당하는 IP 주소.
siaddr	서버 IP 주소. 부팅 이미지를 제공하는 TFTP 서버의 주소 (현재는 거의 사용 안 함).
giaddr	게이트웨이 IP 주소. 클라이언트와 서버가 다른 서브넷에 있을 때 요청을 중계하는 릴레이 에이전트(게이트웨이) 의 주소.
chaddr	클라이언트 하드웨어(MAC) 주소.
vend	벤더 특정 옵션 영역. 추가 설정 정보를 담음.

로컬 서브넷에 BOOTP 서버가 없는 경우, 게이트웨이가 릴레이 에이전트 역할을 수행합니다. 게이트웨이는 클라이언트의 브로드캐스트 요청을 수신하여 자신의 IP 주소를 giaddr 필드에 채운 뒤, BOOTP 서버로 유니캐스트 포워딩합니다. 서버는 giaddr를 보고 응답을 해당 게이트웨이로 보내 클라이언트에게 전달되도록 합니다.

vend 필드에는 추가적인 설정 정보(옵션)가 포함됩니다. 옵션의 시작은 '매직 쿠키'(99.130.83.99) 라는 특정 4바이트 값으로 식별되며, 각 옵션은 TLV(Tag-Length-Value) 구조를 따릅니다. 예를 들어, 서브넷 마스크 옵션은 태그 1, DNS 서버 옵션은 태그 6을 사용합니다.

동적 호스트 설정 프로토콜 (DHCPv4)

자, 이제 DHCP가 BOOTP를 어떻게 확장했는지 구체적으로 살펴봅시다. 가장 큰 차이점은 주소 할당에 '임대(lease)' 개념을 도입한 것입니다. DHCPv4는 세 가지 IP 주소 할당 메커니즘을 제공합니다.

1. 자동 할당 (Automatic Allocation): 클라이언트에게 영구적인 IP 주소를 할당합니다.
2. 동적 할당 (Dynamic Allocation): DHCP의 핵심 기능으로, IP 주소를 특정 시간 동안만 임대(lease) 해줍니다. 이를 통해 사용하지 않는 IP 주소를 회수하여 다른 클라이언트에게 재할당할 수 있어 주소 자원을 효율적으로 관리할 수 있습니다.
3. 수동 할당 (Manual Allocation): 관리자가 특정 하드웨어 주소에 특정 IP 주소를 미리 고정 할당해 둡니다.

새로운 클라이언트가 IP 주소를 할당받는 과정은 일반적으로 4단계(D-O-R-A)로 이루어집니다.

1. DHCPDISCOVER (발견): 클라이언트는 자신의 MAC 주소를 담아 로컬 네트워크에 브로드캐스트하여 DHCP 서버를 찾습니다.
2. DHCPOFFER (제안): DHCPDISCOVER를 수신한 DHCP 서버들은 클라이언트에게 할당해 줄 IP 주소, 임대 시간 등의 정보를 담아 DHCPOFFER 메시지를 보냅니다.
3. DHCPREQUEST (요청): 클라이언트는 여러 개의 DHCPOFFER 중 하나를 선택하고, "이 서버로부터 이 IP 주소를 사용하겠습니다"라는 의미의 DHCPREQUEST 메시지를 다시 브로드캐스트합니다. 이는 선택된 서버에게는 공식적인 요청이 되고, 선택되지 않은 다른 서버들에게는 제안이 거절되었음을 알리는 역할을 합니다.
4. DHCPACK (확인): 요청을 받은 서버는 주소 할당을 확정하고, 최종 임대 정보와 기타 설정(게이트웨이, DNS 서버 등)을 담은 DHCPACK 메시지를 보냅니다. 이 메시지를 받은 클라이언트는 비로소 IP 주소 설정을 완료합니다.

이 외에도 다음과 같은 주요 DHCP 메시지들이 있습니다.

• DHCPNAK: 서버가 클라이언트의 요청을 거절할 때 사용합니다.
• DHCPDECLINE: 클라이언트가 할당받은 주소가 이미 다른 장치에서 사용 중임을 감지했을 때(IP 충돌), 서버에 이를 알리기 위해 사용합니다.
• DHCPRELEASE: 클라이언트가 IP 주소를 더 이상 사용하지 않고 정상적으로 반납할 때 사용합니다.
• DHCPINFORM: 클라이언트가 이미 IP 주소를 가지고 있지만, DNS 서버 주소 등 추가적인 옵션 정보만 요청할 때 사용합니다.

IP 주소 임대 기간을 연장하기 위해, 클라이언트는 두 개의 타이머, T1(갱신 시간) 과 T2(재연결 시간) 를 사용합니다. 임대 기간의 약 50%가 지나 T1에 도달하면, 클라이언트는 자신에게 주소를 할당해 준 서버에게 유니캐스트로 임대 연장을 요청하는 RENEWING 상태가 됩니다. 만약 T1 연장에 실패하여 임대 기간의 약 87.5%인 T2에 도달하면, 클라이언트는 모든 DHCP 서버를 대상으로 브로드캐스트하여 임대 연장을 요청하는 REBINDING 상태가 됩니다.

DHCP는 BOOTP 옵션을 확장하여 다음과 같은 고유 옵션들을 사용합니다.

• DHCP 메시지 타입 (코드 53): DISCOVER(1), OFFER(2), REQUEST(3), ACK(5) 등 메시지의 종류를 명시합니다.
• 서버 식별자 (코드 54): DHCPOFFER 또는 DHCPACK 메시지를 보낸 서버의 IP 주소를 나타냅니다.
• IP 주소 임대 시간 (코드 51): IP 주소를 사용할 수 있는 시간(초)입니다.
• 갱신 (T1) 시간 (코드 58): 임대 기간 갱신을 시도해야 하는 시간입니다.
• 재연결 (T2) 시간 (코드 59): 갱신 실패 시 재연결을 시도해야 하는 시간입니다.

DHCP는 네트워크 계층의 구성을 자동화하여 관리의 복잡성을 크게 줄여줍니다. 이제 마지막으로, 이렇게 설정된 IP 주소를 가지고 로컬 링크 상에서 실제 통신을 하기 위해 필요한 링크 계층 주소와의 변환 과정에 대해 살펴보겠습니다.

8장: 링크 계층 주소 지정 및 주소 결정 프로토콜 (ARP) (10-11차시)

1. 서론: 로컬 링크에서의 최종 주소 해석

IP 주소를 할당받았다고 해서 즉시 통신이 가능한 것은 아닙니다. 이더넷이나 Wi-Fi와 같은 로컬 네트워크 상에서 데이터를 직접 전송하려면, 패킷을 수신할 장치의 물리적인 링크 계층 주소(Link Layer Address) 를 알아야 합니다. IP 주소가 인터넷 전체에서 사용되는 논리적 주소라면, 링크 계층 주소는 동일한 물리적 네트워크 세그먼트 내에서 통신 대상을 최종적으로 식별하는 하드웨어 주소입니다. ARP(주소 결정 프로토콜) 는 이 두 주소 체계 사이의 마지막 간극을 메워주는 필수적인 메커니즘입니다.

파트 1: 링크 계층 주소 지정

링크 계층 주소에는 크게 두 가지 유형이 있습니다.

1. 이더넷 주소 (MAC-48): 1982년 제정된 초기 이더넷 표준(Ethernet II)에서 사용된 48비트 주소입니다.
2. IEEE 802 주소 (EUI-48, EUI-64): IEEE에서 표준화한 48비트(EUI-48) 또는 64비트(EUI-64) 주소입니다. EUI-48과 MAC-48은 비트 수는 같지만, 비트를 해석하는 방식에 차이가 있어 서로 다른 값으로 취급됩니다.

이더넷 II 프레임은 목적지 주소 / 소스 주소 / 타입 / 데이터 / FCS 구조를 가집니다. 여기서 이더넷 주소의 전송 방식은 독특합니다. 주소를 16진수로 표기할 때는 MSB(Most Significant Bit)부터 표기하지만, 실제 네트워크로 전송할 때는 각 옥텟(8비트) 내에서 LSB(Least Significant Bit)부터 거꾸로 전송합니다.

• 예시: F0-2E-15-6C-77-9B
  • F0의 이진 표현: 1111 0000
  • 2E의 이진 표현: 0010 1110
  • 실제 전송 순서: 0000 1111 0111 0100 ... (각 옥텟의 비트 순서가 뒤집힘)

IEEE 802 주소는 다음과 같은 특징을 가집니다.

• 표기법: AC-DE-48-00-00-80과 같이 하이픈으로 구분하는 16진수 텍스트 표현(hexadecimal textual representation) 과, 이더넷 전송 순서에 맞춰 비트를 뒤집어 콜론으로 구분하는 비트 반전 표현(bit-reversed representation) (35:7B:12:00:00:01)이 있습니다.
• 특수 비트: 전송되는 첫 두 비트는 특별한 의미를 가집니다.
  • I/G 비트 (Individual/Group): 첫 번째로 전송되는 비트. 0이면 개별(유니캐스트) 주소, 1이면 그룹(멀티캐스트/브로드캐스트) 주소입니다. M 비트라고도 합니다.
  • U/L 비트 (Universal/Local): 두 번째로 전송되는 비트. 0이면 IEEE에 의해 전 세계적으로 고유하게 할당된 주소(Universal), 1이면 로컬 네트워크 내에서 관리자가 임의로 할당한 주소(Local)를 의미합니다. EUI-48과 MAC-48의 중요한 차이점 중 하나가 바로 이 비트의 해석에 있습니다.

링크 계층에서는 상위 계층 프로토콜을 식별하는 방법도 프레임 종류에 따라 다릅니다. 이더넷 프레임의 특정 필드가 '타입'으로 해석될지 '길이'로 해석될지에 따라 구분됩니다.

프레임 종류	구분 기준 (타입/길이 필드 값)	상위 프로토콜 식별 방법
이더넷 프레임 (EPD 방식)	1536 (0x0600) 이상	EtherType 필드에 상위 프로토콜의 고유 값(예: IPv4는 0x0800)을 직접 명시
CSMA/CD 프레임 (LPD 방식)	1500 이하	해당 필드를 Length로 해석하고, 데이터 부분에 비효율적인 구조의 LPD/SNAP 헤더를 추가하여 프로토콜을 식별

LPD/SNAP 헤더가 비효율적인 이유는 명확합니다. 실무에서는 이 헤더가 AA AA 03 이라는 고정된 3바이트 값과, 거의 항상 00 00 00 으로 채워지는 3바이트 OUI 값을 포함하여 총 6바이트의 불필요한 오버헤드를 발생시키기 때문입니다. 이 점을 기억하면 LPD 방식의 단점을 쉽게 이해할 수 있습니다.

파트 2: 주소 결정 프로토콜 (ARP)

ARP의 핵심 목적은 동일한 로컬 네트워크 상에서, 통신하고자 하는 대상의 IP 주소를 그에 해당하는 링크 계층 주소로 동적으로 변환하는 것입니다. 이 변환 결과는 ARP 캐시라는 메모리 공간에 일정 시간 동안 저장되어 반복적인 요청을 피합니다.

ARP는 간단한 요청(Request)/응답(Reply) 메시지 구조를 가집니다. 대상의 링크 계층 주소를 모르기 때문에, ARP 요청 메시지는 링크 계층의 브로드캐스트 주소(ff:ff:ff:ff:ff:ff) 를 목적지로 하여 해당 네트워크의 모든 장치에 전송됩니다.

하나의 ARP 메시지는 근본적으로 두 가지 기능을 동시에 수행합니다.

1. 주장 (Assertion): 메시지를 보내는 장치는 자신의 IP 주소(ar$spa)와 하드웨어 주소(ar$sha)를 명시함으로써, "나는 이 IP 주소와 이 하드웨어 주소를 사용합니다"라고 네트워크에 주장합니다.
2. 질문 (Question): 대상 IP 주소(ar$tpa)를 명시함으로써, "이 IP 주소를 사용하는 장치의 하드웨어 주소는 무엇입니까?"라고 질문합니다.

ARP는 기본적인 주소 변환 외에도 다음과 같은 고급 기능을 위해 확장되었습니다.

• 충돌 감지 (Conflict Detection): DHCP 클라이언트와 같이 IP 주소를 새로 할당받은 호스트는, 주소를 사용하기 전에 해당 주소가 이미 사용 중인지 확인해야 합니다. 이를 위해 자신의 IP 주소 필드를 0.0.0.0으로 설정하고 대상 IP 주소 필드에 할당받은 주소를 넣어 ARP 탐색(ARP Probe) 요청을 보냅니다. 만약 응답이 온다면, 이는 주소 충돌을 의미합니다.
• ARP 공지 (Gratuitous ARP): 호스트가 IP 주소 설정을 완료하면, 자신의 IP 주소를 출발지와 목적지 모두에 설정한 ARP 메시지를 브로드캐스트합니다. 이를 수신한 이웃 장치들은 자신의 ARP 캐시에 있는 해당 IP 주소에 대한 정보를 새로운 하드웨어 주소로 즉시 갱신할 수 있습니다.
• 프록시 ARP (Proxy ARP): '마법 상자(magic box)'처럼 동작하는 라우터가 다른 네트워크 세그먼트에 있는 호스트를 대신하여 ARP 요청에 응답하는 기술입니다. 라우터는 요청된 IP 주소에 대해 자신의 하드웨어 주소를 응답으로 보내고, 이후 해당 호스트로 가는 패킷을 대신 받아 전달해 줍니다. 이는 마치 라우터가 해당 IP를 소유한 것처럼 행동하므로, IP 스푸핑(spoofing)과 유사한 보안 문제를 야기할 수 있어 현재는 잘 사용되지 않습니다.
• ARP 캐시 유효성 검사 (ARP Cache Validation): ARP 캐시의 정보가 오래되어 유효하지 않게 되는 것을 방지하기 위해, 다음과 같은 메커니즘들이 사용됩니다.
  1. 타임아웃 (Timeout): 일정 시간이 지나면 캐시 항목을 자동으로 삭제합니다.
  2. 유니캐스트 폴링 (Unicast Poll): 캐시 항목이 유효한지 확인하기 위해 대상에게 유니캐스트로 ARP 요청을 보내고, 응답이 없으면 삭제합니다.
  3. 링크 계층 조언 (Link-Layer Advice): 링크 계층에서 데이터 전송 실패가 감지되면 해당 캐시 항목을 무효화합니다.
  4. 상위 계층 조언 (Higher-Layer Advice): IP나 TCP 같은 상위 계층에서 통신 문제를 감지하면 ARP 캐시를 무효화하도록 요청합니다.

응용 프로그램의 도메인 이름에서 시작하여 DNS를 통해 IP 주소를 얻고, 최종적으로 로컬 링크에서 ARP를 통해 물리적인 하드웨어 주소를 찾아내기까지의 과정은 인터넷 통신 전반을 아우르는 여정입니다. ARP는 이 여정의 마지막 단계를 책임지는 매우 중요한 프로토콜로서, 이 보고서에서 다룬 종단 간 통신 프로세스를 완성시킵니다.

---

* 이 보고서는 수업 듣고 요약한 필기를 기반으로 해 Google NotebookLM 인공지능으로 생성한 보고서입니다