🚀HTTP 프로토콜의 작동 원리와 요청/응답 구조
HTTP란?
HTTP(HyperText Transfer Protocol)는 웹 상에서 클라이언트(브라우저)와 서버 간의 데이터 통신을 위한 프로토콜이다.
텍스트, 이미지, 영상 등 다양한 자원을 요청하고 응답받는 데 사용된다.
작동원리
1. 클라이언트가 특정 웹 페이지 요청
2. HTTP 요청(Request) 메시지가 서버로 전송됨
3. 서버는 요청에 맞는 데이터를 찾아 HTTP 응답(Response) 메시지를 클라이언트에게 전달
4. 브라우저는 응답 데이터를 기반으로 웹 페이지를 렌더링
요청 구조
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
- 요청 라인: 메서드(GET), 요청 URI, 프로토콜 버전
- 헤더: 클라이언트 정보(User-Agent), 수락 가능한 데이터 형식(Accept) 등
- 본문(Body): 주로 POST 요청에서 사용 (폼 데이터, JSON 등)
응답 구조
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1024
<html> ... </html>
- 상태 라인: 프로토콜 버전, 상태 코드(200), 설명 메시지(OK)
- 헤더: Content-Type, Content-Length 등
- 본문(Body): 실제 HTML 문서 또는 데이터
🚀주요 HTTP 메서드와 상태 코드
HTTP 메서드 종류
GET | 자원 조회 (URL에 파라미터 포함) |
POST | 자원 생성 (요청 본문에 데이터 포함) |
PUT | 자원 전체 수정 |
PATCH | 자원 부분 수정 |
DELETE | 자원 삭제 |
주요 HTTP 상태 코드
200 OK | 요청 성공 |
201 Created | 자원 생성 성공 |
204 No Content | 성공했지만 응답 본문 없음 |
301 Moved Permanently | URL 영구 이동 |
302 Found | 임시 이동 |
400 Bad Request | 클라이언트 요청 오류 |
401 Unauthorized | 인증 실패 |
403 Forbidden | 접근 권한 없음 |
404 Not Found | 자원 없음 |
500 Internal Server Error | 서버 오류 |
502 Bad Gateway | 게이트웨이 오류 |
503 Service Unavailable | 서버 과부하 또는 점검 중 |
🚀HTTPS의 개념과 SSL/TLS 암호화 과정
HTTPS(HyperText Transfer Protocol Secure)란?
기존 HTTP에 보안을 추가한 통신 프로토콜이다.
항목 | HTTP | HTTPS |
암호화 | ❌ 없음 | ✅ 있음 (SSL/TLS) |
포트 번호 | 80 | 443 |
주소창 표시 | http:// | https:// + 🔒 자물쇠 표시 |
보안성 | 낮음 | 매우 높음 |
HTTP는 모든 데이터가 평문으로 전송되기 때문에
중간에서 도청 및 위조, 변조가 가능하다. 따라서 HTTP를 SSL/TLS로 감싸서 암호화한 HTTPS가 필수가 되었다.
SSL/TLS란?
SSL과 TLS는 인터넷에서 데이터를 암호화해서 안전하게 주고받기 위한 보안 프로토콜이다.
SSL: Secure Sockets Layer (시초, 지금은 사용 X)
TLS: Transport Layer Security (SSL의 발전형, 현재 표준)
일반적으로 "SSL/TLS"라고 부르지만, 요즘은 거의 다 TLS를 사용한다고..
SSL/TLS는 비대칭키(공개키/개인키) + 대칭키 암호화 방식을 혼합해서 사용한다.
왜냐하면 비대칭키는 보안성은 높지만 느리고, 대칭키는 빠르지만 키를 안전하게 전달하기 어렵기 때문이다.
대칭키: 암복호화에 사용하는 키가 동일하다.
비대칭키: 암복호화에 사용하는 키가 서로 다르다.
HTTPS Handshake 단계
handshake란? 안전하게 통신하기 위해 서로 통신 규칙과 키를 협상하는 과정
1. 클라이언트가 서버에 다음 정보를 보낸다.
- 사용할 수 있는 SSL/TLS 버전
- 사용할 수 있는 암호화 알고리즘 목록
- 클라이언트 랜덤 값
- 기타 옵션
2. 서버가 응답한다.
- 선택한 SSL/TLS 버전과 알고리즘
- 서버 인증서 전송 +공개키
- 서버 랜덤 값
3. 클라이언트가 서버가 보낸 인증서를 검증한다.
- 신뢰된 CA(공인 인증기관)가 서명했는가?
- 도메인 이름이 일치하는가?
- 만료되지 않았는가?
4. 클라이언트는 Pre-Master Secret(임시 비밀 키, 대칭키를 생성하기 위한 재료)을 임의로 생성한다.
- 이 값을 서버의 공개키로 암호화해서 서버에 전송한다.
5. 서버는 클라이언트가 보낸 Pre-Master Secret을 자기 개인키로 복호화한다.
- 이제 클라이언트와 서버는 동일한 Pre-Master Secret을 가지고 있다.
- 클라이언트와 서버는 Pre-Master Secret과 이전의 클라이언트/서버 랜덤 값을 조회해서 세션 키(대칭키) 생성
- 최종적으로 서버와 클라이언트는 같은 세션키를 갖고있게 된다.
6. 서버와 클라이언트가 세션 키로 암호화된 메시지를 한 번씩 주고 받고, 이걸 통해 서로 암호화 통신 준비 완료를 확인한다.
- 이제부터는 모든 데이터는 세션 키를 사용해 암호화된 상태로 전송된다.
🚀DNS의 역할과 작동 원리(재귀적/반복적 질의)
DNS란?
DNS(Domain Name System)는 도메인 이름(www.naver.com)을 IP 주소로 변환해주는 시스템이다.
사용자가 브라우저에 도메인을 입력하면, DNS가 이를 IP로 변환하여 해당 서버에 접속 가능하게 한다.
DNS가 IP를 찾는 과정
사용자가 브라우저에 도메인 입력하면 브라우저나 OS에서 캐시를 확인한다.
캐시에 없다면 기지국 DNS 서버 (Local DNS Server)로 요청한다. 이때, Local DNS Server는 일반적으로 ISP에서 제공하는 DNS 서버를 말한다.
ISP란? Internet Service Provider로 인터넷을 사용할 수 있도록 연결을 제공하는 회사를 말한다. 예를들어 KT, SK브로드밴드, LG U+등과 같은 통신사를 말한다.
우리가 도메인을 입력하면, ISP는 자신이 운영하는 로컬 DNS 서버를 통해 해당 IP를 찾아준다.
만일 Local DNS 서버가 IP 주소를 찾지 못하면 Root DNS 서버에 요청한다.
Root DNS는 아래그림처럼 최상위 노드부터 차례대로 요청하게된다.
루트 DNS 서버에 질의 => “.com 도메인을 담당하는 TLD DNS 서버가 어디야?”
.com TLD 서버에 질의 => “tosspayments.com 정보를 가진 권한 DNS 서버(authoritative) 주소가 뭐야?”
권한 DNS 서버에 최종 질의 => 최종 IP 주소 반환
도메인 계층 구조 정리
루트 | . (생략됨) | 루트 DNS 서버 |
TLD | .com, .org | Top-Level Domain (TLD) |
2차 도메인 | naver, google | 개별 조직/서비스명 |
3차 도메인 | www, mail 등 | 서브도메인 |
www.google.com이면
→ 루트 → .com → google.com → www 순으로 찾음.
재귀적 질의란?
요청자가 직접 IP 주소를 얻을 때까지 끝까지 요청 처리해 달라고 하는 방식으로
클라이언트가 Local DNS Resolver에 요청할 때 사용된다.
Resolver(Local DNS Resolver)는 클라이언트의 DNS 요청을 받아서,
필요한 정보를 DNS 서버들에 질의하고, 최종 결과(IP 주소)를 클라이언트에게 응답해주는 중계자이다.
동작 흐름 예시
[클라이언트] → [Local DNS 서버]
"http://www.example.com IP 주소 알려줘 (재귀 요청)"
(Local DNS 서버가 직접 찾아야 함)
→ 루트 DNS 서버에 반복 질의 → ".com DNS 서버 알려줌"
→ .com DNS 서버에 반복 질의 → "example.com DNS 서버 알려줌"
→ example.com의 권한 DNS 서버에 반복 질의 → "IP 주소 알려줌"
[Local DNS 서버] ← IP 주소 받음
[Local DNS 서버] → 클라이언트에게 IP 주소 응답
특징
- 클라이언트는 단 한 번만 요청하면 된다.
- 나머지 DNS 서버들과의 통신은 Local DNS 서버가 책임지고 처리한다.
- 결과적으로 클라이언트는 완성된 결과(IP 주소)만 받는다.
이때! 프로그래밍의 재귀는 자기 호출이고, DNS의 재귀 질의는 "위임형 요청"이라고 한다. => 클라이언트가 Resolver에게 전체 질의를 위임
반복적 질의란?
요청자가 다음 단계의 DNS 서버를 안내받고 스스로 찾아가는 방식이다.
Local DNS 서버가 루트 DNS / TLD DSN / 권한 DNS 에 요청할 때 사용된다.
동작 흐름 예시
[Local DNS 서버] → 루트 DNS 서버
"http://www.example.com IP 알려줘"
→ 루트 DNS: "몰라. .com DNS 주소는 알려줄게"
[Local DNS 서버] → .com DNS 서버
"http://www.example.com IP 알려줘"
→ .com DNS: "몰라. example.com의 권한 DNS 서버는 알려줄게"
[Local DNS 서버] → example.com 권한 DNS 서버
"http://www.example.com IP 알려줘"
→ 권한 DNS: "이거야! 93.184.216.34"
[Local DNS 서버] ← 최종 IP 주소 획득
특징
- 질의자가 DNS 서버마다 직접 물어본다.
- DNS 서버들은 자신이 모르면 "다음 단계의 주소"만 알려준다.
- 효율적이나, 질의자(Local DNS 서버)의 역할이 크다.
도움주신 분
https://hwan-shell.tistory.com/320
DNS에 대한 설명(디테일 하게....)
DNS란 무엇일까요?? Domain Name System의 약자로 인터넷 주소창에 Host Domain Name을 입력했을 때(ex, naver.com, google.com 등..) 해당 문자를 IP주소로 변환해 주는 시스템을 말합니다. 저는 URL창에 Host Domain Name
hwan-shell.tistory.com