HTTP / HTTPS 및 인터넷 통신 기초
1. 인터넷 기초 개념
IP (Internet Protocol)
네트워크 상의 고유한 식별 주소
집의 주소처럼 각 컴퓨터를 구분
예: 192.168.1.1 (IPv4)
2001:0db8:85a3:0000:0000:8a2e:0370:7334 (IPv6)포트 (Port)
서비스별 출입문 번호
같은 컴퓨터에서 여러 서비스를 구분
| 포트 | 서비스 |
|---|---|
| 80 | HTTP |
| 443 | HTTPS |
| 22 | SSH |
| 3306 | MySQL |
| 5432 | PostgreSQL |
DNS (Domain Name System)
도메인을 IP 주소로 자동 변환
전화번호부 같은 역할
사용자 요청: google.com
DNS 변환: 142.250.185.462. TCP 3-Way Handshake
TCP는 신뢰성 있는 연결을 수립하기 위해 3단계 핸드셰이크를 한다.
연결 과정
클라이언트 서버
| |
|--- SYN (seq=x) -----------> |
| |
| <--- SYN-ACK (seq=y, ack=x+1)|
| |
|--- ACK (seq=x+1, ack=y+1) --> |
| |
[연결 수립]각 단계 설명
-
SYN (동기화 신호)
- 클라이언트에서 서버로 "여보세요" 신호 전송
- 클라이언트의 시작 시퀀스 번호(seq) 포함
-
SYN-ACK (동기화 승인)
- 서버에서 클라이언트로 "네 말하세요" 응답
- 서버의 시작 시퀀스 번호(seq) 포함
- 클라이언트의 seq에 1을 더한 값을 ACK로 반환
-
ACK (승인)
- 클라이언트에서 서버로 "좋아 시작" 신호
- 서버의 seq에 1을 더한 값을 ACK로 반환
3. TCP 핸드셰이크가 필요한 이유
핸드셰이크 없다면 발생하는 문제
| 문제 | 설명 |
|---|---|
| 상대 존재 확인 불가 | 서버가 정말 켜져 있는지 모름 |
| 데이터 도착 확인 불가 | 패킷이 제대로 전달되었는지 알 수 없음 |
| 순서 뒤바뀜 | 패킷이 뒤틀린 순서로 도착 가능 |
| 연결 상태 추적 불가 | 통신 상태를 알 수 없음 |
| 데이터 손실 | 손실된 패킷을 재전송하지 않음 |
핸드셰이크가 보장하는 것
- 양쪽 모두 통신 기능 확인
- 데이터 전송 순서 보장
- 손실된 데이터 자동 재전송
- 신뢰성 있는 연결 수립
4. HTTP (HyperText Transfer Protocol)
HTTP란
웹 브라우저와 웹 서버 간 데이터를 주고받기 위한 프로토콜
HTTP 특징
| 특징 | 설명 |
|---|---|
| 비연결성 | 요청-응답 후 연결 해제 |
| 무상태성 | 이전 요청 정보를 기억하지 않음 |
| 텍스트 기반 | 사람이 읽을 수 있는 평문 전송 |
| 요청-응답 모델 | 클라이언트 요청 → 서버 응답 |
HTTP 요청 구조
메서드 경로 HTTP버전
GET /api/user HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer token123
{
"id": 1
}| 부분 | 설명 |
|---|---|
| 메서드 | GET, POST, PUT, DELETE 등 |
| 경로 | /api/user (URL 경로) |
| 헤더 | 요청에 대한 메타데이터 |
| 바디 | 요청 본문 데이터 |
HTTP 응답 구조
HTTP버전 상태코드 상태메시지
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 127
{
"id": 1,
"name": "John",
"email": "john@example.com"
}| 부분 | 설명 |
|---|---|
| 상태코드 | 200, 404, 500 등 |
| 헤더 | 응답에 대한 메타데이터 |
| 바디 | 응답 본문 데이터 (JSON 등) |
HTTP 메서드
| 메서드 | 용도 |
|---|---|
| GET | 데이터 조회 (읽기) |
| POST | 데이터 생성 (쓰기) |
| PUT | 데이터 전체 수정 |
| PATCH | 데이터 부분 수정 |
| DELETE | 데이터 삭제 |
| HEAD | GET과 동일하나 바디 없음 |
HTTP 상태 코드
| 코드 | 의미 | 설명 |
|---|---|---|
| 200 | OK | 요청 성공 |
| 201 | Created | 리소스 생성 성공 |
| 204 | No Content | 성공했으나 반환할 내용 없음 |
| 400 | Bad Request | 잘못된 요청 |
| 401 | Unauthorized | 인증 필요 |
| 403 | Forbidden | 접근 권한 없음 |
| 404 | Not Found | 리소스 없음 |
| 500 | Internal Server Error | 서버 오류 |
| 503 | Service Unavailable | 서버 이용 불가 |
5. HTTP의 치명적 문제
HTTP는 평문(암호화되지 않은 텍스트)으로 데이터를 전송
발생 가능한 문제
| 문제 | 설명 | 예시 |
|---|---|---|
| 도청 (Eavesdropping) | 통신 내용을 누군가 볼 수 있음 | WiFi에서 비밀번호 탈취 |
| 변조 (Tampering) | 전송 중 데이터가 변경됨 | 송금액 변경 |
| 위장 (Impersonation) | 가짜 서버로 위장 | 피싱 사이트 접속 |
6. HTTPS (HTTP Secure)
HTTP의 문제를 해결하기 위해 SSL/TLS 암호화를 추가한 프로토콜이다.
HTTPS 특징
- HTTP + SSL/TLS 암호화
- 포트 443 사용
- 모든 데이터 암호화
- 서버 인증서로 신뢰성 확인
7. SSL/TLS Handshake 과정
HTTPS 연결을 수립할 때 클라이언트와 서버 간의 보안 통신을 위한 협상 과정이다.
4단계 프로세스
클라이언트 서버
| |
|--- Client Hello -----------> |
| (지원하는 암호 방식, 버전) |
| |
| <--- Server Hello, 인증서 --- |
| (선택한 암호 방식, 인증서) |
| |
|--- 인증서 검증, 키 교환 ----> |
| (공개키로 대칭키 암호화) |
| |
| <--- Finished -------------- |
| (이제부터 암호화 통신) |
| |
[암호화된 통신 시작]각 단계 상세 설명
1단계: Client Hello (클라이언트 헬로우)
클라이언트가 서버에게 통신을 시작하고 싶다고 알린다.
- 지원하는 TLS 버전 (TLS 1.2, 1.3 등)
- 지원하는 암호 방식 목록 (Cipher Suite)
- 클라이언트 Random 값 (나중에 대칭키 생성에 사용)
- 세션 ID (이전 세션 재개 시)2단계: Server Hello & Certificate (서버 헬로우 및 인증서)
서버가 클라이언트의 요청에 응답한다.
- 선택한 TLS 버전
- 선택한 암호 방식
- 서버 Random 값
- 서버 인증서 (공개키 포함)
- 인증서 체인 (신뢰성 확인 용)3단계: 인증서 검증 & 키 교환
클라이언트가 서버의 인증서를 검증하고 암호화된 키를 전송한다.
클라이언트 검증 과정:
1. 인증서 만료 여부 확인
2. 도메인 일치 여부 확인
3. 신뢰할 수 있는 CA인지 확인
4. 서명 검증
키 교환:
1. Client Random + Server Random으로 Master Secret 생성
2. Master Secret으로 대칭키(Session Key) 생성
3. 대칭키를 서버의 공개키로 암호화
4. 암호화된 대칭키를 서버에 전송4단계: Finished & 암호화 시작
양쪽이 대칭키를 확인하고 암호화 통신을 시작한다.
- 클라이언트: Finished 메시지 전송 (대칭키로 암호화)
- 서버: Finished 메시지 수신 및 검증
- 이제부터 모든 데이터는 대칭키로 암호화8. 암호화 방식 비교
공개키 암호화 (비대칭 암호화)
장점: 누구나 암호화 가능, 인증 가능
단점: 속도 느림, 계산량 많음
사용처: SSL/TLS 핸드셰이크, 키 교환대칭키 암호화
장점: 속도 빠름, 효율적
단점: 키를 미리 공유해야 함
사용처: 실제 데이터 전송SSL/TLS에서의 사용
1. 핸드셰이크: 공개키 암호화로 대칭키 안전하게 교환
2. 데이터 전송: 대칭키 암호화로 빠르게 암호화된 통신9. 인증서 (Certificate)
인증서란
서버가 신뢰할 수 있다는 것을 보증하는 문서이다.
인증서 구성
- 서버의 공개키
- 서버의 정보 (도메인, 회사명 등)
- CA(인증기관)의 디지털 서명
- 유효 기간인증서 검증 과정
1. 인증서에서 공개키 추출
2. CA의 공개키로 서명 검증
3. 도메인 확인
4. 만료 여부 확인10. HTTP vs HTTPS 요청 흐름
HTTP 요청 흐름
1. TCP 3-Way Handshake
2. HTTP 요청 전송 (평문)
3. HTTP 응답 수신 (평문)
4. TCP 연결 종료HTTPS 요청 흐름
1. TCP 3-Way Handshake
2. SSL/TLS Handshake
3. HTTPS 요청 전송 (암호화)
4. HTTPS 응답 수신 (암호화)
5. TCP 연결 종료결론
인터넷 통신은 여러 프로토콜이 계층적으로 동작한다.
HTTP는 편하지만 보안이 약하므로 반드시 HTTPS를 사용해야 한다.
SSL/TLS는 공개키로 안전하게 대칭키를 교환한 후 대칭키로 빠르게 통신하는 효율적인 방식이다.
