ISO 7계층

계층 번호	계층 이름	주요 기능	프로토콜/예시
7	응용 계층	사용자 인터페이스 제공 및 애플리케이션 서비스	HTTP, FTP, SMTP, DNS 등
6	표현 계층	데이터 형식 변환, 암호화, 압축	TLS, SSL
5	세션 계층	세션 관리 및 연결 제어	NetBIOS, RPC (실제 TCP/IP에서는 별도 구현 없이 상위층에서 처리)
4	전송 계층	신뢰성 있는 데이터 전송, 오류 검출 및 수정	TCP, UDP
3	네트워크 계층	라우팅, 논리적 주소 지정 (IP) 및 경로 결정	IP, ICMP, IGMP
2	데이터 링크 계층	물리 주소 (MAC) 관리, 프레임 구성 및 오류 검출	Ethernet, PPP, Wi-Fi (IEEE 802.11)
1	물리 계층	전기적 신호, 케이블 등 물리적 전송 매체 관리	DSL, ISDN, 광케이블, USB 등

전송 계층 – TCP와 UDP

전송 계층은 네트워크 상에서 호스트 간에 데이터를 주고받을 때, 단순히 호스트끼리가 아니라 호스트 내의 특정 프로세스까지 데이터를 전달할 수 있도록 하는 역할을 수행합니다. 이 문서에서는 TCP와 UDP의 목적, 특징, 연결 수립 및 종료 과정, 그리고 상태 관리에 대해 자세히 다룹니다.

TCP와 UDP의 목적과 특징

포트를 통한 프로세스 식별

IP/MAC 주소와 포트 번호

IP 주소와 MAC 주소는 패킷을 송수신하는 호스트를 식별하지만, 실제 데이터는 호스트 내의 특정 프로세스로 전달되어야 합니다.
각 프로세스는 고유한 포트 번호를 할당받으므로, ‘IP 주소:포트 번호’의 조합을 통해 특정 프로세스를 정확하게 식별할 수 있습니다.

포트 번호의 범위와 종류

포트 번호는 16비트로 표현되어 0부터 65535까지 총 65,536개의 번호를 가집니다.
번호의 사용 목적에 따라 세 가지 범주로 나뉩니다.

NAT와 NAPT

NAT (Network Address Translation)

기본 개념:

NAT는 내부 네트워크(사설 IP 대역)를 사용하는 호스트들이 외부 네트워크(인터넷)와 통신할 때, 내부에서 사용하던 사설 IP 주소를 외부에서 사용 가능한 공인 IP 주소로 변환해 주는 기술입니다.

1:1 NAT vs. 다대1 NAT:

1:1 NAT (Static NAT):

내부의 각 호스트에 대해 하나의 고정된 공인 IP를 할당합니다. 이 경우 NAT 기기는 내부 IP와 공인 IP 간에 일대일 매핑을 유지하므로 포트 번호 변환 없이도 데이터가 올바른 호스트로 전달될 수 있습니다.
단점: 공인 IP 주소가 충분할 때만 가능하며, 자원이 한정된 환경에서는 비효율적입니다.
일반적인 NAT (대부분은 PAT 또는 NAPT):
대부분의 가정이나 소규모 네트워크에서는 여러 내부 호스트가 하나 또는 소수의 공인 IP를 공유합니다.
이 경우 포트 번호를 추가로 사용하여 내부 호스트들을 구분하는데, 이것이 바로 NAPT (Network Address Port Translation)입니다.

NAPT (Network Address Port Translation)

포트 번호의 역할:

내부의 여러 호스트가 하나의 공인 IP를 공유하는 상황에서, 단순히 IP 주소만 변환한다면 외부에서 들어오는 응답 패킷이 어느 내부 호스트로 전달되어야 하는지 구분할 수 없습니다.
NAPT는 이 문제를 해결하기 위해 포트 번호도 함께 변환합니다.
예를 들어, 내부 호스트 A와 B가 모두 사설 IP를 사용하다가 외부로 나갈 때, NAT 기기는 두 호스트의 IP를 동일한 공인 IP로 변환하면서 A에는 포트 6200, B에는 포트 6201 등 서로 다른 포트 번호를 할당합니다.
이를 통해 외부에서 들어오는 응답 패킷은 공인 IP와 해당 포트 번호를 기준으로 NAT 기기가 원래의 내부 호스트로 올바르게 전달할 수 있습니다.

(비)신뢰성과 (비)연결형 보장

TCP (Transmission Control Protocol)

연결형 프로토콜로, 데이터 전송 전에 반드시 연결 수립(쓰리 웨이 핸드셰이크) 과정을 거칩니다.
신뢰성 보장:
오류 제어: 재전송, 중복 ACK, 타임아웃 등을 통해 전송 오류를 감지하고 복구합니다.
흐름 제어: 수신 윈도우를 통해 수신 호스트가 한 번에 처리할 수 있는 데이터 양을 조절합니다.
혼잡 제어: 혼잡 윈도우 값을 조절(대표 알고리즘 AIMD)하여 네트워크 혼잡 상황에서 전송량을 제한합니다.
TCP 헤더는 UDP 헤더에 포함된 기본 필드(송신지/수신지 포트, 길이, 체크섬) 외에 순서 번호, 확인 응답 번호, 제어 비트(SYN, ACK, FIN 등)가 추가되어 복잡하지만 그만큼 안정적인 전송을 지원합니다.

UDP (User Datagram Protocol)

비연결형 프로토콜로, 연결 수립과 종료 과정 없이 단순히 데이터를 전송합니다.
별도의 신뢰성 보강 기능이 없으므로 전송 속도는 빠르지만 데이터 손실이나 순서 뒤바뀜이 발생할 수 있습니다.
UDP 헤더는 매우 단순하여 빠른 전송이 필요한 애플리케이션에 적합합니다.

TCP의 연결부터 종료까지

TCP는 데이터 전송 전에 연결을 수립하고, 전송 후 연결을 종료하는 과정을 통해 상태를 유지하면서 안정적인 통신을 지원합니다.

TCP의 연결 수립

쓰리 웨이 핸드셰이크 (Three-Way Handshake)

TCP 연결을 수립하기 위해 다음의 3단계를 수행합니다.

1. [A → B] SYN 세그먼트 전송
호스트 A가 SYN 비트가 1인 세그먼트를 보내며, 자신의 초기 순서 번호를 포함합니다.
2. [B → A] SYN+ACK 세그먼트 전송
호스트 B는 A의 요청에 대해 SYN과 ACK 비트가 1인 세그먼트를 전송하며, 자신의 순서 번호와 A의 세그먼트에 대한 확인 응답 번호를 포함합니다.
3. [A → B] ACK 세그먼트 전송
호스트 A가 B의 응답을 확인하는 ACK 세그먼트를 보내 연결이 확정됩니다.

용어

액티브 오픈 (Active Open): 먼저 SYN을 전송하여 연결 요청을 시작하는 호스트 (예: A).
패시브 오픈 (Passive Open): 연결 요청을 수신하여 응답하는 호스트 (예: B).

TCP의 오류, 흐름 및 혼잡 제어

오류 제어 (Error Control)

데이터 전송 중 오류가 발생하면, 중복 ACK나 타임아웃을 통해 오류를 감지하고 해당 세그먼트를 재전송합니다.

파이프라이닝 전송 (Pipelining Transmission)

ACK 응답을 기다리지 않고 여러 세그먼트를 연속해서 전송하여 전송 효율을 극대화합니다.

흐름 제어 (Flow Control)

수신 호스트가 한 번에 처리할 수 있는 데이터의 양(수신 윈도우)을 고려하여 송신 속도를 조절합니다.
TCP 헤더의 윈도우 필드를 통해 이 정보를 전달합니다.

혼잡 제어 (Congestion Control)

네트워크 내 혼잡 상황(중복 ACK, 타임아웃 등)을 감지하여 혼잡 윈도우 값을 조절함으로써 전송량을 제한합니다.
대표적 알고리즘 AIMD (Additive Increase/Multiplicative Decrease)는 혼잡이 없으면 선형적으로 증가하고, 혼잡이 감지되면 윈도우를 절반으로 감소시킵니다.

TCP의 종료

연결 종료 (Four-Way Handshake)

TCP 연결 종료는 다음 4단계로 이루어집니다.

1. [A → B] FIN 세그먼트 전송
호스트 A가 FIN 비트를 설정한 세그먼트를 보내 연결 종료를 요청합니다.
2. [B → A] ACK 세그먼트 전송
호스트 B가 A의 FIN 요청을 확인하는 ACK를 전송합니다.
3. [B → A] FIN 세그먼트 전송
호스트 B가 자체 FIN 세그먼트를 보내 종료를 요청합니다.
4. [A → B] ACK 세그먼트 전송
호스트 A가 B의 FIN 요청을 확인하는 ACK를 보내고, 이후 A는 일정 시간(TIME-WAIT) 후 완전히 종료됩니다.
용어
액티브 클로즈 (Active Close): 먼저 FIN을 전송하여 종료를 시작하는 호스트 (예: A).
패시브 클로즈 (Passive Close): 종료 요청에 응답하는 호스트 (예: B).
TIME-WAIT: 액티브 클로즈 호스트가 마지막 ACK 후 일정 시간 동안 대기하여 재전송 가능성에 대비하는 상태입니다.

TCP의 상태 관리

TCP는 연결 수립부터 종료까지 다양한 상태(state)를 유지하며, 각 상태는 네트워크 통신의 현재 상황을 나타냅니다.

연결 전 상태

CLOSED: 아무런 연결도 없는 상태.
LISTEN: 서버가 연결 요청(SYN)을 기다리는 상태.

연결 수립 과정

SYN-SENT: 액티브 오픈 후, SYN 전송 후 응답 대기 상태.
SYN-RECEIVED: 패시브 오픈 후, SYN+ACK 전송 후 ACK 대기 상태.
ESTABLISHED: 쓰리 웨이 핸드셰이크 완료 후 데이터 전송이 가능한 상태.

연결 종료 과정

FIN-WAIT-1: FIN 전송 후 ACK 대기 상태.
FIN-WAIT-2: ACK 수신 후, 상대방의 FIN 전송 대기 상태.
CLOSE-WAIT: FIN 수신 후, FIN 전송 대기 상태.
LAST-ACK: FIN 전송 후 마지막 ACK 대기 상태.
TIME-WAIT: 마지막 ACK 전송 후 일정 시간 대기하는 상태.
CLOSING: 양쪽이 동시에 FIN을 보내고 서로의 ACK를 기다리는 상태.

응용 계층 – HTTP의 기초

HTTP는 웹 상에서 다양한 자원(HTML, 이미지, 동영상 등)을 송수신하는 애플리케이션 계층 프로토콜입니다. 이 장에서는 DNS, URI/URL, HTTP의 특징, 메시지 구조, 메서드, 상태 코드 및 주요 헤더에 대해 다룹니다.

DNS와 URI/URL

도메인 네임과 DNS

도메인 네임 (Domain Name)

IP 주소만으로 호스트를 식별하는 것은 번거로우며, IP 주소는 변경될 가능성이 있으므로 사람이 기억하기 쉬운 문자열(예: www.example.com)을 사용합니다.
도메인 네임은 계층적 구조를 가지며, 점(.)을 기준으로 여러 단계(루트, 최상위, 2단계, 3단계 등)로 구성됩니다.
루트 도메인 (Root Domain): .

→ 보통은 생략되며, 도메인 네임의 최상위 부분을 나타냅니다.
최상위 도메인 (Top-Level Domain, TLD): .com
→ 도메인 이름의 마지막 부분으로, 인터넷 도메인 네임 시스템에서 최상위 역할을 합니다.

DNS (Domain Name System)

도메인 네임과 IP 주소를 매핑하는 역할을 하며, 전 세계 여러 네임 서버가 계층적이고 분산적으로 관리됩니다.
클라이언트는 먼저 로컬 네임 서버에 질의하며, 로컬 서버에 해당 정보가 없을 경우 루트, TLD, 하위 도메인 서버 순으로 상위 네임 서버에 질의하여 최종적으로 매핑 정보를 얻습니다.
DNS는 응답 시간을 단축하기 위해 DNS 캐시를 사용하며, 공개 DNS 서버(예: 구글 8.8.8.8, 클라우드플레어 1.1.1.1)도 활용할 수 있습니다.
도메인 네임과 IP 주소의 매핑 정보는 DNS 자원 레코드로 저장되며, 각 레코드는 이름, 값, 레코드 타입 및 TTL(Time To Live) 정보를 포함합니다.

자원과 URI/URL

자원 (Resource)

네트워크 상에서 주고받는 최종 대상(HTML 문서, 이미지, 동영상, JSON 등)을 의미합니다.

URI (Uniform Resource Identifier)

자원을 식별하는 통일된 방식으로, URN (Uniform Resource Name)과 URL (Uniform Resource Locator)로 구분되나, 실제 웹에서는 위치 기반의 URL이 주로 사용됩니다.

URL의 구조

URL은 다음과 같은 요소로 구성됩니다:

scheme: 자원에 접근하는 방법 (예: http, https)
authority: 호스트(도메인 네임 또는 IP)와 선택적으로 포트 번호 (예: example.com:80)
path: 자원의 위치를 계층적으로 표현 (예: /home/images/a.png)
query: 추가 매개변수 (예: ?q=network)
fragment: 자원의 특정 부분을 지정 (예: #section1)

HTTP의 특징과 메시지 구조

HTTP는 다양한 종류의 자원을 전송하기 위한 애플리케이션 계층 프로토콜로, 그 설계 목표와 구조는 다음과 같이 설명할 수 있습니다.

HTTP의 특징

요청-응답 기반 프로토콜

클라이언트가 HTTP 요청 메시지를 보내면, 서버는 이에 대응하는 응답 메시지를 전송합니다.

미디어 독립적 프로토콜

HTML, 이미지, JSON, XML, PDF 등 다양한 미디어 타입의 데이터를 주고받을 수 있습니다.
미디어 타입은 타입/서브타입 형식(예: text/html, application/json)으로 표현됩니다.

스테이트리스 (Stateless) 프로토콜

서버는 각 HTTP 요청을 독립적으로 처리하며, 이전 요청의 상태를 기억하지 않습니다.
이러한 설계는 서버의 확장성(scalability)과 견고성(robustness)을 높이는 데 기여합니다.

지속 연결 (Persistent Connection)

초기 HTTP/1.0은 요청 후 연결을 종료(비지속 연결)했으나, HTTP/1.1부터는 keep-alive를 통해 하나의 TCP 연결에서 여러 요청/응답을 처리할 수 있습니다.

HTTP 버전 비교

HTTP/1.1: 지속 연결, 평문 텍스트 메시지 전송, 콘텐츠 협상 등 기본 기능 제공
HTTP/2.0: 바이너리 기반 전송, 헤더 압축, 서버 푸시, 멀티플렉싱 등을 통해 HOL(Head-Of-Line) 블로킹 문제 개선
HTTP/3.0: UDP 기반의 QUIC 프로토콜을 사용하여 전송 속도 및 연결 지연 문제를 개선

HTTP 메시지 구조

HTTP 메시지는 다음 세 부분으로 구성됩니다.

시작 라인 (Start-Line)

요청 메시지: 요청 라인 — 메서드, 요청 대상, HTTP 버전
예: GET /index.html HTTP/1.1
응답 메시지: 상태 라인 — HTTP 버전, 상태 코드, 이유 구문
예: HTTP/1.1 200 OK

필드 라인 (Header Lines)

하나 이상의 HTTP 헤더가 헤더 이름: 헤더 값 형식으로 포함됩니다.

메시지 본문 (Message Body)

요청의 경우 서버에 전송할 데이터, 응답의 경우 클라이언트에 전달할 자원(HTML, 이미지 등)이 포함됩니다.

HTTP 메서드와 상태 코드

HTTP의 메서드와 상태 코드는 클라이언트와 서버 간의 상호작용 및 요청 결과를 명확하게 전달하기 위한 핵심 요소입니다. 아래 표를 통해 주요 HTTP 메서드와 상태 코드에 대해 자세하고 보강된 설명을 확인할 수 있습니다.

HTTP 메서드

메서드	용도	설명
GET	자원 조회(습득)	서버에 저장된 자원을 조회할 때 사용하며, URL에 포함된 정보로 대상 자원을 지정합니다. 요청 본문이 없으며, 캐싱과 북마크에 적합합니다.
HEAD	자원 헤더 조회	GET과 거의 동일하나, 응답 메시지에 본문 없이 헤더 정보만 반환합니다. 주로 메타 데이터 확인이나 캐시 유효성 검사에 사용됩니다.
POST	특정 작업 요청 (주로 자원 생성)	서버에 데이터를 전송하여 새로운 자원을 생성하거나, 서버 측에서 특정 작업(예: 폼 제출, 파일 업로드)을 처리하도록 요청합니다.
PUT	자원 전체 대체	요청 메시지에 포함된 데이터로 기존 자원을 완전히 대체(덮어쓰기)합니다. 자원이 존재하지 않을 경우 새로 생성하는 경우도 있습니다.
PATCH	자원의 일부분 수정	PUT과 달리 자원의 일부만 수정할 때 사용되며, 부분 업데이트를 위해 변경할 필드만 포함한 요청을 보냅니다.
DELETE	자원 삭제	서버에 존재하는 특정 자원을 삭제하도록 요청합니다. 삭제 작업 후 응답 코드 및 결과 메시지로 작업 완료 여부를 확인합니다.
CONNECT	양방향 터널 연결	클라이언트와 서버 간에 양방향 터널(예: SSL 터널)을 형성하여, 주로 프록시 서버와의 연결에 사용됩니다.
OPTIONS	지원 메서드 및 통신 옵션 확인	해당 URL에 대해 서버가 지원하는 메서드 목록과 기타 통신 옵션을 확인할 때 사용되며, CORS 정책 확인에도 활용됩니다.
TRACE	루프백 테스트	클라이언트가 요청 메시지를 그대로 반영하여 서버가 전송한 응답을 통해 경로상의 수정이나 변형 여부를 테스트하는 데 사용됩니다.

HTTP 상태 코드

상태 코드	분류	설명
100-199	정보성 상태 코드	요청을 받았으며, 현재 처리 중임을 나타냅니다. 예: 100 Continue – 초기 요청 부분은 성공적으로 수신되었음을 알림.
200-299	성공 상태 코드	요청이 성공적으로 처리되었음을 의미합니다.
200	OK	요청이 성공적으로 완료되었으며, 요청한 자원이 정상적으로 반환됨.
201	Created	요청이 성공적이며, 그 결과로 새로운 자원이 생성됨 (예: POST 요청 후).
202	Accepted	요청은 성공적으로 접수되었으나, 아직 처리가 완료되지 않음 (비동기 처리 상황 등에서 사용).
204	No Content	요청이 성공적이지만, 반환할 메시지 본문이 없음 (예: DELETE 요청 후).
300-399	리다이렉션 상태 코드	클라이언트가 다른 URL로 재요청해야 함을 의미합니다.
301	Moved Permanently	요청한 자원이 영구적으로 새로운 위치로 이동하였음을 나타내며, 이후 요청은 새 URL로 보내야 함 (메서드 변경 가능성 있음).
308	Permanent Redirect	영구적 리다이렉션을 나타내며, 재요청 시 원래의 HTTP 메서드가 그대로 유지됨.
302	Found	일시적으로 다른 URL로 이동하였음을 나타내며, 클라이언트가 재요청할 때 메서드 변경 가능성이 있음.
303	See Other	다른 URL로 재요청할 것을 권장하며, 재요청 시 반드시 GET 방식으로 변경됨.
307	Temporary Redirect	일시적 리다이렉션을 나타내며, 재요청 시 기존의 HTTP 메서드가 유지됨.
304	Not Modified	클라이언트가 캐시하고 있는 자원이 최신임을 나타내며, 변경된 내용이 없으므로 재전송할 필요 없음.
400-499	클라이언트 에러 상태 코드	클라이언트의 요청이 잘못되었거나, 인증/권한 문제 등으로 요청을 처리할 수 없음을 나타냅니다.
400	Bad Request	요청 메시지의 문법이나 형식에 오류가 있어 서버가 요청을 이해하지 못함.
401	Unauthorized	요청한 자원에 접근하기 위해서는 인증이 필요함을 나타내며, 인증 정보를 제공하지 않았거나 잘못된 경우.
403	Forbidden	인증은 되었으나, 해당 자원에 대한 접근 권한이 부족하여 요청이 거부됨.
404	Not Found	요청한 자원을 서버에서 찾을 수 없음.
405	Method Not Allowed	요청한 HTTP 메서드가 해당 자원에서 지원되지 않음을 나타냄.
500-599	서버 에러 상태 코드	서버 내부의 문제 또는 중간 서버의 오류로 인해 요청을 처리할 수 없음을 나타냅니다.
500	Internal Server Error	서버 내부의 에러로 인해 요청을 처리할 수 없음. 보안상의 이유로 자세한 내부 오류 내용은 공개하지 않음.
502	Bad Gateway	클라이언트와 서버 사이의 중간 서버가 잘못된 응답을 받아 발생하는 오류를 의미함.

HTTP 주요 헤더

HTTP 헤더는 요청 및 응답 메시지에 부가 정보와 제어 정보를 담아 전송하며, 이를 통해 클라이언트와 서버 간의 통신 조건을 조율합니다.

요청 메시지에서 주로 활용되는 HTTP 헤더

Host

요청 대상 호스트(도메인 또는 IP, 선택적으로 포트 번호)를 명시합니다.
요청 라인과 함께 URL을 유추할 수 있습니다.

User-Agent

요청을 보낸 클라이언트(예: 웹 브라우저)의 정보(브라우저 종류, 운영체제, 렌더링 엔진 등)를 포함합니다.
이를 통해 서버는 클라이언트 환경에 맞춘 응답을 제공할 수 있습니다.

Referer

요청 직전에 사용자가 머무르던 URL을 전달하여, 클라이언트의 유입 경로를 파악하는 데 사용됩니다.

응답 메시지에서 주로 활용되는 HTTP 헤더

Server

응답을 보낸 서버의 정보(운영체제, 웹 서버 종류 등)를 명시합니다.

Allow

해당 URL에 대해 서버가 지원하는 HTTP 메서드 목록을 전달하며, 405 에러 발생 시 참고할 수 있습니다.

Location

리다이렉션이 발생하거나 새로운 자원이 생성된 경우, 그 위치(URL)를 클라이언트에 안내합니다.

요청과 응답 메시지 모두에서 활용되는 HTTP 헤더

Date: 메시지가 생성된 날짜와 시간을 표시합니다.
Content-Length: 메시지 본문의 바이트 단위 크기를 명시합니다.
Content-Type: 메시지 본문에 사용된 미디어 타입(예: text/html; charset=UTF-8)을 나타냅니다.
Content-Language: 메시지 본문에 사용된 언어(예: ko-KR, en-US)를 명시합니다.
Content-Encoding: 메시지 본문이 압축 또는 인코딩된 방식을 나타내며, 예를 들어 gzip, deflate, br 등이 사용됩니다.
Connection: 연결 유지 방식(예: keep-alive 지속 연결, close 연결 종료)을 지정하여 후속 요청 처리 방식을 결정합니다.