WEB | 프론트엔드 개발자로서 알아야할 HTTP 기초

HTTP 의 개념 설명

HTTP 의 사전적 정의는 HyperText Transfer Protocol, 즉 World Widw Web을 위한 데이터 통신의 기초이자 웹 사이트를 이용하는데 쓰는 프로토콜이다.

 

이를 한 단계 풀어서 설명하자면 컴퓨터 내부에서 혹은 컴퓨터 사이의 데이터 교환방식을 정하는 규칙체계가 존재하는데, 이것이 프로토콜이다.  인터넷에서 컴퓨터들이 서로 정보를 주고 받는데 쓰이는 프로토콜은 대게 OSI 7계층 모델로 설명되거나 TCP/IP 4계층 모델로 설명된다.

이 중에 애플리케이션 계층은 웹 서비스, 이메일 등 서비스를 실질적으로 이용하는 사람들에게 제공한다. HTTP 는 FTP, SSH, DNS 등과 함께 응용 프로그램이 사용되는 프로토콜 계층인 애플리케이션 계층이다. 

 

HTTP는 HTTP/1.0 부터 시작해서 발전을 거듭하여 현재는 HTTP/3 이다.

 

1. HTTP/1.0

기본적으로 한 연결 당 하나의 요청을 처리하도록 설계되었다. 

서버로부터 파일을 가져올 때마다 TCP의 3-way hand shake를 계속해서 열어야 하므로 RTT 가 증가하는 단점이 있다.

RTT가 증가하는 단점을 개선하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩 등을 사용했다.

 

* RTT란? 패킷이 목적이에 도달하고 나서 다시 출발지로 돌아오는데 필요한 시간, 패킷 왕복시간

2. HTTP/1.1 

매번 TCP 연결을 하는 것이 아니라 한번 TCP를 초기화 한 다음 keep-alive 옵션을 사용하여 여러 개의 파일을 송수신 할 수 있게 바뀌었다. 이전에도 keep-alive 옵션은 존재하였지만 표준화 되지 않았고 1.1에서 표준화되어 기본 옵션으로 설정되었다. 

하지만 이 방법 역시 요청할 리소스 개수에 비례하여 대기 시간이 길어지는 단점이 존재하였다. 

또한 HTTP/1.1 헤더에는 쿠키와 같은 다수의 메타 데이터가 들어있고 압축이 되지 않아 무겁다는 단점도 있었다. 

 

3. HTTP/2

멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선순위 처리를 지원하는 프로토콜로 응답시간을 앞당길 수 있다.

멀티플렉싱은 여러 개의 스트림을 사용하여 송수신을 하는데, 특정 패킷이 손실되어도 다른 스트림에는 영향을 주지 않는다. 

헤더 압축은 허프만 코딩 압축 알고리즘을 사용하는 HPACK 압축형식을 사용하여 헤더에 사용하는 비트양을 줄이는 방법이다.

서버 푸시는 클라이언트가 서버에 요청을 해야 파일을 다운로드 받을 수 있었던 HTTP/1.1 과 달리 클라이언트 요청 없이도 서버가 바로 리소스를 푸시할 수 있다.

 

4. HTTPS

웹 페이지에 접속할 때 URL 이 HTTPS 로 시작하는 것이 안전하다라는 이야기를 들어본 적이 있을 것이다. 

HTTPS 는 HTTP/2 위에서 동작하는데 애플리케이션 계층과 전송 계층 상이에 신뢰계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP 요청을 의미한다. 이를 통해 통신을 암호화하는 것이다.

출처 : https://www.hostinger.com.br/tutoriais/o-que-e-ssl-tls-https

통신이 암호화 되면 제3자가 메시지를 도청하거나 변조하지 못하게 된다.

이는 보안 외에도 이점을 갖고 있는데, 구글에서 공식적으로 모든 사이트 내 요소가 동일하다면 HTTPS 서비스를 하는 사이트가 그렇지 않은 사이트보다 SEO 순위가 높을 것이라고 밝히고 있으므로 SEO에도 도움이 된다.

 

5. HTTP/3

2022년 6월 표준화된 HTTP/3 는 TCP 기반의 HTTP/1, HTTP/2 와 달리 UDP 기반의 QUIC 계층 위에서 동작한다.

가장 큰 특징은 통신을 하기 위해 3-way 핸드셰이크, 즉 3번의 핸드셰이크가 필요했던 이전과 달리 보안 세션을 설정하기 위한 한 번의 핸드셰이크만 필요로 한다. 

HTTP/2 대비 가장 큰 장점 3가지가 있는데, 

1️⃣ Zero RTT

3 RTT가 필요한 이전 방식과 달리 1RTT 만으로도 통신이 가능하다. 뿐만 아니라 연결에 한번 성공한다면 서버는 해당 설정을 캐싱해두었다가 다음 연결 때 캐싱된 설정을 사용하여 0 RTT 만으로도 통신을 시작할 수 있다. 

2️⃣ 패킷 손실에 빠른 대응

타임 스탬프를 사용하여 패킷의 전송 순서를 파악하거나 타임스탬프를 사용할 수 없다면 시퀀스 번호에 기반하여 암묵적으로 전송 순서를 추론하는 TCP 와 달리 QUIC는 패킷마다 고유한 패킷번호를 부여함으로써 패킷 손실이 발생하였을 때 빠르게 감지할 수 있다.

3️⃣ 클라이언트 IP가 변경되어도 연결 유지

TCP의 경우 IP를 기반으로 클라이언트를 식별하므로 IP가 변경되면 연결이 끊어져 다시 연결을 생성하기 위해 3 핸드셰이크 과정을 거쳐야 한다. 반면 QUIC는 랜덤한 값인 Connection ID를 사용하여 서버와 연결을 생성함으로써 IP가 변경되더라도 IP와 무관하게 연결을 계속 유지할 수 있다. 

 

HTTP response status code

- 1xx(정보) : 요청을 받았으며, 클라이언트가 프로세스를 계속 진행 중임

- 2xx(성공) : 요청을 성공적으로 받아서 프로세스를 완료했음

- 3xx(리다이렉션) : 요청을 완료하기 위해 추가적인 작업이 필요함

- 4xx(클라이언트 오류) : 클라이언트가 잘못된 방법 혹은 문법을 사용하였음

- 5xx(서버 오류) : 정상적인 클라이언트 요청에 대해 서버의 문제로 응답할 수 없음

 

1xx : Information responses

100 Continue

요청이 진행 중임. 클라이언트는 요청을 계속 이어서 보내야 하며, 이미 요청을 완료한 경우에는 무시해도 된다.

2xx : Successful responses

200 OK

요청이 성공적으로 완료되었음

201 Created

리소스 생성 성공

204 No Content

리소스 삭제 성공

3xx : Redirection messages

304 Not Modified

이전의 요청과 비교하여 달라진 것이 없음 (캐시를 목적으로 사용됨)

4xx : Client error responses

400 Bad Request

잘못된 문법 혹은 형식으로 요청을 보내고 있어 서버에서 이해할 수 없음

401 Unauthorized

요청을 위한 권한 인증이 완료되지 않았음(ex 토큰이 없음)

403 Forbidden

클라이언트가 요청한 컨텐츠에 대해 접근할 권리가 없음

404 Not Found

리소스(DB, 경로)를 찾을 수 없음

409 Confilict

클라이언트의 요청과 서버의 상태와 충돌이 발생

5xx : Server error responses

500 Internal Server Error

서버 문제로 응답할 수 없음

 

 

참고
- '면접을 위한 CS 전공지식 노트' 중 SECTION 2.5 HTTP, 저자 주홍철, 출판사 길벗
- HTTP/3는 왜 UDP를 선택한 것일까?, evan-moon, 깃허브
- Amazon CloudFront, HTTP/3 지원 시작, Amazon Web Services 한국 블로그
- w3 RFC 2616 상태 코드 정리
- HTTP 상태 코드 정리, WhaTap