네트워크 심화

하윤·2025년 10월 26일
DNSgrpchttphttpsrestapi

CS

목록 보기
6/10

HTTP vs HTTPS

항목HTTPHTTPS
의미HyperText Transfer ProtocolHyperText Transfer Protocol Secure
정의웹에서 데이터를 주고받는 프로토콜HTTP에 보안 계층(SSL/TLS)을 추가한 프로토콜
보안 여부암호화 없음 (평문 통신)SSL/TLS 암호화 적용
기본 포트 번호80443
사용 계층애플리케이션 계층 (L7)애플리케이션 계층 (SSL/TLS는 전송 계층과 애플리케이션 계층 사이에 위치)

SSL/TLS의 역할

HTTPS의 핵심인 SSL(Secure Sockets Layer)/TLS(Transport Layer Security)

  1. 암호화: 클라이언트(브라우저)와 서버 간의 통신 내용을 암호화하여 제3자가 데이터를 가로채도 내용을 이해할 수 없게 한다. (대칭키 및 비대칭키 암호화 조합 사용)
  2. 무결성: 데이터가 전송 중에 변조되지 않았음을 보장한다.
  3. 인증: 클라이언트가 접속하려는 서버가 진짜 서버임을 확인하여 중간자 공격(Man-in-the-Middle Attack)을 방지한다.

HTTPS 동작 원리 (TLS Handshake)

  1. Client Hello: 클라이언트가 서버에 지원 가능한 암호화 방식과 난수 전송
  2. Server Hello: 서버가 선택한 암호화 방식과 인증서(SSL 인증서) 전송
  3. 인증서 검증: 클라이언트가 인증서의 유효성(CA, 도메인 일치 등) 확인
  4. 대칭키 교환: 암호화된 세션 키를 생성 및 교환
  5. 암호화 통신 시작: 세션 키를 이용해 데이터 암호화 통신 수행

TLS 1.3의 특징

Handshake 단계 단축, Perfect Forward Secrecy 기본 적용

Let’s Encrypt

무료로 SSL 인증서를 발급해주는 대표적인 기관

DNS 동작 원리

DNS는 사람이 읽기 쉬운 도메인 이름(예: www.google.com)을 컴퓨터가 이해하는 IP 주소(예: 142.251.42.100)로 변환해주는 시스템

⇒ 인터넷의 전화번호부 역할

DNS Query의 동작 과정 (Recursive Query 기준)

  1. 클라이언트 (Local DNS Server에 요청)
    • 사용자가 웹 브라우저에 도메인 이름(예: www.example.com)을 입력하면, 사용자의 PC에 설정된 Local DNS Server (일반적으로 ISP에서 제공)에 IP 주소를 질의한다.
    • Local DNS Server는 먼저 자신의 캐시(Cache)에 해당 정보가 있는지 확인한다. 있으면 즉시 응답하고, 없으면 다음 단계로 넘어간다.
  2. Root DNS Server에 질의
    • Local DNS Server가 Root DNS Server에 www.example.com의 IP를 질의한다.
    • Root DNS Server는 .com 도메인을 관리하는 TLD(Top-Level Domain) DNS Server의 주소를 응답한다.
  3. TLD (Top-Level Domain) DNS Server에 질의
    • Local DNS Server가 TLD DNS Server (예: .com 서버)에 다시 질의한다.
    • TLD DNS Server는 example.com을 관리하는 Authoritative DNS Server의 주소를 응답한다.
  4. Authoritative DNS Server에 질의
    • Local DNS Server가 Authoritative DNS Server (실제 서버의 IP 주소를 알고 있는 서버)에 최종 질의한다.
    • Authoritative DNS Server는 요청된 도메인(www.example.com)에 해당하는 최종 IP 주소를 Local DNS Server에 응답한다.
  5. 클라이언트에 최종 응답
    • Local DNS Server는 이 IP 주소를 캐시에 저장하고, 클라이언트(사용자 PC)에 최종 응답한다.
    • 클라이언트는 응답받은 IP 주소로 웹 서버에 접속을 시도한다.

캐싱 메커니즘

  • 각 DNS 응답에는 TTL(Time To Live) 값이 있어 일정 시간 동안 재사용 가능.
  • DNS 캐시로 인해 성능 향상 및 요청 부하 감소.

DNSSEC(DNS Security Extensions)

DNS 위변조 공격 방지를 위해 응답에 디지털 서명 추가

CDN(Content Delivery Network)와 연계

사용자 위치에 따라 가장 가까운 서버로 연결

REST API vs gRPC

구분REST API (Representational State Transfer)gRPC (Google Remote Procedure Call)
기반 프로토콜주로 HTTP/1.1 (최근 HTTP/2도 사용)HTTP/2
메시지 형식주로 JSON 또는 XML (사람이 읽기 쉬운 텍스트 기반)기본적으로 Protocol Buffers (Protobuf) (이진(Binary) 기반)
통신 스타일리소스 중심 (GET, POST, PUT, DELETE 등 HTTP 메서드와 URI 사용)서비스/함수 중심 (원격 함수 호출 형태)
데이터 크기 & 속도상대적으로 큼, 파싱 속도 느림Protobuf 및 HTTP/2의 장점으로 인해 데이터 크기가 작고 처리 속도가 빠름
스트리밍제한적 (일반적으로 요청-응답 단방향 통신)양방향 스트리밍을 포함한 다양한 스트리밍 지원 (HTTP/2 덕분)
언어 의존성언어에 독립적이며, 브라우저 연동 용이 (모든 언어 가능)Protobuf IDL(인터페이스 정의 언어)을 통해 다국어 환경에서 엄격한 인터페이스 계약 제공(=어려움)
주요 사용처범용적인 웹 서비스, 공용 API, 브라우저 연동이 필요한 경우마이크로서비스 간 통신, 고성능/저지연이 필요한 내부 시스템, 다국어 환경

gRPC 통신 흐름

  1. .proto 파일로 인터페이스 정의
  2. 각 언어별로 Stub 코드 자동 생성
  3. 클라이언트가 Stub 호출 → 서버의 메서드 직접 호출하는 것처럼 동작
  4. HTTP/2 기반 스트림으로 고성능 통신 수행

gRPC Stream 종류

  • Unary RPC (단일 요청-응답)
  • Server Streaming RPC (서버가 여러 번 응답)
  • Client Streaming RPC (클라이언트가 여러 번 요청)
  • Bidirectional Streaming RPC (양방향 스트리밍)

Protocol Buffers (Protobuf)

데이터를 직렬화하는 메커니즘으로, JSON보다 훨씬 효율적인 이진 형식. 스키마를 정의하여 데이터 구조를 강제할 수 있어 타입 안정성이 높다.

HTTP/2

REST API가 주로 사용하는 HTTP/1.1의 한계를 극복하기 위해 등장. 멀티플렉싱(Multiplexing), 헤더 압축, 서버 푸시 등의 기능을 통해 gRPC의 고성능을 가능하게 한다.

로드 밸런싱 (Load Balancing)

여러 대의 서버에 네트워크 트래픽을 분산하여 특정 서버에 부하가 집중되는 것을 막고, 서비스의 가용성(Availability)과 응답 시간을 향상시키는 기술

  • 종류: L4 로드 밸런서 (전송 계층: IP, Port 기반 분산)와 L7 로드 밸런서 (애플리케이션 계층: URL, HTTP 헤더 등 기반 분산)가 대표적
  • 목적: 서버 장애 시 트래픽 우회(Failover), 서버 성능 증대.

CORS (Cross-Origin Resource Sharing)

CORS는 브라우저가 다른 도메인(origin)으로 요청을 보낼 때

이를 허용할지 말지 결정하는 보안 정책(Security Policy)

즉, “브라우저 단에서의 보안 장치”이지, 서버 자체의 문제는 아니다.

CORS 에러 예시

// Frontend: https://myapp.com
fetch("https://api.server.com/data")
// -> Access to fetch at 'https://api.server.com/data' from origin 'https://myapp.com' has been blocked by CORS policy.

WebSocket (웹소켓)

WebSocket은 HTTP를 기반으로 한 실시간 양방향 통신 프로토콜

한 번 연결(Handshake)되면 서버 ↔ 클라이언트가 자유롭게 데이터를 주고받을 수 있음.

주로 채팅, 주식 시세, 실시간 알림, 게임 서버 등에서 사용됩니다.

Reverse Proxy (리버스 프록시)

클라이언트의 요청을 대신 받아 내부 서버에 전달하고 결과를 돌려주는 중간 서버

대표적으로 Nginx, Apache, HAProxy, Traefik 등이 있다.

정리

┌─────────────────────────────┐
│        [Browser / React]  │
│  - HTTPS 요청 (HTTP/2 or 3)│
│  - CORS 정책 적용           │
│  - WebSocket 연결 가능      │
└──────────────┬──────────────┘
              │ HTTPS (443)
              ▼
┌─────────────────────────────┐
│        [Reverse Proxy]    │   ← (예: Nginx / HAProxy)
│ - SSL/TLS 처리 (HTTPS 종단점)│
│ - CORS 헤더 설정            │
│ - WebSocket 업그레이드 허용  │
│ - Load Balancing / Caching │
│ - Backend 요청 전달 (proxy) │
└──────────────┬──────────────┘
              │ HTTP (내부망)
              ▼
┌─────────────────────────────┐
│     [Backend Servers]       │
│ - REST API (Express, Django)│
│ - gRPC (microservices)      │
│ - WebSocket 서버            │
│ - DB 연결                   │
└──────────────┬──────────────┘
              ▼
┌─────────────────────────────┐
│       [Database / Cache]  │
│  MySQL, Redis, MongoDB 등 │
└─────────────────────────────┘
profile
하윤
코린씨
이전 포스트

네트워크 기초

다음 포스트

데이터베이스 기초

4개의 댓글

comment-user-thumbnail
뚜우웅이
2025년 10월 26일

익숙하지 않은 gRPC에 대해 자세하게 작성되어 있어서 이해하기 좋았어요!

답글 달기
comment-user-thumbnail
윤현승
2025년 10월 27일

글이 길어 두려웠는데 중간중간 사진 자료가 있어 지루하지 않았습니다!

답글 달기
comment-user-thumbnail
동준
2025년 10월 27일

gRPC, 로드밸런싱같은 자세하게 몰랐던 내용을 이해할 수 있어 좋았습니다!

답글 달기
comment-user-thumbnail
규미
2025년 10월 27일

통신흐름이 자세하게 정리되어 있어서 이해가 더 잘 되었습니다!

답글 달기