HTTP 를 기본으로 하는 프로토콜
HTTP 가 웹 브라우저라는 환경이 이미 널리 퍼져있기 때문에
새로운 프로토콜을 만들지 않고 HTTP 를 기반으로 하는 프로토콜이 구현되어 있다
SPDY
HTTP 의 병목 현상을 해소하기 위한 프로토콜
HTTP 의 병목 현상
실시간 서비스가 점점 많아지면서 HTTP 에서 점점 처리하기에 병목 현상이 발생한다
HTTP 에서는 서버의 정보가 갱신되었는지 아닌지를 알기 위해 클라이언트가 항상 서버 측에 확인하러 가야 한다
만약 서버 상 정보가 갱신되지 않은 경우에도 불필요한 통신이 발생한다
현재 웹에 요구되고 있는 사용하는 방법으로는 HTTP 사양이 병목 현상이 된다
- 1개의 커넥션으로 1개의 요청만 보낼 수 있다
- 요청은 클라이언트에서만 시작할 수 있고 응답만 받을 수 없다
- 요청/응답 헤더를 압축하지 않은 채로 보낸다
- 장황한 헤더를 보낸다
- 데이터 압축을 임의로 선택할 수 있다
Ajax 를 통한 해결 방법
JS 나 DOM 조작을 활용하는 방식으로 웹 페이지의 일부만 고쳐쓸 수 있는 비동기 통신 방법이다
페이지의 일부분만 갱신되기 때문에 응답 데이터 양이 줄어든다는 장점이 있다
Ajax 를 사용해서 실시간으로 서버에 정보를 취득하려고 하면 대량의 요청이 발생한다는 문제가 있다 HTTP 통신의 문제 자체가 해결되는 것은 아니다
Comet 에 의한 해결 방법
서버측의 콘텐츠 갱신이 있었을 경우 클라이언트부터 요청을 기다리지 않고
클라이언트에 보내기 위한 방법이다
응답을 연장시킴으로 서버에서 통신을 개시하는 서버 푸쉬 기능을 유사하게 따르고 있다
서버 콘텐츠가 갱신되었을 때 응답을 보내 클라이언트에 반영할 수 있다
콘텐츠를 실시간 갱신할 수는 있지만 응답을 보류하기 위해 연결을 유지하는 시간이 길어진다
커넥션을 유지하는 동안은 리소스를 소비한다
역시 HTTP 통신 문제 자체가 해결되는 것은 아니다
SDPY의 목표
HTTP 라는 프로토콜 자체의 제약을 해결하기 위한 것으로
HTTP 의 병목 현상을 프로토콜 레벨에서의 개선 하기 위한 프로토콜이다
SPDY 설계와 기능
HTTP 를 바꾸는 것이 아니라 TCP/IP 의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다
보안을 위해 표준으로 SSL 을 사용하도록 한다
다중화 스트림
탄일 TCP 접속을 통해 복수의 HTTP 요청을 무제한으로 처리할 수 있다
한 번의 TCP 접속으로 요청을 받기 때문에 TCP 효율이 좋다
요청 우선 순위
요청 우선 순위를 부여할 수 있다
복수의 요청을 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상을 해결할 수 있다
HTTP 헤더 압축
헤더를 압축하여 적은 패킷으로 통신할 수 있다
서버 푸시 기능
서버에서 클라이언트로 데이터를 푸시하는 기능을 지원한다
요청을 기다리지 않고 데이터를 보낼 수 있다
서버 힌트 기능
서버가 클라이언트에게 요청을 제안할 수 있다
병목 현상
SPDY 는 병목 현상을 해결하는 좋은 기술이지만
SPDY 는 한 개의 도메인과의 통신을 다중화할 뿐이기 때문에 복수의 도메인으로 리소스를 사용하고 있는 경우에 효과는 한정적이다
대부분 웹 사이트의 문제는 병목 현상만 있는 것이 아니다
WebSocket
WebSocket 은 브라우저에서 양방향 통신을 한다
Ajax 와 Comet 을 사용한 통신은 웹 브라우징을 고속화하지만
HTTP 프로토콜을 사용하고 있는 이상 병목 현상을 완전히 해결할 수는 없다
WebSocket 은 새로운 프로토콜과 API 로 병목현상을 해결한다
처음에는 HTML5 사양의 일부로 책정이 되어 있었지만
현재는 단독 프로토콜로서 규정이 책정되었다
WebSocket 의 설계와 기능
웹 소켓은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격으로
XMLHttpRequest 의 결점을 해결하기 위한 기술
WebSocket 프로토콜
웹 서버와 클라이언트가 한 번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 HTTP 접속의 출발점이 클라이언트에 있다는 것에는 변함이 없지만
한 번 접속을 하면 어느 쪽에서도 송신을 할 수 있다
서버 푸시 기능
서버에서 데이터를 푸시하는 서버 푸시 기능을 제공하기 때문에 클라이언트 요청을 기다리지 않고 데이터를 보낼 수 있다
통신량 삭감
WebSocket 은 접속을 계속 유지하기 때문에 HTTP 에 오버헤드가 줄어든다
헤더의 사이즈도 작기 때문에 통신량이 더 줄어든다
WebSocket 통신을 하려면 한 번 HHTP에 접속을 확립 후 WebSocket 핸드쉐이크 절차를 밟을 필요가 있다
핸드쉐이크/요청
WebSocket 통신은 HTTP 의 Upgrade 헤더 필드를 사용해서
프로토콜 변경하는 것으로 핸드쉐이크를 실시한다
Sec-WebSOcket-Key 에는 핸드쉐이크에 필요한 저장되어 Set-WebSocket-Protocol 에 사용하는 서브 프로토콜이 저장되어 있다
서브 프로토콜은 WebSocket 프로토콜에 의한 연결을 여러 개로 구분하고 싶을 때 이름을 붙여 정의한다
핸드쉐이크/응답
요청에 대한 응답은 상태코드 101로 반환된다
Sec-WebSocket-Accept 는 Sec-WebSocket-Key 의 값에서 생성된 값이 저장된다
핸드쉐이크에 의해 WebSocket 연결이 확립된 후에는 HTTP가 아닌
WebSocket 독자적 데이터 프레임을 이용하여 통신한다
WebSocket API
JS 에서 WebSocket 프로토콜을 사용한 양방향 통신을 위해서는
W3C 에서 사양이 책정되어 있는 WebSocket API 에서 제공하고 있는
WebSocket 인터페이스를 사용한다
HTTP/2.0
웹 체감 속도의 개선을 목포료 하고 만들어졌다
https://namu.wiki/w/HTTP/2
WebDAV
웹 서버 상의 파일을 관리한다
웹 서버의 콘텐츠에 대해 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1 을 확장한 프로토콜
