-대표 상태 코드: `301 Moved Permanently`, `308 Permanent Redirect`
-클라이언트는 이후부터항상 새 URL을 사용해야 함
-검색 엔진도 URL 변경을 반영함 (SEO 영향 있음)
『이것이 취업을 위한 컴퓨터 과학이다』, p.456
-`301`: 원래는 GET 요청만 고려했으나, 실제 구현에서는 POST → GET으로 바뀌는 경우도 있음
-`308`: 요청 방식(예: POST)을 그대로 유지하고 새 URL로 리다이렉트 (보다 명확한 동작)
2. 일시적 리다이렉션 (Temporary Redirect)
자원이 임시로 다른 위치에 있는 경우, 혹은 특정 조건에서만 위치가 변경된 경우 사용됩니다.
- 대표 상태 코드: `302 Found`, `307 Temporary Redirect`, `303 See Other` - 이후 요청에서는 여전히 원래 URL을 사용할 수 있음
『이것이 취업을 위한 컴퓨터 과학이다』, p.457
- `302`: 전통적으로 많이 사용되었으나, 명확한 의미 없이 POST → GET으로 바뀌는 등 불명확성 존재 - `307`: 요청 메서드를 그대로 유지하여 재요청 (POST → POST) - `303`: 메서드를 GET으로 변경하여 리소스를 다시 요청하는 방식 (주로 응답 페이지 안내 시 사용)
✅ 상황에 따라 적절한 리다이렉션 선택이 중요합니다!
상태 코드
설명
요청 방식 유지 여부
주 용도
301
영구 이동
유지 안 될 수 있음
URL 구조 변경
308
영구 이동
유지됨
REST API 안전한 리다이렉션
302
임시 이동
유지 안 됨 (대개 GET)
전통적 웹 페이지 이동
307
임시 이동
유지됨
폼 제출 등 보존 필요
303
다른 위치 보기
GET으로 변경됨
응답 안내 페이지 등
💡 REST API에서는 308, 307을 사용하는 것이 안전하며, 브라우저 기반 응답 페이지 안내에는 303이 유용합니다.
HTTP 헤더는 요청과 응답 메시지에 포함되어 메타데이터를 전달합니다. 헤더는 이름과 값으로 구성되며, Header-Name: value 형식을 가집니다.
✅ 요청 메시지에서 자주 쓰는 헤더
헤더
설명
Host
요청 대상 도메인 이름 (필수)
User-Agent
브라우저/클라이언트 정보
Referer
이전 요청 페이지의 주소 (출처)
✅ 응답 메시지에서 자주 쓰는 헤더
헤더
설명
Server
서버 소프트웨어 정보
Location
새로 생성된 리소스 주소 (POST 201, 리다이렉션 3xx)
Allow
지원하는 메서드 목록 (405 응답 시 포함됨)
✅ 요청/응답 공통으로 사용되는 헤더
헤더
설명
Content-Type
본문의 타입 (예: application/json, text/html)
Content-Length
본문의 크기 (바이트 단위)
Content-Language
콘텐츠 언어 (예: ko-KR)
Content-Encoding
압축 방식 (예: gzip)
Date
메시지 생성 시점
Connection
연결 방식 (keep-alive, close)
6. 면접 질문 예시
Q. HTTP의 킵 얼라이브(Keep-Alive)란 무엇인가요?
HTTP/1.0은 요청마다 TCP 연결을 새로 맺는 비지속 연결 방식이었지만, HTTP/1.1부터는 기본적으로 연결을 끊지 않고 지속 연결(Persistent Connection)을 유지합니다.
Keep-Alive는 이러한 지속 연결을 가능하게 하는 HTTP 헤더로, 여러 개의 요청/응답을 하나의 TCP 연결로 처리할 수 있도록 합니다.
장점: 연결 수 감소 → 속도 향상 + 리소스 절약
예시 헤더: Connection: keep-alive
HTTP/1.0에서는 요청을 보낼 때마다 매번 새로운 TCP 연결을 맺고, 응답 후 즉시 연결을 끊는 방식인 비지속 연결을 사용했습니다. 하지만 HTTP/1.1부터는 기본적으로 지속 연결(Persistent Connection)을 지원하며, Connection: keep-alive 헤더를 통해 하나의 TCP 연결을 재사용할 수 있게 되었습니다. 이를 통해 여러 개의 요청과 응답을 하나의 연결로 처리할 수 있어, 연결 수를 줄이고 네트워크 자원을 절약하며 전체 통신 속도를 향상시킬 수 있습니다.
Q. HTTP 1.1과 HTTP 2.0의 차이점은 무엇인가요?
구분
HTTP/1.1
HTTP/2.0
데이터 형식
텍스트 기반
바이너리 기반
연결 방식
요청당 순차 처리 (HOL blocking 발생)
멀티플렉싱으로 동시 요청 가능
서버 푸시
미지원
서버 푸시(Server Push) 가능
성능
헤더 중복 많음, 느린 처리
헤더 압축 + 빠른 처리
HTTP/1.1은 텍스트 기반 프로토콜로, 요청을 순차적으로 처리하기 때문에 하나의 요청이 끝날 때까지 다음 요청을 대기해야 하는 HOL(Head-of-Line) 블로킹 문제가 있었습니다.
반면 HTTP/2.0은 바이너리 기반 프로토콜이며, 하나의 연결 내에서 여러 요청과 응답을 동시에 주고받을 수 있는 멀티플렉싱(Multiplexing)을 지원하여 병목 현상을 해결했습니다. 또한 헤더를 압축해 오버헤드를 줄이고, 서버가 클라이언트 요청 없이도 데이터를 푸시할 수 있는 서버 푸시 기능도 도입되어, 웹 페이지 로딩 성능이 크게 개선되었습니다.
Q. HTTP 메서드인 GET과 POST의 차이는 무엇인가요?
구분
GET
POST
목적
데이터 조회
데이터 생성 / 전송
데이터 전달 위치
URL (쿼리 스트링)
HTTP 본문 (Body)
브라우저 캐시
가능
일반적으로 불가능
예시
/search?q=chatgpt
/login (본문에 id/pw 포함)
GET 메서드는 리소스를 조회할 때 사용되며, 전달할 데이터가 URL의 쿼리 문자열에 포함됩니다. 반면 POST 메서드는 리소스를 생성하거나 서버로 데이터를 전송할 때 사용되며, 데이터는 HTTP 메시지의 본문(Body)에 담깁니다.
GET 요청은 브라우저의 캐시에 저장되거나 URL로 공유될 수 있는 반면, POST는 그렇지 않기 때문에 민감한 정보를 전송할 때는 반드시 POST 방식을 사용하는 것이 바람직합니다.
특히 비밀번호, 토큰, 주민번호와 같은 정보는 URL에 노출될 경우 보안 사고로 이어질 수 있으므로, POST 본문을 활용하고 가능하면 HTTPS를 통해 암호화하여 전송해야 안전합니다.
Q. HTTP 메서드인 PUT과 PATCH의 차이는 무엇인가요?
구분
PUT
PATCH
목적
전체 리소스 교체
일부 필드 수정
데이터 구조
전체 객체 필요
변경될 필드만 포함
멱등성
멱등 (같은 요청 여러 번 가능)
멱등일 수도, 아닐 수도 있음
PUT 메서드는 전체 리소스를 대체하는 방식으로 동작하며, 해당 리소스를 통째로 덮어쓰기 때문에 요청 본문에는 전체 객체 구조가 포함되어야 합니다.
반면 PATCH는 리소스의 일부 필드만 선택적으로 수정할 때 사용되며, 수정하고자 하는 필드만 전달하면 됩니다.
예를 들어 사용자의 모든 정보를 업데이트할 때는 PUT을 사용하고, 비밀번호만 변경할 경우 PATCH를 사용하는 것이 적절합니다. PUT은 동일한 요청을 여러 번 보내더라도 결과가 같기 때문에 멱등성을 가지지만, PATCH는 구현 방식에 따라 멱등성이 보장되지 않을 수도 있습니다.
Q. 리다이렉션의 정확한 의미는?
리다이렉션은 서버가 클라이언트에게 “요청한 리소스는 다른 곳으로 이동되었어요” 라고 알려주는 응답입니다.
대표 상태 코드: 301, 302, 303, 307, 308
함께 전달되는 Location 헤더를 통해 이동할 URL 경로가 포함됩니다.
HTTP/1.1 301 Moved Permanently
Location: /new-page
리다이렉션은 서버가 클라이언트에게 요청한 리소스가 다른 위치로 이동되었음을 알리는 응답을 보내는 것을 말합니다. 이때 클라이언트는 응답에 포함된 Location 헤더 값을 참고하여 자동으로 새 위치로 이동합니다.
대표적인 상태 코드는 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect 등이 있으며, 각각 리다이렉션의 성격에 따라 영구/임시 여부와 요청 방식 유지 여부 등이 다릅니다. 예를 들어 301은 해당 리소스가 완전히 이동되었음을 의미합니다.
Q. HTTP 요청 메시지를 보낸 클라이언트들이 이전에 접속한 URL을 알고 싶을 때?
➡️ Referer(오타 아님) 헤더를 확인하면 됩니다.
Referer: https://www.example.com/previous-page
브라우저가 이전에 방문한 페이지의 URL을 서버로 전송함
사용 예시: 유입 경로 분석, 보안 정책 설정 (e.g., 이미지 hotlinking 방지)
이전 페이지에서 현재 페이지로 이동했을 때의 URL 정보를 알고 싶다면, 요청에 포함된 Referer 헤더를 확인하면 됩니다.
이 헤더는 클라이언트(주로 브라우저)가 현재 요청을 보내기 전 어떤 페이지에서 왔는지를 나타내는 정보를 담고 있어, 유입 경로 분석이나 리퍼러 기반 접근 제어 등에 사용됩니다.
예를 들어, 이미지 핫링크 방지를 위해 특정 사이트에서 온 요청만 허용하는 등의 보안 정책을 설정할 때도 활용됩니다.
Q. HTTP 요청 메시지를 보낸 클라이언트들의 접속 정보를 알고 싶을 때?
➡️ User-Agent 헤더를 확인합니다.
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/123.0
브라우저, 운영체제, 디바이스 정보가 포함됨
사용 예시: 사용자 환경별 렌더링, 크롤러 식별 등
클라이언트의 브라우저 종류나 운영체제, 디바이스 정보 등을 확인하고 싶을 때는 요청 메시지에 포함된 User-Agent 헤더를 확인합니다.
이 헤더에는 예를 들어 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/123.0" 같은 문자열이 포함되며, 이를 통해 접속한 클라이언트의 환경을 유추할 수 있습니다. 이 정보는 다양한 디바이스에 맞게 화면을 조정하거나, 웹 크롤러와 일반 사용자를 구분하는 용도로도 사용됩니다.
7. 마무리
이번 포스트에서는 다음을 학습했습니다.
HTTP 메서드를 통해 요청의 목적을 정의한다.
상태 코드를 통해 요청 결과를 숫자로 표현한다.
헤더를 통해 다양한 요청/응답 정보를 함께 전달한다.
다음 포스트에서는 HTTPS, TLS, 인증과 상태 유지 (쿠키/세션/토큰) 등을 심화 학습할 예정입니다.
