Http/1.0 ~http/3

 

HTTP/1.0은 Hypertext Transfer Protocol의 첫 번째 버전 중 하나로, 웹 브라우저와 웹 서버 간의 통신을 정의하는 프로토콜이다. 

1996년에 공식적으로 발표되었으며, 오늘날의 웹 통신 기초를 형성함.

 

주요 특징 및 동작 방식

단일 연결, 단일 요청/응답(Single Request-Response per Connection)

HTTP/1.0은 기본적으로 하나의 TCP 연결에서 하나의 요청과 응답을 처리한 후 연결을 닫는다. 즉, 클라이언트가 웹 서버에 요청을 보내면, 서버는 응답을 보내고 나서 연결을 종료한다. 

 

제한점

연결의 비효율성 : 각 요청마다 새로운 연결을 설정하고 해제해야 하므로, 여러 리소스 요청 시 비효율적이다.

지속 연결(Persistent Connection)의 부재: HTTP/1.0은 지속적인 연결을 유지하는 기능을 기본적으로 제공하지 않음.

서버로부터 파일을 가져올 때마다 TCP의 3-웨이 핸드 셰이크를 계속해서 열어야 하기 때문에 RTT가 증가하는 단점이 있음.

(RTT: 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간, 패킷 왕복 시간)

(3-Way Handshake(3-웨이 핸드셰이크): TCP(Transmission Control Protocol)에서 클라이언트와 서버 간의 연결을 설정하는 과정입니다. 이 과정은 양측이 서로를 확인하고, 데이터를 신뢰성 있게 주고받을 준비가 되었음을 보장하는 중요한 절차)

http/1.0 연결, 동작 방식

 

 

HTTP/1.1

HTTP/1.1은 인터넷에서 데이터를 주고받는 데 사용되는 가장 기본적인 프로토콜 중 하나인 HTTP(HyperText Transfer Protocol)의 한 버전이다. HTTP/1.1은 1997년에 표준화되었으며, 그 이전의 버전인 HTTP/1.0에 비해 여러 가지 중요한 개선사항을 포함하고 있다.

 

HTTP/1.1에는 여러가지 개선사항이 있지만 그중에서 중요한 몇가지만 찝어서 설명하도록 하겠다.

1.0에서는 불가능한 지속 연결과 클라이언트가 다수의 요청을 보낼수 있는 파이프라이닝이 가능해졌다

1. Persistent Connections (지속 연결)

   - HTTP/1.0에서는 클라이언트가 서버에 요청을 보낼 때마다 새로운 TCP 연결을 열어야 했다. 반면, HTTP/1.1에서는 기본적으로 연결을 유지(persistent connection)한다. 여러 요청과 응답이 동일한 TCP 연결을 통해 이루어지므로, 연결을 재설정하는 데 드는 오버헤드가 줄어들고 성능이 향상된다.

 

TCP (Transmission Control Protocol): 인터넷에서 데이터를 안정적이고 신뢰성 있게 전송하기 위해 사용되는 핵심 통신 프로토콜이다. TCP는 데이터가 손실되지 않고 올바른 순서로 전달되도록 보장하며, 많은 인터넷 애플리케이션과 서비스의 기본 전송 메커니즘으로 사용된다.

UDP (User Datagram Protocol): 인터넷에서 데이터를 빠르게 전송하기 위해 사용되는 비연결형 프로토콜이다(클라이언트와 서버간 연결 x). TCP와 달리, UDP는 데이터 전송의 신뢰성을 보장하지 않으며, 연결을 설정하지 않고 데이터를 전송할 수 있습니다.

 

 

2. Pipelining (파이프라이닝)
   - HTTP/1.1에서는 클라이언트가 서버로 다수의 요청을 동시에 보내는 것이 가능해졌다. 이를 파이프라이닝이라 하며, 클라이언트는 첫 번째 요청에 대한 응답을 기다리지 않고 연속적으로 여러 요청을 보낼 수 있다. 이는 네트워크 효율성을 높이지만, 모든 서버와 브라우저가 이 기능을 완전히 지원하지는 않았다.

 

HTTP/1.1

해당 기술이 가능한 이유를 조금 자세하게 설명하자면 한 번 TCP 초기화를 한 이후에 Keep-alive라는 옵션으로 여러 개의 파일을 송수신할 수 있게 바뀌었다.

하지만 문서 안에 포함된 다수의 리소스(이미지, 동영상, css 파일, js파일 등)를 처리하려면 요청할 리소스 개수에 비례해서 대기 시간이 길어지는 단점이 있다. --> HOL Blocking 때문

 

(HOL Blocking : 네트워크에서 같은 큐에 있는 패킷이 그 첫 번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한다.)

(Keep-alive: 클라이언트와 서버 간의 연결을 일정 시간 동안 유지하여 여러 요청을 하나의 연결에서 처리할 수 있도록 사용되는 매커니즘.)

 

HTTP/2

HTTP/2는 HTTP/1.1의 한계를 극복하고 웹 성능을 개선하기 위해 개발된 차세대 웹 전송 프로토콜이다. HTTP/2는 2015년에 표준화되었으며, 구글의 SPDY 프로토콜을 바탕으로 개발되었다. HTTP/2는 웹 페이지 로드 속도를 크게 향상시키고, 네트워크 효율성을 높이는 다양한 기능을 제공한다.

 

Binary Protocol (이진 프로토콜)

• HTTP/2는 HTTP/1.1과 달리 텍스트가 아닌 이진 형식(0과1로 이루어진 데이터)으로 데이터를 전송합니다. 이진 프로토콜은 데이터 파싱을 더 빠르고 효율적으로 수행할 수 있게 해주며, 전송 중 오류 발생 가능성을 줄여줍니다.

Multiplexing (멀티플렉싱)

• HTTP/2는 단일 TCP 연결에서 여러 요청과 응답을 동시에 처리할 수 있는 멀티플렉싱 기능을 지원합니다. 이는 HTTP/1.1의 파이프라이닝을 대체하며, 한 요청이 지연되더라도 다른 요청에 영향을 주지 않고 병렬로 처리할 수 있게 해줍니다. 결과적으로 웹 페이지 로드 속도가 크게 개선됩니다.

(스트림 : 시간이 지남에 따라 사용할 수 있게 되는 일련의 데이터 요소를 가리키는 데이터 흐름)

multiconnection과 mulitplexing의 간단모식도

 

이렇게 HTTP/1.1에서는 기본적으로 각 요청마다 별도의 TCP 연결을 생성하거나, 같은 연결을 재사용하는 방법(persistent connection)을 사용했다. 그러나 브라우저는 성능을 높이기 위해 여러 개의 연결을 동시에 열어 리소스를 병렬로 가져온 덕분에 페이지 로딩 속도가 개선되지만, 여러 연결을 여는 것은 네트워크 오버헤드를 증가시키고 서버의 리소스를 더 많이 소비하게 되는 단점이 생겼다 하지만 HTTP/2.0에서는 멀티플렉싱을 통해 하나의 연결에서 여러 요청과 응답이 동시에 이루어질 수 있다. 예를 들어, HTML, CSS, 이미지 등을 동시에 전송할 수 있으며, 한 리소스의 지연이 다른 리소스에 영향을 미치지 않는다. 이 방식은 네트워크 효율성을 크게 높이고, 서버와 클라이언트 모두의 리소스를 절약한다.

 

Header Compression (헤더 압축)

HTTP/1.x에는 크기가 큰 헤더가 문제가 있었다. 그러기에 HTTP/2는 헤더 정보를 효율적으로 압축하기 위해 HPACK(허프만 코딩 알고리즘 사용)이라는 압축 방식을 사용하였다. HTTP/1.1에서는 각 요청마다 반복되는 헤더 정보가 비효율적이었는데, HTTP/2에서는 이 압축 기능을 통해 전송되는 데이터 양을 줄이고 성능을 향상시킬 수 있다.

 

-> HTTP 헤더란?

HTTP 헤더는 클라이언트(예: 웹 브라우저)와 서버 간에 주고받는 메타데이터로, 요청이나 응답에 대한 추가 정보를 담고 있다. 

정말 간단히 예를 들면

 

• 웹에서 데이터를 주고받을 때, 헤더는 편지 봉투에 적혀 있는 작은 메모와 비슷하다. 이 메모에는 편지를 어떻게 처리해야 하는지에 대한 중요한 정보가 담겨 있다.
• 브라우저가 웹 서버에 "이 페이지를 주세요"라고 요청할 때, 이 요청에 어떤 추가 정보가 필요한지를 헤더로 알려줍니다. 서버도 마찬가지로, 응답할 때 필요한 추가 정보를 헤더로 보낸다.

 

Server Push (서버 푸시)

HTTP/1.1에는 서버 푸시 기능이 기본적으로 없었다. 따라서 클라이언트(예: 웹 브라우저)가 서버에 요청을 보낼 때마다, 서버는 클라이언트가 요청한 자원만 응답으로 보내고, 다른 자원은 클라이언트가 별도로 요청해야만 했다. 하지만  HTTP/2는 서버가 클라이언트가 요청하지 않은 리소스를 미리 클라이언트로 전송할 수 있는 서버 푸시 기능을 제공한다. 예를 들어, HTML 문서를 요청할 때 서버가 해당 페이지에 필요한 CSS 파일이나 이미지 파일을 미리 클라이언트에 전송함으로써 페이지 로딩 시간을 줄일 수 있습니다.

서버 푸쉬 모식도

 

HTTPS

HTTPS는 HTTP Secure의 약자로, 웹에서 데이터를 안전하게 전송하기 위한 HTTP의 확장 버전이다. HTTPS는 HTTP와 TLS (Transport Layer Security) 또는 SSL (Secure Sockets Layer)을 결합하여 데이터를 암호화하고 보안을 강화한다. 

 

HTTPS의 작동원리는 3단계로 이루어진다.

1. 암호화

• 전송 암호화: HTTPS는 클라이언트와 서버 간의 데이터 전송을 암호화한다. 이를 통해 데이터가 인터넷을 통해 이동하는 동안 제3자가 내용을 읽거나 변조할 수 없게 만든다.
• SSL/TLS: HTTPS는 SSL(구버전) 또는 TLS(최신 버전) 프로토콜을 사용하여 암호화를 구현합니다. 이 프로토콜들은 암호화 알고리즘을 사용해 데이터를 보호하고, 안전한 통신을 보장한다.

2. 인증

• 서버 인증: HTTPS는 웹 서버의 신뢰성을 검증하는 인증서를 사용한다. 인증서는 공인된 인증 기관(Certificate Authority, CA)에서 발급하며, 서버가 실제로 그 도메인에 대한 권한이 있음을 보증한다.
• 클라이언트 인증: 경우에 따라, 클라이언트도 인증서를 사용하여 서버에게 자신의 신원을 증명할 수 있다. 이 과정은 두 단계의 인증을 요구하는 보안이 중요한 시스템에서 주로 사용된다.

3. HTTPS 연결 과정 (핸드쉐이크)

• 서버 인증서 전송: 클라이언트가 HTTPS 웹사이트에 접속하면, 서버는 SSL/TLS 인증서를 클라이언트에게 전송한다.
• 인증서 검증: 클라이언트는 인증서가 신뢰할 수 있는 인증 기관에서 발급된 것인지 확인한다. 인증서가 유효하면, 클라이언트는 서버와 안전한 연결을 설정한다.
• 세션 키 생성: 클라이언트와 서버는 세션 키를 생성하고, 이 키를 사용해 서로 암호화된 데이터를 주고받는다.

HTTPS 인증서에 SSL, TLS 인증서에 대해 잠깐 짚고 넘어가겠다.

 

SSL(Secure Sockets Layer)

SSL은 인터넷에서 데이터를 암호화하여 보안적인 통신을 제공하기 위해 넷스케이프(Netscape)에서 개발한 프로토콜이다. SSL의 목적은 데이터가 네트워크를 통해 전송되는 동안 기밀성과 무결성을 유지하는 것이다. (지금은 보안 취약점이 많기에 https는 SSL을 사용하지 않고 TLS를 사용한다.)

 

TLS(Transport Layer Security)

TLS는 SSL의 후속 프로토콜로, 더 강력한 보안성을 제공하기 위해 개발되었다. TLS는 SSL의 기능을 기반으로 하면서 보안과 성능을 개선하였다. 이 기술이 어떻게 작동하고 왜 중요한지 쉽게 정리해 보겠다.

1. 데이터 암호화

• 기밀성 보호: TLS는 클라이언트와 서버 간의 데이터 전송을 암호화한다. 암호화된 데이터는 제3자가 읽거나 이해할 수 없으므로, 중간에서 데이터를 엿보는 공격자(스니핑)로부터 보호가 된다. 즉 해커가 중간에서 훔쳐가도 내용을 이해할 수 없게 만든다.
• 전송 도중 데이터 보호: 웹 페이지를 로드하거나 온라인 거래를 수행할 때, TLS는 데이터가 인터넷을 통해 전송되는 동안 안전하게 보호한다.

2. 서버 인증

• 신뢰할 수 있는 서버 확인: TLS는 서버 인증서를 사용하여 웹 사이트가 실제로 주장하는 대로 그 웹 사이트인지 확인할 수 있도록 한다. 인증서는 공인된 인증 기관(Certificate Authority, CA)에서 발급되며, 이를 통해 사용자는 서버의 신뢰성을 검증할 수 있다.
• 피싱 방지: 사용자가 접속하는 웹사이트가 실제로 그 웹사이트인지 확인할 수 있어, 피싱 공격과 같은 사기 웹사이트로부터 보호된다.

3. 데이터 무결성

• 변조 방지: TLS는 데이터 전송 중에 내용이 변경되거나 변조되는 것을 방지한다. 이를 통해 데이터가 수신자에게 도착하기 전까지 원본 그대로 유지되도록 보장한다.
• 위조 방지: 메시지 인증 코드를 사용하여 데이터가 전송 중에 변경되지 않았음을 확인할 수 있다.

4. 개인정보 보호

• 안전한 개인정보 전송: 로그인 정보, 신용카드 번호, 개인 정보 등 민감한 데이터를 안전하게 전송할 수 있다. TLS 암호화 덕분에 이 정보가 도중에 탈취되지 않는다.(SHA-256, SHA-384 해싱 알고리즘을 사용함)
• 사용자 신뢰 구축: 사용자는 HTTPS를 통해 데이터를 안전하게 전송할 수 있음을 알고 있어, 웹사이트를 더 신뢰할 수 있다.

5. 검색 엔진 최적화 (SEO) 향상

• 검색 순위 상승: 구글과 같은 검색 엔진은 HTTPS를 사용하는 웹사이트를 우선적으로 고려한다. HTTPS는 검색 엔진에서 웹사이트의 순위를 높이는 데 유리하게 작용한다.
• 신뢰도 증진: 사용자들에게 안전한 사이트로 인식되기 때문에 방문자 수가 증가할 수 있다.

6. 웹 사이트의 전반적인 보안 강화

• 보안성 강화: 최신 TLS 버전은 이전 버전의 보안 취약점을 해결하고, 강력한 암호화 알고리즘을 지원하여 더 높은 수준의 보안을 제공한다.
• 미래의 보안 표준: 최신 웹 보안 표준을 채택함으로써 웹사이트가 최신 보안 요구 사항을 충족하게 된다.

HTTPS 구축 방법

 

1. 직접 CA에서 도메인에 대한 SSL/TLS 인증서를 구매한 다음 이 인증서를 웹 서버에 설치하여 HTTPS를 활성화함.

• 장점 : 직접 제어가 가능하고, 원하는 설정을 자유롭게 조정이 가능하다.
• 단점 : 인증서 관리가 복잡하고, 서버 관리자가 HTTPS 설정 및 유지보수를 모두 직접 해야 한다.

2. 서버 앞단의 HTTPS를 제공하는 로드밸런서를 둠 

로드 밸런서(Load Balancer): 서버에 들어오는 트래픽을 여러 서버로 분산시켜주는 장치나 소프트웨어

• 장점: 중앙에서 HTTPS 트래픽을 관리할 수 있어 서버의 부담이 줄어들고, 복잡한 인증서 관리를 로드 밸런서에서 처리가 가능하다.
• 단점: 로드 밸런서 장비에 대한 추가 비용이 발생할 수 있고, 관리자가 로드 밸런서 설정을 잘 이해하고 있어야 한다.

3. 서버 앞단의 HTTPS를 제공하는 CDN을 둬서 구축한다.

CDN(Content Delivery Neywork): 전 세계에 분산된 서버 네트워크를 통해 웹 콘텐츠를 더 빠르고 안전하게 제공하는 기술

 

• 장점: CDN을 사용하면 전 세계 어디서나 빠르고 안전한 HTTPS 연결을 제공할 수 있다. CDN 제공업체가 인증서 관리와 보안을 책임지므로 관리가 쉽다.
• 단점: CDN 사용료가 발생할 수 있으며, CDN 제공업체에 일부 제어권을 위임하게 된다.

(CDN기업 종류로는 Cloudflare, Akamai, Amazon CloudFront, Fastly가 있다)

 

HTTP/3

QUIC 프로토콜 사용:

• HTTP/3는 TCP 대신 QUIC을 사용한다. QUIC은 Google에서 개발한 전송 프로토콜로, TCP와 UDP의 장점을 결합한 형태이다. QUIC은 UDP 기반이지만, TCP와 비슷한 연결 안정성(패킷 순서 보장, 오류 수정 등)을 제공하며, TCP의 문제점(연결 설정 속도, 헤드 오브 라인 블로킹 등)을 해결하는 것을 목표로 한다.

빠른 연결 설정:

• QUIC은 TLS(Transport Layer Security) 암호화를 포함하는 단일 연결 설정 과정을 통해, 기존의 TCP에서 필요한 다중 핸드셰이크(연결 설정) 단계를 크게 줄였다. 그 결과, 연결 설정 속도가 빨라져 웹 페이지 로딩 시간이 단축된다.
• 특히, 첫 연결 이후 재연결 시에는 핸드셰이크 과정이 생략될 수 있어, 더 빠른 연결이 가능하다.

QUIC

 

QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-웨이 핸드셰이크 과정을 거치지 않아도 된다.

오른쪽 그림처런 QUIC은 첫 연결 설정에 1-RTT만 소요된다. 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신 시작이 가능하다.

 

헤드 오브 라인 블로킹(Head-of-Line Blocking) 문제 해결:

• TCP 기반의 HTTP/2에서는 하나의 패킷이 손실되면 그 패킷이 재전송되어야만 이후의 패킷들이 처리될 수 있다. 이를 "헤드 오브 라인 블로킹"이라고 하는데, 이 문제는 전체적인 전송 속도를 저하시킬 수 있다.
• 반면, HTTP/3의 QUIC 프로토콜은 패킷 손실이 발생해도 다른 스트림의 패킷 전송에 영향을 주지 않기 때문에, 전송 효율성이 더 높다.

향상된 보안:

• HTTP/3는 TLS 1.3을 기본으로 사용하여 모든 연결에서 강력한 암호화를 제공한다. 이는 HTTP/2에서의 보안성을 더 발전시킨 것이며, 보안 위험을 줄여준다.
• QUIC 자체가 암호화를 기본으로 하기 때문에, QUIC 연결은 항상 암호화된 상태로 이루어진다.

모바일 및 무선 네트워크에 최적화:

• HTTP/3는 연결의 지속성을 유지하는 데 뛰어난 성능을 발휘한다. 예를 들어, 사용자가 모바일 네트워크에서 이동할 때 IP 주소가 변경되더라도, QUIC은 연결을 끊지 않고 계속 유지할 수 있다. 이는 무선 네트워크에서 매우 유리하다.

• HTTP/3의 장점
  • 더 빠른 웹 브라우징 경험: 핸드셰이크 과정을 단축하고, 헤드 오브 라인 블로킹 문제를 해결하여, 사용자에게 더 빠른 웹 페이지 로딩 속도를 제공한다.
  • 높은 안정성: 네트워크 변동이 있는 상황에서도 안정적으로 연결을 유지한다.
  • 강화된 보안: QUIC의 기본 암호화 덕분에, 데이터 전송 중 보안이 더 강력하게 보호된다.