6. 네트워크 심화

규미·2025년 10월 23일

CS-study

목록 보기

6/10

HTTP(HyperText Transfer Protocol)와 HTTPS(HyperText Transfer Protocol Secure)는 모두 웹에서 데이터를 주고받기 위한 프로토콜(규약)입니다. 가장 큰 차이점은 보안입니다.

HTTP

데이터를 암호화하지 않고 '평문(Plain Text)' 그대로 전송합니다.
중간에 데이터를 가로채는 '스니핑(Sniffing)'이나 '중간자 공격(MITM)'에 매우 취약합니다.
로그인 정보, 개인정보, 결제 정보 등이 그대로 노출될 수 있습니다.
기본 포트로 80번을 사용합니다.

HTTPS

HTTP의 보안이 강화된 버전으로, SSL/TLS (Secure Sockets Layer/Transport Layer Security) 프로토콜을 사용해 데이터를 암호화합니다.
기본 포트로 443번을 사용합니다.

HTTPS의 암호화

1. 데이터 암호화 (기밀성)

중간에 데이터를 가로채도 내용을 알 수 없습니다. 이는 '하이브리드 암호화' 방식을 통해 구현됩니다.

SSL/TLS Handshake (악수): 클라이언트와 서버가 처음 연결할 때, 어떤 방식으로 암호화할지 '합의'하는 과정을 거칩니다.
비대칭키 (공개키/비밀키): 이 '합의' 과정에서 안전하게 '대칭키'를 교환하기 위해 사용됩니다.
- 클라이언트는 서버가 제공한 공개키로 실제 데이터를 암호화할 임시 대칭키(세션키)를 암호화해서 보냅니다.
- 서버는 자신만이 가진 비밀키로 이 메시지를 해독하여 '임시 대칭키'를 얻습니다.
대칭키: Handshake가 끝나면, 클라이언트와 서버 양측 모두 동일한 '대칭키'를 갖게 됩니다. 비대칭키는 연산이 느리기 때문에, 실제 데이터 통신은 이 대칭키를 이용해 빠르고 효율적으로 암호화/복호화합니다.

2. 서버 인증 (신원 보증)

내가 접속하려는 서버가 진짜 www.google.com이 맞는지, 해커가 만든 가짜 피싱 사이트가 아닌지 확인합니다.

서버는 Handshake 과정에서 신뢰할 수 있는 기관(CA, Certificate Authority)으로부터 발급받은 SSL/TLS 인증서를 클라이언트(브라우저)에게 제시합니다.
이 인증서에는 '이 도메인은 이 서버 소유가 맞음'이라는 CA의 서명과 서버의 '공개키'가 포함되어 있습니다.
브라우저는 내장된 신뢰할 수 있는 CA 목록을 확인하여 이 인증서가 위조되지 않았는지 검증합니다.

3. 데이터 무결성 (위변조 방지)

데이터가 전송 도중에 해커에 의해 수정되거나 변조되지 않았음을 보장합니다.

데이터와 함께 메시지 인증 코드(MAC)라는 일종의 검증용 '꼬리표'를 함께 암호화하여 보냅니다.
데이터를 받은 쪽에서는 복호화 후, 받은 데이터로 동일한 '꼬리표'를 만들어봅니다.
두 꼬리표가 일치하지 않으면, 중간에 데이터가 변조되었음을 감지할 수 있습니다.

결론적으로, 민감한 정보를 다루는 모든 웹사이트(로그인, 결제, 회원가입 등)는 반드시 HTTPS를 사용해야 합니다.

HTTP와 HTTPS 차이점

특징	HTTP (HyperText Transfer Protocol)	HTTPS (HyperText Transfer Protocol Secure)
보안(암호화)	암호화되지 않은 평문(Plain Text) 전송	SSL/TLS 프로토콜을 사용해 데이터 암호화
안전성	중간자 공격(MITM), 스니핑 등에 취약	데이터 암호화, 서버 인증, 무결성 보장
기본 포트	80	443
인증서	필요 없음	SSL/TLS 인증서 (CA 발급) 필요
URL 접두사	`http://`	`https://`
주요 용도	단순 정보 조회 (보안 불필요 시)	로그인, 결제, 개인정보 등 민감 정보 처리

DNS 동작 원리

DNS(Domain Name System)는 www.google.com처럼 사람이 기억하기 쉬운 도메인 이름을, 컴퓨터가 통신할 때 실제 사용하는 172.217.161.196 같은 IP 주소로 변환해주는 시스템입니다. (인터넷의 '전화번호부' 역할)

DNS가 동작하는 과정은 다음과 같습니다. (캐시(Cache)에 정보가 없는 경우)

사용자 (Web Browser): 사용자가 브라우저에 www.google.com을 입력합니다.
Local DNS 서버 (Recursive Resolver):
- PC는 가장 먼저 설정된 'Local DNS 서버' (보통 KT, SKT 같은 통신사(ISP)가 제공)에게 해당 도메인의 IP 주소를 물어봅니다.
- Local DNS 서버는 이전에 이 주소를 찾았다면 캐시된 IP를 바로 응답하지만, 없다면 IP 주소를 찾기 위한 여행을 시작합니다.
Root DNS 서버:
- Local DNS 서버는 최상위인 'Root DNS 서버'에게 ".com 도메인을 관리하는 서버가 어디야?"라고 물어봅니다.
- Root 서버는 ".com은 TLD 서버가 관리해. 걔 주소는 'A'야."라고 응답합니다.
TLD (Top-Level Domain) 서버:
- Local DNS 서버는 'A' 주소(TLD 서버)로 가서 "google.com 도메인을 관리하는 서버가 어디야?"라고 물어봅니다.
- TLD 서버는 "google.com은 'Authoritative DNS 서버'가 관리해. 걔 주소는 'B'야."라고 응답합니다.
Authoritative DNS 서버:
- Local DNS 서버는 'B' 주소(Authoritative DNS 서버, 즉 google.com의 실제 정보가 저장된 서버)로 가서 "www.google.com의 IP 주소가 뭐야?"라고 물어봅니다.
- Authoritative DNS 서버는 "그 도메인의 IP 주소는 172.217.161.196이야."라고 최종 답변을 줍니다.
응답 및 캐싱:
- Local DNS 서버는 알아낸 IP 주소(172.217.161.196)를 사용자 PC에게 전달합니다.
- 동시에 이 정보를 일정 시간(TTL, Time To Live) 동안 자신의 캐시에 저장하여, 다음번에 동일한 요청이 오면 3~5번 과정을 생략하고 바로 응답합니다.

REST API vs gRPC

REST API와 gRPC는 클라이언트와 서버가 서로 통신하는 방식(API)을 구현하는 대표적인 두 가지 방법입니다.

REST (Representational State Transfer) API:
- 프로토콜: HTTP/1.1을 기반으로 합니다.
- 데이터 형식: 주로 JSON (가끔 XML)을 사용합니다. 텍스트 기반이라 사람이 읽고 이해하기 쉽습니다.
- 동작 방식: HTTP 메서드(GET, POST, PUT, DELETE)와 URL(URI)을 조합하여 '자원(Resource)'을 정의하고 조작합니다.
  - 예: GET /users/123 (123번 사용자의 정보를 가져온다)
- 장점: 범용성이 매우 높습니다. 거의 모든 시스템이 HTTP와 JSON을 지원하므로 호환성이 좋습니다.
- 단점: 텍스트 기반(JSON)이고 HTTP 헤더 정보가 많아 gRPC에 비해 상대적으로 무겁고 속도가 느릴 수 있습니다.
gRPC (Google Remote Procedure Call):
- 프로토콜: HTTP/2를 기반으로 하여 더 빠르고 효율적인 통신이 가능합니다. (하나의 연결로 여러 요청/응답을 동시에 처리하는 '멀티플렉싱' 등 지원)
- 데이터 형식: Protocol Buffers (Protobuf)라는 바이너리(이진) 직렬화 형식을 사용합니다.
- 동작 방식: '자원' 중심이 아닌 '함수(서비스)' 중심입니다. 원격 서버에 있는 함수를 마치 로컬 함수처럼 호출(RPC)합니다.
  - 예: GetUser(user_id: 123)
- 장점: 성능이 매우 뛰어납니다. Protobuf는 JSON보다 훨씬 가볍고 파싱 속도가 빠릅니다. HTTP/2의 스트리밍(양방향 통신) 기능을 강력하게 지원합니다.
- 단점: 데이터가 바이너리라 사람이 바로 읽기 어렵고, 브라우저에서 직접 지원하지 않아 별도 설정(gRPC-Web)이 필요할 수 있습니다.

언제 무엇을 쓸까요?

REST API: 외부(웹 브라우저, 모바일 앱, 다른 회사)에 공개되는 공용 API나 범용성이 중요할 때 적합합니다.
gRPC: 마이크로서비스 아키텍처(MSA) 환경에서 서비스 내부 간의 통신처럼 성능이 매우 중요하고 빠른 응답이 필요할 때 적합합니다.

REST API와 gRPC 차이점

특징	REST (Representational State Transfer) API	gRPC (Google Remote Procedure Call)
기반 프로토콜	HTTP/1.1 (주로 사용)	HTTP/2 (필수)
데이터 형식	JSON (텍스트 기반)	Protocol Buffers (Protobuf) (바이너리 기반)
설계 방식	자원(Resource) 중심 (명사 중심)
(예: `GET /users/123`)	서비스/함수(Service) 중심 (동사 중심)
(예: `GetUser(user_id: 123)`)
성능	상대적으로 느림 (텍스트 파싱, 헤더 오버헤드)	매우 빠름 (바이너리 직렬화, HTTP/2 멀티플렉싱)
스트리밍	기본 미지원 (별도 기술 필요)	서버/클라이언트/양방향 스트리밍 기본 지원
스키마(계약)	유연함 (OpenAPI 등으로 별도 정의)	엄격함 (`.proto` 파일을 통해 스키마 필수 정의)
브라우저 지원	모든 브라우저에서 직접 지원	별도 설정(gRPC-Web 프록시) 필요
주요 용도	외부 공개 API, 웹/모바일 클라이언트 통신	MSA 내부 서비스 간 통신, 고성능/실시간 통신