[CS] 인터넷 네트워크와 핵심 개념 정리: IP, TCP/UDP, PORT, DNS

우리는 웹 브라우저나 모바일 애플리케이션을 통해 끊임없이 서버와 데이터를 주고받습니다. 클라이언트가 요청(Request)을 보내고 서버가 응답(Response)을 주는 이 일련의 과정은 개발자에게는 너무나 익숙한 루틴입니다. 하지만 단순히 API를 호출하고 응답받는 것을 넘어, "실제로 데이터가 어떤 규칙과 경로를 통해 목적지까지 도달하는가?"에 대한 이해는 시스템의 안정성과 성능을 고민하는 단계에서 필수적인 역량이 됩니다.

인터넷(Internet)은 수많은 컴퓨터가 거미줄처럼 연결된 거대한 네트워크망입니다. 이 복잡한 망 속에서 데이터가 유실되지 않고 정확한 목적지를 찾아가기 위해서는 약속된 규칙, 즉 프로토콜(Protocol)이 필요합니다.

이번 포스팅에서는 인터넷 통신을 지탱하는 실제 기술 용어들을 중심으로 인터넷 네트워크의 핵심 개념을 정리해보려 합니다.

1. 인터넷 통신 (Internet Communication)

1-1. 인터넷(Internet)의 정의와 노드(Node) 간 연결

인터넷은 'Inter-network'라는 단어에서 유래했듯이, 전 세계의 작은 네트워크들이 서로 연결되어 형성된 거대한 네트워크의 집합체입니다.

이 거대한 망 안에서 정보를 주고받는 각각의 단말기(PC, 스마트폰, 서버 등)를 노드(Node)라고 부릅니다. 두 노드가 데이터를 주고받으려면 물리적, 논리적으로 연결되어 있어야 합니다. 하지만 모든 컴퓨터가 1:1로 직접 연결되는 것은 물리적으로 불가능합니다.

따라서 인터넷은 수많은 중계 장비(Router, Switch)와 케이블(광케이블, 구리선)을 거쳐 데이터를 목적지까지 전달하는 방식을 취합니다. 우리가 흔히 '인터넷에 연결되었다'고 말하는 것은, 내 컴퓨터가 ISP(인터넷 서비스 제공자)의 네트워크를 통해 전 세계의 거대한 네트워크 망(World Wide Web)의 일원이 되었음을 의미합니다.

1-2. 클라이언트 - 서버 (Client - Server) 아키텍처

현대 인터넷 통신, 특히 웹(Web) 환경에서 가장 보편적으로 사용되는 모델은 클라이언트-서버 구조입니다.

• 클라이언트(Client): 서비스를 사용하는 입장입니다. 데이터를 요청(Request)하는 주체이며, 주로 웹 브라우저나 모바일 애플리케이션이 이에 해당합니다.
• 서버(Server): 서비스를 제공하는 입장입니다. 클라이언트의 요청을 받아 데이터를 처리하고, 그 결과인 응답(Response)을 반환하는 시스템입니다.

이 구조에서 통신은 항상 클라이언트가 서버로 요청을 보내는 것에서 시작됩니다. (※ WebSocket 등 양방향 통신 예외 존재)

1-3. 복잡한 네트워크 망과 규칙의 필요성

문제는 클라이언트와 서버가 바로 옆에 붙어있는 것이 아니라는 점입니다. 내 컴퓨터에서 보낸 데이터가 구글 서버까지 도달하기 위해서는 수많은 중간 노드와 해저 케이블을 거쳐야 합니다.

이 복잡한 인터넷 망 속에서 데이터가 길을 잃지 않고, 손상 없이 정확한 서버에 도달하기 위해서는 명확한 약속(Protocol)이 필요합니다. 다음과 같은 요소들이 포함됩니다.

• 어디로 갈 것인가? (IP 주소)
• 어떻게 신뢰성 있게 보낼 것인가? (TCP/UDP)
• 어떤 애플리케이션으로 보낼 것인가? (PORT)

2. IP (Internet Protocol)

2-1. IP의 역할: 주소 지정과 패킷(Packet)

인터넷망에 연결된 수많은 노드를 식별하기 위해서는 고유한 주소가 필요합니다. IP(Internet Protocol)는 데이터가 정확한 목적지를 찾아갈 수 있도록 IP 주소(IP Address)라는 논리적 주소를 각 장치에 부여합니다.

클라이언트가 서버로 데이터를 보낼 때, 데이터는 한 번에 통째로 전송되지 않습니다. 네트워크 효율을 위해 작은 단위로 쪼개져서 전송되는데, 이 단위를 패킷(Packet)이라고 부릅니다.

IP는 이 패킷에 출발지 IP 주소(Source IP)와 목적지 IP 주소(Destination IP) 정보를 포함한 헤더(Header)를 붙여 전송합니다.

2-2. 패킷의 전달 과정 (Routing)

클라이언트에서 출발한 IP 패킷은 목적지 서버까지 한 번에 도달하지 않습니다. 중간에 위치한 수많은 라우터(Router)들을 거쳐가며 이동합니다.

각 라우터는 패킷의 목적지 IP 주소를 확인하고, 자신의 라우팅 테이블(Routing Table)을 참조하여 다음으로 보낼 최적의 경로에 있는 라우터에게 패킷을 넘겨줍니다. 이 과정을 통해 패킷은 최종 목적지인 서버에 도달하게 됩니다.

2-3. IP 프로토콜의 한계

IP는 인터넷 통신의 핵심이지만, 단독으로 사용하기에는 치명적인 약점들이 있습니다. 이를 이해하는 것이 중요합니다.

• 비연결성 (Connectionless):
• IP는 패킷을 받을 상대방(서버)이 현재 통신 가능한 상태인지 확인하지 않고 무작정 전송합니다. 서버가 꺼져 있어도 패킷은 전송됩니다.
• 비신뢰성 (Unreliability):
  • 패킷 소실: 중간 라우터에 부하가 걸리거나 장애가 생기면 패킷이 사라질(Loss) 수 있으며, IP는 이를 복구해주지 않습니다.
  • 패킷 순서 불일치: 여러 개의 패킷을 보냈을 때, 네트워크 상황에 따라 서로 다른 경로로 이동할 수 있습니다. 이로 인해 늦게 보낸 패킷이 먼저 도착하는 등 순서가 뒤바뀔 수 있습니다.
• IP는 'Best Effort' 방식을 따릅니다. 즉, 전송을 위해 최선을 다하지만 결과는 보장하지 않습니다.

결론적으로 IP는 "목적지까지 데이터를 보내는 것"에만 집중할 뿐, 데이터가 "잘 도착했는지, 순서는 맞는지"는 신경 쓰지 않습니다.

3. TCP, UDP

인터넷 프로토콜(IP)은 패킷의 유실이나 순서 뒤바뀜을 해결해주지 않습니다. 이를 보완하기 위해 IP 계층 위에서 동작하는 것이 바로 전송 계층(Transport Layer)의 프로토콜인 TCP와 UDP입니다.

애플리케이션의 목적에 따라 개발자는 신뢰성(TCP)과 효율성(UDP) 중 하나를 선택해야 합니다.

3-1. TCP (Transmission Control Protocol)

TCP는 인터넷상에서 데이터를 메시지 형태로 보내기 위해 IP와 함께 사용하는 프로토콜입니다. IP가 처리하지 못하는 패킷의 추적 및 관리를 담당하여 '신뢰할 수 있는 연결형 서비스'를 제공합니다.

[TCP의 핵심 기능]

• 연결 지향 (Connection-oriented): 데이터 전송 전에 먼저 두 노드 간의 논리적 연결을 수립합니다. 이 과정을 3-way Handshake라고 합니다.
  • 1단계 (SYN): 클라이언트가 서버에 접속 요청 메시지 전송
  • 2단계 (SYN+ACK): 서버가 요청을 수락하고, 클라이언트에게도 접속 요청 메시지 전송
  • 3단계 (ACK): 클라이언트가 서버의 요청을 수락하며 최종 연결 수립
• 데이터 전달 보증: 데이터를 보낸 후, 상대방이 잘 받았는지 확인하는 응답(ACK)을 받습니다. 만약 응답이 없다면 패킷이 유실된 것으로 간주하고 자동으로 재전송합니다.
• 순서 보장: 패킷이 순서대로 도착하지 않더라도, 각 패킷에 부여된 시퀀스 번호(Sequence Number)를 통해 원본 데이터의 순서대로 재조립합니다.

즉, TCP는 속도가 조금 느려지더라도 데이터가 100% 완벽하게 전달되어야 하는 환경(웹 브라우징, 이메일, 파일 전송 등)에서 사용됩니다.

3-2. UDP (User Datagram Protocol)

UDP는 TCP와 달리 데이터의 신뢰성보다는 전송 속도와 효율성을 중시하는 프로토콜입니다. TCP가 제공하는 복잡한 기능을 모두 덜어내고, IP에 단순히 PORT 정보와 체크섬(Checksum) 정도만 추가한 아주 단순한 구조입니다.

[UDP의 핵심 기능]

• 비연결형 (Connectionless): 3-way Handshake 같은 연결 수립 과정이 없습니다. 그냥 보냅니다.
• 비신뢰성: 데이터가 잘 도착했는지 확인하지 않습니다(ACK 없음). 데이터가 중간에 유실되거나 순서가 바뀌어도 재전송하거나 순서를 조정하지 않습니다.
• 단순함과 빠름: 신뢰성을 위한 부가적인 절차(Handshake, Flow Control 등)가 없으므로 헤더의 크기가 작고 전송 속도가 매우 빠릅니다.

UDP는 데이터가 일부 유실되어도 괜찮지만 실시간성이 중요한 서비스(실시간 스트리밍, 온라인 게임, VoIP)나, 단순한 요청(DNS) 등에 주로 사용됩니다.

(최근에는 HTTP/3에서 QUIC 프로토콜을 통해 UDP를 기반으로 신뢰성을 확보하는 기술도 사용되고 있습니다.)

3-3. TCP vs UDP 요약

특성 TCP (Transmission Control Protocol) UDP (User Datagram Protocol)

연결 방식	연결 지향 (3-way Handshake)	비연결형
신뢰성	높음 (전송 보장, 순서 보장)	낮음 (유실 가능, 순서 보장 X)
전송 속도	상대적으로 느림 (오버헤드 발생)	빠름
사용 사례	HTTP(Web), Email, File Transfer	Streaming, Online Game, DNS

4. PORT

IP 주소를 통해 패킷이 목적지 컴퓨터(Host)까지 도달했습니다. 하지만 컴퓨터 내부에서는 웹 브라우저, 메신저, 게임 등 수많은 애플리케이션이 동시에 실행되고 있습니다.

이때, 도착한 패킷이 어느 프로세스로 전달되어야 하는지 구분하기 위해 사용하는 논리적인 식별자가 바로 포트(Port)입니다.

4-1. 포트의 정의와 필요성

• 정의: 운영체제(OS) 상에서 실행 중인 프로세스와 네트워크 사이의 논리적 연결 통로(Endpoint)를 식별하는 16비트 숫자입니다.
• 역할: 하나의 IP 주소로 들어온 데이터를 여러 애플리케이션이 동시에 사용할 수 있도록 분배해줍니다. 이를 기술적으로 멀티플렉싱(Multiplexing)과 디멀티플렉싱(Demultiplexing)을 지원한다고 표현합니다.
• 소켓(Socket)과의 관계: 네트워크 프로그래밍에서 소켓을 바인딩(Bind)할 때, IP 주소 + 포트 번호의 조합으로 네트워크상의 유일한 프로세스를 식별합니다.

4-2. 포트 번호의 범위와 분류

포트 번호는 0번부터 65535번까지 사용할 수 있으며, 관리 목적에 따라 크게 세 가지 범위로 나뉩니다.

1. Well-known Ports (0 ~ 1023):
   • 국제 도메인 관리 기구(ICANN)에 의해 미리 정의된 포트입니다.
   • 시스템 레벨의 주요 프로토콜이 사용하며, 일반 애플리케이션이 이 대역을 사용하려면 관리자 권한(Root)이 필요한 경우가 많습니다.
   • 예: 20, 21(FTP), 22(SSH), 80(HTTP), 443(HTTPS)
2. Registered Ports (1024 ~ 49151):
   • 특정 애플리케이션이 사용하기 위해 등록된 포트 대역입니다.
   • 개발자가 서버 프로그램을 만들 때 주로 이 대역의 포트를 사용합니다. (예: Spring Boot의 기본 포트인 8080, MySQL의 3306)
3. Dynamic Ports / Ephemeral Ports (49152 ~ 65535):
   • 클라이언트가 서버와 통신을 시작할 때, OS가 임시로 할당하는 포트 대역입니다.
   • 사용자가 웹 브라우저를 켜서 구글에 접속하면, 서버는 80/443 포트를 쓰지만, 내 컴퓨터(클라이언트)는 이 대역 중 남는 포트 하나를 랜덤으로 할당받아 통신합니다.

4-3. 포트와 통신의 흐름

통신은 항상 출발지 IP : 출발지 Port와 목적지 IP : 목적지 Port의 쌍으로 이루어집니다.

• 서버(Server): 특정 포트(예: 8080)를 열어두고, 요청이 오기를 기다립니다. 같은 포트를 두 개의 프로세스가 동시에 점유할 수 없습니다. (포트 충돌 발생)
• 클라이언트(Client): 데이터를 보낼 때, 목적지 서버의 포트 번호를 알고 있어야 합니다. 만약 포트 번호를 지정하지 않으면 프로토콜의 기본 포트(http는 80, https는 443)로 요청을 보냅니다.

5. DNS (Domain Name System)

인터넷 통신의 최종 목적지는 IP 주소로 결정됩니다. 하지만 사람이 수많은 웹사이트의 숫자 IP 주소를 모두 외우는 것은 불가능합니다. 또한 외운다 하더라도 언제든 변할 수 있는 IP 주소를 일일히 적용할 수는 없습니다.

• DNS(Domain Name System)는 사람이 기억하기 쉬운 도메인 이름(Domain Name)을 컴퓨터가 통신에 사용할 수 있는 IP 주소로 변환(Translation)하거나, 그 반대의 역할을 수행하는 분산형 데이터베이스 시스템입니다.

5-1. DNS의 계층 구조

전 세계의 모든 도메인 정보를 하나의 서버에 저장할 수는 없습니다. 따라서 DNS는 역트리(Inverted Tree) 형태의 계층적 구조로 분산 관리됩니다. 도메인 이름의 뒤에서부터 앞으로 해석하며 관리 범위를 좁혀나갑니다.

• Root DNS Server (.):
  • DNS 계층의 최상위에 위치합니다. 전 세계에 13개의 원본 서버가 존재하며, TLD 서버의 정보를 관리합니다. 도메인 끝에 보이지 않는 점(.)이 생략되어 있습니다.
• TLD (Top-Level Domain) Server:
  • .com, .net, .kr, .org 등 최상위 도메인을 관리하는 서버입니다. 해당 확장자를 가진 도메인을 관리하는 하위 네임 서버(Authoritative Server)의 위치를 알려줍니다.
• Authoritative Name Server (권한 있는 네임 서버):
  • 실제 특정 도메인(예: naver.com, google.com)의 IP 주소 정보를 가지고 있는 최종 서버입니다. 도메인 구매 시 설정하는 네임 서버가 바로 이곳을 가리킵니다.

5-2. DNS 동작 과정 (DNS Resolution)

사용자가 브라우저 주소창에 www.example.com을 입력했을 때, 실제 IP 주소를 찾아오는 과정을 DNS Resolution이라고 합니다. 이 과정은 재귀적 질의(Recursive Query)와 반복적 질의(Iterative Query)가 혼합되어 일어납니다.

1. Local Cache 확인: 브라우저 캐시나 OS의 hosts 파일에 해당 도메인의 IP가 저장되어 있는지 먼저 확인합니다.
2. DNS Resolver(Local DNS) 요청: 캐시에 없다면, PC에 설정된 ISP의 DNS 서버나 Public DNS(예: 8.8.8.8)인 Recursive Resolver에게 IP를 물어봅니다.
3. Root DNS 질의: Resolver는 Root DNS에게 .com을 관리하는 TLD 서버의 위치를 물어봅니다.
4. TLD DNS 질의: Resolver는 알아낸 TLD 서버에게 example.com을 관리하는 Authoritative 서버의 위치를 물어봅니다.
5. Authoritative DNS 질의: Resolver는 최종 네임 서버에게 www.example.com의 진짜 IP 주소를 요청하고 응답받습니다.
6. 결과 반환 및 캐싱: Resolver는 알아낸 IP(93.184.216.34)를 클라이언트(브라우저)에게 전달하고, 다음번 요청을 위해 일정 시간(TTL) 동안 자신의 캐시에 저장합니다.

5-3. 주요 DNS 레코드 (DNS Records)

DNS 서버는 단순히 IP만 저장하는 것이 아니라, 목적에 따라 다양한 타입의 레코드(Record)를 저장합니다.

• A (Address Mapping): 도메인 주소를 IPv4 주소로 매핑합니다. (가장 기본)
• AAAA (IP Version 6 Address): 도메인 주소를 IPv6 주소로 매핑합니다.
• CNAME (Canonical Name): 도메인의 별칭(Alias)을 설정합니다. (예: m.example.com -> example.com)
• NS (Name Server): 해당 도메인의 권한을 가진 네임 서버 정보를 지정합니다.
• MX (Mail Exchanger): 이메일 전송을 위한 메일 서버를 지정합니다.

6. 인터넷 프로토콜 스택 4계층 (TCP/IP 4 Layer)

인터넷 통신은 하나의 거대한 규칙이 아니라, 역할별로 나뉜 여러 규칙의 집합으로 이루어집니다. 이를 체계화한 것이 TCP/IP 4계층 모델입니다. (학술적으로는 OSI 7계층 모델이 존재하지만, 현대 인터넷의 실질적인 표준은 TCP/IP 4계층입니다.)

우리가 애플리케이션에서 데이터를 보낼 때, 데이터는 상위 계층에서 하위 계층으로 내려가며 각 계층의 정보(Header)를 덧씌우는 캡슐화(Encapsulation) 과정을 거치게 됩니다.

6-1. 계층별 역할 및 핵심 요소

각 계층은 독립적인 역할을 수행하며, 상위 계층의 요청을 받아 하위 계층으로 전달합니다. 위에서부터 아래로(L4 -> L1) 데이터가 흐르는 과정을 따라가 보겠습니다.

1. 애플리케이션 계층 (Application Layer) - L4

• 역할: 사용자와 직접 상호작용하는 응용 프로그램 레벨의 프로토콜입니다. 사용자가 전송하고자 하는 데이터(Data/Message) 자체를 생성합니다.
• 핵심 기능: 데이터의 내용을 정의하고, 통신 서비스를 제공합니다.
• 주요 프로토콜: HTTP(웹), DNS(도메인), FTP(파일), SSH(원격 접속)
• 데이터 단위: 데이터 (Data) 또는 메시지 (Message)

2. 전송 계층 (Transport Layer) - L3

• 역할: 애플리케이션 계층에서 내려온 데이터에 식별자(PORT)와 전송 방식(TCP/UDP) 정보를 추가합니다. 통신의 양 끝단(End-to-End) 간의 데이터 전송을 담당합니다.
• 핵심 기능:
  • 포트 번호를 통해 어떤 프로세스로 갈지 구분.
  • TCP를 선택할 경우 데이터의 신뢰성과 순서를 보장.
• 주요 프로토콜: TCP, UDP
• 데이터 단위: 세그먼트 (Segment - TCP), 데이터그램 (Datagram - UDP)

3. 인터넷 계층 (Internet Layer) - L2

• 역할: 전송 계층에서 내려온 데이터에 주소(IP) 정보를 추가하여 목적지까지의 경로를 찾습니다.
• 핵심 기능:
  • IP 주소를 이용한 패킷의 주소 지정(Addressing).
  • 목적지까지 최적의 경로를 찾는 라우팅(Routing).
• 주요 프로토콜: IP, ICMP, ARP
• 데이터 단위: 패킷 (Packet)

4. 네트워크 인터페이스 계층 (Network Interface Layer) - L1

• 역할: 물리적인 주소(MAC)를 사용하여 실제 데이터를 전기 신호(비트)로 변환하고, 물리적 장비(케이블, 랜카드)를 통해 인접한 기기로 전달합니다.
• 핵심 기능: 프레임 동기화 및 물리적 전송 에러 제어.
• 주요 프로토콜: Ethernet(이더넷), Wi-Fi, Bluetooth
• 데이터 단위: 프레임 (Frame)

6-2. 데이터 전송의 흐름: 캡슐화 (Encapsulation)

개발자가 코드를 작성하여 "Hello"라는 문자열을 서버로 보낼 때, 네트워크 내부에서는 다음과 같은 포장 과정이 일어납니다.

1. App Layer: "Hello" 데이터 생성
2. Transport Layer: "Hello" + [출발/목적지 PORT, TCP 정보] 헤더 부착
3. Internet Layer: 위 데이터 전체 + [출발/목적지 IP] 헤더 부착
4. Network Interface Layer: 위 패킷 전체 + [MAC 주소] 헤더 부착 -> 전기 신호로 송출

반대로 데이터를 받는 쪽(Server)에서는 하위 계층에서 상위 계층으로 올라가며 헤더를 하나씩 벗겨내는 역캡슐화(Decapsulation) 과정을 통해 원본 "Hello" 데이터를 확인하게 됩니다.