2.5 HTTP

HTTP의 모든 것

2.5.1 HTTP/1.0

• HTTP/1.0은 기본적으로 한 연결당 하나의 요청만 처리하는 방식으로 설계되었습니다. 즉, 서버로부터 파일을 가져올 때마다 새로운 TCP 연결을 열어야 하며, 이는 3-way handshake를 반복적으로 수행해야 함을 의미합니다. 이로 인해 RTT(패킷 왕복 시간)가 증가하게 됩니다.
  • RTT는 패킷이 목적지에 도달한 후 다시 출발지로 돌아오기까지 걸리는 시간을 말합니다.
• 이를 해결하기 위해 여러 가지 방법들이 사용되었습니다:
  • 이미지 스플리팅: 많은 이미지를 다운로드 받을 때 과부하를 줄이기 위해 하나의 큰 이미지를 다운로드받고, CSS를 통해 이를 분할하여 표시하는 방법입니다.
  • 코드 압축: 코드의 크기를 최소화하기 위해 개행 문자와 빈칸을 제거하는 방식입니다.
  • 이미지 Base64 인코딩: 이미지 파일을 Base64로 인코딩하여 서버로의 HTTP 요청을 줄이는 방식입니다. 그러나 이 방법은 용량이 약 37% 증가하는 단점이 있습니다.

2.5.2 HTTP/1.1

• HTTP/1.1은 HTTP/1.0에서 발전한 버전으로, 한 번의 TCP 연결을 초기화한 후 Keep-alive 옵션을 통해 여러 파일을 송수신할 수 있도록 개선되었습니다.
  • HTTP/1.0에서도 Keep-alive가 존재했지만 표준화되지 않았고, HTTP/1.1에서부터 표준화되어 기본 옵션으로 설정되었습니다.
  • 이를 통해 매번 TCP 연결을 새로 열지 않아도 되므로 RTT가 줄어듭니다.
• 하지만 여전히 여러 리소스를 처리하는데 문제가 발생할 수 있습니다:
  • 문서 안에 포함된 다수의 리소스(이미지, 동영상, CSS 파일 등)에 대한 요청이 많을 경우, 요청 개수에 비례하여 대기 시간이 길어질 수 있습니다.
  • HOL Blocking (Head of Line Blocking): 네트워크에서 동일 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상입니다.
  • 또한, HTTP/1.1의 헤더는 쿠키 등 많은 메타데이터를 포함하고 있어 무겁고 압축되지 않아 성능 저하를 초래할 수 있습니다.

2.5.3 HTTP/2

• HTTP/2는 구글의 SPDY 프로토콜에서 파생된 버전으로, HTTP/1.x보다 지연 시간을 줄이고 응답 시간을 빠르게 할 수 있는 기술을 도입했습니다.
  • 멀티플렉싱: 여러 개의 스트림을 사용하여 송수신하는 방식으로, 특정 스트림의 패킷이 손실되더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 정상적으로 동작할 수 있습니다. 이를 통해 단일 연결로 병렬로 여러 요청을 받고 응답을 줄 수 있어 HOL Blocking 문제를 해결할 수 있습니다.
  • 헤더 압축: 허프만 코딩 압축 알고리즘을 사용하여 HPACK 압축 형식으로 헤더를 압축합니다.
    • 허프만 코딩: 문자열을 문자 단위로 쪼개 빈도수를 세어 빈도가 높은 정보를 적은 비트 수로 표현하고, 빈도가 낮은 정보는 비트 수를 많이 사용하여 전체 데이터의 비트 양을 줄이는 원리입니다.
  • 서버 푸시: 클라이언트의 요청 없이 서버가 리소스를 먼저 보내는 기술로, HTML 파일에 포함된 CSS나 JS 파일을 서버가 먼저 푸시할 수 있습니다.

2.5.4 HTTPS

• HTTPS는 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣어 신뢰할 수 있는 HTTP 요청을 의미합니다. HTTP/2는 HTTPS 위에서 동작합니다.
  • SSL/TLS: 전송 계층에서 보안을 제공하는 프로토콜로, 클라이언트와 서버가 통신할 때 제 3자가 메시지를 도청하거나 변조하지 못하도록 합니다.
  • SSL/TLS는 보안 세션을 기반으로 데이터를 암호화하며, 보안 세션을 설정할 때 인증 메커니즘, 키 교환 암호화 알고리즘, 해싱 알고리즘이 사용됩니다.
  • 보안 세션은 보안이 시작되고 끝나는 동안 유지되는 세션을 말하며, SSL/TLS는 핸드셰이크를 통해 보안 세션을 생성하고 이를 기반으로 상태 정보를 공유합니다.
  • 인증 메커니즘은 CA (Certificate Authorities)에서 발급한 인증서를 기반으로 이루어집니다. CA는 신뢰성 있는 기업들이 참여할 수 있으며, 대표적으로 아마존, Comodo, GoDaddy, GlobalSign 등이 있습니다.
  • CA 인증서를 발급 받으려면, 사이트 정보와 공개키를 CA에 제출해야 하며, 이후 CA는 공개키를 해시한 값을 사용하여 인증서를 발급합니다.

2.5.5 HTTP/3

• HTTP/3는 TCP 위에서 돌아가는 HTTP/2와는 달리, QUIC이라는 계층 위에서 동작하며, 주로 UDP를 사용합니다. QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 3-way handshake 같은 과정을 거치지 않아 지연 시간이 감소하는 장점이 있습니다.
  • QUIC의 첫 연결은 1-RTT만 소요됩니다.
  • 멀티플렉싱은 HTTP/2의 장점이 그대로 적용되어, 초기 연결 설정 시에도 지연 시간이 감소합니다.
  • QUIC은 순방향 오류 수정 메커니즘(FEC)을 적용하여 전송한 패킷이 손실되었을 때, 수신 측에서 에러를 검출하고 수정하는 방식입니다. 이를 통해 열악한 네트워크 환경에서도 낮은 패킷 손실률을 유지합니다.
  • HTTP/3는 QUIC 위에서 동작하며, 전송 계층 위의 애플리케이션 계층으로 웹 서비스 통신에 사용됩니다.