개념 정리
웹 동작 원리와 HTTP / REST API
단원 개요
브라우저 주소창에 URL을 입력했을 때 일어나는 전체 네트워크·렌더링 과정과 HTTP 프로토콜의 무상태성(Stateless), 메서드 멱등성(Idempotency), 상태 코드, REST API 설계를 학습합니다.선수 개념
필수 키워드:443번TCP 3-Way HandshakeTLS HandshakeHTTP Request 전송 및 서버 처리HTTP Response 수신DOM 트리CSSOM 트리렌더 트리(Render Tree)레이아웃(Layout/Reflow)페인팅(Paint)
1
브라우저에 URL을 입력하면 일어나는 일 (면접 최빈출 시나리오)
사용자가 브라우저에 https://www.example.com/posts를 입력하고 엔터를 치면 화면이 뜨기까지 다음 5단계가 순차적으로 일어납니다:
1
URL 파싱 및 DNS 조회 (Domain Name System):
•
브라우저가 프로토콜(
https), 도메인(www.example.com), 경로(/posts)를 분리합니다.•
사람이 읽는 도메인 이름을 컴퓨터가 찾아갈 수 있는 IP 주소(예:
93.184.216.34)로 변환하기 위해 브라우저 캐시 ➔ OS(hosts) 캐시 ➔ 공유기/ISP 로컬 DNS 서버 ➔ 루트/TLD/권한 있는 DNS 서버 순으로 질의하여 IP를 획득합니다.2
TCP 3-Way Handshake 및 TLS 암호화 협상:
•
획득한 IP 주소와 HTTPS 기본 포트(443번, HTTP는 80번)로 TCP 3-Way Handshake를 수행해 연결을 수립하고, 이어서 TLS Handshake로 서버 인증서를 검증하고 대칭 세션키를 교환합니다.
3
HTTP Request 전송 및 서버 처리:
•
브라우저가 HTTP 요청 메시지(Start Line + Headers + Body)를 서버로 보냅니다. 웹 서버(Nginx 등)와 WAS(Node.js, Spring, Django)가 비즈니스 로직과 DB 조회를 수행합니다.
4
HTTP Response 수신:
•
서버가 상태 코드(
200 OK)와 함께 HTML, CSS, JS 또는 JSON 응답 본문을 브라우저로 돌려보냅니다.5
브라우저 렌더링 파이프라인 (Critical Rendering Path):
•
HTML을 파싱해 DOM 트리를 만들고, CSS를 파싱해 CSSOM 트리를 만든 뒤 둘을 합쳐 렌더 트리(Render Tree)를 구성하고, 각 요소의 위치·크기를 계산하는 레이아웃(Layout/Reflow)과 픽셀을 색칠하는 페인팅(Paint)을 거쳐 화면에 출력합니다.
핵심 원리
HTTP의 2대 특징은 '비연결성(Connectionless)'과 '무상태성(Stateless)'입니다. 서버가 클라이언트의 이전 요청 상태를 기억하지 않기 때문에 서버를 수십 대로 쉽게 확장(Scale-out)할 수 있으며, 로그인 유지가 필요할 때는 쿠키(Cookie)·세션(Session)이나 JWT 토큰을 헤더에 담아 보냅니다.2
HTTP 메서드(CRUD)와 멱등성(Idempotency), 상태 코드
•
HTTP 주요 메서드와 멱등성(Idempotency):
•
멱등성이란 동일한 요청을 1번 보내든 100번 반복해서 보내든 서버의 리소스 상태가 똑같이 유지되는 성질입니다 (네트워크 오류 시 안전하게 자동 재시도 가능한지 판단하는 기준!).
| HTTP 메서드 | 역할 (CRUD) | 요청 Body 유무 | 안전성 (Safe) | 멱등성 (Idempotent) |
|---|---|---|---|---|
| GET | 리소스 조회 (Read) | 없음 (Query String 사용) | O (서버 상태 변경 안 함) | O (멱등) |
| POST | 신규 리소스 생성 (Create) | 있음 | X | X (호출할 때마다 중복 생성됨!) |
| PUT | 리소스 전체 덮어쓰기 수정 | 있음 | X | O (몇 번을 덮어써도 결과 동일) |
| PATCH | 리소스 일부 필드만 수정 | 있음 | X | X (증감 연산 등 구현에 따라 비멱등) |
| DELETE | 리소스 삭제 (Delete) | 없음 | X | O (이미 지워진 결과 상태는 동일) |
•
필수 HTTP 응답 상태 코드 (Status Code):
•
2xx (성공):
200 OK (조회/작업 성공), 201 Created (POST 생성 성공), 204 No Content (성공했으나 응답 본문 없음).•
3xx (리다이렉션):
301 Moved Permanently (영구 주소 이전), 304 Not Modified (브라우저 캐시 재사용).•
4xx (클라이언트 측 잘못):
400 Bad Request (파라미터/문법 오류), 401 Unauthorized (인증 안 됨 - 로그인 필요), 403 Forbidden (인가 실패 - 로그인은 했으나 관리자 권한 없음), 404 Not Found (URL 리소스 없음).•
5xx (서버 측 장애):
500 Internal Server Error (서버 코드 예외 발생), 502 Bad Gateway, 503 Service Unavailable (서버 과부하/점검).풀이
1) RESTful API 설계 (URI에는 동사 대신 복수형 명사 /users를 사용하고 행위는 HTTP 메서드로 표현합니다):
•
42번 회원 조회:
GET /users/42•
42번 회원의 이메일만 부분 수정:
PATCH /users/42 (Body: {"email": "new@example.com"})•
42번 회원 탈퇴(삭제):
DELETE /users/422) 401 vs 403 상태 코드 구분:
•
로그인하지 않은(신원 미확인, Unauthenticated) 사용자의 마이페이지 접근:
401 Unauthorized•
로그인은 했으나 관리자 권한이 없는(권한 부족, Unauthorized access) 일반 회원의 관리자 페이지 접근:
403 Forbidden3
RESTful API 설계 원칙과 쿠키(Cookie) vs 세션(Session) vs JWT
•
RESTful API 핵심 설계 규칙:
1
URI는 리소스(자원)만 나타내므로
/getUsers나 /deleteOrder처럼 동사를 쓰지 않고 소문자 복수형 명사(/users, /orders/15/items)로 계층 관계를 표현합니다.2
리소스에 대한 행위(CRUD)는 오직 HTTP 메서드(GET, POST, PUT, PATCH, DELETE)로만 표현합니다.
•
웹 인증(Authentication) 3대 방식 비교:
•
쿠키 (Cookie): 브라우저 로컬에 저장되는 작은 텍스트 조각으로, 매 요청마다 자동으로 서버에 전송되지만 탈취·변조 위험이 있습니다(
HttpOnly, Secure 옵션 필수).•
세션 (Session): 민감한 로그인 상태를 서버 메모리나 Redis DB에 저장하고 브라우저에는 난수로 된 세션 ID만 쿠키로 발급합니다. 보안성이 높고 강제 로그아웃이 쉬우나 서버 메모리를 차지합니다.
•
JWT (JSON Web Token): 사용자 정보(Payload)에 서버 비밀키로 전자서명(HMAC/RSA)을 한 토큰을 클라이언트에 발급합니다. 서버가 별도 저장소를 둘 필요가 없는 완전한 Stateless 구조라 MSA 분산 서버 환경에 유리하지만, 한 번 발급된 토큰은 만료 전까지 강제 무효화하기 어렵다는 단점이 있어 짧은 Access Token과 긴 Refresh Token을 조합해 사용합니다.
주의할 점
JWT 토큰의 Payload(내용물)는 암호화된 것이 아니라 단순 Base64 인코딩된 텍스트이므로 누구나 디코딩해서 눈으로 읽을 수 있습니다(위변조만 불가능할 뿐!). 따라서 JWT Payload에는 비밀번호나 주민등록번호 같은 민감 정보를 절대 넣으면 안 됩니다.핵심 요약
- ✓브라우저에 URL 입력 시 DNS 조회(IP 변환) ➔ TCP 3-Way Handshake ➔ HTTP 요청/응답 ➔ DOM/CSSOM 렌더링 순으로 동작한다.
- ✓HTTP 메서드 중 GET, PUT, DELETE는 여러 번 호출해도 서버 상태가 동일한 '멱등성(Idempotency)'을 가지지만 POST는 멱등하지 않다.
- ✓401 상태 코드는 인증(로그인)이 안 된 경우이고, 403 상태 코드는 로그인은 했으나 접근 권한(인가)이 없는 경우이다.
- ✓RESTful API는 URI에 복수형 명사(/users/1)만 사용하여 자원을 식별하고, 행위는 HTTP 메서드로 구분하여 설계한다.