8일차 - HTTP에 기능을 추가한 프로토콜

오늘은 기존의 HTTP의 사양에 따른 병목현상을 예방하기 위한 것에 대해 배웠다.

HTTP가 처음 개발되었을 때는 단순히 HTML을 전송하기 위한 목적이여서 오늘날에 와서 새로운 기능들을 대처하기에는

부족한 점이 많은 프로토콜이라는 생각이 들었다.

현재는 HTTP 1.1버전을 대부분 사용하지만 1.1버전의 부족한 점을 보완하기위해 2.0버전을 개발 중이라는 것도 알게 되었다.

 

 

1. SPDY

SPDY는 HTTP의 병목현상을 해소하고 웹 페이지 로딩 시간을 절반 단축하려는 목표로 개발되고 있다.

병목현상은 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한을 받는 현상이다.

기존의 HTTP를 사용하면 어떠한 원인으로 병목현상이 발생하는 것일까?

- 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.

- 리퀘스트는 클라이언트에서만 시작할 수 있고 리스폰스만 받는 것을 불가하다.

- 리퀘스트, 리스폰스 헤더를 압축하지 않는 체로 보내어 헤더의 정보가 많을수록 지연이 심해진다.

- 정확한 헤더를 보내는 것이 원칙이여서 매번 같은 헤더를 보내는 것은 낭비이다.

- 데이터 압축을 임의로 선택할 수 있어 압축해서 보내는 것이 강제적이지 않다.

 

요즘은 sns과 같은 실시간으로 정보를 확인하는 것이 일반적이다. 이러한 실시간 서비스를 웹에서 사용하면 대량의 갱신 정보가 발생하게 되고 위에서 본 HTTP의 사양은 병목현상을 발생시키게 된다.

병목현상을 해결하기 위한 방법은 무엇일까?

1) Ajax에 의한 해결 방법

Ajax는 javascript나 DOM(Document Object Model) 조작 등을 활용하는 방식으로 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법이다.

기존의 동기식 통신에 비해 리스폰스로 전송되는 데이터 양이 줄어든다는 장점이 있다.

Ajax의 핵심기술은 XMLHttpRequest라는 API로 스크립트 언어를 통해 서버와 HTTP 통신이 가능하다.

이를 활용하여 이미 읽어 들인 웹 페이지부터 리퀘스트를 발행할 수 있기 때문에 페이지의 일부 데이터만 받는 것이 가능해진다.

이러한 Ajax를 사용하면 웹 페이지의 갱신 상황을 확인하여 웹 페이지의 갱신된 일부만 리스폰스로 보내는 것이 가능하하다.

하지만, Ajax를 사용해서 실시간으로 서버에서 정보를 취득하려고 하면 대량의 리퀘스트가 발생하는 문제가 발생하고

HTTP의 문제를 모두 해결할 수는 없다.

 

2) Comet에 의한 해결 방법

comet은 서버 측의 콘텐츠에 갱신이 있었을 경우, 클라이언트로부터 리퀘스트를 기다리지 않고 클라이언트에 보내기 위한 방법이다.

보통의 경우에 리퀘스트가 오면 리스폰스를 바로 반환하지만 comet에서는 리스폰스를 보류 상태로 두고 서버의 콘텐츠가 갱신되었을 때 리스폰스를 반환하는 것이다.

comet은 콘텐츠를 실시간으로 갱신할 수는 있지만 리스폰스를 보류하기 위해 커넥션을 유지하는 시간이 길어지고 이로 인해 리소스를 소비하게 되는 단점이 있다.

comet도 ajax와 같이 HTTP 자체의 문제를 해결할 수 있는 것이 아니다.

 

위 두 가지의 방법으로 실시간 서비스를 위한 갱신에 도움이 되지만 HTTP의 사양으로 인한 제약을 해결할 수는 없었다.

SPDY는 HTTP가 가지고 있던 병목 현상을 프로토콜 레벨에서 해소하기 위해 개발이 진행되고 있는 프로토콜이다.

지금부터 SPDY에 대해 알아보자.

 

SPDY는 TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다.

또한, SPDY는 보안을 위해 표준으로 SSL을 사용하도록 되어 있다.

SPDY를 사용하면 어떠한 기능이 추가될까?

1) 다중화 스트림

단일 TCP 접속을 통해 다수의 HTTP 리퀘스트를 무제한으로 처리가 가능하다.

2) 리퀘스트의 우선 순위 부여

SPDY는 무제한으로 리퀘스트를 병렬 처리하는 것이 가능한 것과 더불어 각 리퀘스트에 우선 순위를 부여할 수 있다.

이는 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상을 해결하기 위한 기능이다.

3) HTTP 헤더 압축

SPDY는 리퀘스트와 리스폰스의 HTTP 헤더를 압축할 수 있다.

이 기능은 기존의 HTTP에 비해 적은 패킷 수와 바이트 수로 통신이 가능하도록 해준다.

4) 서버 힌트 기능

서버가 클라이언트에게 리퀘스트 해야 할 리소스를 제안이 가능하다.

이미 캐시를 가지고 있는 상태라면 불필요한 리퀘스트를 보내지 않아도 리소스의 존재를 클라이언트가 알 수 있다.

 

 

2. WebSocket

Websocket은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격으로 주로 ajax나 comet에서 사용하는 XMLHttpRequest의 결점을 해결하기 위한 기술로서 개발이 되고 있다.

HTTP에 의한 접속의 출발점이 클라이언트에 있다는 것은 변함이 없지만 한 번 접속을 하게 되면 websocket을 사용하여 서버와 클라이언트 어느 쪽에서도 송신을 할 수 있게 된다.

 

websocket의 특징은 다음과 같다.

1) 서버 푸시 가능

서버에서 클라이언트에 데이터를 푸시하는 서버 푸시 기능을 제공한다.

이 기능을 통해 서버는 클라이언트의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다.

2) 통신량의 삭감

websocket은 접속을 한번 확립하면 접속을 유지하는 특성이 있다.

이러한 특성으로 HTTP에 비해 자주 접속을 하는 오버헤드가 적어지고 헤더의 사이즈도 작아지기 때문에 통신량을 줄일 수 있다.

 

 

3. WebDAV (Web-based Distributed Authoring and Versioning)

WebDAV는 웹 서버 콘텐츠에 대해서 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1을 확장한 프로토콜이다.

HTTP/1.1의 PUT 메소드나 DELETE 메소드를 사용하면 웹 서버 상의 파일작성이나 삭제 등을 할 수 있지만 보안이나 편의성 등의 문제가 있어 사용되지는 않는다.

WebDAV에 새롭게 추가한 개념은 다음과 같다.

1) 컬렉션(collection)

여러 개의 리소스를 한꺼번에 관리하기 위한 개념으로 각종 조작은 컬렉션 단위로 이루어 진다.

2) 프로퍼티(property)

리소스의 프로퍼티를 정의한 것으로 이름=값의 형식으로 이루어진다.

3) 잠금(lock)

파일을 편집할 수 없는 상태로 만든 것이다. 여려 명의 사람이 동시에 편집하는 경우 등을 예방한다.