A(송신자)에서 B(수신자)로 데이터가 이동하면서 각 계층을 거치며 캡슐화/역캡슐화(encapsulation/decapsulation)

구간	계층	역할	장비
A (Source)	Application~Physical	데이터를 생성하고 물리적으로 전송 시작	PC
Switch	Data link, Physical	MAC 주소 기반으로 프레임 전달	스위치
Router	Network, Data link, Physical	IP 주소 기반으로 라우팅	라우터
Switch	Data link, Physical	목적지 LAN으로 전달	스위치
B (Destination)	Physical~Application	데이터를 수신하고 상위 계층으로 전달	PC

📦 캡슐화(encapsulation)

A의 Application 계층에서 생성된 데이터는
→ Transport 계층에서 세그먼트(segment)로 변환
→ Network 계층에서 패킷(packet)
→ Data link 계층에서 프레임(frame)
→ Physical 계층에서 비트(bit)로 변환되어 전송됩니다.

📬 역캡슐화(decapsulation)

B는 Physical 계층부터 데이터를 수신해서
→ 상위 계층으로 하나씩 포장을 벗겨내어
→ 최종적으로 Application 계층에서 원본 데이터를 얻습니다.

📤 송신 측(Source)

Application 계층
- 메시지(Message, M) 생성.
- 예: 이메일 내용, 웹 요청, 파일 데이터 등.
Transport 계층
- 세그먼트(Segment)를 만듦: 메시지 앞에 Transport 헤더(Ht) 추가.
- 이 헤더에는 포트 번호 등 정보가 포함됨. [Ht][M]
Network 계층
- 패킷/데이터그램(Datagram)으로 변환: Network 헤더(Hn) 추가.
- 이 헤더에는 출발지 IP와 목적지 IP 정보가 들어감. [Hn][Ht][M]
Data Link 계층
- 프레임(Frame): Link 헤더(Hl) 추가.
- MAC 주소(출발지/목적지)가 포함됨. [Hl][Hn][Ht][M]
Physical 계층
- 비트(bit) 단위로 변환되어 케이블이나 무선 전파로 전송됨.

🔁 2. 중간 장비: Switch & Router

🪧 스위치 (2계층 장비)

Data Link 계층까지만 이해함.
MAC 주소 기반으로 목적지를 찾아 프레임을 전달.
헤더는 수정하지 않고 그대로 목적지 쪽으로 전달.

프레임 [Hl][Hn][Ht][M] 그대로 전달

🛰 라우터 (3계층 장비)

Network 계층까지 이해함.
프레임의 Link 헤더(Hl)는 제거하고 새로운 Link 헤더를 붙여서 다음 홉으로 전달함.
(즉, Link 계층 헤더는 홉마다 바뀜)
Network 헤더(Hn)는 그대로 유지됨.
(즉, IP 주소는 송신~수신까지 동일) [Hl(새로운)][Hn][Ht][M]

DHCP

IP 주소, 첫번째 홉 라우터, DNS 주소를 받는 프로토콜
DHCP → UDP → IP → 802.3 Ethernet(Data Link) → Physical
broadcast 이더넷 프레임 LAN으로 전송(FFFFFFFFFFF)
IP 주소, 첫번째 홉 라우터, DNS 주소를 DHCP ACK과 함께 응답(다시 캡슐화)
DHCP 클라이언트가 응답 받음

DNS Query

ARP 브로드캐스트 통해서 외부로 향하는 라우터(first hop router)의 MAC주소를 알아냄
해당 라우터 주소로 DNS Query 쏨
라우터를 통해 외부로 나간다음 목적지 네트워크로 IP 데이터그램이 이동(DNS 쿼리는 UDP라서)
목적지 네트워크 쪽에서 DNS 서버로 라우팅됨
DNS 쪽에서 역캡슐화하고, IP 주소를 클라이언트 쪽으로 다시 응답

HTTP 든 TCP 연결

클라이언트가 먼저 웹 서버에 TCP Socket을 열음
3 way handshake(SYN → SYN, ACK → ACK)
Http 요청을 TCP Socket으로 쏨
HTTP 든 IP datagram(하나의 IP 패킷을 의미) 요청이 도메인으로 라우팅됨
웹 서버는 HTTP 응답을 보냄
HTTP 응답이 다시 클라이언트한테 돌아감

프로토콜

프로토콜은 서로 다른 장치·소프트웨어가 데이터를 주고받을 때 따라야 하는 규칙
무엇을, 언제, 어떻게, 얼마나, 오류가 나면 어떻게 처리할지까지 표준화
프로토콜들이 계층으로 쌓여 동작하며, 각 계층은 명확한 역할과 인터페이스로 상호 운용성을 보장

인터넷 구조

네트워크 엣지

네트워크 엣지(Edge)는 내부 네트워크가 외부 네트워크(인터넷)와 만나는 경계
가정·기업·모바일 환경에서 사용자의 트래픽이 처음 진입·이탈하는 지점으로, 모뎀/라우터, 방화벽, ISP 액세스 포인트, CDN의 엣지 서버, 5G 기지국/엣지 MEC 노드 등
여기서 주소 할당, NAT, 방화벽 정책, 캐싱·압축, TLS 종료, DDoS 방어 같은 처리가 이뤄져 지연을 줄이고 보안을 강화
클라우드에서는 사용자가 가까운 엣지 로케이션을 통해 리소스에 접속하며, 글로벌 서비스는 엣지에 캐시와 컴퓨팅을 배치해 성능을 높임

Access networks, physical media

유선, 무선형 통신 링크

Network core

서로 연결된 라우터들
네트워크들의 네트워크

Access networks

Cable-based access

Cable headend - 중앙 통제 지점(허브 역할)

위성/지상파/IP 정보 수신

인코딩/디코딩

멀티플렉싱 및 변조

증폭 및 전송

FDM(주파수 분할 다중화)

하나의 물리 매체(동축/광섬유/무선 등)를 여러 개의 주파수 서브밴드로 분할해, 각 밴드에 별도 신호를 실어 동시에 보내는 방식
각 채널은 서로 겹치지 않도록 가드 밴드를 두고, 송·수신측에서 밴드패스 필터로 분리
라디오 방송의 AM/FM 채널, 케이블 TV, 아날로그 전화망의 다중화, OFDM의 전신 등에서 쓰였고, 오늘날엔 OFDM처럼 직교 부반송파로 확장되어 Wi‑Fi/LTE/5G 등 핵심 기술로 발전
장점은 동시성·지연 최소화이고, 단점은 주파수 자원 비효율(가드 밴드), 채널 간 간섭 관리가 까다롭다

HFC

광 케이블 + 동축 케이블

digital Subscriber line

DSL은 주거용 액세스 네트워크(residential access nets) 를 종단 시스템(end systems)에서 에지 라우터(edge router)로 연결하는 방식
DSL 모뎀(DSL modem): 사용자 측에 위치하여 데이터를 처리 ◦ 스플리터(splitter): 사용자 측에서 데이터와 음성 신호를 분리 ◦ DSLAM (DSL Access Multiplexer): 중앙 사무실(central office)에 위치하며, DSL 액세스 다중화 장치 역할

Wireless access networks

access point 를 통해 라우터와 종단 시스템 연결

Wireless local area networks(WLANs)
- 가정의 공유기를 통해서 연결
Wide-area cellular access networks
- 기지국의 network operator
모두 다중 엑세스를 위해 CSMA/CA 방식 사용

CSMA/CA (Carrier Sensing Mulitple Access with Collision Avoidance) 이더넷 환경에서의 다중 접속 과정에서 RTS/CTS 방식을 통해 충돌을 미리 회피하는 방법 무선랜 방식은 충돌 감지가 어렵기 때문에 회피 전략 사용 송신을 원하는 주체가 RTS(Request To Send)를 보내면 수신 측이 CTS(Clear To Send)를 보내고 난 뒤에 전송 통신이 끝나면 ACK을 알려 끝났음을 알려줌. 경쟁 윈도우 방식을 통해 랜덤한 시간동안 대기

Application layer

아키텍처

Client-Server 아키텍처

서버의 경우

항상 켜져있음
영구적인 IP 주소
스케일링을 위한 데이터 센터

클라이언트의 경우

서버와 통신
즉각적인 연결
동적인 IP 주소
서버와 직접적으로 연결되어 있지 않음

P2P 아키텍처

P2P 아키텍처는 항상 서버가 켜져 있는 구조가 아니다. P2P 아키텍처는 동등한 노드들이 서로 직접 자원과 데이터를 교환하는 분산 구조로서 작동한다.

P2P는 중앙 서버 없이(또는 최소한으로) 참여자 각자가 동시에 제공자와 소비자 역할을 수행한다. 연결·검색·라우팅·전송을 네트워크의 말단 노드들이 협력해 처리하므로 확장성이 높고 단일 장애점이 줄어든다는 장점을 가지고 있다. 왜냐면 한 노드가 참여하게 되면, 그 노드 또한 이러한 작업에 참여하기 때문에 혼자서 확장성을 조절할 수 있다.

하지만 이러한 P2P의 특성 상, Peer 그룹을 제대로 유지하지 않는다면 네트워크가 급격하게 성능이 안좋아질 수 있으므로 이에 대한 대비가 필요하다.

Socket

소켓은 애플리케이션이 네트워크로 데이터를 송수신하기 위한 통신 엔드포인트이다.

운영체제가 제공하는 추상화로, 프로세스가 소켓을 생성해 IP 포트에 바인딩하고 연결(TCP)하거나 메시지를 주고받기(UDP) 위해 사용한다.

서버는 소켓을 listen/accept로 클라이언트의 연결을 받고, 클라이언트는 connect로 서버에 접속합니다. 그 뒤에는 파일처럼 read/write 또는 send/recv로 바이트 스트림(TCP)이나 데이터그램(UDP)을 교환한다. 소켓은 응용 계층의 코드가 전송 계층(TCP/UDP)과 네트워크 계층(IP)을 다루도록 해주는 표준 인터페이스라고 이해하면 된다.

따라서 소켓은 클라이언트와 서버 두 곳에 각각 위치하며, 소켓을 통해 메시지를 교환하면서 데이터를 송수신 할 수 있는 것이다.

메시지를 받기 위해서는 식별자가 필요한데, 특정 호스트에 대한 주소 말고도 호스트가 실행하고 있는 특정 프로세스에 요청을 전달해야 하므로 IP 주소와 포트 넘버가 필요하다.

그렇다면 이러한 애플리케이션이 하는 전송 서비스에서 필요한 것은 무엇일까?

데이터 무결성(data integrity)
- 데이터가 전체 수명주기 동안 정확하고 일관되며 변조되지 않았음을 보장
타이밍
- 게임과 같은 요소들은 지연 시간이 중요하기 때문에 타이밍 또한 중요한 요소이다.
처리량(Throughput)
- 단위 시간당 시스템이 처리하는 작업이나 데이터의 양
보안(security)
- 데이터 무결성, 암호화 등

HTTP Connection

HTTP Connection에는 비지속 연결과 지속 연결 두 가지 방식이 존재한다.

비지속 연결의 경우, 한번 TCP 연결이 열리면 최대 하나의 객체(고유의 URL을 가진 파일)을 보낸 후에 연결이 바로 닫히기 때문에 만약 하나의 HTML 파일에 여러 참조 객체들이 엮여 있으면 그 때마다 연결하고 파일을 받아야 하기 때문에 여러 TCP 연결이 필요하다.

이처럼 RTT(Round Trip Time, 패킷이 클라이언트에서 서버로 갔다가 다시 돌아오는 시간)는 객체마다 TCP 연결 설정 과정, 메시지 교환에 2RTT가 들며, 추가적으로 객체의 전송 시간까지 고려해야 하기 때문에 전체적인 시간은 2RTT + 파일 전송 시간이 된다.

반면 지속 연결(Persistent) HTTP의 경우에는 TCP 연결이 서버에서 계속 열려 있는 상태기 때문에 여러 객체들이 하나의 TCP 연결을 통해서 오고갈 수 있다. 그렇게 되면 추가적으로 연결 과정에서 발생하는 오버헤드를 줄일 수 있다.

HTTP Message

HTTP 메시지는 기본적으로 캐리지 리턴(/r)을 통해서 각 라인을 구별하며, 각 줄에서는 띄어쓰기를 통해서 구별한다

실제 생김새는 위와 같다.

기본적으로 HTTP는 무상태성을 지니기 때문에, 서버가 항상 요청마다 클라이언트의 상태를 가지고 있지 않다. 이러한 특성 때문에 클라이언트와 서버 간의 상태 보존을 위해서 사용하는 것이 cookie이다. HTTP 쿠키는 브라우저가 서버로부터 받은 작은 데이터로, 이후 요청마다 함께 보내 상태를 유지한다.

쿠키는 본질적으로 서버가 응답 헤더로 지시한 키-값을 브라우저가 저장하고, 같은 도메인으로의 요청에 자동 첨부해 세션 유지와 사용자 식별을 가능하게 만드는 메커니즘이다.

이러한 특성을 이용하여 사용자 인증, 장바구니, 추천 알고리즘 등에 활용한다

동작 원리

• 서버 → 브라우저: 응답의 Set-Cookie 헤더로 쿠키를 설정합니다. • 브라우저 → 서버: 이후 같은 도메인/경로/보안 조건이 맞으면 Cookie 헤더로 쿠키를 전송합니다. • 만료·삭제: Expires/Max-Age로 유효기간을 제어하며, 브라우저나 서버가 재지정해 삭제할 수 있습니다.

주요 속성

• Name=Value: 쿠키의 기본 데이터. • Domain/Path: 어느 호스트·경로에 대해 쿠키를 보낼지 범위를 제한. • Expires/Max-Age: 영속 쿠키(브라우저 재시작 후에도 유지) vs 세션 쿠키(탭/세션 종료 시 삭제). • Secure: HTTPS 요청에만 전송. • HttpOnly: 자바스크립트에서 접근 불가(XSS로부터 탈취 위험 감소). • SameSite: 크로스 사이트 전송을 제어해 CSRF 위험을 낮춤. Strict/Lax/None(→ None은 Secure 필요).

서버 세션과의 관계

• 세션 쿠키: 서버가 세션 ID를 발급해 쿠키에 담고, 서버 메모리·스토어에서 상태를 관리. • 토큰 쿠키: JWT 같은 토큰을 쿠키에 저장해 무상태 인증을 구현.

보안 이슈

하지만 이러한 쿠키 또한 보안적인 문제가 있다. 위 그림과 같이 서드 파티 쿠키로 활용할 경우에는 내가 직접 제어하는 것이 아닌, 다른 사이트에서 광고를 받아오는 과정에서 쿠키가 자동으로 함께 넘어가기 때문에 이러한 서드 파티에서는 사용자의 브라우저 기록 등을 알 수 있는 도구가 되기도 한다.

이 외에도 보안 이슈는 • XSS: HttpOnly로 스크립트 접근을 차단하고, CSP·입력검증으로 예방. • CSRF: SameSite=Lax/Strict 사용, 또는 토큰(Double Submit/Origin 체크). • 중간자·도청: Secure로 HTTPS만 허용, 전송 중 보호. • 스코프 최소화: Domain/Path를 좁게, 필요 최소한의 만료시간. 를 통해 예방해야 한다.

Web Cache

Web cache는 자주 요청되는 웹 콘텐츠를 중간에 저장해 재사용하여 지연과 트래픽을 줄인다.

웹 캐시는 브라우저·프록시·CDN·서버 등 다양한 층에서 동작하며, 동일하거나 조건부로 유효한 응답을 재활용해 성능과 비용을 개선한다. 핵심은 서버가 제공하는 캐시 제어 헤더를 해석해 유효기간과 재검증 규칙을 따르게 해야 한다는 것이다 이러한 웹 캐시는 각 기관이나 학교 등에서도 활용이 가능한데, 자주 가져오는 에셋들에 대해서 대역폭을 늘리는 것보다 로컬 웹 캐시를 히트하게 해서 캐시된 콘텐츠들을 가져오게 하는게 싸게 먹히기 때문에 LAN을 통해 접근할 수 있는 로컬 웹 캐시를 사용하기도 한다.

캐시 계층과 동작

브라우저 캐시: 사용자의 로컬에 저장. 이미지·CSS·JS 등 정적 리소스에 효과적.
프록시/중간 캐시: 기업 프록시나 ISP·CDN 엣지에서 다수 사용자에게 공유.
원서버 캐시: 리버스 프록시(Nginx, Varnish)로 백엔드 부하를 줄임.

요청이 오면 캐시는 저장된 응답의 유효성을 확인하고, 만료 전이면 바로 반환, 만료 시엔 서버에 재검증 요청을 보낸다

핵심 헤더

Cache-Control: max-age, s-maxage, public/private, no-store, no-cache, must-revalidate 등 정책을 정의.
Expires: 절대 만료 시각(구식이지만 여전히 사용).
ETag: 콘텐츠 식별 해시. If-None-Match로 조건부 요청(304 Not Modified) 지원.
Last-Modified: 마지막 변경 시각. If-Modified-Since와 함께 재검증.
Vary: Accept-Encoding, User-Agent 등 선택자별로 캐시 키를 분기.

Conditional GET

Conditional GET은 리소스가 바뀌었을 때만 새로 내려받도록 하는 HTTP 요청이다. 왜 조건부라고 하냐면, 클라이언트가 이전 응답의 ETag나 Last-Modified 정보를 담아 조건을 걸고 GET을 보내서 조건에 따라 새롭게 갱신하는 지의 여부를 결정하기 때문이다. 서버는 콘텐츠가 그대로면 304 Not Modified로 본문 없이 응답해 네트워크를 절약하고, 변경됐으면 200 OK와 새 본문을 돌려줍니다.

동작 방식

클라이언트가 저장한 메타데이터를 조건 헤더로 전송:
If-None-Match: 이전의 ETag 값을 전송. 서버 ETag가 같으면 304.
If-Modified-Since: 이전의 Last-Modified 시각을 전송. 그 이후로 수정 없으면 304.
서버 판단의 경우
- 동일/수정 없음 → 304 + 캐시 갱신 규칙만 전달, 본문 생략.
- 변경됨 → 200 + 새 ETag/Last-Modified + 본문. 로 이루어진다.

HTTP/2

HTTP/2는 여러 객체 요청을 가진 HTTP 요청들에 대해서 지연을 줄이고자 새롭게 내놓은 HTTP 표준이다.

기존의 HTTP/1.1에서는 위에서 설명한 바와 같이 기존에 HTTP가 가졌던 매 요청마다 TCP 연결을 수립하는 문제를 해결하고자 하나의 TCP 연결을 통해 여러 요청이나 파이프라이닝화된 요청의 방식을 제안하기도 했다.

이 방식의 경우 서버가 FCFS(First-Come-First-Served) 방식을 통해 요청에 대한 응답을 해줬는데, 작은 객체의 경우 앞에 큰 객체가 있을 경우 전송을 기다려야 하는 만큼 기다려야 하는 문제가 생긴다. 이를 HOL Blocking(Head-Of-Line Blocking)이라고 한다. 또한 아무리 TCP 연결을 끊지 않고 보내더라도, HTTP 요청에서 보내는 헤더는 매번 함께 보내져야 했기에 헤더가 비대한 HTTP의 경우에는 비효율성을 보이기도 했다.

HTTP/2는 이러한 문제들을 해결하기 위해 나온 새로운 표준이다. 단일 TCP 연결에서 멀티플렉싱으로 다중 스트림을 동시에 처리하고, 헤더 압축(HPACK) 으로 오버헤드를 줄이며, 서버 푸시 와 우선순위로 리소스 전달을 최적화해 이러한 병목을 제거했다. 결과적으로 지연을 줄이고 페이지 로딩을 안정적으로 가속시켰다. 추가적으로 기존의 객체를 더 작은 frame 단위로 쪼개 보내며 HOL Blocking 문제도 완화시켰다.

서버 푸시란? 서버가 요청된 리소스와 함께 클라이언트가 필요할 추가 리소스를 미리 보내는 기능 한번에 HTML, CSS, JS를 같이 보낼 수 있기 때문에 RTT가 줄어든다

HTTP3

하지만 HTTP2에서도 한계는 있었다.

가장 먼저 단일 TCP 연결과 함께 멀티플렉싱을 사용한다고 하더라도, 하나의 패킷 손실이 HTTP/2의 스트림을 멈추게 하는 TCP 레벨의 HOL BLocking 문제가 다시 발생
- HTTP1.1에서는 이를 병렬 TCP 연결을 통해 해결하려는 시도는 있었다.
단일 연결이라 하더라도 처음의 TCP 3-way handshaking은 필요하기 때문에 이로 인한 지연
TCP 연결 자체에는 따로 보안처리가 안됨 의 문제들이 있었기에, 이러한 한계점을 보완한 HTTP/3가 나오게 되었다.

QUIC + HTTP/3가 보완한 점

UDP 기반 전송 + 내장 TLS 1.3: 전송층과 보안을 결합해 1-RTT에 암호화된 데이터 송신, 재개 시 0-RTT 지원.r
패킷 단위 멀티플렉싱: 스트림을 QUIC이 전송층에서 분리해 손실이 특정 스트림에만 영향 → HOL 블로킹 해소.
연결 마이그레이션: 연결 ID(Connection ID)로 네트워크 변경(IP/포트 변동)에도 세션 지속.
혼잡·재전송의 유연성: TCP 제약 없이 현대화된 혼잡 제어와 재전송 정책을 실험·배포 가능.
헤더 보호와 암호화된 메타데이터: 중간 장비 간섭을 줄여 프로토콜 경직화 문제 완화.
향상된 흐름제어: 스트림/연결 단위로 독립적인 플로우 컨트롤 제공.

이렇듯 HTTP/3는 경량화된 HTTP/2를 기반으로 QUIC 프로토콜을 더해 만들어지는 과정에서 보안을 챙기면서도 혼잡, 재전송 등 유연성이 높아졌다.

보면 QUIC 프로토콜의 경우에는 TLS 1.3 버전이 탑재된 것을 알 수 있다. 이 TLS 1.3 버전은 기존의 재접속시 다시 RTT가 필요했던 문제를 세션 티켓을 발급하는 방법으로 0-RTT까지 만들었다.

처음 연결의 handshake 과정에서 서버가 가지고 있는 세션 키를 준 후에, 나중에 클라이언트가 재접속한다고 했을 때 해당 세션 키를 재사용함으로써 0-RTT로 다시금 연결을 수립하고 데이터를 보낼 수 있도록 하는 것이다.

DNS

DNS 레코드

DNS는 여러 유형의 레코드로 도메인 → IP, 메일, 별칭, 권한 등을 표현한다. 이는 분산된 데이터베이스에서 관리하는데, RR이라는 형식으로 저장한다.

RR format (name, value, type, ttl)

우리가 쓰는 DNS 레코드들은 대부분 정해져있다.

A
- name은 호스트 이름, value는 IP 주소(최종적으로 얻고자 하는 IP 주소)
CNAME
- value값에 대한 특별한 별칭
- 한 이름을 다른 정식 이름으로 가리키는 방법으로, A에 등록한 것들을 지정한다.
NS
- 특정 도메인에 대해서 해당 존의 권한 네임서버를 지정합니다.
MX
- SMTP 메일 서버

DNS name resolution

Iterated Query(반복 쿼리)

DNS 이름 해석 과정에서 반복 쿼리를 활용한 방식은 각 DNS 서버로부터 가능한 한 부분적 답을 받아가며 최종 권한 서버를 찾아가는 방식이다. 연결된 네임 서버는 다음 단계 네임 서버 정보로 응답하는 구조로 되어 있다. 반복적으로 쿼리를 각 부분에서 날림으로써 부하 분산과 함께 책임 분산(?)도 가능해진다.

Recursive Query(재귀 쿼리)

Recursive DNS query는 요청을 받은 DNS 서버가 스스로 최종 답을 찾아서 반환하는 방식이다. 로컬 DNS 서버가 요청을 받으면 루트 DNS 서버로 요청을 날리고, 계속 파고들어가면서 다음 네임서버로, 다음 네임서버의 응답을 받고 다다음 네임서버로의 요청을 계속 재귀적으로 보내는 방식이다. 연결된 네임 서버에게 주소변환 임무를 일임하는 방식으로, 상위 계위의 네임 서버에 부하가 올 수 있는 위험이 있다. 결국 로컬 DNS 서버가 부하를 다 책임지는 방식인 것이다.

DNS zone

DNS zone은 동일한 도메인의 이름을 가진 컴퓨터들의 집합을 이야기한다.

위 예시와 같이 하나의 네임서버에서 관리되는 도메인 이름 공간으로, 특정 도메인 앞에 붙은 도메인들을 담당한다. 도메인 네임 공간은 root domain 아래 계위적으로 조성되는 tree 구조를 가지며, 이 트리 구조의 각 도메인은 도메인 네임 공간의 해당 영역에 대한 관리권한 위임 단위로 볼 수 있다.

Transport Layer

TCP

TCP는 연결을 먼저 설정하고 순서 보장·재전송·흐름제어·혼잡제어로 바이트 스트림을 안정적으로 전달한다. 손실·중복·순서 뒤바뀜을 스스로 처리해 애플리케이션 레이어에서 안정성을 덜 신경 쓰도록 합니다.

특징

신뢰성 보장
- 재전송(ARQ), 확인응답(ACK), 순서 제어(시퀀스 번호).
흐름·혼잡 제어
- 윈도우, 슬로우 스타트 등으로 네트워크 과부하를 방지.
연결
- 클라이언트-서버간 연결 필요
- 3-way 핸드셰이크, 연결 종료는 4-way.
단위
- 연결당 연속적인 바이트 스트림(메시지 경계 없음).
제공하지 않는 것들
- 타이밍, 최소 처리량 보장, 보안(TLS로 보장) 등

TCP를 보안적으로 보완하는 법

기본 TCP, UDP 소켓은 암호화를 미지원하기 때문에 패스워드도 평문 그대로 전송한다 이러한 보안적 취약점을 보완하기 위해 TLS를 사용한다.

TLS는 네트워크 통신을 암호화하고 무결성과 인증을 제공하는 보안 프로토콜이다.

TLS(Transport Layer Security)는 애플리케이션 데이터(예: HTTP)를 전송하기 전에 암호화해 도청을 막고, 무결성 검증으로 변조를 탐지하며, 서버(필요 시 클라이언트) 인증으로 신뢰를 확인한다. 오늘날 HTTPS, 이메일, 데이터베이스 연결 등 대부분의 보안 통신의 표준이기도 하다

기밀성
무결성
종단점 인증 세 개가 메인이라고 보면 된다.

이러한 TSL는 응용 계층에 구현되어 있으며 TLS 라이브러리로 암호화해서 전송되고, 인터넷에서 전송된다.

그림처럼 TLS는 응용 계층과 전송 계층(TCP) 사이에서 존재한다. 또한 추가적으로 이러한 TLS 계층이 있다면, 기존의 3-way handshake로 연결이 수립된 이후에 4 way-handshake를 추가적으로 진행하면서 인증서를 교환하고 이를 기반으로 암호화된 데이터를 주고받는 형식이다.

UDP

반면 UDP는 헤더가 작고 연결 절차가 없어 지연이 매우 낮다. 다만 패킷 손실·중복·순서 불일치를 애플리케이션이 직접 다뤄야 하는 만큼 사용하기가 까다롭다

특징

비연결
- 핸드셰이크 없음, 브로드캐스트/멀티캐스트 가능.
단위
- 애플리케이션이 보낸 데이터그램이 그대로 경계 유지.
오버헤드 적음
- 헤더 작고 상태 없음 → 지연 최소, 처리량 유리.
제공하지 않는 것들
- 신뢰성, 흐름 제어, 혼잡 제어, 타이밍, 처리량 보장, 보안, 연결 설정 등을 모두 제공하지 않는다

언제 무엇을 쓰나

TCP: 웹(HTTP/HTTPS), 이메일, 파일 전송 등 정확·완전 전달이 필수인 서비스.
UDP: 실시간 스트리밍, 게임, VoIP, DNS처럼 약간의 손실 허용하고 지연 민감한 서비스. 필요하면 애플리케이션 레벨에서 재전송·순서 보정·FEC를 덧붙입니다.

🐢꾸준함의 미학

탐색기

네트워크_1주차