HTTP

HTTP는 Hyper Text Transfer Protocol의 약자로, W3 상에서 정보를 주고 받을 수 있는 프로토콜이다. 주로 TCP를 사용하고, HTTP/3부터는 UDP를 사용하며, 80번 포트를 사용한다.

클라이언트와 서버 사이에 이뤄지는 요청/응답 프로토콜이라 할 수 있다. 웹브라우저(클라이언트)가 HTTP를 통해 서버로부터 웹페이지나 그림 정보를 요청하면, 서버는 요청에 대한 응답 정보를 해당 사용자에게 전달한다.

HTTP를 통해 전달되는 데이터는 URL을 통해 조회할 수 있다.

HTTP 1.1 vs HTTP 2.0 vs HTTP 3.0

HTTP 1.1

• 속도가 느림.
  -> 연결당 하나의 요청과 응답을 처리하기 때문에 동시 전송 문제와 다수의 리소스를 처리하는 데에 속도와 성능 이슈 존재 (HOL(Head Of Line) Blocking (특정 응답 지연))
• HTTP 1.1의 제한된 사양으로 인해 클라이언트의 요청 순서와 서버의 응답 순서를 동기화해야 함.
• Round Trip Time 증가 (양방향 지연)
  -> 헤더가 큼. (쿠키의 비중 큼)
  -> 헤더에 많은 메타 데이터가 포함됨.
  -> 사용자가 방문한 웹페이지는 다수의 http요청이 발생되는데, 이때 요청마다 중복된 헤더 값을 전송하게 되고, 각 도메인에 설정된 쿠키 정보도 매 요청마다 헤더에 포함되어 전송. -> 헤더가 쓸데없이 큼

HTTP 2.0

HTTP 1.1의 느린 속도를 개선하기 위하여 SDPY 기반으로 등장

• 속도가 빠름
  -> Multiplexed Streams: 한 연결에 여러 개의 메세지를 동시에 송수신 할 수 있음.
  -> 요청에 대한 연결 상에서 다중화되기 때문에 HOL 발생하지 않음.
  -> Stream Prioritization: 요청 리소스 간 의존 관계 설정
  -> Header Compression: Header 정보를 HPACK 방식으로 압축하여 전송 -> 헤더의 크기 작아짐
  -> Server Push: HTML 문서 상에 필요한 리소스를 클라이언트 요청 없이 보낼 수 있음.
  -> 프로토콜 협상 메커니즘: 프로토콜을 선택
  -> HTTP 1.1과의 호환성이 매우 높음. -> 메소드, 상태 코드, URI/헤더 필드
  -> 페이지 로딩 속도 향상됨.

HTTP 3.0

UDP를 사용한 HTTP이다. HTTP 3.0은 QUIC이라는 프로토콜 위애서 돌아가는데, QUIC은 UDP를 사용하는 프로토콜이다.

TCP의 특징을 생각해보면 전송을 보장하는 대신에 3-hand shake, 4-hand shake 처럼 오버헤드가 발생하여 속도가 느리다. 이로 인해 HOLB 등과 같은 문제를 피할 수 없다.

UDP는 best effort를 특징으로 하는 프로토콜로, 전송을 보장하지는 않지만 실시간 프로그램에 매우 적합한 프로토콜이다.

QUIC는 TCP hand shake 과정을 최적화하는 것에 초점을 맞추어 설계되었다. UDP는 Datagram 방식을 사용하는 프로토콜이기 때문에 각각의 패킷 간 순서가 존재하지 않는 독립적인 패킷이다. UDP는 TCP에 비해 헤더가 비어있기 때문에 커스터마이징할 수 있는 여지가 많고, 이를 이용하여 구현을 어떻게 하느냐에 따라 신뢰성을 확보할 수 있다.

즉, HTTP 3.0은 신뢰성을 확보한 UDP 방식이라고 생각할 수 있다.

QUIC

연결 레이턴시 감소

• Round Trip Time: 클라이언트가 요청하고, 서버가 이에 대한 응답을 해주는 사이클
• TCP, TLS 기반의 HTTPS: 1(TCP)+2(TLS)=3
• QUIC 기반의 HTTPS: 1

TCP+TLS의 경우에는 데이터를 교환하기 전에 신뢰성 있는 연결과 암호화에 필요한 정보를 교환한 후에 데이터를 교환하게 된다.

패킷 손실 감지에 걸리는 시간 단축

TCP는 송신 측이 패킷을 보낸 이후에 타이머를 통해 패킷의 손상 여부를 확인한다. 이 과정에서 타임아웃을 동적으로 계산해야 하고, 패킷 재전송 시 ACK를 받았을 때 첫번째 전송에 대한 ACK인지, 두번째 전송에 대한 ACK인지 확인해야 한다. 이를 재전송 모호성이라 한다.

QUIC의 경우에는 헤더에 패킷 번호 공간을 부여하여 패킷 손실 감지에 걸리는 시간을 단축한다.

Multiplexing 지원

여러 개의 스트림을 사용하면 하나의 스트림의 패킷이 손실되어도 다른 스트림은 그대로 사용할 수 있다. HTTP 2.0과 마찬가지로 Muliplexing을 지원하여 이러한 이점을 가진다.

클라이언트의 IP가 바뀌어도 연결 유지

TCP의 경우에는 발신지의 IP, port와 수신지의 IP, port로 연결을 식별한다. 이로 인해 클라이언트의 IP가 바뀔 경우 연결을 끊어버리게 된다. 이 경우 3-hand shake를 통해 다시 연결해야 하기 때문에 지연이 발생한다.

QUIC의 경우에는 connection ID를 통해 연결을 생성하기 때문에 클라이언트의 IP가 바뀌어도 연결을 끊지 않는다.

정리

• HTTP 1.1(TCP): 헤더가 매우 크고, 하나의 연결에 하나의 통신만 가능하기 때문에 성능의 문제 존재
• HTTP 2.0(TCP): HTTP 1.1의 성능을 개선하고자 등장한 버전. 헤더를 줄이고, Multiplexing을 지원하여 하나의 연결로 여러 개의 데이터 교환을 처리할 수 있음. 또한 HTTP 1.1과의 호환성이 좋음.
• HTTP 3.0(UDP): TCP연결의 단점을 해결하고자 UDP 방식으로 동작하는 QUIC을 이용하여 연결. TCP의 단점은 hand-shake로 인한 부하가 가장 큼. UDP의 헤더에 빈 공간이 많기 때문에 이를 이용하여 신뢰성을 보장하는 UDP 형태를 구현하여 사용. UDP방식이기 때문에 연결 부하가 없고, 패킷 헤더에 패킷 번호를 부여하여 패킷 손실 감지에 대한 부하를 줄임. 또한 HTTP 2.0과 마찬가지로 Muliplexing을 지원하고, 연결 시에 connection ID를 이용하여 클라이언트의 IP가 바뀌어도 연결을 끊지 않고 지속시킴.

HTTP 응답 코드

1xx (Information response)

요청을 받았고, 이를 계속 진행함을 의미

2xx (Success response)

요청을 성공적으로 받았고, 인식/수용함을 의미

3xx (Redirection response)

요청 완료를 위해 추가 작업 조치가 필요함을 의미

4xx (Client error response)

요청의 문법이 잘못되었거나 요청을 처리할 수 없음을 의미

5xx (Server error response)

서버가 유효안 요청에 대한 충족을 실패함을 의미

HTTPS

HTTPS는 Hyper Text Transfer Protocol over Secure Socket, HTTP over TLS, HTTP over SSL, HTTPS over Secure의 약자로, W3 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발한 넷스케이프 웹 프로토콜로, 전자 상거래에서 널리 쓰인다. (거래에는 보안이 필수적이기 때문)

소켓 통신에서 일반 텍스트를 이용하는 대신에 SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. 기본 TCP/IP 포트는 443번이다.