##본 포스팅은 '그림으로 배우는 Http & Network Basic - 우에노 센'을 읽고 쓴 요약/정리 글입니다.
HTTP를 기본으로 하는 프로토콜
주로 HTML로 작성된 문서를 전송하기 위한 프로토콜로 HTTP를 생각했었다.
여러 새로운 프로토콜이 나오긴 했지만, HTTP라는 프로토콜의 제한이나 한계가 있었고
또 무시하고 새로 만들기엔 HTTP라는 프로토콜을 무시할 수 없었다.
그래서 HTTP를 기반으로 해서 여기에 추가하는 형태로 새로운 프로토콜이 몇가지가 구현되었다.
HTTP의 병목현상을 해소하는 SPDY
Google이 2010년에 발표한 SPDY는 HTTP의 병목 현상을 해소하고 웹 페이지 로딩 시간을 50% 단축한다는 못표를 세우고 개발되고 있다.
[HTTP의 병목 현상]
갱신된 정보를 가능한 빨리 실시간으로 표시하기 위해서는 서버상의 정보가 갱신되었을 때, 그것을 클라언트의 화면에 반영할 필요가 있다.
HTTP에서는 서버의 정보가 갱신되었는지 아닌지를 항상 서버측에 확인하러 가야한다.
- 1개의 커넥션 : 1개의 리퀘스트
- 리퀘스트는 클라이언트에서만 보낼 수 있음
- 리퀘스트/리스폰스 헤더를 압축하지 않은 체로 보내기에 헤더의 정보가 많을수록 지연이 심해짐
- 매번 같은 헤더를 보내는건 낭비
위와 같은 이유로 생기는 병목현상을 해결하는 방법은 아래와 같이 등장하였다.
1. Ajax에 의한 해결 방법
Ajax는 JavaScript나 DOM 조작 등을 활용하는 방식으로, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법이다.
페이지의 일부분만 갱신되기 떄문에 리스폰스로 전송되기 데이터 양은 줄어든다는 장점이 있다.
Ajax의 핵심 기술을 XMLHttpRequest라는 API로 JavaScript 등의 스크립트 언어로 서버와 HTTP 통신을 할 수 있다.
이것을 사용하여 페이지 일부분 데이터만 받는 것이 가능하게 된다.
하지만 Ajax를 사용해서 실시간으로 서버에서 정보를 취득하려고 하면
대량의 리퀘스트가 발생한다는 단점이 있다.
2. Comet에 의한 해결 방법
Comet은 서버 측의 콘텐츠에 갱신이 있었을 경우, 클라이언트부터 리퀘스트를 기다리지 않고 클라이언트에 보내기 위한 방법이다.
응답을 연장시킴으로써, 리스폰스를 보류상태로 해 두고, 서버의 콘텐츠가 갱신되었을 때에 리스폰스를 반환한다는 것이다.
하지만 이또한 커넥션을 유지하는 동안은 리소스를 소비한다.
3. SPDY의 목표
SPDY는 TCP/IP의 어플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다.
SPDY가 세션 계층으로서 그 사이에 들어감으로써 데이터의 흐름을 제어하지만, HTTP의 커넥션은 확립되어있다.
그래서 HTTP의 GET과 POST 같은 메소드나 쿠키, HTTP 메시지 등을 그대로 사용할 수 있다.
- 다중화 스트림
단일 TCP 접속을 통해 복수의 HTTP 리퀘스트를 무제한으로 처리할 수 있다.
- 리퀘스트의 우선 순위 부여
각 리퀘스트에 우선 순위를 할당할 수도 있다.
- HTTP 헤더 압축
리퀘스트와 리스폰스의 HTTP 헤더를 압축한다.
- 서버 푸시 기능
서버에서 클라이언트로 데이터를 푸쉬하는 서버 푸시 기능을 지원한다.
서버 측은 클라이언트의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다.
- 서버 힌트 기능
리퀘스트 해야 할 리소스를 제안할 수 있다.
이미 캐시를 가지고 있는 상태면 불필요한 리퀘스트를 보내지 않아도 된다.
하지만 SPDY는 한 개의 도메인과의 통신을 다중화할 뿐이기 떄문에 웹 사이트에서 복수의 도메인으로 리소스를 사용하고 있는 경우에는 그 효과가 한정적이다.
브라우저에서 양방향 통신을 하는 WebSocket
WebSocket은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격으로 WebSocket 프로토콜을 IETF가 책정하고 WebSocket API를 W3C가 책정하고 있다.
WebSocket은 웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON, XML, HTML 등 임의 형식의 데이터를 보내게 된다.
접속의 출발점이 클라이언트에 있다는 것에는 변함이 없지만 한번 접속을 화립하면 WebSocket을 사용하면 서버와 클라이언트 어느쪽에서도 송신을 할 수 있게 된다.
- 서버 푸시 기능
서버 푸시 기능을 제공한다.
- 통신량의 삭감
한번 확립하면 접속을 유지하려고 한다.
- 핸드쉐이크/리퀘스트
WebSocket으로 통신을 하려면 HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 실시한다.
Sec-WebSocket-Key에는 핸드쉐이크에 필요한 키가 저장되어 Set-WebSocket-Protocol에는 사용하는 서브 프로토콜이 저장되어있다.
서브 프로토콜은 WebSocket 프로토콜에 의한 커넥션을 여러 개로 구분하고 싶을 떄에 이름을 붙여서 정의한다.
- 핸드쉐이크/리스폰스
앞선 리퀘스트에 대한 리스폰스는 상태 코드 [101]로 반환된다
커넥션이 확립된 이후에는 HTTP가 아닌 WebSocket 독자적인 데이터 프레임을 이용해 통신을 한다.
양방향 통신을 하기 위해서는 W3C에서 사양이 책정되어 제공되고 있는 WebSocket 인터페이스를 사용한다.
웹 서버 상의 파일을 관리하는 WebDAV
WebDAV는 웹 서버의 콘텐츠에 대해서 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1을 확장한 프로토콜이다.
파일 작성이나 삭제 등 기본적인 기능 이외에 파일 작성자 등의 관리나 편집 중에 다른 유저가 다시 고쳐 쓰지 못하도록 잠금기능, 갱신 정보를 관리하는 리비전 기능 등이 준비되어있다.
