HTTP vs HTTPS 차이점 완전 정리 + TCP/IP 핸드쉐이크(3-Way Handshake) 이해하기

 

HTTP vs HTTPS 차이점 완전 정리 + TCP/IP 핸드쉐이크(3-Way Handshake) 이해하기

대표 이미지: HTTP/HTTPS, TCP/IP 네트워크 흐름을 떠올리기 좋은 ‘서버 인프라’ 분위기

웹 개발을 하다 보면 “HTTP와 HTTPS는 뭐가 다르지?”, “TCP 핸드쉐이크가 왜 필요하지?” 같은 질문이 꼭 나옵니다. 이 글은 HTTP ↔ HTTPS 차이를 보안/성능/운영 관점에서 정리하고, 그 아래에서 TCP/IP 3-Way Handshake를 “패킷이 실제로 어떻게 오가는지” 느낌이 오도록 설명합니다. 마지막에는 TLS 핸드쉐이크가 TCP 위에서 어떻게 얹히는지까지 연결해 드립니다.

---

1) HTTP란? (HyperText Transfer Protocol)

HTTP는 브라우저(클라이언트)와 서버가 요청(Request) ↔ 응답(Response)을 주고받는 규칙(프로토콜)입니다. 기본적으로 HTTP는 “평문(Plain Text)” 통신이기 때문에 네트워크 중간에서 패킷을 훔쳐보면 요청/응답 내용을 그대로 읽을 수 있습니다.

HTTP의 핵심 특징

• 평문 통신: 암호화가 없어서 도청/변조에 취약
• 무상태(Stateless): 요청 간 상태를 저장하지 않음(세션/쿠키 등으로 보완)
• 응용 계층(OSI 7계층 중 7계층): TCP 위에서 동작하는 “웹 규칙”
• 기본 포트: 80

---

2) HTTPS란? (HTTP + TLS/SSL)

HTTPS는 HTTP에 TLS(예전 표현으로 SSL) 암호화를 얹어, “전송 중인 데이터”를 안전하게 만드는 방식입니다. 즉, HTTP 자체가 바뀐 게 아니라 HTTP 메시지가 TLS 터널 안에서 오간다고 보면 됩니다.

HTTPS가 제공하는 3대 보안 효과

1. 기밀성(Confidentiality): 암호화로 도청 방지
2. 무결성(Integrity): 전송 중 변조 감지/방지
3. 인증(Authentication): “진짜 그 서버가 맞는지” 증명(인증서 기반)

HTTPS는 단순히 “자물쇠 아이콘” 이상의 의미가 있습니다. 특히 로그인/결제 같은 민감 정보뿐 아니라, 쿠키/토큰/세션ID가 오가는 대부분의 서비스에서 사실상 필수입니다.

---

3) HTTP vs HTTPS 차이점 한눈에 정리

구분	HTTP	HTTPS
암호화	없음(평문)	TLS로 암호화
위협	도청/중간자 공격에 취약	도청/변조/사칭 방어
기본 포트	80	443
SEO/브라우저 정책	경고/제한이 생길 수 있음	권장(현대 웹의 기본)
운영	설정 단순	인증서 발급/갱신/리다이렉트 등 운영 필요

그럼 HTTPS는 항상 느린가?

예전에는 TLS 오버헤드가 부담이 되기도 했지만, 현재는 상황이 많이 달라졌습니다. 이유는 간단합니다:

• TLS 세션 재사용(재연결 비용 감소)
• HTTP/2, HTTP/3 같은 최신 프로토콜의 실사용이 대부분 HTTPS 기반
• CDN/리버스 프록시(예: Cloudflare, Nginx)에서 TLS 처리 최적화

즉, 체감 성능은 “HTTPS라서 무조건 느리다”가 아니라 서버 구성 + 캐싱 + 프로토콜(HTTP/2/3) + 네트워크 환경에 의해 결정됩니다.

---

4) TCP/IP 핸드쉐이크란? (3-Way Handshake)

웹을 열 때 “HTTP 요청”이 바로 날아가는 것처럼 보여도, 실제로는 그 전에 전송 계층(Transport)에서 TCP 연결을 먼저 맺어야 합니다. 이 연결을 맺는 절차가 바로 TCP 3-Way Handshake 입니다.

왜 ‘핸드쉐이크’가 필요할까?

• 양쪽이 통신 가능한 상태인지 확인(서버가 열려 있는지, 경로가 살아 있는지)
• 순서 보장: TCP는 “순서대로, 빠짐없이” 전달해야 함
• 초기 시퀀스 번호(ISN) 합의: 데이터 조각의 순서를 맞추기 위한 기준점

3-Way Handshake 흐름(그림으로 이해)

클라이언트(Client)                             서버(Server)
    |                                               |
    |  1) SYN (seq = x)                              |
    |----------------------------------------------->|
    |                                               |
    |  2) SYN-ACK (seq = y, ack = x+1)               |
    |<-----------------------------------------------|
    |                                               |
    |  3) ACK (ack = y+1)                            |
    |----------------------------------------------->|
    |                                               |
    |        ✅ TCP 연결 성립(Established)            |
  

패킷 3개가 의미하는 것

1. SYN: “나 연결할래” + “내 시작 번호는 x야”
   (클라이언트가 서버의 포트를 향해 연결 요청)
2. SYN-ACK: “좋아 연결하자” + “내 시작 번호는 y야” + “네 x 받았어”
   (서버도 자신의 시작 번호를 제시하고, 클라이언트 SYN을 확인)
3. ACK: “너 y도 받았어. 이제 데이터 보내자”
   (이 ACK가 도착하면 양쪽 모두 연결이 성립)

---

5) TCP 연결 후, 그 위에서 HTTP/HTTPS는 어떻게 흐를까?

여기서 핵심은 “계층”입니다. 아주 단순화하면 아래처럼 쌓여 있습니다.

[브라우저/서버 애플리케이션]
        ↓
HTTP (요청/응답 규칙)
        ↓
TLS (HTTPS일 때만: 암호화/인증)
        ↓
TCP (연결/순서/재전송)
        ↓
IP (주소/라우팅)
        ↓
Ethernet/Wi-Fi (실제 물리 전송)
  

HTTP 통신 순서(HTTP 기준)

1. TCP 3-Way Handshake로 연결 성립
2. HTTP Request 전송 (GET/POST 등)
3. HTTP Response 수신
4. 연결 유지(Keep-Alive) 또는 종료

HTTPS 통신 순서(HTTPS 기준)

1. TCP 3-Way Handshake로 연결 성립
2. TLS Handshake (인증서 검증, 키 교환 등)
3. TLS로 암호화된 채널 위에서 HTTP Request/Response
4. 연결 유지 또는 종료

그래서 “HTTPS가 연결 과정이 1단계 더 있다”고 말하는 이유가 여기 있습니다. 다만 실제 성능은 재사용/최적화가 많이 적용되어 운영에서는 HTTPS가 표준입니다.

---

6) 개발자가 실무에서 꼭 알아야 하는 포인트

(1) “HTTP → HTTPS 리다이렉트”는 필수 습관

운영 환경에서 HTTP를 완전히 끄기 어려운 경우가 많습니다. (예: 오래된 링크, 캐시된 URL) 그럴 때는 80으로 들어온 요청을 443으로 강제 이동시키는 방식이 기본입니다.

# (예시) Nginx 리다이렉트 개념
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

(2) Mixed Content(혼합 콘텐츠) 문제

페이지는 HTTPS인데 내부 리소스(이미지/JS/CSS)가 HTTP로 로딩되면 브라우저가 경고하거나 차단할 수 있습니다. 실무에서 “왜 배포하니까 이미지가 안 뜨지?” 문제의 단골 원인이 바로 이 Mixed Content입니다.

(3) 쿠키 보안 옵션도 같이 봐야 함

• Secure: HTTPS에서만 쿠키 전송
• HttpOnly: JS로 쿠키 접근 차단(XSS 방어에 도움)
• SameSite: CSRF 완화에 도움(Lax/Strict/None)

(4) HTTP/3는 왜 자주 언급될까?

요즘은 HTTP/3(QUIC)가 확산되면서 “TCP 대신 UDP” 기반으로 가는 흐름이 있습니다. 다만 오늘 주제의 핵심은 여전히 대부분의 HTTP/1.1, HTTP/2가 TCP 기반이고, 네트워크 기초를 이해하려면 TCP 핸드쉐이크는 반드시 알고 있어야 한다는 점입니다.

---

7) 초보자용 요약: “한 문장”으로 정리

• HTTP: 암호화 없는 웹 통신 규칙(평문) → 보안에 취약
• HTTPS: HTTP에 TLS를 얹어서 암호화/인증/무결성을 보장
• TCP 3-Way Handshake: HTTP/HTTPS 전에 “연결부터 성립”시키는 절차(SYN → SYN-ACK → ACK)

---

8) (보너스) 면접/시험에서 자주 나오는 질문 포인트

Q1. HTTPS는 “완벽한 보안”인가요?

아닙니다. 전송 중 도청/변조를 막는 데 강력하지만, 서버가 해킹당하거나(데이터베이스 유출), 클라이언트가 악성코드에 감염되면 다른 문제입니다. 또한 인증서 검증이 우회되거나, 사용자가 가짜 사이트를 믿어버리는 사회공학 공격도 존재합니다.

Q2. TCP가 순서를 보장하는 방식은?

시퀀스 번호(Sequence Number)로 데이터 조각의 순서를 정하고, ACK로 “여기까지 받았다”를 확인하며, 누락이 있으면 재전송(Retransmission)합니다.

---

마무리

HTTP/HTTPS 차이와 TCP 핸드쉐이크는 네트워크/백엔드에서 “기초인데 실제로 강력한” 지식입니다. 특히 HTTPS는 요즘 웹에서 선택이 아니라 기본에 가깝고, TCP 3-Way Handshake를 이해하면 “왜 지연이 생기는지”, “왜 연결이 끊기는지”, “왜 재시도가 필요한지” 같은 문제를 훨씬 정확히 디버깅할 수 있습니다.

---

SEO 메타 정보

Meta Description (160자 내외)

HTTP와 HTTPS 차이점을 보안·성능·운영 관점에서 정리하고, TCP/IP 3-Way Handshake 흐름(SYN/SYN-ACK/ACK)과 HTTPS의 TLS 연결 과정을 쉽게 설명합니다.

관련 키워드 태그 10개

#HTTP #HTTPS #TLS #SSL #TCPIP #3WayHandshake #네트워크기초 #웹보안 #백엔드개발 #HTTP2