할일
HTTP&Network 책읽기(~262)
C프로그래밍 책읽기(~250)
HTTP&Network 책
HTTP의 병목현상
- 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.
- 리퀘스트는 클라이언트에서만 시작할 수 있다. 리스폰스만 받는 것은 불가능하다.
- 리퀘스트/리스폰스 헤더를 압축하지 않은 채로 보낸다. 헤더의 정보가 많을 수록 지연이 심해짐
- 장황한 헤더를 보낸다. 매번 같은 헤더를 보내는 것은 낭비다.
- 데이터 압축을 임의로 선택할 수 있다. 압축해서 보내는 것이 강제적이지는 않다.
Ajax에 의한 해결 방법
웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법임
실시간으로 서버에서 정보를 취득하려고 하면 대량의 리퀘스트가 발생함
HTTP의 프로토콜 자신이 가지고 있는 문제가 해결되는 것은 아님
Comet에 의한 해결 방법
서버 측의 콘텐츠에 갱신이 있었을 경우 클라이언트부터 리퀘스트를 기다리지 않고 보내기 위한 방법
응답을 연장시킴으로써 서버에서 통신을 개시하는 서버 푸시 기능을 유사하게 따르고 있음
통상 리퀘스트가 오면 리스폰스를 바로 반환하지만 Comet에서는 리스폰스를 보류 상태로 해 두고
서버의 콘텐츠가 갱신되었을 때에 리스폰스를 반환한다.
실시간 갱신이 가능하지만 리스폰스를 보류하기 위해 커넥션을 유지하는 시간이 길어진다.
SPDY - HTTP의 병목 현상을 해소하는 목표를 세우고 개발되고 있음
TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작
데이터의 흐름은 제어하지만 HTTP의 커넥션은 확립되어 있다.
장점
- 다중화 스트림 : 단일 TCP 접속을 통해서 복수의 HTTP 리퀘스트를 무제한으로 처리할 수 있다.
때문에 TCP의 효율이 높아진다.
- 리퀘스트의 우선 순위 부여 : 복수의 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상 방지
- HTTP 헤더 압축 : 리퀘스트와 리스폰스 HTTP 헤더를 압축. 이로 인해 보다 적은 패킷 수와 송신 바이트 수로
통신을 할 수 있음
- 서버 푸시 기능 : 서버에서 클라이언트로 데이터를 푸쉬하는 서버 푸시 기능을 지원함
그래서 서버 측은 클라이언트의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있음
WebSocket - 새로운 프로토콜과 API에 의해 병목 현상을 해결하기 위한 기술로서 개발되어 있음
웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식
JSON이나 XML, HTML이나 이미지 등의 임의 형식의 데이터로 보내게 됨
WebSocket으로 통신을 하려면 한번 HTTP에 접속을 확립하고, WebSocket에 의해 통신을 하기위해
핸드쉐이크 절차를 밟을 필요가 있음
-> HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경
WebSocket URL 형식 - ws:// , wss://
웹 서버 상의 파일을 관리하는 WebDAV
웹 서버의 콘텐츠에 대해서 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로
HTTP/1.1를 확장한 프로토콜임 / 잠금 기능, 갱신 정보를 관리하는 리비전 기능등도 제공
기본 제공 메소드 및 상태 코드 외에 리모트 파일 관리를 위해서 추가되어 있는 부분이 있음
아직까지 HTTP의 문제점이 꽤나 많다는 것도 처음 알았고 Ajax 외에 Comet, SPDY,WebDAV와 같은 개념들도 아예 처음 들어서 신기했다.
WebSocket은 많이 들어보긴 했는데 아예 프로토콜을 다르게 사용한다는 것도 신기했고 WebSocket은 병목 현상을 해결 하기 위한 기술이고 자주 사용될 개념이다 보니 나중에 토이 프로젝트할 때 WebSocket을 사용해서 구현해야하는 기능도 넣어서 진행해봐야겠다.