HTTP 프로토콜의 진화: 1.0에서 2.0으로

HTTP(HyperText Transfer Protocol)는 인터넷에서 가장 널리 사용되는 네트워크 프로토콜이며, 모든 WWW 파일은 이 표준을 따라야 합니다. 원래 설계 목표는 HTML 페이지를 게시하고 수신하는 방법을 제공하는 것이었으며, 이는 WWW 서버에서 로컬 브라우저로 하이퍼텍스트를 전송하는 데 사용되며 기본적으로 포트 80을 사용합니다. HTTP 클라이언트가 요청을 시작하면 서버의 지정된 포트(기본적으로 포트 80)에 대한 TCP 연결을 설정합니다.

HTTP 프로토콜은 TCP 프로토콜과 충돌하지 않는다는 점에 주목할 가치가 있습니다. HTTP는 7계층 프로토콜의 애플리케이션 계층에 있는 반면 TCP는 전송 계층의 논리적 문제를 해결하는 역할을 합니다. HTTP는 웹 페이지를 열 때 많은 양의 데이터를 전송해야 하므로 UDP 대신 TCP를 선택했으며, TCP 프로토콜은 데이터의 질서 있는 구성 및 오류 수정을 달성하기 위해 전송 제어를 제공할 수 있습니다. 또한 HTTP 프로토콜의 병목 현상 및 최적화 기술도 TCP 프로토콜의 특성을 기반으로 합니다. 예를 들어 TCP 연결을 설정할 때의 3방향 핸드셰이크는 1.5 RTT(왕복 시간)의 지연을 유발합니다. 각 요청의 핸드셰이크 지연을 피하기 위해 애플리케이션 계층은 다양한 전략을 가진 HTTP 영구 연결 체계를 채택합니다. 또한 TCP는 연결 초기 단계에서 느린 시작 특성을 가지므로 일반적으로 연결 재사용 성능이 새 연결보다 좋습니다.

HTTP 연결은 "요청-응답" 모드를 채택합니다. 요청을 할 때 먼저 연결을 설정해야 할 뿐만 아니라 클라이언트가 서버에 요청을 보낸 후에만 서버가 데이터로 응답할 수 있습니다. 인터넷의 발전과 함께 HTTP 프로토콜도 지속적으로 업그레이드되어 HTTP/1.0, HTTP/1.1 및 HTTP/2.0과 같은 버전이 잇따라 등장했으며 각 버전은 성능과 기능면에서 최적화되고 개선되었습니다.

HTTP 프로토콜 버전 비교 테이블

HTTP/1.0

HTTP/1.0은 통신에서 버전 번호를 지정하는 HTTP 프로토콜의 첫 번째 버전으로, 프록시 서버와 같은 시나리오에서 여전히 널리 사용됩니다. 이 버전은 브라우저와 서버가 단기 연결만 유지하도록 규정합니다. 브라우저는 각 요청에 대해 서버와의 TCP 연결을 설정해야 하며 서버는 요청 처리를 완료한 후 즉시 TCP 연결을 끊습니다. 각 클라이언트를 추적하거나 과거 요청을 기록하지 않습니다.

이 메커니즘은 몇 가지 성능 결함으로 이어집니다. 많은 이미지를 포함하는 웹 페이지를 예로 들어 보겠습니다. 웹 페이지 파일 자체에는 이미지 데이터가 포함되어 있지 않지만 이미지의 URL 주소만 지정합니다. 브라우저가 이 웹 페이지에 액세스하면 먼저 웹 페이지 파일에 대한 요청을 보냅니다. HTML 콘텐츠를 구문 분석할 때 이미지 태그를 찾으면 src 속성에 지정된 URL에 따라 이미지 데이터를 다운로드하기 위해 서버에 다시 요청을 보냅니다. 즉, 이미지가 많은 웹 페이지에 액세스하려면 여러 번의 요청과 응답이 필요하며 매번 단일 문서 또는 이미지를 전송하기 위해 별도의 연결을 설정해야 합니다. 이미지 파일이 작더라도 연결을 자주 설정하고 닫는 프로세스는 시간이 많이 걸리고 클라이언트와 서버 모두의 성능에 심각한 영향을 미칩니다. 마찬가지로 웹 페이지에 JavaScript 파일 및 CSS 파일과 같은 콘텐츠가 포함된 경우 유사한 문제가 발생합니다.

동시에 대역폭과 대기 시간도 네트워크 요청에 영향을 미치는 중요한 요소입니다. 현재 네트워크 인프라에서 대역폭이 크게 향상됨에 따라 응답 속도의 대기 시간 문제가 더욱 두드러졌습니다. HTTP/1.0의 가장 비판받는 두 가지 문제는 연결을 재사용할 수 없다는 점과 HOL 차단입니다.

이러한 두 가지 문제를 이해하려면 클라이언트가 도메인 이름에 따라 서버에 연결을 설정한다는 점을 명확히 해야 합니다. 일반적으로 PC 브라우저는 단일 도메인 이름의 서버에 동시에 6-8개의 연결을 설정하는 반면 모바일 브라우저는 4-6개로 제어합니다. 연결 수가 많을수록 좋은 것은 아니며, 너무 많으면 리소스 오버헤드와 전체 대기 시간이 증가합니다. 연결을 재사용할 수 없으면 각 요청에 대해 3방향 핸드셰이크와 느린 시작이 발생합니다. 3방향 핸드셰이크는 대기 시간이 높은 시나리오에서 상당한 영향을 미치며, 느린 시작은 큰 파일에 대한 요청에 더 큰 영향을 미칩니다. HOL 차단은 대역폭을 완전히 활용할 수 없게 만들고 이후의 정상적인 요청이 차단됩니다.

HOL 차단은 정상적인 요청이 비정상적인 요청의 영향을 받게 하며, 이 손실은 네트워크 환경의 영향을 받아 무작위적이고 모니터링하기 어렵습니다. HOL 차단으로 인한 대기 시간을 해결하기 위해 프로토콜 설계자는 파이프라이닝 메커니즘을 도입했지만 이 메커니즘은 HTTP/1.1에만 적용되며 엄격한 사용 조건이 있으며 많은 브라우저 공급업체가 이를 지원하지 않습니다.

HTTP/1.0에서는 요청 헤더가 비교적 간단합니다. 예를 들어 웹 페이지 리소스를 가져올 때:

GET /index.html HTTP/1.0
User - Agent: Mozilla/5.0

HTTP/1.1

HTTP/1.0의 단점을 극복하기 위해 HTTP/1.1은 영구 연결을 지원합니다(기본 모드는 파이프라이닝이 있는 영구 연결). 여러 HTTP 요청과 응답을 단일 TCP 연결을 통해 전송할 수 있으므로 연결 설정 및 종료의 소비와 대기 시간이 줄어듭니다. 많은 이미지를 포함하는 웹 페이지를 예로 들어 보겠습니다. 여러 요청과 응답을 하나의 연결로 전송할 수 있지만 각 개별 웹 페이지 파일에 대한 요청과 응답은 여전히 자체 연결을 사용해야 합니다. 또한 HTTP/1.1을 사용하면 클라이언트가 이전 요청의 결과가 반환될 때까지 기다리지 않고 다음 요청을 보낼 수 있으며 서버는 클라이언트가 각 요청의 응답 콘텐츠를 구별할 수 있도록 요청을 수신한 순서대로 응답 결과를 다시 보내야 하므로 전체 다운로드 프로세스에 필요한 시간이 크게 줄어듭니다.

HTTP/1.1에서는 connection 헤더가 요청 및 응답 헤더에 나타날 수 있으며 이는 클라이언트와 서버가 영구 연결을 처리하는 방법을 나타내는 데 사용됩니다. 기본적으로 클라이언트와 서버는 상대방이 영구 연결을 지원한다고 가정합니다. 클라이언트가 HTTP/1.1 프로토콜을 사용하지만 영구 연결을 사용하지 않으려면 헤더에서 connection 값을 close로 지정해야 합니다. 서버가 영구 연결을 지원하지 않으려면 응답에서 connection 값을 close로 명확하게 설정해야 합니다. close 값이 요청 또는 응답의 헤더에 포함되어 있는지 여부에 관계없이 이는 현재 TCP 연결이 요청 처리가 완료된 후 끊어지고 클라이언트의 후속 새 요청은 새 TCP 연결을 만들어야 함을 나타냅니다. 예를 들어:

# 요청 헤더
GET /index.html HTTP/1.1
User - Agent: Mozilla/5.0
Connection: close

# 응답 헤더
HTTP/1.1 200 OK
Content - Type: text/html
Connection: close

또한 HTTP/1.1은 더 많은 요청 헤더와 응답 헤더를 추가하여 HTTP/1.0의 기능을 개선하고 확장했습니다.

• Host 헤더 지원: HTTP/1.0은 Host 요청 헤더 필드를 지원하지 않으며 브라우저는 호스트 헤더 이름을 통해 액세스할 서버의 특정 WEB 사이트를 지정할 수 없어 동일한 IP 주소와 포트 번호에서 여러 가상 WEB 사이트의 구성을 제한합니다. HTTP/1.1이 Host 요청 헤더 필드를 추가한 후 브라우저는 호스트 헤더 이름을 통해 액세스할 사이트를 명확하게 지정하여 동일한 IP 주소와 포트 번호에서 다른 호스트 이름을 가진 여러 가상 WEB 사이트를 만들 수 있습니다. 예를 들어:

GET /index.html HTTP/1.1
Host: example.com

• 영구 연결 제어: HTTP/1.1의 영구 연결은 새로운 요청 헤더를 통해 구현됩니다. Connection 요청 헤더의 값이 Keep - Alive이면 클라이언트는 이 요청의 결과를 반환한 후 서버에 연결을 유지하도록 알립니다. 값이 close이면 서버에 결과를 반환한 후 연결을 닫도록 알립니다.
• 캐싱 및 중단된 다운로드 재개: HTTP/1.0은 파일의 중단된 다운로드 재개를 지원하지 않으며 각 파일 전송은 0바이트 위치에서 시작됩니다. HTTP/1.1은 새로운 RANGE:bytes 필드를 추가하고 RANGE:bytes=XXXX는 서버에 파일의 XXXX바이트 위치에서 전송을 시작하도록 요청하여 중단된 다운로드를 재개할 수 있도록 합니다. 예를 들어:

GET /largefile.zip HTTP/1.1
Range: bytes=1000 -

또한 HTTP/1.1은 캐시 처리, 대역폭 최적화, 오류 알림 관리 등 측면에서 개선되었습니다.

• 캐시 처리: HTTP/1.0은 주로 If - Modified - Since 및 Expires를 캐시 판단 기준으로 사용하고 HTTP/1.1은 Entity tag, If - Unmodified - Since, If - Match, If - None - Match 등과 같은 더 많은 캐시 제어 전략을 도입했습니다.
• 대역폭 최적화: HTTP/1.0에는 대역폭 낭비 현상이 있으며 중단된 다운로드 재개를 지원하지 않습니다. HTTP/1.1은 요청 헤더에 range 헤더 필드를 도입하여 리소스의 일부만 요청할 수 있도록 하고 반환 코드는 206(Partial Content)이며 대역폭 활용률을 향상시킵니다.
• 오류 알림: HTTP/1.1은 요청된 리소스가 현재 상태와 충돌함을 나타내는 409(Conflict), 서버의 리소스가 영구적으로 삭제되었음을 나타내는 410(Gone)과 같은 24개의 새로운 오류 상태 응답 코드를 추가합니다.

SPDY: HTTP/2.0의 선구자

SPDY는 표준 프로토콜이 아닙니다. 개발팀은 이를 인터넷 초안으로 승격하려고 했지만 결국 자체적으로 공식 표준이 되지 못했습니다. 그러나 SPDY 개발팀의 구성원은 HTTP/2.0을 공식화하는 전체 프로세스에 참여했습니다. HTTP/2.0의 주요 기능은 주로 SPDY 기술에서 비롯되었으며 SPDY의 성과가 채택되어 HTTP/2.0으로 진화했다고 간주할 수 있습니다. 2015년 9월 Google은 SPDY 지원을 제거하고 대신 Chrome 51에서 효력이 발생하는 HTTP/2.0을 채택한다고 발표했습니다.

SPDY는 HTTP를 대체하지 않지만 HTTP 요청 및 응답이 네트워크를 통해 전송되는 방식을 수정합니다. SPDY 전송 계층을 추가하기만 하면 기존 서버 측 애플리케이션은 어떤 수정도 할 필요가 없습니다. SPDY를 사용하여 전송할 때 HTTP 요청은 처리, 표시, 단순화 및 압축됩니다.

SPDY에는 다음과 같은 새로운 기능이 있습니다.

• 멀티플렉싱: 여러 요청 스트림이 단일 TCP 연결을 공유하여 HOL 차단 문제를 해결하고 대기 시간을 줄이고 대역폭 활용률을 향상시킵니다.
• 요청 우선 순위: 각 요청에 대한 우선 순위를 설정하여 중요한 요청이 먼저 응답되도록 할 수 있습니다. 예를 들어 브라우저가 홈페이지를 로드할 때 HTML 콘텐츠를 먼저 표시한 다음 정적 리소스 및 스크립트 파일을 로드하는 데 우선 순위를 둘 수 있습니다.
• 헤더 압축: HTTP/1.x의 헤더에는 종종 중복되고 불필요한 정보가 포함되어 있습니다. SPDY는 적절한 압축 알고리즘을 선택하여 패킷 크기와 수를 줄입니다.
• HTTPS 기반 암호화 프로토콜 전송: 전송된 데이터의 안정성을 향상시킵니다.
• 서버 푸시: SPDY를 사용하는 웹 페이지의 경우 클라이언트가 sytle.css를 요청하면 서버는 sytle.js를 클라이언트에 푸시합니다. 클라이언트가 나중에 sytle.js를 가져오면 다른 요청을 하지 않고 캐시에서 직접 검색할 수 있습니다.

HTTP/2.0

HTTP/2.0과 SPDY의 차이점

• 전송 프로토콜: HTTP/2.0은 일반 텍스트 HTTP 전송을 지원하는 반면 SPDY는 HTTPS 사용을 강제합니다. HTTP/2.0은 비 HTTPS를 지원하지만 Chrome 및 Firefox와 같은 주류 브라우저는 TLS를 기반으로 배포된 HTTP/2.0 프로토콜만 지원합니다. 따라서 HTTP/2.0으로 업그레이드하려면 일반적으로 HTTPS를 먼저 업그레이드해야 합니다.
• 메시지 헤더 압축 알고리즘: HTTP/2.0은 HPACK 알고리즘을 사용하여 메시지 헤더를 압축하는 반면 SPDY는 DEFLATE 알고리즘을 사용합니다.

HTTP/2.0의 새로운 기능(HTTP/1.x와 비교)

• 멀티플렉싱: HTTP/2.0을 사용하면 단일 HTTP/2 연결을 통해 여러 요청-응답 메시지를 동시에 시작할 수 있습니다. HTTP/1.1 프로토콜에서 브라우저 클라이언트는 동일한 도메인 이름의 요청 수에 제한이 있으며 제한을 초과하는 요청은 차단됩니다. 이는 일부 웹 사이트가 여러 정적 리소스 CDN 도메인 이름을 사용하는 이유 중 하나입니다. HTTP/2.0의 멀티플렉싱을 사용하면 HTTP 프로토콜 통신의 기본 단위를 프레임으로 줄여 단일 연결에서 메시지를 병렬로 교환할 수 있으며 이러한 프레임은 논리적 스트림의 메시지에 해당하여 여러 TCP 연결에 의존하지 않고 여러 스트림의 병렬 처리를 달성합니다. 예를 들어 여러 리소스를 동시에 요청할 때:

:method: GET
:scheme: https
:authority: example.com
:path: /image1.jpg

:method: GET
:scheme: https
:authority: example.com
:path: /image2.jpg

HTTP/1.1의 영구 연결 재사용과 비교하여 HTTP/1.*에서는 각 요청-응답에 대해 연결이 설정되고 사용 후 닫히며 각 요청은 연결을 설정해야 합니다. HTTP/1.1의 파이프라이닝 모드에서는 몇 가지 요청이 직렬 단일 스레드 처리를 위해 대기열에 추가되고 후속 요청은 이전 요청이 반환될 때까지 기다려야 실행할 수 있습니다. 요청이 시간 초과되면 후속 요청이 차단됩니다. 반면 HTTP/2.0에서는 하나의 연결에서 여러 요청을 병렬로 실행할 수 있으며 심각한 대기 시간이 있는 요청은 다른 연결의 정상적인 실행에 영향을 미치지 않습니다.

HTTP/2.0의 멀티플렉싱은 TCP 연결을 더욱 효과적으로 사용하고 HTTP 성능을 향상시킵니다. TCP 연결은 초기 단계에서 연결 속도를 제한하고 데이터가 성공적으로 전송됨에 따라 속도를 점진적으로 높이는 "자체 조정"을 수행합니다. 즉, TCP 느린 시작입니다. HTTP/2.0을 사용하면 모든 데이터 스트림이 동일한 연결을 공유할 수 있으므로 HTTP 연결의 비효율성을 줄이고 혼잡 및 패킷 손실 복구 시간을 줄이고 연결 처리량을 늘릴 수 있습니다.

• 요청 우선 순위: 멀티플렉싱으로 인해 중요한 요청이 차단될 수 있습니다. HTTP/2.0에서는 각 요청에 대한 우선 순위를 설정할 수 있으며 31비트 우선 순위 값을 사용하며 0은 가장 높은 우선 순위를 나타내고 2(31) - 1은 가장 낮은 우선 순위를 나타냅니다. 서버는 우선 순위에 따라 리소스 할당을 제어하고 우선 순위가 높은 요청 프레임을 클라이언트에 우선적으로 처리하고 반환할 수 있습니다.
• 이진 프레이밍: HTTP/1.1은 텍스트 구문 분석을 기반으로 하며 텍스트 형식의 다양성으로 인해 구문 분석 중에 여러 시나리오를 고려해야 하므로 견고성이 떨어집니다. HTTP/2.0은 이진 형식 구문 분석을 채택하고 애플리케이션 계층(HTTP/2.0)과 전송 계층(TCP 또는 UDP) 사이에 이진 프레이밍 계층을 추가합니다. 이 계층은 전송된 모든 정보를 더 작은 메시지 및 프레임(frame)으로 나누고 이진 형식으로 인코딩합니다. HTTP/1.x의 헤더 정보는 HEADER 프레임으로 캡슐화되고 RequestBody는 DATA 프레임으로 캡슐화됩니다. HTTP/2.0의 모든 통신은 하나의 연결에서 완료되며 이 연결은 임의의 수의 양방향 데이터 스트림을 전송할 수 있습니다.
• 헤더 압축: HTTP/1.1은 HTTP 헤더 압축을 지원하지 않으며 SPDY와 HTTP/2.0이 이 목적으로 등장했습니다. SPDY는 DEFLATE 알고리즘을 사용하고 HTTP/2.0은 HPACK 알고리즘을 사용합니다. HTTP/2.0은 사전을 유지하고 HTTP 헤더를 점진적으로 업데이트하여 헤더 전송으로 인해 발생하는 트래픽을 줄입니다. 양쪽 통신 당사자는 중복 헤더의 전송을 피하고 전송 크기를 줄이기 위해 각각 헤더 필드 테이블을 캐시합니다.
• 서버 푸시: HTTP/2.0에서 서버는 클라이언트의 단일 요청에 여러 응답을 보낼 수 있습니다. 서버 푸시는 HTTP/1.x 시대에 임베디드 리소스를 사용하는 최적화 방법을 더 이상 필요 없게 만듭니다. 홈페이지에서 요청이 시작되면 서버는 홈페이지 콘텐츠, 로고, 스타일 시트 및 클라이언트가 필요한 기타 리소스로 응답할 수 있으며 이러한 리소스를 캐시하여 동일한 출처의 다른 페이지 간에 캐시된 리소스의 공유를 실현할 수 있습니다.

참조 링크

• MDN Web Docs: HTTP
• IETF HTTP/2 Specification

Leapcell: 최고의 서버리스 웹 호스팅

마지막으로 서비스를 배포하는 데 가장 적합한 플랫폼인 **Leapcell**을 추천하고 싶습니다.

🚀 좋아하는 언어로 빌드

JavaScript, Python, Go 또는 Rust로 쉽게 개발할 수 있습니다.

🌍 무료로 무제한 프로젝트 배포

사용한 만큼만 지불하세요. 요청도 없고 요금도 없습니다.

⚡ 사용한 만큼 지불, 숨겨진 비용 없음

유휴 요금 없이 원활한 확장성만 제공합니다.

📖 문서 탐색

🔹 Twitter에서 팔로우하세요: @LeapcellHQ