HTTP 특징, HTTP 1,2,3의 차이, HTTP 상태코드

Net

October 22, 2022

Songhee Lee

Previous Next

TL;DR

HTTP 특징
HTTP 1, 2, 3
HTTP 상태 코드

HTTP

HyperText Transfer Protocol

웹 상에서 클라이언트와 서버 간에 요청(request) 과 응답(response) 으로 정보를 주고받을 수 있는 프로토콜.

Request의 예시

  GET <https://www.naver.com> HTTP/1.1								
  User-Agent: Chrome/5.0 (Windows NT 10.0; Win64; x64) ...			

Response의 예시

  HTTP/1.1 200 OK														// 시작줄
  Connection: keep-alive												 // 헤더
  Content-Length: 21211
  Content-Type: text/html;

  <!DOCTYPE html><html><head><title...

HTTP 특징

1. 서버-클라이언트 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있다.

2. 비연결성(Connectionless)

클라이언트가 어떠한 데이터를 요청하면 서버는 응답을 하고 한 번 맺었던 연결을 끊어버린다.

장점
- 리소스를 아낄 수 있기 때문에 더 많은 연결을 할 수 있다.
단점
- 매번 연결을 새로 맺기 때문에 시간이 발생한다.(3 way handshake)
- 매번 새로운 연결을 해야하므로 오버헤드가 발생한다.

3. 무상태(Stateless)

연결을 끊는 순간 서버는 클라이언트의 상태 정보를 유지하지 않는다.

장점
- 서버의 확장에 용이하다(scale out). stateful은 특정 클라이언트를 특정 서버가 전담하는 식으로 대응한다. 따라서 동적으로 서버를 확장하기가 어렵다. 반면에 statelesss하다면 서버 호출 시 정보를 다 넘겨주기 때문에 문제가 발생해도 다른 서버를 호출해 처리가 가능하다. 따라서 스케일 아웃(같은 기능하는 서버군들의 수평 확장)에 유리하다.
단점
- 클라이언트가 추가 데이터를 전송해야 한다.

HTTP 버전

HTTP 0.9 (1991년)

HTTP 헤더도 없고, HTML파일만 전송 가능했던 것이 특징
요청 method는 GET만 존재
응답도 파일 자체로만 구성됨

/* 응답 */
<HTML>
A very simple HTML page
</HTML>

HTTP 1.0 (1996년) - 헤더의 등장

HTTP 헤더(header) 개념이 도입
버전 정보, 상태코드가 함께 전송되기 시작.
Content-type 도입으로 HTML이외의 문서 전송이 가능해짐

/* 요청 */
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

/* 응답 */
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

한계 : 커넥션 하나 당 요청 하나 와 응답 하나 만 처리가 가능. → HTTP 1.1에서 개선

HTTP 1.1 (1997년) - 커넥션 재사용

HTTP 1.1의 가장 큰 특징은 사용된 커넥션을 다시 열어 시간을 절약하게 했다는 것
- Persistent Connection : 지정한 timeout 동안 커넥션을 닫지 않아 속도가 빨라짐
파이프라이닝(Pipelining) : 여러 개의 요청을 보낼 때 처음 요청이 응답될 때까지 기다리지 않고 바로 요청을 보내는 것
- 대기 시간 줄이기
- 하지만 HOL blocking 문제로 인해 대부분의 브라우저에서는 여러개의 tcp 연결을 만들어 병렬적으로 이용하는 방식을 많이 사용했다. (이렇게 하면 추가 메모리와 CPU 리소스 낭비됨)

호스트헤더(Host Header)

단점

무거운 header 구조(ex. 쿠키)
HOL (Head of Line) blocking: 특정 응답의 지연. 앞 응답이 오래걸리면 뒤 요청은 Blocking되어버림.

HTTP2.0 (2015년) - 멀티 플렉싱

HTTP/2.0의 핵심은 기존의 요청 메세지를 작은 프레임으로 쪼갰다는 것
- 헤더와 컨텐츠 부분을 하나의 프레임으로 분리
- 기존의 텍스트 형식의 요청 메세지를 바이너리 인코딩을 통해 최적화

Multiplexed Streams : HTTP 1.1의 HTTP Pipelining의 개선안
- 하나의 Connection으로 동시에 여러 개의 메세지를 주고 받을 수 있음.
- 응답은 요청 순서에 상관없이 Stream으로 받기 때문에 HOL Blocking 도 발생하지 않음
- 여러 개의 스트림을 인터리빙 함 : 쪼개진 프레임들을 서로 끼워넣는 것
- 위 그림에서 스트림 1, 3, 5 총 3개의 스트림이 병렬적으로 하나의 연결 안에서 이루어지기 때문에 응답 다중화(멀티 플렉싱)를 가능하게 해서 HOL blocking 문제 해결
- 여러 개의 연결이 없어도 돼서 리소스 비용 더 절감됨
Stream Prioritization : 응답에 대한 우선순위를 정해 우선순위가 높을수록 응답을 빨리함.
Header Compression : Header Table과 Huffman Encoding을 사용하는 HPACK 압축방식으로 이를 개선. 클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경령화.

HTTP 3.0 () - with QUIC

HTTP 2.0의 TCP 기반을 둔 Headof line 블록킹 문제

HTTP 상태코드

클라이언트가 서버에 보낸 요청이 어떻게 처리되었는지 보여주는 코드.

1xx(Informational) : 요청이 수신되어 처리중

2xx(Successful) : 요청 정상 처리

200 OK : GET 요청 성공
201 Created : POST 새로운 리소스 생성
- 클라이언트 요청이 성공해서 새로운 리소스가 생성되었을 때 돌아오는 응답코드.
- HTTP Heder에 Location을 같이 넣어 응답
202 Accepted : 요청이 접수되었으나 처리가 완료되지는 않았다는 뜻.
여기서 잠깐!

202 Accepted는 언제 사용할까요? (요청 완료하고 201 보내면 안되나?)
- 서버가 요청은 받아들일 수 있는데,
- 언제 처리를 완료할것인지 보장도 없을 때 보내는 응답
204 No Contented : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없다는 뜻. (ex. 웹문서 편집기 save 버튼)

3xx(Redirection) : 요청을 완료하려면 추가 행동이 필요

이때 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동을 한다.(Redirect)

영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동

301 Moved Permanently : 리다이렉트 요청 시 요청 메서드가 Get으로 변하고, 본문이 제거 될 수 있음.
308 Permanent Redirect : 리다이렉트 요청 시 요청 메서드와 본문 유지됨.

일시 리다이렉션 : 일시적인 변경. 잠깐 이동할 때 쓴다.

예를 들어 주문 완료 후 주문 내역 화면으로 이동하는 경우
302 Found : 리다이렉트 요청 시 메서드가 GET으로 변할 수 있고, 본문이 제거될 수 있음.
303 See Other : 302와 기능 같음. 요청 메서드가 무조건 GET으로 변경됨
307 Temporary Redirect : 302와 기능 같음. 리다이렉트 시 요청 메서드와 본문을 유지.

특수 리다이렉션 : 결과 대신 캐시를 사용

캐시 결과가 만료된 것 같을 때, 클라이언트가 서버에 캐시가 만료된 것이 맞는지 확인. 서버가 캐시를 그대로 사용해도 된다고 알려줌)
304 Not Modified : 클라이언트에게 리소스가 수정되지 않았다는 것을 알려줌. 응답에 메세지 바디를 포함하면 안 된다.

4xx(Client Error) : 클라이언트 오류

잘못된 문법 등으로 서버가 요청을 수행할 수 없음
400 Bad Request : 요청 구문, 메시지 등 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음.
401 Unauthorized : 클라이언트가 해당 리소스를 쓰기 위해서는 인증이 필요함.
- 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해줘야함
403 Forbidden : 서버가 사용자의 요청을 이해했지만, 승인을 거부함.
- 예를 들어 어드민 등급이 아닌 사용자가 어드민 등급의 리소스에 접근한 경우
404 Not Found : 요청 리소스를 찾을 수 없음.
- 클라이언트가 없는걸 요청했으니, 잘못된 요청

5xx(Server Error) : 서버 오류

서버가 정상 요청을 처리하지 못함.
500 Internal Server Error : 서버 내부에 문제가 발생해서 오류가 발생함. 애매하면 500.
503 Service Unavailable : 서버에 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음.

예상 질문

HTTP 각 버전의 가장 큰 특징을 발전 흐름에 따라 얘기해주세요. (HTTP 1.1 / 2.0 / 3.0 의 차이점에 대해서 설명해주세요)

HTTP 1.1 은 Pipelining이 특징이다. 기본적으로 HTTP 요청은 순차적이기 때문에 요청에 대한 응답을 받고 나서야 새로운 요청을 보낸다. 하지만 HTTP 1.1 에서는 응답을 기다리지 않고 요청을 연속적으로 보내는 기능이 추가되었다. 하나의 connection에서 한 번에 순차적인 여러 요청을 보내고 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄인다.
HTTP 2.0 은 Multiplexed Streams가 특징이다. HTTP 1.1 에서는 요청의 순서와 응답의 순서는 동기화 되어야 하므로 특정 요청을 처리하는데 많은 시간이 걸린다면 그 뒤의 다른 요청을 처리하는데 지연이 발생하여 HOL Blocking 이 발생한다. HTTP 2.0 은 하나의 Connection으로 동시에 여러 개의 메세지를 주고 받을 수 있다. 응답은 요청 순서에 상관없이 Stream 으로 받기 때문에 HOL Blocking 발생이 줄어든다.
HTTP 3.0은 TCP가 아닌 UDP를 사용한다는 것이다. HTTP 3.0 은 QUIC라는 프로토콜 위에서 돌아가는 HTTP인데, QUIC은 UDP를 사용하는 프로토콜이다. 그리고 TCP hand shake 과정을 최적화하는 것에 초점을 맞추어 설계되었다. UDP는 TCP에 비해 헤더가 많이 비어있기에, 커스터마이징할 수 있는 여지가 많고 이를 이용해 개발자가 구현을 어떻게 하느냐에 따라서 신뢰성을 확보할 수 있다.

POST로 주문 후에 웹 브라우저를 새로고침하면 다시 요청이 돼서 중복 주문이 될 수 있는데, 이를 어떻게 해결하나요?

POST / Redirect / Get
POST 요청을 GET 메서드로 리다이렉트 해서 요청을 중복하지 않고 결과 화면만 GET으로 요청하는 방법입니다.

HTTP 메소드 종류와 사용법을 CRUD 관점에서 설명해주세요.

HTTP 응답 코드 중 클라이언트 에러를 나타내는 401번과 403번의 차이점을 설명해 주세요.

401번은 Unauthorized로, 클라이언트가 응답을 받기 위해 권한을 가진 사용자인지 인증할 필요가 있다는 의미입니다. 403번은 Forbidden로, 클라이언트가 콘텐츠에 접근할 권리가 없음을 의미합니다. 401과 다른 점은 이 때 서버는 클라이언트가 누구인지 알고 있다는 점입니다.