HTTP란
HTTP는 WWW에서 브라우저와 서버 간 데이터를 주고받기 위한 통신 프로토콜입니다. 웹에서 텍스트, 이미지, 동영상 등 다양한 리소스를 요청하고 전달받는 데 사용됨
HTTP의 목적
데이터의 형식에 구애받지 않고 애플리케이션의 다양한 자원을 네트워크를 통해 송수신하는 것
HTTP의 특징
1. 요청 응답 기반 프로토콜
HTTP는 기본적으로 요청 메세지를 보내는 보내는 클라이언트와 이에 대해 응답 메세지를 보내는 서버가 서로 요청/응답 멧지를 주고받는 구조로 작동
2. 미디어 독립적 프로토콜
HTTP는 주고받을 자원의 특성과 무관하게 자원을 주고받는 수단(인터페이스)의 역할만 수행. 예를 들어 (HTML, JPEG, PNG, JSON, XML, PDF) 등 다양한 자원을 주고받을 수 있음
3. 스테이트리스 프로토콜
서버는 HTTP요청을 보낸 클라이언트 관련 상태를 기억하지 않기 때문에 클라이언트의 모든 HTTP요청은 기본적으로 독립적인 요청으로 간주됨
4. 지속 연결 프로토콜
- HTTP 1.1이상에서는 지속연결 사용
- 하나의 TCP연결 상에서 여러 개의 요청-응답을 주고받을 수 있는 기술
- 이를 통해 비지속 연결보다 빠른 속도로 여러 HTTP의 요청과 응답을 처리할 수 있음
HTTP의 변천사
1. HTTP/1.1
1997년에 등장한 HTTP의 표준으로, 현재까지도 널리 사용됨
1) 특징
- 지속 연결 : 기본적으로 TCP연결을 재사용하여 여러 요청을 처리함
Connection: keep-alive - 파이프라이닝 : 여러 요청을 연속으로 보내 처리 속도를 높일 수 있으나, 응답 순서가 유지되어야 하기 때문에 헤드 오브 라인 블로킹(Head-of-Line Blocking)이 발생할 수 있음
- 캐싱 지원 :
Cache-control, 'ETag'같은 헤더를 통해 클라이언트와 서버 간 데이터 캐싱을 지원함 - 호스트 헤더 필수 : 여러 도메인을 동일한 IP에서 호스팅할 수 있도록
Host헤더를 요구함
2) 단점
- 한 연결에서 하나의 요청-응답이 순차적으로 처리되어 병렬 처리가 비효율적
- 헤드 오브 라인 블로킹 문제(: 네트워크에서 한 요청이 지연되면 뒤따르는 모든 요청도 함께 지연됨)가 성능 병목 유발 가능
2. HTTP/2
2015년에 표준화된 버전으로, 성능 개선에 초점을 맞추고 있음
1) 특징
- 멀티플렉싱(Multiplexing) : 단일 연결에서 여러 요청과 응답을 동시에 처리할 수 있음. 헤드 오브 라인 블로킹을 줄인다
- 헤더 압축 : 중복 데이터를 줄이기 위해 헤더를 압축해 전송
- 서버 푸시 : 클라이언트가 요청하지 않은 리소스도 서버가 미리 클라이언트로 전송할 수 있음
- 이진 프로토콜 : HTTP/1.1의 텍스트 기반 프로토콜을 이진 프레이밍(binary framing)으로 본경해 효율성을 높임
2) 장점
-
더 빠른 데이터 전송과 네트워크 자원 활용
-
지연 시간 감소
HTTP/3
HTTP/2의 성능 문제를 개선하고자 개발된 최신 프로토콜. QUIC(Quick UDP Internet Connections)를 기반으로 함
1) 특징
- UDP기반 : TCP대신 UDP를 사용해 빠른 연결 수립과 데이터 전송을 지원
- 연결 복구 가능 : 네트워크가 변경되어도 기존 연결을 유지할 수 있음. 예를 들어 Wi-Fi에서 LTE로 전환시에도 연결이 끊기지 않음
- 내장된 TLS 1.3 : 보안을 강화하며 핸드셰이크 과정을 줄여 연결 속도를 높임
- 헤드 오브 라인 블로킹 제거 : HTTP/2에서 단일 연결 내 문제가 발생하면 전체 요청이 지연되지만, HTTP/3는 각 스트림이 독립적으로 동작해 이를 방지
2) 장점
- 모바일 환경에서 안정적이며 빠른 데이터 전송 가능
- 높은 보안성과 저지연 연결
++ HTTP/3에서 UDP를 사용하는데 연결복구 기능과 보안성 강화가 이해가 안되어 추가
- UDP는 기본적으로 연결 상태를 관리하지 않지만 QUIC가 이를 보완해 연결 관리 기능을 자체적으로 구현(클라이언트와 서버 간 연결 상태를 유지하기 위해 고유한 연결ID를 사용). 그래서 네트워크 환경이 바뀌어도 동일한 연결ID를 사용해 동일한 세션을 유지할 수 있다!
- 보안성이 강화되는 이유 : TLS1.3을 프로토콜 내부에 통합해 데이터 암호화를 기본적으로 제공, 초기 핸드셰이크 과정에서 보안을 설정함
++ HTTP 파이프라이닝
HTTP파이프라이닝은 HTTP/1.1에서 등장한 기술로, 하나의 TCP연결을 통해 클라이언트가 다수의 요청을 연속적으로 전송할 수 있게 하는 방식
- 연속적인 요청 전송 : 클라이언트는 서버의 응답을 기다리지 않고, 여러 개의 요청을 연속적으로 보냄
- 서버의 응답 처리 : 서버는 요청을 받은 순서대로 처리하고, 응답을 같은 순서로 클라이언트에게 보냄
- 장점 : 네트워크 효율성 증가, TCP연결유지
- 단점 : 헤드 오브 라인 블로킹(이전 요청의 응답이 지연되면, 뒤따르는 모든 응답 지연), 서버의 구현 부담(요청 순서를 유지해야 하므로, 복잡성 증가)
++TLS 1.3도입으로 핸드셰이크 과정 단축
보안 계층이 QUIC 프로토콜에 내장되어 있어 별도의 과정 없이 보안 연결이 이루어집니다. 이전 세션에서 세션 키를 재사용할 수 있는 경우, 서버와 클라이언트는 핸드셰이크 없이 바로 데이터를 전송할 수 있습니다. 핸드셰이크와 암호화가 프로토콜 수준에서 함께 처리됩니다.
1. TLS 1.2핸드셰이크(왕복 2번 필요)
1) Client Hello : 클라이언트에서 서버로 요청 보냄. 클라이언트의 암호화 알고리즘 지원 목록과 난수 전달
2) Server Hello : 서버가 암호화 알고리즘을 선택하고 자신의 인증서와 난수를 전달
3) Key Exchange & Finished Messages : 클라이언트와 서버가 서로 암호화 키를 교환하고 세션 키를 생성. 이후 클라이언트가 데이터를 암호화해 전송
2. TLS 1.3 핸드셰이크
1) Client Hello : 클라이언트가 초기 연결 요청과 함께 자신의 지원 알고리즘 목록, 난수, 초기 암호화 데이터 전송. 이전 세션에서 공유한 세션 키를 포함
2) Server Hello & Encrypted Extensions : 서버가 암호화 알고리즘을 선택하고 세션 키를 생성. 이후 암호화된 데이터를 즉시 교환
3) 데이터 전송 시작 : 서버와 클라이언트는 세션 키를 통해 데이터를 바로 전송
HTTP가 스테스트리스 프로토콜인 이유는?
1. 단순성과 확장성
- 상태를 유지하지 않기 때문에, 서버는 각 요청을 별도로 처리할 수 있어 단순한 설계가 가능
- 대규모 트래픽을 처리하는 데 유용하며, 요청을 분산 처리하거나 로드 밸런싱이 용이
2. 연결 유지 부담 감소
- 상태를 저장하면 서버가 추가 메모리를 사용해야 하므로 성능에 영향을 줌
- 스테이트리스 구조는 상태 저장에 따른 부하를 줄여 성능 최적화
3. 서버의 추가와 대체가 쉬워짐
- HTTP서버가 지켜야 할 주요 설계 목표는 확장성(scalability)과 견고성(robustness)이 있음. 모든 요청을 독립으로 처리시 서버의 추가나 대체가 쉬워짐. 즉, 상태를 유지하지 않는 스테이트리스한 특성은 필요한 경우 언제든 쉽게 서버를 추가할 수 있어 확장성을 높이고, 서버 중 하나에 문제가 생기더라도 쉽게 다른 서버로 대체할 수 있어 견고성을 높일 수 있음
- 또한, 스케일 아웃, 즉 수평확장에 있어서 유리함. 같은 기능을 하는 서버를 여러 개로 확장시킬 수 있음
stateless의 한계
1. 상태 관리의 복잡성 증가
- HTTP 자체가 상태를 저장하지 않으므로, 상태를 유지하려면 클라이언트가 쿠키, 세션, 토큰 등의 보조 기술을 추가적으로 사용해야 함
- 이로 인해 개발자가 별도의 상태 관리 로직을 구현하고 유지해야 하므로 복잡성이 증가할 수 있음
2. 클라이언트-서버 간 불필요한 데이터 전송
- 매 요청마다 필요한 모든 데이터를 클라이언트가 서버에 전송해야 하므로, 데이터 크기가 커질수록 네트워크 부하가 발생할 가능성 존재(예: 사용자의 인증 정보를 매번 전송해야 하는 경우)
3. 리소스 낭비
- 이전 상태를 기억하지 않기 때문에 서버는 요청을 받을 때마다 처음부터 새로 처리해야 함
- 같은 사용자가 반복적으로 요청하는 경우에도 매번 동일한 작업을 반복하게 되어 성능 저하가 발생할 수 있음
4. 실시간 데이터 유지 어려움
- 연결 상태를 기억하지 않으므로, 실시간 채팅이나 스트리밍 같은 상태를 유지하는 애플리케이션에서는 stateless방식이 비효율적
- 이를 해결하기 위해 WebSocket같은 상태 유지 가능한 프로토콜을 사용해야 함
5. 안전성 및 신뢰성 부족
- stateless 특성상 서버는 클라이언트의 이전 요청 상황을 알 수 없기 때문에 요청이 중단되거나 에러가 발생했을 때 복구가 어려울 수 있으며, 중복 요청이 발생한 경우 이를 추가하는 로직이 추가로 필요
HTTP의 요청, 응답 모델
HTTP의 메세지는 기본적으로 시작라인, 필드라인, 메세지 본문으로 구성됨. 필드 라인은 여러 개가 존재할 수 있고, 메세지 본문은 없을 수도 있음.
1. 요청(Request)
클라이언트가 서버에 작업을 요청하는 메세지
- 요청 라인 : HTTP메서드(예: GET, POST), 요청URL, HTTP버전이 포함
- 헤더(Header) : 요청에 대한 추가 정보가 포함됨(예: 브라우저 정보, 인증 정보)
- 본문(Body) : POST, PUT요청에서 데이터를 서버에 전송할 때 사용됨
2. 응답(Response)
서버가 클라이언트 요청에 대해 처리 결과를 전달하는 메세지
- 상태 라인 : HTTP버전, 상태 코드(예: 200 OK, 404 NOT Found), 상태 메세지
- 헤더 : 응답에 대한 메타데이터로, 콘텐츠 유형, 길이 등의 정보를 포함
- 본문 : 클라이언트가 요청한 리소스(예: html, json데이터)가 포함
3. 작동 흐름
- 클라이언트가 요청을 서버로 보냄
GET /index.html HTTP/1.1 - 서버가 요청을 처리하고, 결과를 응답으로 반환
HTTP/1.1 200 OK와 함께 HTML문서를 전달
HTTP 헤더의 종류
HTTP 헤더는 응답 메세지에 포함되어 추가 정보를 제공하는데 사용됨. HTTP헤더는 크게 다음 4가지 종류로 나뉜다
1. 일반 헤더(General Headers)
요청과 응답에 모두 사용되며, 메세지에 대한 일반 정보를 제공함
- Cache-Control : 캐싱 동작을 제어함
Cache-control: no-cache - Connection : 연결 유지 여부를 나타냄
Connection: keep-alive - Date : 메세지가 생성된 날짜와 시간을 나타냄
Date: Tue, 10 Dec 2024 10:30:00 GMT
2. 요청 헤더(Request Headers)
클라이언트가 서버에 요청을 보낼 때 추가 정보를 포함함
- Host : 요청 대상 서버의 도메인과 포트를 지정
Host: www.example.com - User-Agent : 클라이언트의 소프트웨어 정보를 제공
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) - Accept : 클라이언트가 받을 수 있는 MIME타입을 지정
Accept: text/html, application/json - Authorization : 인증 정보를 서버에 전달
Authorization: Bearer <token>
응답 헤더(Response Headers)
서버가 클라이언트에 응답할 때 메세지와 관련된 정보를 포함함
- Server : 서버 소프트웨어의 정보를 나타냄
Server: Apache/2.4.41 (Ubuntu) - Location : 리소스가 이동된 URL을 제공
Location: https://example/new-page - Retry-After : 클라이언트가 다시 요청해야 하는 시간을 제공
Retry-after: 120
4. 엔티티 헤더(Entity-Headers)
요청이나 응답 본문(Entity body)과 관련된 정보를 제공
- Context-Type : 본문의 MIME타입을 지정 `content-tyhpe: application/json'
- Content-Length : 본문의 길이를 바이트 단위로 나타냄
Content-Length: 348 - Content-Encoding : 본문에 적용된 인코딩 방식을 나타냄
Content-Encoding: gZip - Last-Modified : 리소스가 마지막으로 수정된 시간을 나타냄
Last-Modeified: Mon, 09 Dec 2024 15:45:00 GMT
HTTP Keep-alive
HTTP 연결을 지속적으로 유지하며, 여러 개의 요청을 한 번의 연결로 처리할 수 있게 하는 기능. 기본적으로 HTTP는 각 요청마다 새로운 연결을 맺고, 요청을 처리한 후 연결을 끊음. 하지만 Keep-Alive를 사용하면, 클라이언트와 서버 간의 연결을 여러 요청에 대해 재사용할 수 있음. 이로 인해 성능이 개선되고, 연결을 생성하는 데 드는 오버헤드를 줄일 수 있음
HTTP 메서드
| HTTP 메서드 | 설명 |
|---|---|
| GET | 자원을 습득하기 위한 메서드 |
| HEAD | GET과 동일하나, 헤더만을 응답받는 메서드 |
| POST | 서버로 하여금 특정 작업을 처리하게끔 하는 메서드 |
| PUT | 자원을 대체하기 위한 메서드 |
| PATCH | 자원에 대한 부분적 수정을 위한 메서드 |
| DELETE | 자원을 삭제하기 위한 메서드 |
| CONNECT | 자원에 대한 양방향 연결을 시작하는 메서드 |
| OPTIONS | 사용 가능한 메서드 등 통신 옵션을 확인하는 메서드 |
| TRACE | 자원에 대한 루프백 테스트를 수행하는 메서드 |
1. GET과 HEAD
1) GET
가장 흔히 사용하는 메서드 중 하나로, 자원을 조회하는 용도의 메서드. 웹 브라우저를 통한 웹 페이지 조회는 웹 브라우저의 GET 요청 메세지에 대한 응답을 의미
2) HEAD
응답 메세지에 메세지 본문이 표시되지 않는다는 점을 제외하면 사실상 GET 메서드와 동일
2. POST
서버로 하여금 특정 작업을 처리하도록 하는 용도로 사용. 많은 경우에 클라이언트가 서버에 새로운 자원을 생성하고자 할 때 사용.
GET 메서드와 다른 점은 Message body가 같이 전달된다
3. PUT과 PATCH
PUT메서드가 덮어쓰기를 요청하는 메서드인 반면 PATCH메서드는 부분적 수정을 요청하는 메서드이다
4. DELETE
DELETE 메서드는 특정 자원의 삭제를 요청할 때 사용하는 메서드
HTTP 상태 코드
상태 코드 : 요청의 결과를 나타내는 3자리의 정수. 이들 중 200번대부터 500번대가 자주 사용하는 상태 코드에 해당됨.
| 상태 코드 | 설명 |
|---|---|
| 100번대(100 ~ 199) | 정보성 상태 코드 |
| 200번대(200 ~ 299) | 성공 상태 코드 |
| 300번대(300 ~ 399) | 리다이렉트 상태 코드 |
| 400번대(400 ~ 499) | 클라이언트 에러 상태 코드 |
| 500번대(500 ~ 599) | 서버 에러 상태 코드 |
1. 200번대 : 성공 상태 코드
- 200번대 상태 코드 : 요청이 성공했음을 의미함. 서버는 요청한 자원과 함께 상태 코드 200(OK)를 응답하고, 새로운 자원을 생성한 경에는 상태 코드 201(Created)를 응답함. 또한, 작업 시간이 긴 대용량 파일에 대한 업로드 작업이나 배치 작업과 같이 요청 결과를 바로 응답하기 어려운 경우에는 상태 코드 202(Accepted)로 응답할 수 있음
| 상태 코드 | 이유 구문 | 설명 |
|---|---|---|
| 200 | OK | 요청이 성공했음 |
| 201 | Created | 요청이 성공했으며, 새로운 자원이 생성되었음 |
| 202 | Accepted | 요청을 잘 받았으나, 아직 요청한 작업이 끝나지 않았음 |
| 203 | No Content | 요청이 성공했지만, 메세지 본문으로 표시할 데이터가 없음 |
2. 300번대 : 리다이렉션 상태 코드
리다이렉션(Redirection)이란 클라이언트가 요청한 자원이 다른 곳에 있을 때 다른 곳으로 요청을 이동시키는 것을 의미. 클라이언트가 요청한 자원이 다른 URL에 있을 경우, 서버는 리다이렉션 상태 코드와 함께 응답 메세지의 Location 헤더를 통해 요청한 자원이 위치한 URL을 안내해줄 수 있음. 이를 수신한 클라이언트는 Location 헤더에 명시된 URL로 재요청을 보내 새로운 URL에 대한 응답을 받게 된다.
영구적 리다이렉션은 자원이 완전히 새로운 곳으로 이동하여 경로가 영구적으로 재지정되는 것을 의미. 자원의 위치가 영구적으로 변경되었음을 시사하므로, 기존 URL에 요청 메세지를 보내면 항상 새로운 URL로 리다이렉트됨.
일시적 리다이렉션은 자원의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요할 경우에 주로 사용.
303(Moved Permanently)과 308(Permanent Redirect), 그리고 302(Found)와 303(See Other), 307(Temporary Redirect)은 재요청 메서드가 어떻게 변경되는지에 따라 구분할 수 있음
| 상태 코드 | 이유 구문 | 설명 |
|---|---|---|
| 301 | Moved Permanently | 영구적 리다이렉션 - 재요청 메서드가 변경될 수 있음 |
| 308 | Permanent Redirect | 영구적 리다이렉션 - 재요청 메서드가 변경되지 않음 |
| 302 | Found | 일시적 리다이렉션 - 재요청 메서드가 변경될 수 있음 |
| 303 | See Other | 일시적 리다이렉션 - 재요청 메서드가 GET으로 변경됨 |
| 307 | Temporary Redirect | 일시적 리다이렉션 - 재요청 메서드가 변경되지 않음 |
| 304 | Not Modified | 캐시 - 자원이 변경되지 않음 |
3. 400번대 : 클라이언트 에러 상태 코드
400번대 에러 코드는 '클라이언트에게 잘못이 있음'을 나타내는 상태 코드이다
| 상태 코드 | 이유 구문 | 설명 |
|---|---|---|
| 400 | Bad Request | 요청 메세지의 내용이나 형식 자체에 문제가 있음 |
| 401 | Unauthorized | 요청한 자원에 대한 유효한 인증이 없음 |
| 403 | Forbidden | 요청이 서버에 의해 거부됨(예: 자원에 대한 접근 권한이 충분하지 않음) |
| 404 | Not Found | 요청받은 자원을 찾을 수 없음 |
| 405 | Method Not Allowed | 요청한 메서드를 지원하지 않음 |
4. 500번대 상태 코드
500번대 상태 코드는 '서버에게 잘못이 있음'을 나타내는 상태 코드이다
사실 500번대 상태 코드의 대부분은 '요청을 처리할 수 없음'을 나타내는 500이다. 서버에 어떤 문제가 발생했을 때 익명의 다수 사용자에게 오류 원인을 상세히 공개하는 것은 보안상 좋지 않이 때문에 보통 서버 문제를 가리키는 상태 코드를 500으로 통칭하는 경우가 많다.
| 상태 코드 | 이유 구문 | 설명 |
|---|---|---|
| 500 | Internal Server Error | 요청을 처리할 수 없음 |
| 502 | Bad Gateway | 중간 서버의 통신 오류 |
