[Network] : Web과 HTTP

HTTP 개요

HyperText Transfer Protocol로

Web의 애플리케이션 계층 프로토콜입니다.

• 클라이언트(브라우저)와 서버 간의 Request-Response 모델을 사용합니다.
• HTTP는 TCP를 사용하며, 기본적으로 80번 포트를 사용합니다.
• HTTP는 상태를 유지하지 않는 Stateless한 프로토콜입니다.

Stateless Protocol

어떠한 이전 요청과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜

HTTP의 연결 유형

HTTP의 연결 유형에는 2가지 있습니다.

Non-persistent HTTP : HTTP/1.0

• 각 객체마다 별도의 TCP 연결을 사용하는 방식입니다.
• 연결 설정, 객체 전송, 연결 종료의 과정으로 이루어집니다.
• 따라서, 여러 Object를 다운로드하기 위해서는 여러 연결이 필요합니다.

연결 과정

1. 클라이언트가 서버에 TCP 연결을 80번 포트로 요청합니다.

2. 서버는 TCP 연결 요청을 수락하고 클라이언트에게 알립니다.

3. 클라이언트가 TCP 연결 소켓을 통해 HTTP 요청 메시지를 전송합니다.

4-a. HTTP 서버가 요청 메시지를 받고 응답 메시지를 생성합니다.

4-b. 서버는 이 응답 메시지를 클라이언트에게 소켓으로 전송합니다. 그리고 HTTP 서버가 TCP 연결을 종료합니다.

5. 클라이언트는 응답 메시지를 받아 필요한 곳에 활용합니다.

6. 각 요청마다 위의 1 ~ 5단계를 반복합니다.

RTT : Round Trip Time

데이터 패킷이 출발지에서 목적지로 갔다가 다시 출발지로 돌아오는 데 걸리는 시간을 의미합니다.

• 클라이언트 → 서버로 요청 패킷을 보내고, 서버 → 클라이언트로 응답 패킷이 돌아오는 데 걸리는 총 시간
• 밀리초(ms) 단위로 측정됩니다.
• 네트워크 지연 시간을 나타내는 지표로 사용됩니다.

Non-persistent HTTP의 경우, 각 객체마다 새로운 TCP를 연결하기 때문에 객체당 2RTT가 필요합니다. 따라서, $$Response \space Time = 2RTT + file \space transmission \space time$$이 됩니다.

문제점

결국 Non-persistent HTTP에는 다음과 같은 문제점이 존재합니다.

• 각 객체마다 새로운 TCP 연결을 설정하고 종료해, 불필요한 네트워크 오버헤드를 발생시킵니다.
• 매 요청마다 TCP 3-way handshake가 필요해 지연 시간이 늘어납니다.
• 연결 설정과 해제가 빈번해 서버에 추가적인 부하를 줍니다.
• 각 연결마다 TCP Buffer와 같은 리소스를 할당하고 해제하기 때문에 네트워크 리소스 낭비가 발생합니다.

이러한, 문제를 해결하기 위해 Persistent HTTP가 도입되었습니다.

Persistent HTTP : HTTP/1.1

• 하나의 TCP 연결로 여러 객체를 전송할 수 있습니다.
• 서버는 응답 후에도 연결을 유지합니다.
• 클라이언트는 참조된 객체를 발견하는 즉시 요청을 보낼 수 있습니다.
• 연결을 명시적으로 종료하거나 일정 시간 동안 사용하지 않을 때까지 연결을 유지합니다.
• RTT가 줄어들어 응답 속도가 개선됩니다.

HTTP 메서드

HTTP 메서드에 대한 내용은 여기를 참고해주세요.

쿠키 : Cookie

서버가 클라이언트에 저장하는 작은 데이터 조각입니다.

• 클라이언트는 이후 요청 시 쿠키를 서버로 다시 전송합니다.
• 이를 통해 Stateless한 HTTP 프로토콜에서 상태 정보를 유지할 수 있습니다.

쿠키의 생성 및 전송 과정

1. 서버는 HTTP 응답에 `Set-Cookie` 헤더를 포함하여 쿠키를 설정합니다.
2. 브라우저는 이 쿠키를 저장합니다.
3. 이후 요청 시 브라우저는 `Cookie` 헤더에 저장된 쿠키를 포함하여 서버로 전송합니다.

Web Cache : Proxy Server

원본 서버를 거치지 않고 클라이언트의 요청을 처리하는 중간 서버입니다.

• 동일한 리소스에 대한 반복적인 요청을 줄이고 응답 시간을 단축시킬 수 있습니다.
• 클라이언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 것입니다.

Client 1이 Origin Server에 접속해서 생긴 데이터(캐시)가 Proxy에 쌓이고, Client 2가 똑같은 요청을 하면 Origin Server에 요청할 필요없이 Proxy에서 응답해주는 구조입니다.

조건부 GET : Conditional GET

웹 캐시를 통해 응답 시간을 줄일 수 있지만, 웹 캐시 서버에 있는 데이터가 가장 최신 데이터인지 확인하는 작업이 필요합니다. 이런 문제를 해결하기 위해 HTTP는 조건부 GET 메서드를 이용합니다.

작동 방식

1. 클라이언트는 `If-modified-since` 헤더를 사용해 캐시된 복사본의 날짜를 명시합니다.
2. 서버는 요청받은 객체가 해당 날짜 이후에 수정되었는지 확인합니다.
3. 객체가 수정되지 않았다면, 서버는 304 Not Modified 응답을 보냅니다. 이 응답에는 객체 데이터가 포함되어 있지 않습니다.
4. 객체가 수정되었다면, 서버는 200 OK 응답과 함께 새로운 객체 데이터를 전송합니다.

즉, HTTP 요청 메시지를 통해 Web Cache에 있는 객테를 그대로 받아 사용할 것인지, Origin Server로부터 업데이트된 객체를 받을 것인지를 결정하는 과정입니다.

장점

• 네트워크 대역폭 절약 : 수정되지 않은 객체는 다시 전송되지 않습니다.
• 서버 부하 감소 : 불필요한 데이터 전송을 줄입니다.
• 클라이언트 응답 시간 단축 : 캐시된 데이터를 즉시 사용할 수 있습니다.

HTTP/2

HTTP/1.1의 성능을 개선하기 위해 도입되었습니다.

• HTTP/2는 텍스트 기반이 아닌 바이너리 프로토콜입니다. 따라서, 데이터 전송에 필요한 바이트 수를 줄이고 파싱 효율성을 높입니다.
• 단일 TCP 연결을 통해 여러 요청과 응답을 동시에 처리할 수 있습니다.

기존 HTTP/1.1의 경우, 한번에 하나의 객체만 전송이 가능했습니다. 즉, Connection 1개 당 1개의 요청을 처리했습니다. 이와 같은 경우, Packet 대기열이 존재할 때, 앞선 Packet이 지연될 때 발생하는 성능 저하인 HOL(Head-of-Line) Blocking 문제가 발생할 수 있습니다.

HTTP/2의 경우, 위 그림처럼 객체를 Frame 단위로 분할해 전송하기 때문에, HOL Blocking 문제를 방지할 수 있다.

HTTP/3

• UDP를 기반으로 하는 QUIC 프로토콜을 사용합니다.
• 더 나은 성능과 보안을 제공합니다.