Lecture 27. 네트워크
개요
핵심 질문
- OSI 7계층과 TCP/IP 모델은 어떻게 구성되는가?
- TCP와 UDP는 어떤 상황에서 각각 사용하는가?
- HTTP는 어떻게 동작하며 HTTPS는 무엇을 추가하는가?
- AI 시스템에서 네트워크 지식이 왜 필요한가?
학습 목표
- OSI 7계층과 TCP/IP 4계층 모델의 각 계층 역할을 설명할 수 있다.
- IP 주소 체계·라우팅·NAT 원리를 이해한다.
- TCP 연결 수립(3-way handshake)·흐름·혼잡 제어를 설명할 수 있다.
- HTTP 메서드·상태 코드·헤더와 HTTPS의 TLS 핸드셰이크를 이해한다.
- REST, gRPC, 스트리밍 등 AI 서빙에서 사용하는 프로토콜 차이를 이해한다.
핵심 개념
1. 네트워크 기본 구조
네트워크 구성 요소
- 호스트: 네트워크 가장자리에서 데이터를 최초 송신하고 최종 수신하는 노드
- 클라이언트: 요청을 보내는 호스트
- 서버: 응답을 보내는 호스트
- 중간 노드: 패킷을 목적지까지 전달하는 노드 (라우터, 스위치 등)
- 패킷: 네트워크를 통해 송수신되는 데이터 단위 — 페이로드 + 헤더 (+ 트레일러)
전송 방식
| 방식 | 설명 |
|---|---|
| 유니캐스트 | 1:1 송수신 |
| 브로드캐스트 | 네트워크 내 모든 호스트에 전송 |
| 멀티캐스트 | 동일 그룹 호스트에만 전송 |
| 애니캐스트 | 동일 그룹 중 가장 가까운 호스트에 전송 |
2. 네트워크 참조 모델
OSI 7계층 모델
통신 단계를 이론적으로 7개 계층으로 분리한 참조 모델.
| 계층 | 이름 | 역할 | PDU | 대표 프로토콜 |
|---|---|---|---|---|
| 7 | 응용 계층 | 네트워크 서비스 제공 | 데이터 | HTTP, HTTPS, DNS, FTP |
| 6 | 표현 계층 | 인코딩·압축·암호화 | 데이터 | SSL/TLS |
| 5 | 세션 계층 | 세션 생성·유지·종료 | 데이터 | — |
| 4 | 전송 계층 | 신뢰성 있는 전송, 프로세스 식별 | 세그먼트/데이터그램 | TCP, UDP |
| 3 | 네트워크 계층 | 네트워크 간 통신, 라우팅 | 패킷 | IP, ICMP, ARP |
| 2 | 데이터 링크 계층 | 같은 LAN 내 통신, 오류 검출 | 프레임 | 이더넷, MAC |
| 1 | 물리 계층 | 비트 신호 송수신 | 비트/심볼 | 케이블, Wi-Fi |
TCP/IP 4계층 모델
구현 중심의 실용적 모델.
| TCP/IP 계층 | 대응 OSI 계층 |
|---|---|
| 응용 계층 | 세션·표현·응용 계층 |
| 전송 계층 | 전송 계층 |
| 인터넷 계층 | 네트워크 계층 |
| 네트워크 액세스 계층 | 데이터 링크·물리 계층 |
캡슐화와 역캡슐화
송신: 상위 계층 → 하위 계층으로 헤더를 순차적으로 추가 (캡슐화). 수신: 하위 계층 → 상위 계층으로 헤더를 순차적으로 제거 (역캡슐화).
3. 데이터 링크 계층
이더넷 (Ethernet)
LAN에서 가장 많이 사용되는 기술 (IEEE 802.3).
이더넷 프레임 구조:
| 필드 | 크기 | 내용 |
|---|---|---|
| 프리앰블 | 8 B | 동기화용 비트열 |
| 수신지 MAC | 6 B | 목적지 MAC 주소 |
| 송신지 MAC | 6 B | 출발지 MAC 주소 |
| 타입/길이 | 2 B | 상위 프로토콜 타입 또는 데이터 크기 |
| 데이터 | 46~1500 B | 페이로드 |
| FCS | 4 B | CRC 오류 검출 값 |
MAC 주소: 48비트 물리 주소, NIC마다 고유하게 부여. AA:BB:CC:DD:EE:FF 형식.
스위치: MAC 주소 테이블로 목적지 포트로만 프레임 전달. 전이중 모드 지원.
ARP (Address Resolution Protocol)
동일 네트워크 내에서 IP 주소 → MAC 주소 변환.
- 목적지 IP로 브로드캐스트 ARP 요청
- 해당 IP를 가진 호스트가 자신의 MAC 주소를 유니캐스트로 응답
- ARP 테이블에
<IP, MAC>캐싱
4. 네트워크 계층 — IP
IP의 특성
- 신뢰할 수 없는 프로토콜: 패킷 전달 보장 안 함 (Best-effort Delivery)
- 비연결형 프로토콜: 사전 연결 과정 없음
IPv4 주소 구조
점(.)으로 구분된 4개의 옥텟(0~255). 예: 192.168.1.100
서브넷 마스크와 CIDR
CIDR 표기: 192.168.1.0/24 → 앞 24비트가 네트워크 주소.
특수 주소
- 루프백:
127.0.0.1(자기 자신) - 기본 게이트웨이: 외부 네트워크로 나가는 첫 번째 라우터
- 브로드캐스트: 호스트 주소 비트 전부 1
공인 IP vs 사설 IP
| 종류 | 설명 | 범위 |
|---|---|---|
| 공인 IP | 전 세계 고유, 인터넷 통신 | ISP 할당 |
| 사설 IP | 내부 네트워크용 | 10.x.x.x, 172.16-31.x.x, 192.168.x.x |
NAT (Network Address Translation)
사설 IP → 공인 IP 변환으로 외부 통신. NAPT는 포트 번호까지 함께 변환하여 다수의 사설 IP를 하나의 공인 IP로 대응.
IP 단편화 (Fragmentation)
MTU(최대 전송 단위, 1500 B)를 초과하는 패킷을 분할 전송 후 수신지에서 재조합. 식별자·플래그·단편화 오프셋 필드로 관리.
ICMP
IP 패킷 전송 과정의 피드백 메시지 프로토콜. ping 명령이 ICMP Echo 요청/응답을 사용.
라우팅
라우터가 IP 패킷을 목적지까지 전달하기 위해 최적 경로를 결정하는 과정. 라우팅 테이블에 따라 다음 홉(Next Hop)으로 패킷 전달.
5. 전송 계층 — TCP와 UDP
포트 번호
IP 주소가 호스트를 식별하면, 포트 번호는 호스트 내 프로세스를 식별한다.
| 범위 | 이름 | 용도 |
|---|---|---|
| 0 ~ 1023 | 잘 알려진 포트 | HTTP(80), HTTPS(443), SSH(22), DNS(53) |
| 1024 ~ 49151 | 등록된 포트 | MySQL(3306), Redis(6379), HTTP 대체(8080) |
| 49152 ~ 65535 | 동적 포트 | 클라이언트 임시 포트 |
TCP vs UDP
| 특성 | TCP | UDP |
|---|---|---|
| 연결 방식 | 연결형 (3-way handshake) | 비연결형 |
| 신뢰성 | 보장 (재전송, 순서 보장) | 미보장 |
| 흐름/혼잡 제어 | 있음 | 없음 |
| 오버헤드 | 높음 | 낮음 |
| 속도 | 느림 | 빠름 |
| 사용처 | 파일 전송, HTTP, SSH | 스트리밍, DNS, VoIP, QUIC |
TCP 3-way Handshake (연결 수립)
클라이언트 → 서버: SYN (seq=x)
서버 → 클라이언트: SYN+ACK (seq=y, ack=x+1)
클라이언트 → 서버: ACK (ack=y+1)
→ ESTABLISHED 상태TCP 4-way Handshake (연결 종료)
클라이언트 → 서버: FIN
서버 → 클라이언트: ACK
서버 → 클라이언트: FIN
클라이언트 → 서버: ACK
→ TIME_WAIT → CLOSEDTCP 오류·흐름·혼잡 제어
- 오류 제어: 타임아웃 또는 중복 ACK 시 세그먼트 재전송
- 흐름 제어: 수신 윈도우(rwnd) 크기로 송신량 조절 — 수신 버퍼 오버플로 방지
- 혼잡 제어 (AIMD): 혼잡 없으면 RTT마다 혼잡 윈도우(cwnd) 1씩 선형 증가, 혼잡 감지 시 절반으로 감소
TCP 상태
CLOSED → LISTEN → SYN-RECEIVED → ESTABLISHED → FIN-WAIT-1 → FIN-WAIT-2 → TIME-WAIT → CLOSED
AI 개발자 심화 — QUIC와 HTTP/3
QUIC는 UDP 위에서 TCP의 신뢰성을 구현한 프로토콜. 3-way handshake 없이 0-RTT 또는 1-RTT 연결 수립 → LLM API 호출 레이턴시 감소. HTTP/3은 QUIC 기반.
6. 응용 계층 — HTTP와 HTTPS
DNS
도메인 네임 → IP 주소 변환 계층적 분산 시스템.
클라이언트 → 로컬 DNS → 루트 네임 서버 → TLD 서버 → 권한 서버 → IP 주소 반환DNS 캐시로 반복 질의 최소화. TTL(Time To Live) 만료 시 재질의.
URL 구조
scheme://authority/path?query#fragment
https://api.example.com/v1/chat?lang=ko#section1HTTP 특징
- 요청-응답 기반: 클라이언트가 요청, 서버가 응답
- 스테이트리스: 각 요청은 독립적 — 상태 유지는 쿠키·세션으로 별도 관리
- 미디어 독립적: 텍스트·이미지·JSON·바이너리 등 제한 없이 전송
- 지속 연결 (Keep-Alive): 하나의 TCP 연결로 여러 요청/응답 처리
HTTP 메서드
| 메서드 | 목적 | 멱등성 | 안전성 |
|---|---|---|---|
| GET | 자원 조회 | ✓ | ✓ |
| POST | 자원 생성, 처리 요청 | ✗ | ✗ |
| PUT | 자원 전체 대체 | ✓ | ✗ |
| PATCH | 자원 부분 수정 | ✗ | ✗ |
| DELETE | 자원 삭제 | ✓ | ✗ |
| HEAD | 헤더만 조회 | ✓ | ✓ |
| OPTIONS | 가능한 메서드 확인 | ✓ | ✓ |
HTTP 상태 코드
| 코드 | 의미 |
|---|---|
| 200 OK | 요청 성공 |
| 201 Created | 자원 생성 성공 |
| 204 No Content | 성공, 응답 본문 없음 |
| 301/308 | 영구 리다이렉션 |
| 302/307 | 임시 리다이렉션 |
| 304 Not Modified | 캐시 유효 (자원 미변경) |
| 400 Bad Request | 잘못된 요청 형식 |
| 401 Unauthorized | 인증 필요 |
| 403 Forbidden | 권한 없음 |
| 404 Not Found | 자원 없음 |
| 429 Too Many Requests | 요청 한도 초과 (Rate Limit) |
| 500 Internal Server Error | 서버 내부 오류 |
| 502 Bad Gateway | 중간 서버 오류 |
| 503 Service Unavailable | 서버 과부하·점검 중 |
주요 HTTP 헤더
| 헤더 | 방향 | 역할 |
|---|---|---|
Host | 요청 | 요청 대상 호스트 |
Content-Type | 양방향 | 본문 미디어 타입 (application/json) |
Authorization | 요청 | 인증 토큰 (Bearer <token>) |
Cache-Control | 양방향 | 캐시 정책 (no-cache, max-age=3600) |
Content-Length | 양방향 | 본문 크기 (바이트) |
Transfer-Encoding | 응답 | 청크 전송 (chunked) — 스트리밍에 사용 |
쿠키와 캐시
- 쿠키: 서버가 생성하여 클라이언트에 저장하는
<name=value>데이터 — HTTP 스테이트리스 보완 - 캐시: 응답 자원의 사본 저장으로 불필요한 재전송 방지.
ETag·If-None-Match로 신선도 검증.
HTTPS와 TLS 핸드셰이크
TLS(Transport Layer Security)로 HTTP를 암호화.
1. TCP 3-way Handshake
2. TLS Handshake
- Client Hello: TLS 버전, 암호 스위트 목록, 클라이언트 난수
- Server Hello: 선택된 TLS 버전·암호 스위트, 서버 난수
- Certificate: 서버 인증서 전송 (CA 서명)
- 키 교환: 대칭 키 생성을 위한 정보 교환
- Finished: 양측에서 핸드셰이크 완료 확인
3. 암호화된 HTTP 통신 시작AI 개발자 심화 — REST vs gRPC
| REST (HTTP/1.1~2) | gRPC (HTTP/2 기반) | |
|---|---|---|
| 데이터 형식 | JSON (텍스트) | Protocol Buffers (바이너리) |
| 스키마 | 비공식 (OpenAPI) | 공식 (.proto 파일) |
| 성능 | 중간 | 빠름 (이진 직렬화, 헤더 압축) |
| 스트리밍 | SSE, WebSocket 별도 | 네이티브 지원 |
| 생태계 | 광범위 | 마이크로서비스, 내부 통신 |
| LLM 서빙 사용 | OpenAI API, HuggingFace | Triton Inference Server, KServe |
LLM API 호출 흐름:
클라이언트 → HTTPS POST /v1/chat/completions → 로드 밸런서 → 추론 서버 → GPU 연산 → 응답AI 개발자 심화 — 스트리밍 응답 (SSE)
LLM이 토큰을 생성할 때마다 실시간으로 클라이언트에 전달하는 방식.
SSE (Server-Sent Events): HTTP 연결을 유지한 채 서버 → 클라이언트 단방향 스트림.
HTTP/1.1 200 OK
Content-Type: text/event-stream
Transfer-Encoding: chunked
data: {"choices": [{"delta": {"content": "안"}}]}
data: {"choices": [{"delta": {"content": "녕"}}]}
data: [DONE]WebSocket: 양방향 전이중 통신 — 채팅 애플리케이션, 실시간 협업.
7. 고가용성과 로드 밸런싱
가용성
로드 밸런싱
클라이언트 요청을 여러 서버에 분산하는 기술.
| 알고리즘 | 방식 |
|---|---|
| 라운드 로빈 | 순서대로 순환 분배 |
| 최소 연결 | 현재 연결이 가장 적은 서버로 |
| IP 해시 | 클라이언트 IP 기반 고정 서버 배정 |
| 가중치 기반 | 서버 사양에 따라 비율 배분 |
리버스 프록시 (Reverse Proxy)
클라이언트와 오리진 서버 사이에서 요청을 대신 받아 서버로 전달. 로드 밸런싱·SSL 종료·캐싱·보안 기능 제공. Nginx, HAProxy가 대표적.
스케일링
- 스케일 업 (수직 확장): 단일 서버 사양 향상 — 단순하지만 한계 존재
- 스케일 아웃 (수평 확장): 서버 수 증가 — 유연하고 결함 감내 높음
- 오토스케일링: 트래픽에 따라 동적으로 서버 추가·제거
AI 개발자 심화 — LLM 서빙 인프라
- 레이턴시 vs 처리량 트레이드오프: 배치 크기가 클수록 처리량(tokens/s)은 높아지지만 첫 토큰 지연(TTFT, Time To First Token)은 증가.
- 연속 배칭 (Continuous Batching): 고정 배치 크기 대신 생성이 완료된 요청을 즉시 제거하고 새 요청을 삽입 — GPU 활용률 극대화. vLLM의 핵심 기법.
- 분산 학습 통신:
AllReduce는 모든 GPU가 그래디언트를 합산하는 집합 연산. Ring-AllReduce 알고리즘으로 통신량. - CDN (Content Delivery Network): 모델 가중치·데이터셋 파일을 지리적으로 분산된 엣지 서버에 배포 → 다운로드 속도 향상.
수식 정리
CIDR 서브넷 가용 호스트 수
(네트워크 주소·브로드캐스트 주소 제외)
TCP 혼잡 제어 AIMD
가용성
- MTBF: 평균 고장 간격, MTTR: 평균 복구 시간
레이턴시 구성 요소