[Network] HTTP의 병목현상과 WebSocket

HTTP를 기본으로 하는 프로토콜

 

HTTP의 병목현상을 해소하는 SPDY(스피디) - 사실상 사장된 기술

 

SPDY의 발전과 HTTP/2로의 전환:

• SPDY는 2010년 구글이 발표한 이후 웹 성능 향상에 큰 영향을 미쳤음
• 그러나 SPDY 자체는 더 이상 활발히 사용되지 않음
• SPDY의 핵심 개념과 기술은 HTTP/2의 기반이 됨

HTTP/2의 도입:

• 2015년 HTTP/2가 공식적으로 표준화 됨
• HTTP/2는 SPDY의 많은 특징을 계승하여 개발 됨
• 대부분의 주요 웹 브라우저와 서버는 HTTP/2를 지원

 

1. HTTP의 병목현상

병목현상: 시스템의 전체 처리 능력이 가장 성능이 낮은 부분에 의해 제한되는 현상

 

연결 제한 (Connection Limit):

• HTTP/1.1은 일반적으로 브라우저당 도메인별로 동시 연결 수를 6-8개로 제한
• 많은 리소스가 필요한 웹페이지의 경우, 이 제한으로 인해 로딩 시간이 길어질 수 있음

Head-of-Line Blocking:

• HTTP/1.1에서는 하나의 연결에서 요청과 응답이 순차적으로 처리
• 큰 요청이 앞에 있으면, 그 뒤의 작은 요청들이 지연될 수 있음

반복적인 헤더 정보:

• 각 HTTP 요청마다 중복된 헤더 정보를 전송해야 함
• 이는 불필요한 대역폭 사용을 초래하고, 특히 모바일 환경에서 성능 저하의 원인이 됨

단방향 통신:

• 클라이언트의 요청이 있어야만 서버가 응답할 수 있음
• 서버가 클라이언트에게 능동적으로 데이터를 푸시할 수 없어, 실시간 업데이트가 필요한 경우 비효율적

압축의 제한:

• HTTP/1.1에서는 body 내용은 압축할 수 있지만, 헤더는 압축할 수 없음
• 헤더가 큰 경우 불필요한 대역폭을 사용

도메인 샤딩의 필요성:

• 연결 제한을 우회하기 위해 여러 서브도메인을 사용하는 도메인 샤딩 기법이 사용
• 이는 DNS 조회 시간을 증가시키고 추가적인 TCP 연결을 필요로 하여 새로운 오버헤드를 만듬

지연 시간에 민감:

• 각 요청-응답 사이클이 완료되어야 다음 요청을 할 수 있어, 네트워크 지연 시간에 매우 민감

상태 비저장 프로토콜:

• HTTP는 상태를 저장하지 않아, 매 요청마다 필요한 모든 정보를 포함해야 함
• 이는 쿠키나 세션 관리를 위한 추가적인 메커니즘 필요

 

 

2. 브라우저 양방향통신, WebSocket

WebSocket의 작동방식

 

초기 연결:

• 클라이언트가 서버에 HTTP 연결을 요청하면서 WebSocket으로의 업그레이드를 요청(초기 핸드셰이크를 수행)
• 서버가 이를 승인하고 프로토콜을 WebSocket으로 전환

양방향 통신:

• WebSocket 연결이 수립되면, 클라이언트와 서버 간에 자유로운 양방향 통신이 가능
• 클라이언트는 언제든 서버로 메시지를 보낼 수 있음
• 서버도 별도의 요청 없이 클라이언트에게 실시간으로 데이터를 푸시할 수 있음

연결 종료:

• 클라이언트나 서버 중 어느 쪽에서든 연결 종료를 요청 가능
• 상대방이 이를 확인하면 연결 종료 

 

이 다이어그램의 특징:

• 초기 연결은 HTTP를 통해 이루어지지만, 그 이후에는 WebSocket 프로토콜을 사용
• 연결이 수립된 후에는 클라이언트와 서버가 대등한 위치에서 자유롭게 통신 가능
• 서버가 클라이언트의 요청 없이도 데이터를 전송할 수 있어, 실시간 업데이트에 매우 효과적

 

사용 사례:

• 실시간 채팅 애플리케이션
• 라이브 스코어보드나 주식 시세 같은 실시간 업데이트
• 온라인 게임
• 협업 도구 (실시간 문서 편집 등)
• IoT 디바이스 모니터링

장점:

• 실시간 양방향 통신으로 즉각적인 데이터 교환이 가능
• HTTP Long Polling에 비해 서버 리소스를 효율적으로 사용
• 헤더 오버헤드가 적어 네트워크 트래픽을 줄일 수 있음

단점:

• 일부 오래된 브라우저에서는 지원되지 않을 수 있음
• 방화벽이나 프록시 서버가 WebSocket 연결을 차단할 수 있음
• 서버 측에서 연결 상태를 관리해야 하므로 복잡성이 증가할 수 있음

 

3. HTTP Long Polling은 또 뭔가?

실시간에 가까운 웹 애플리케이션을 구현하기 위한 기술 중 하나. 전통적인 폴링(polling) 방식을 개선한 것으로, 서버와 클라이언트 간의 지속적인 연결을 시뮬레이션

• 클라이언트가 서버에 요청을 보내고, 서버는 새로운 데이터가 있을 때까지 응답을 보류
• 데이터가 있거나 타임아웃이 발생하면 서버가 응답을 보냄
• 클라이언트는 응답을 받는 즉시 새로운 요청을 보냄

작동 방식:

1. 클라이언트가 HTTP 요청을 서버로 보냅니다.
2. 서버는 요청을 받지만, 즉시 응답하지 않고 대기합니다.
3. 새로운 데이터가 생기거나 정해진 시간(타임아웃)이 지나면 서버가 응답합니다.
4. 클라이언트는 응답을 처리하고 즉시 새로운 요청을 보냅니다.

장점:

• 실시간에 가까운 업데이트를 제공할 수 있습니다.
• 일반 HTTP를 사용하므로 대부분의 브라우저와 서버에서 지원됩니다.
• 방화벽이나 프록시 서버와의 호환성이 좋습니다.
• WebSocket보다 구현이 간단할 수 있습니다.

단점:

• 각 클라이언트마다 서버에 연결을 유지해야 해서 서버 리소스 사용량이 높습니다.
• 실제 실시간 통신에 비해 약간의 지연이 있을 수 있습니다.
• 많은 수의 동시 접속자가 있을 경우 확장성 문제가 발생할 수 있습니다.
• 클라이언트와 서버 간의 연결이 자주 끊겼다 다시 맺어지므로 오버헤드가 발생합니다.