-
Notifications
You must be signed in to change notification settings - Fork 0
6주차
이번 주차에서는 네트워크 통신의 전체 흐름을 이해하기 위한 기본 개념을 학습한다.
OSI 7 Layer와 TCP/IP 4 Layer가 네트워크 통신을 어떻게 계층별로 나누는지 살펴보고, 데이터가 송신 측에서 계층을 내려가며 포장되는 캡슐화(Encapsulation) 과정과 수신 측에서 포장을 해제하는 역캡슐화(Decapsulation) 과정을 이해한다.
또한 IP 주소, Port 번호, DNS가 각각 어떤 대상을 식별하고 어떤 역할을 담당하는지 학습한다.
주요 학습 키워드는 다음과 같다.
- OSI 7 Layer
- TCP/IP 4 Layer
- Encapsulation / Decapsulation
- IP Address
- Port
- DNS
인터넷에서 상대방의 특정 서비스와 통신하려면 다음 세 가지 정보가 필요하다.
| 구분 | 식별 대상 | 예시 | 비유 |
|---|---|---|---|
| DNS | 도메인 이름을 IP 주소로 변환 |
www.example.com → 93.184.216.34
|
상호명으로 주소 찾기 |
| IP 주소 | 통신할 장치 또는 네트워크 인터페이스 | 93.184.216.34 |
건물 주소 |
| Port 번호 | 장치 안에서 통신할 애플리케이션 또는 서비스 | 443 |
건물의 호수 |
예를 들어 브라우저에서 https://www.example.com에 접속하면 다음과 같이 동작한다.
- DNS를 이용해
www.example.com의 IP 주소를 조회한다. - 조회한 IP 주소를 이용해 목적지 서버를 찾는다.
- HTTPS 서비스가 사용하는 TCP 443번 Port로 연결한다.
- 데이터는 TCP/IP 계층을 따라 캡슐화되어 네트워크로 전송된다.
- 서버는 데이터를 역캡슐화한 후 웹 서버 프로그램에 전달한다.
핵심: DNS는 이름을 주소로 바꾸고, IP는 목적지 장치를 찾으며, Port는 그 장치 안의 서비스를 찾는다.
OSI 7 Layer(Open Systems Interconnection 7 Layer)는 네트워크 통신 과정을 7개의 계층으로 나눈 참조 모델이다.
국제표준화기구인 ISO가 서로 다른 제조사와 시스템 간의 통신 구조를 표준화하기 위해 만들었다. 각 계층은 자신의 역할을 수행하고, 바로 위 계층에는 필요한 기능을 제공하며, 바로 아래 계층의 기능을 이용한다.
계층을 나누면 다음과 같은 장점이 있다.
- 복잡한 네트워크 통신 과정을 단계별로 이해할 수 있다.
- 특정 계층에서 발생한 문제를 빠르게 구분할 수 있다.
- 각 계층의 기술을 독립적으로 개발하거나 변경하기 쉽다.
- 서로 다른 제조사의 장비와 소프트웨어가 표준에 따라 통신할 수 있다.
| 계층 | 이름 | 주요 역할 | 대표 프로토콜·기술 | 데이터 단위 | 대표 장비 |
|---|---|---|---|---|---|
| 7 | Application | 사용자와 가까운 네트워크 서비스 제공 | HTTP, HTTPS, DNS, SMTP, IMAP, POP3, FTP, SSH | Data | L7 스위치, 프록시 |
| 6 | Presentation | 데이터 형식 변환, 인코딩, 압축, 암호화 | TLS/SSL, UTF-8, JPEG, JSON | Data | - |
| 5 | Session | 통신 세션의 설정, 유지, 종료 및 동기화 | RPC, NetBIOS 세션 | Data | - |
| 4 | Transport | 프로세스 간 전송, 신뢰성·흐름·오류 제어, Port 사용 | TCP, UDP | Segment(TCP), Datagram(UDP) | L4 스위치, 방화벽 |
| 3 | Network | 다른 네트워크까지의 경로 선택과 IP 주소 기반 전달 | IPv4, IPv6, ICMP, IPsec | Packet | 라우터, L3 스위치 |
| 2 | Data Link | 같은 네트워크 구간에서 MAC 주소 기반 전달, 오류 검출 | Ethernet, Wi-Fi, VLAN, ARP* | Frame | 스위치, 브리지 |
| 1 | Physical | 전기·광·무선 신호로 비트를 전송 | 케이블, 광섬유, 전파, 1000BASE-T | Bit | 허브, 리피터 |
ARP는 IP 주소와 MAC 주소를 연결하므로 문헌이나 구현 관점에 따라 2계층 또는 2.5계층으로 설명되기도 한다.
사용자가 이용하는 애플리케이션에 네트워크 서비스를 제공하는 계층이다. 브라우저, 메일 클라이언트 등의 프로그램 자체가 계층인 것은 아니며, 프로그램이 사용하는 HTTP, SMTP, DNS와 같은 통신 규칙이 이 계층에 해당한다.
대표적인 예시는 다음과 같다.
- 웹 페이지 요청: HTTP, HTTPS
- 도메인 이름 조회: DNS
- 메일 전송: SMTP
- 메일 수신: POP3, IMAP
- 원격 접속: SSH
- 파일 전송: FTP
서로 다른 시스템이 데이터를 같은 의미로 해석할 수 있도록 데이터의 표현 형식을 변환한다.
- 문자 인코딩과 디코딩
- 데이터 직렬화와 역직렬화
- 압축과 압축 해제
- 암호화와 복호화
예를 들어 문자열을 UTF-8 바이트로 변환하거나, 데이터를 JSON 형식으로 표현하거나, TLS를 통해 데이터를 암호화하는 기능을 이 계층의 역할로 설명할 수 있다.
두 시스템 사이의 논리적인 대화인 세션을 생성하고 유지하며 종료한다.
- 세션 연결 설정과 종료
- 통신 상태 유지
- 연결이 중단됐을 때 이어서 처리하기 위한 동기화 지점 관리
- 전이중·반이중 등 대화 방식 관리
현대의 실제 TCP/IP 구현에서는 세션 계층의 기능이 애플리케이션이나 전송 계층에 포함되는 경우가 많다.
송신 장치의 프로세스에서 수신 장치의 프로세스까지 데이터를 전달한다. IP 주소가 목적지 장치를 찾는 데 사용된다면, Port 번호는 그 장치에서 실행 중인 목적지 서비스를 찾는 데 사용된다.
주요 역할은 다음과 같다.
- 데이터를 적절한 크기로 분할하고 다시 조립한다.
- 출발지와 목적지 Port 번호를 관리한다.
- TCP에서는 순서 보장, 재전송, 흐름 제어, 혼잡 제어를 수행한다.
- UDP에서는 연결 설정과 재전송을 최소화하여 빠르게 전달한다.
IP 주소를 이용하여 목적지 네트워크를 식별하고, 여러 네트워크를 거쳐 목적지까지 전달할 경로를 결정한다.
라우터는 목적지 IP 주소와 라우팅 테이블을 확인하여 패킷을 다음 경로인 Next Hop으로 전달한다. IP는 최선형 전달을 수행하지만, 패킷의 도착이나 순서를 자체적으로 보장하지는 않는다.
하나의 로컬 네트워크 구간에서 프레임을 전달한다. Ethernet 환경에서는 MAC 주소를 사용한다.
주요 역할은 다음과 같다.
- 출발지와 목적지 MAC 주소 지정
- 프레임 단위 전달
- FCS를 이용한 전송 오류 검출
- 스위치의 MAC 주소 테이블을 이용한 프레임 전달
라우터를 거쳐 다른 네트워크 구간으로 이동하면 프레임의 출발지·목적지 MAC 주소는 구간마다 바뀔 수 있다. 반면 일반적인 통신에서 출발지·목적지 IP 주소는 종단 간 유지된다. 단, NAT를 통과하면 IP 주소나 Port 번호가 변환될 수 있다.
0과 1의 비트 정보를 전기 신호, 빛 또는 무선 전파로 변환하여 실제 매체를 통해 전달한다.
- 케이블과 커넥터 규격
- 전압과 신호 방식
- 데이터 전송 속도
- 물리적 연결과 전송 거리
송신 측에서는 7계층에서 1계층 방향으로 내려가고, 수신 측에서는 1계층에서 7계층 방향으로 올라간다.
송신: Application → Presentation → Session → Transport → Network → Data Link → Physical
수신: Physical → Data Link → Network → Transport → Session → Presentation → Application
TCP/IP 4 Layer는 실제 인터넷에서 사용되는 프로토콜들을 4개 계층으로 구분한 모델이다. OSI 7 Layer가 통신 기능을 설명하기 위한 참조 모델이라면, TCP/IP 모델은 인터넷의 실제 프로토콜 구조를 중심으로 한다.
| TCP/IP 계층 | 주요 역할 | 대표 프로토콜·기술 | OSI 대응 계층 |
|---|---|---|---|
| Application | 사용자 서비스, 데이터 표현, 세션 관리 | HTTP(S), DNS, SMTP, IMAP, SSH, DHCP | OSI 5~7계층 |
| Transport | 프로세스 간 통신과 Port 관리 | TCP, UDP | OSI 4계층 |
| Internet | IP 주소 기반의 패킷 전달과 라우팅 | IPv4, IPv6, ICMP, IPsec | OSI 3계층 |
| Network Access | 같은 링크에서 프레임·비트 전송 | Ethernet, Wi-Fi, ARP | OSI 1~2계층 |
| OSI 7 Layer | TCP/IP 4 Layer |
|---|---|
| 7. Application | Application |
| 6. Presentation | Application |
| 5. Session | Application |
| 4. Transport | Transport |
| 3. Network | Internet |
| 2. Data Link | Network Access |
| 1. Physical | Network Access |
자료에 따라 TCP/IP를 5계층 모델로 나누기도 한다. 이 경우 Network Access 계층을 Data Link 계층과 Physical 계층으로 분리한다. 이는 분류 방식의 차이이며 기본 원리는 같다.
| 구분 | OSI 7 Layer | TCP/IP 4 Layer |
|---|---|---|
| 목적 | 네트워크 통신 기능을 체계적으로 설명 | 인터넷에서 실제 사용하는 프로토콜 구조 표현 |
| 계층 수 | 7개 | 4개 |
| 특징 | 각 계층의 역할을 세밀하게 구분 | 일부 계층을 통합하여 실용적으로 구성 |
| 활용 | 학습, 설계, 장애 분석 | 실제 인터넷 통신과 프로토콜 구현 |
OSI와 TCP/IP는 서로 경쟁하는 방식이라기보다, 같은 통신 과정을 서로 다른 관점과 세분화 정도로 표현한 모델이다.
캡슐화(Encapsulation)는 송신 측에서 상위 계층의 데이터에 각 계층이 자신의 제어 정보인 헤더를 붙여 하위 계층으로 전달하는 과정이다.
필요에 따라 데이터 링크 계층은 뒤쪽에 Trailer도 추가한다. 각 계층의 헤더에는 해당 계층이 통신하는 데 필요한 주소, Port, 순서 번호, 오류 검사용 정보 등이 들어간다.
각 계층에서 다루는 데이터 단위를 **PDU(Protocol Data Unit)**라고 한다.
| 계층 | PDU | 추가되는 주요 정보 |
|---|---|---|
| Application | Data | HTTP 요청, DNS 질의 등 애플리케이션 데이터 |
| Transport | TCP Segment / UDP Datagram | 출발지·목적지 Port, 순서 번호 등 |
| Internet/Network | IP Packet | 출발지·목적지 IP 주소 등 |
| Network Access/Data Link | Frame | 출발지·목적지 MAC 주소, 오류 검출 정보 |
| Physical | Bit | 전기·광·무선 신호로 표현된 0과 1 |
[Application Data]
↓ TCP Header 추가
[TCP Header | Data] = Segment
↓ IP Header 추가
[IP Header | TCP Header | Data] = Packet
↓ Ethernet Header와 Trailer 추가
[Ethernet Header | IP Header | TCP Header | Data | Trailer] = Frame
↓ 비트와 신호로 변환
01010110 ... = Bit
예를 들어 HTTPS 요청을 전송할 때 각 계층에는 대략 다음 정보가 들어간다.
- Application: 암호화된 HTTP 요청 데이터
- Transport: 클라이언트 임시 Port와 서버 TCP 443번 Port
- Internet: 클라이언트 IP와 서버 IP
- Network Access: 현재 네트워크 구간의 출발지 MAC과 목적지 MAC
역캡슐화(Decapsulation)는 수신 측에서 각 계층이 자신에게 해당하는 헤더를 확인하고 제거한 뒤 상위 계층으로 데이터를 전달하는 과정이다.
Bit
↓ 신호를 Frame으로 복원
Frame
↓ Ethernet Header·Trailer 확인 및 제거
Packet
↓ IP Header 확인 및 제거
Segment
↓ TCP Header 확인, 데이터 순서 정리
Application Data
↓
목적지 애플리케이션에 전달
모든 헤더가 목적지까지 동일하게 유지되는 것은 아니다.
- 2계층 Frame: 라우터를 통과할 때 제거되고 다음 네트워크 구간에 맞게 새로 생성된다.
- 3계층 IP Packet: 일반적으로 출발지부터 목적지까지 전달되지만, TTL/Hop Limit 등의 값은 변경된다. NAT 환경에서는 IP 주소도 변경될 수 있다.
- 4계층 Segment: 일반적으로 종단 간 유지되지만, NAT/PAT 환경에서는 Port가 변환될 수 있다.
스위치는 주로 2계층의 MAC 주소를 보고 전달하고, 라우터는 3계층의 IP 주소를 보고 다음 경로를 결정한다.
IP 주소(Internet Protocol Address)는 IP 네트워크에서 통신 대상을 식별하고 패킷을 목적지까지 전달하기 위해 네트워크 인터페이스에 부여하는 논리적 주소이다.
IP 주소에는 일반적으로 다음 두 가지 의미가 포함된다.
- Network 부분: 어느 네트워크에 속해 있는지 식별한다.
- Host 부분: 해당 네트워크 안의 인터페이스를 식별한다.
서브넷 마스크 또는 Prefix Length를 이용해 두 부분의 경계를 구분한다.
IP 주소: 192.168.1.10
Prefix Length: /24
네트워크 주소: 192.168.1.0
호스트 범위: 192.168.1.1 ~ 192.168.1.254
위 예시는 일반적인
/24IPv4 서브넷이다. 네트워크 주소와 브로드캐스트 주소는 일반 호스트에 할당하지 않는다.
IPv4 주소는 32비트이며, 8비트씩 4개로 나누어 10진수로 표현한다.
192.168.1.10
- 전체 주소 공간은 약 43억 개이다.
- 주소 부족 문제를 완화하기 위해 사설 IP, NAT, CIDR 등을 사용한다.
- IPv4는 브로드캐스트를 지원한다.
IPv6 주소는 128비트이며, 16비트 단위의 16진수 8개로 표현한다.
2001:0db8:0000:0000:0000:ff00:0042:8329
연속된 0은 한 번에 ::로 줄일 수 있고, 각 그룹 앞의 0도 생략할 수 있다.
2001:db8::ff00:42:8329
- IPv4보다 매우 큰 주소 공간을 제공한다.
- 브로드캐스트 대신 멀티캐스트와 애니캐스트를 사용한다.
- 주소 자동 설정 기능을 지원한다.
| 구분 | 공인 IP | 사설 IP |
|---|---|---|
| 사용 범위 | 인터넷 전체 | 조직이나 가정의 내부 네트워크 |
| 중복 가능 여부 | 인터넷에서 고유해야 함 | 서로 다른 내부 네트워크에서 중복 가능 |
| 인터넷 직접 통신 | 가능 | 일반적으로 NAT 필요 |
| 할당 주체 | ISP 또는 공인 기관 체계 | 내부 네트워크 관리자 또는 공유기 |
IPv4의 대표적인 사설 주소 범위는 다음과 같다.
| 사설 주소 범위 | CIDR |
|---|---|
10.0.0.0 ~ 10.255.255.255
|
10.0.0.0/8 |
172.16.0.0 ~ 172.31.255.255
|
172.16.0.0/12 |
192.168.0.0 ~ 192.168.255.255
|
192.168.0.0/16 |
192.168.x.x는 대표적인 사설 IP이므로 일반적으로 내부 네트워크에서 사용한다. 그러나 사설 IP라는 사실만으로 같은 조직의 신뢰할 수 있는 장치라고 단정할 수는 없다.
NAT(Network Address Translation)는 라우터나 방화벽이 내부의 사설 IP와 외부의 공인 IP를 변환하는 기술이다.
여러 내부 장치가 하나의 공인 IP를 공유할 때는 보통 Port 번호까지 함께 변환하는 PAT(Port Address Translation) 또는 NAPT를 사용한다.
192.168.1.10:51000 ─┐
192.168.1.20:52000 ─┼─ NAT/PAT ─→ 203.0.113.10:40001, 40002 ...
192.168.1.30:53000 ─┘
- 고정 IP: 관리자가 직접 설정하거나 제공자가 고정적으로 할당한다. 서버처럼 주소가 계속 같아야 하는 환경에 적합하다.
- 동적 IP: DHCP 서버가 일정 기간 임대한다. 일반 사용자 장치에서 많이 사용한다.
# Windows
ipconfig
# Linux
ip addr
# 목적지까지의 경로 확인
tracert example.com # Windows
traceroute example.com # LinuxPort 번호는 하나의 장치에서 실행되는 여러 네트워크 애플리케이션과 서비스를 구분하는 16비트 번호이다. 사용 가능한 범위는 0부터 65535까지이다.
IP 주소만 있으면 목적지 장치까지는 도달할 수 있지만, 그 안의 웹 서버, 메일 서버, SSH 서버 중 어느 프로그램에 전달할지는 알 수 없다. 전송 계층은 목적지 Port 번호를 확인하여 알맞은 프로세스의 소켓으로 데이터를 전달한다.
| 범위 | 이름 | 설명 |
|---|---|---|
0 ~ 1023 |
Well-Known Ports | 널리 알려진 표준 서비스가 주로 사용 |
1024 ~ 49151 |
Registered Ports | 특정 애플리케이션이 등록하여 사용 |
49152 ~ 65535 |
Dynamic/Private Ports | 클라이언트의 임시 Port 등으로 주로 사용 |
운영체제별 임시 Port 범위는 설정에 따라 다를 수 있다.
| Port | 전송 프로토콜 | 서비스 | 설명 |
|---|---|---|---|
| 20, 21 | TCP | FTP | 데이터 전송, 제어 연결 |
| 22 | TCP | SSH | 암호화된 원격 접속 |
| 23 | TCP | Telnet | 평문 원격 접속 |
| 25 | TCP | SMTP | 메일 서버 간 전송 |
| 53 | UDP/TCP | DNS | 이름 조회, 큰 응답·영역 전송 등은 TCP도 사용 |
| 67, 68 | UDP | DHCP | 서버와 클라이언트의 IP 설정 할당 |
| 80 | TCP | HTTP | 일반 웹 통신 |
| 110 | TCP | POP3 | 메일 수신 |
| 143 | TCP | IMAP | 서버 기반 메일 동기화 |
| 443 | TCP/UDP | HTTPS | HTTP over TLS, HTTP/3는 UDP 기반 QUIC 사용 |
| 465 | TCP | SMTPS | 처음부터 TLS를 사용하는 SMTP 제출에 주로 사용 |
| 587 | TCP | SMTP Submission | 메일 클라이언트의 발송 제출, STARTTLS 사용 가능 |
| 993 | TCP | IMAPS | TLS 기반 IMAP |
| 995 | TCP | POP3S | TLS 기반 POP3 |
| 3306 | TCP | MySQL/MariaDB | 데이터베이스 접속 |
| 8080 | TCP | HTTP Alternate | 웹 애플리케이션·프록시 등에 자주 사용 |
Port 번호는 관례적인 기본값이다. 관리자가 서비스를 다른 Port에서 실행할 수도 있다.
웹 서버가 TCP 443번 Port에서 대기하고 있을 때, 클라이언트도 443번을 사용하는 것은 아니다. 클라이언트 운영체제는 보통 임시 Port를 자동으로 할당한다.
클라이언트 192.168.1.10:53124 → 서버 203.0.113.20:443
- 목적지 Port
443: 서버의 HTTPS 서비스를 식별한다. - 출발지 Port
53124: 서버가 응답을 돌려보낼 클라이언트 소켓을 식별한다.
하나의 TCP 연결은 일반적으로 다음 4개의 값으로 구분한다.
출발지 IP + 출발지 Port + 목적지 IP + 목적지 Port
여기에 전송 프로토콜까지 포함하여 통신 흐름을 구분하기도 한다. TCP Port와 UDP Port는 별도의 공간이므로 같은 번호를 동시에 사용할 수 있다.
Port가 열려 있다는 표현은 보통 다음 조건을 함께 의미한다.
- 해당 Port에서 서비스가 실행되며 연결을 기다리고 있다.
- 운영체제 및 네트워크 방화벽이 해당 통신을 허용한다.
- 목적지까지의 네트워크 경로가 정상이다.
서비스가 실행되지 않거나 방화벽이 차단하면 연결할 수 없다. 단순히 방화벽 규칙만 허용했다고 서비스가 자동으로 실행되는 것은 아니다.
# Linux에서 수신 대기 중인 TCP/UDP Port 확인
ss -tulnp
# Windows에서 연결 및 수신 대기 Port 확인
netstat -ano
# 특정 호스트의 TCP Port 연결 확인
Test-NetConnection example.com -Port 443 # PowerShell
nc -vz example.com 443 # LinuxDNS(Domain Name System)는 사람이 기억하기 쉬운 도메인 이름을 컴퓨터가 통신에 사용하는 IP 주소 등의 정보로 변환하는 분산형 이름 시스템이다.
www.example.com → 93.184.216.34
DNS가 없다면 웹사이트에 접속할 때마다 숫자로 된 IP 주소를 기억해야 한다. 또한 서버의 IP가 변경될 때마다 사용자가 새 주소를 알아야 한다. DNS를 사용하면 도메인 이름은 유지하면서 연결되는 IP 주소만 변경할 수 있다.
DNS 이름은 오른쪽에서 왼쪽 방향으로 더 구체적인 영역을 나타낸다.
www.mail.example.com.
│ │ │ └─ Root(루트, 보통 마지막 점은 생략)
│ │ └────── Top-Level Domain: com
│ └───────────── Second-Level Domain: example
└────────────────── Host/Subdomain: www.mail
실제로 www.mail.example.com에서는 com이 TLD, example이 그 하위 도메인이며 mail, www는 차례로 더 하위의 레이블이다.
| 구성 요소 | 역할 |
|---|---|
| Stub Resolver | 사용자 장치에서 DNS 질의를 시작하는 기능 |
| Recursive Resolver | 클라이언트를 대신해 여러 DNS 서버에 질의하고 결과를 반환 |
| Root DNS Server | 해당 TLD DNS 서버의 위치 안내 |
| TLD DNS Server |
.com, .kr 등 하위 도메인의 권한 서버 위치 안내 |
| Authoritative DNS Server | 특정 도메인의 실제 DNS 레코드를 보유하고 최종 답변 제공 |
사용자가 www.example.com에 처음 접속하고 캐시에 결과가 없다고 가정하면 다음과 같이 진행된다.
- 브라우저와 운영체제의 DNS 캐시를 확인한다.
- 캐시에 없으면 설정된 Recursive DNS 서버에 질의한다.
- Recursive DNS 서버는 자신의 캐시를 확인한다.
- 결과가 없으면 Root DNS 서버에 질의하여
.comTLD 서버의 위치를 받는다. -
.comTLD DNS 서버에 질의하여example.com의 Authoritative DNS 서버 위치를 받는다. - Authoritative DNS 서버에
www.example.com의 레코드를 질의한다. - IP 주소를 클라이언트에 반환하고 TTL 동안 캐시에 저장한다.
- 클라이언트는 반환된 IP 주소로 실제 통신을 시작한다.
Root와 TLD 서버가 최종 IP 주소를 항상 직접 알려주는 것은 아니다. 일반적으로 다음에 질의할 권한 서버의 위치를 안내한다.
- 재귀적 질의(Recursive Query): 클라이언트가 DNS Resolver에 최종 결과를 요청한다. Resolver가 대신 조회를 완료해 응답한다.
- 반복적 질의(Iterative Query): DNS 서버가 자신이 아는 최선의 정보 또는 다음에 질의할 서버의 위치를 반환한다.
일반적으로 사용자 장치와 Recursive Resolver 사이에서는 재귀적 질의를 사용하고, Resolver가 DNS 계층을 조회할 때는 반복적 질의를 사용한다.
| 레코드 | 역할 | 예시 |
|---|---|---|
| A | 도메인을 IPv4 주소에 연결 | example.com → 192.0.2.10 |
| AAAA | 도메인을 IPv6 주소에 연결 | example.com → 2001:db8::10 |
| CNAME | 하나의 이름을 다른 정규 이름에 연결 | www.example.com → example.com |
| MX | 해당 도메인의 메일 수신 서버 지정 | example.com → mail.example.com |
| NS | 도메인의 권한 DNS 서버 지정 | example.com → ns1.example.net |
| TXT | 임의의 텍스트 정보 저장 | SPF, DKIM 검증 정보 등 |
| PTR | IP 주소를 도메인 이름으로 역조회 | 192.0.2.10 → mail.example.com |
| SOA | DNS 영역의 기본 관리 정보 저장 | 주 서버, 일련번호, 갱신 시간 등 |
MX 레코드에는 IP 주소가 아니라 메일 서버의 호스트 이름을 지정한다. 해당 호스트 이름의 A 또는 AAAA 레코드를 다시 조회하여 실제 IP를 찾는다.
DNS 결과를 매번 Root 서버부터 조회하면 시간이 오래 걸리고 DNS 서버의 부하가 커진다. 따라서 브라우저, 운영체제, Recursive Resolver 등은 조회 결과를 일정 시간 저장한다.
**TTL(Time To Live)**은 DNS 레코드를 캐시에 보관할 수 있는 시간을 의미한다.
- TTL이 길면 DNS 질의 횟수와 부하는 줄지만 변경 사항의 반영이 느리다.
- TTL이 짧으면 변경 사항은 빨리 반영되지만 질의 횟수와 부하가 증가한다.
DNS 레코드를 변경했는데도 이전 IP로 접속되는 경우, 캐시의 TTL이 아직 만료되지 않았을 가능성이 있다.
DNS는 기본적으로 53번 Port를 사용한다.
- UDP 53: 일반적인 DNS 질의와 응답에 주로 사용한다.
- TCP 53: 영역 전송(AXFR/IXFR), 응답이 크거나 신뢰성 있는 연결이 필요한 경우 등에 사용한다.
- 현대 DNS는 상황에 따라 DoT(TCP 853)나 DoH(HTTPS 443)처럼 암호화된 방식도 사용할 수 있다.
# 기본 조회
nslookup example.com
# 특정 레코드 조회
nslookup -type=mx example.com
nslookup -type=txt example.com
# Linux의 dig 사용
dig example.com A
dig example.com MX
dig example.com TXT
# 역방향 조회
nslookup 8.8.8.8
dig -x 8.8.8.8기본 DNS 질의는 일반적으로 암호화되지 않는다. 또한 DNS 응답을 위조하거나 잘못된 정보를 캐시에 저장시키는 공격이 발생할 수 있다.
- DNSSEC: DNS 응답에 전자서명을 적용하여 데이터의 출처와 무결성을 검증한다.
- DoT(DNS over TLS): DNS 질의를 TLS로 암호화한다.
- DoH(DNS over HTTPS): DNS 질의를 HTTPS를 통해 암호화한다.
DNSSEC은 응답의 진위를 검증하는 기술이고, DoT와 DoH는 질의·응답 구간을 암호화하는 기술이므로 목적이 다르다.
브라우저는 URL에서 다음 정보를 확인한다.
https://www.example.com
│ │
│ └─ 도메인 이름: www.example.com
└───────── 프로토콜: HTTPS → 기본 Port 443
브라우저와 운영체제의 캐시를 확인하고, 결과가 없으면 DNS Resolver를 통해 www.example.com의 IP 주소를 조회한다.
운영체제는 목적지 IP가 자신과 같은 네트워크인지 서브넷 정보로 판단한다.
- 같은 네트워크: 목적지 장치로 직접 전송한다.
- 다른 네트워크: 기본 게이트웨이인 라우터로 전송한다.
IPv4 Ethernet 환경에서는 ARP를 이용해 같은 링크에서 다음으로 전달할 대상의 MAC 주소를 알아낸다. 다른 네트워크로 보낼 때 프레임의 목적지 MAC은 최종 서버가 아니라 우선 기본 게이트웨이의 MAC 주소가 된다.
일반적인 HTTPS 통신에서는 클라이언트가 서버의 TCP 443번 Port로 연결한다. TCP를 사용하면 먼저 연결을 설정하고, 이후 TLS 협상을 통해 암호화 통신을 준비한다.
HTTP/3을 사용하는 경우에는 TCP 대신 UDP 기반 QUIC을 사용하지만, 목적지 Port는 일반적으로 443번이다.
애플리케이션 데이터에 TCP 또는 UDP 헤더, IP 헤더, Ethernet 헤더와 Trailer가 차례대로 붙는다. 완성된 프레임은 비트 신호로 변환되어 전송된다.
라우터는 들어온 프레임에서 2계층 정보를 제거하고 목적지 IP와 라우팅 테이블을 확인한다. 다음 네트워크 구간에 맞는 새로운 2계층 프레임으로 패킷을 캡슐화하여 전달한다.
이 과정은 목적지 네트워크에 도착할 때까지 반복된다.
서버는 Frame → Packet → Segment → Data 순서로 헤더를 확인하고 제거한다. TCP 목적지 Port가 443번임을 확인한 운영체제는 해당 Port에서 대기 중인 HTTPS 서버 프로세스의 소켓에 데이터를 전달한다.
서버의 응답도 같은 방식으로 캡슐화되어 클라이언트에 전달되고, 클라이언트는 이를 역캡슐화하여 브라우저에 표시한다.
| 증상 | 우선 확인할 계층·요소 | 확인 예시 |
|---|---|---|
| 케이블 연결 또는 링크 자체가 안 됨 | Physical | 케이블, 무선 신호, NIC Link 상태 |
| 같은 네트워크의 장치와 통신 불가 | Data Link | MAC, VLAN, 스위치, ARP |
| 다른 네트워크로 통신 불가 | Network/Internet | IP, 서브넷, 게이트웨이, 라우팅 |
| 서버 IP에는 도달하지만 서비스 연결 불가 | Transport | Port 수신 대기, TCP/UDP, 방화벽 |
| 도메인만 접속되지 않고 IP 접속은 됨 | Application의 DNS | DNS 설정, 레코드, 캐시 |
| 연결은 되지만 웹 오류가 발생함 | Application | HTTP 상태 코드, 웹 서버, 애플리케이션 로그 |
| HTTPS 인증서 또는 암호화 오류 | Presentation/Application 구현 영역 | 인증서, TLS 버전, 암호화 스위트 |
계층별 구분은 문제의 원인 범위를 좁히는 기준이다. 실제 장비와 프로토콜은 여러 계층의 기능을 함께 수행할 수 있으므로 하나의 증상을 반드시 한 계층에만 고정해서 판단해서는 안 된다.
| 구분 | IP 주소 | MAC 주소 |
|---|---|---|
| 계층 | 3계층 | 2계층 |
| 성격 | 논리적 주소 | 링크 계층 주소 |
| 주요 범위 | 여러 네트워크를 거친 종단 간 전달 | 현재 로컬 네트워크 구간의 전달 |
| 변경 | 네트워크 환경이나 NAT에 따라 변경 가능 | 인터페이스에 부여되지만 변경·가상화 가능 |
| 확인 대상 | 라우터 | 스위치 |
| 구분 | IP 주소 | Port 번호 |
|---|---|---|
| 식별 대상 | 장치의 네트워크 인터페이스 | 장치 안의 애플리케이션 통신 종점 |
| 계층 | Network/Internet | Transport |
| 예시 | 203.0.113.10 |
443 |
| 비유 | 건물 주소 | 건물의 호수 |
| 구분 | TCP | UDP |
|---|---|---|
| 연결 방식 | 연결 지향 | 비연결형 |
| 신뢰성 | 순서 보장, 재전송, 오류·흐름·혼잡 제어 | 전달·순서·재전송을 기본 보장하지 않음 |
| 헤더와 처리 | 상대적으로 큼 | 상대적으로 작고 단순함 |
| 장점 | 안정적인 데이터 전달 | 낮은 지연과 작은 오버헤드 |
| 대표 용도 | 웹(HTTP/1.1, HTTP/2), SSH, SMTP, IMAP | DNS 질의, 음성·영상, 게임, QUIC/HTTP/3 |
UDP를 사용한다고 애플리케이션이 신뢰성을 구현할 수 없는 것은 아니다. QUIC처럼 UDP 위에서 연결 관리, 재전송, 암호화 등을 구현하는 프로토콜도 있다.
도메인 이름 IP 주소 Port
www.example.com → 93.184.216.34 + 443
사람이 읽는 이름 목적지 장치 목적지 서비스
- OSI 7 Layer는 네트워크 통신 기능을 7단계로 세분화한 참조 모델이다.
- TCP/IP 4 Layer는 실제 인터넷 프로토콜 구조를 Application, Transport, Internet, Network Access 계층으로 구분한 모델이다.
- 송신 측은 상위 계층 데이터에 헤더를 붙이는 캡슐화를 수행한다.
- 수신 측은 계층별 헤더를 확인하고 제거하는 역캡슐화를 수행한다.
- IP 주소는 패킷을 전달할 목적지 장치 또는 네트워크 인터페이스를 식별한다.
- Port 번호는 목적지 장치 안에서 데이터를 받을 애플리케이션 서비스를 식별한다.
- DNS는 도메인 이름을 IP 주소 등의 정보로 변환한다.
- 스위치는 주로 MAC 주소, 라우터는 IP 주소, 운영체제의 전송 계층은 Port 번호를 기준으로 데이터를 전달한다.
- 실제 통신에서는 DNS 조회 → 목적지 IP 확인 → Port 연결 → 캡슐화 → 라우팅 → 역캡슐화 순서가 서로 이어진다.
OSI 7 Layer는 네트워크 통신 기능을 세밀하게 구분한 참조 모델이고, TCP/IP 4 Layer는 실제 인터넷 프로토콜 구조를 중심으로 구성한 모델이다. TCP/IP의 Application 계층은 OSI의 5-7계층을 포함하고, Network Access 계층은 OSI의 1-2계층을 포함한다.
IP 주소는 목적지 장치를 찾는 정보일 뿐이다. 장치 안의 어떤 서비스와 통신할지 구분하려면 Port 번호도 필요하다. 예를 들어 203.0.113.10:443은 해당 장치의 HTTPS 서비스에 연결한다는 의미이다.
아니다. 일반적인 DNS 질의는 UDP 53번을 주로 사용하지만, 영역 전송이나 큰 응답 등에서는 TCP 53번도 사용한다. DoT와 DoH 같은 암호화 DNS 방식은 각각 TLS와 HTTPS를 이용한다.
일반적으로 IP 주소는 출발지부터 목적지까지 유지되고, MAC 주소는 각 네트워크 구간에 맞게 라우터를 지날 때마다 바뀐다. 다만 NAT를 통과하면 IP 주소나 Port 번호도 변환될 수 있다.
동일한 IP 주소와 전송 프로토콜에서 같은 Port를 같은 조건으로 여러 프로그램이 동시에 수신 대기하는 것은 일반적으로 불가능하다. 다만 서로 다른 IP 주소에 바인딩하거나, TCP와 UDP를 각각 사용하거나, 운영체제의 Port 재사용 기능을 명시적으로 사용하는 등의 경우에는 가능할 수 있다.
localhost는 자신의 장치를 의미하는 호스트 이름이며 보통 127.0.0.1 또는 ::1로 해석된다. 8080은 해당 장치에서 접속할 서비스의 Port 번호이다.
반드시 그렇지는 않다. Ping은 주로 ICMP를 이용해 IP 계층의 도달 가능성을 확인한다. Ping이 성공해도 웹 서버가 실행되지 않거나 TCP 443번 Port가 방화벽에 차단되어 있으면 HTTPS 접속은 실패할 수 있다. 반대로 보안 정책으로 ICMP를 차단했어도 웹 서비스는 정상일 수 있다.
반드시 그렇지는 않다. 서비스가 해당 Port에서 수신 대기해야 하며, 호스트 방화벽과 네트워크 방화벽이 통신을 허용해야 하고, 라우팅과 NAT 설정도 올바르게 구성되어야 한다.
- 이름을 IP로 바꾸는 것은? → DNS
- 목적지 장치를 식별하는 것은? → IP 주소
- 장치 안의 서비스를 식별하는 것은? → Port 번호
- 같은 네트워크 구간에서 사용하는 주소는? → MAC 주소
- 여러 네트워크 사이에서 경로를 선택하는 장비는? → 라우터
- 송신 측에서 계층별 헤더를 붙이는 과정은? → 캡슐화
- 수신 측에서 계층별 헤더를 제거하는 과정은? → 역캡슐화
- TCP Segment에 들어가는 대표 주소 정보는? → 출발지·목적지 Port
- IP Packet에 들어가는 대표 주소 정보는? → 출발지·목적지 IP
- Ethernet Frame에 들어가는 대표 주소 정보는? → 출발지·목적지 MAC
백현빈 → 강민주 → 조수빈 → 임현빈 → 전병훈 → 이건희
(이후 동일한 순서로 반복)