HTTP의 용도는 다방면에 이르게 됨. 따라서, 프로토콜의 제한과 한계가 생겼는데 이를 해결하기 위해 새로운 프로토콜이 몇 가지 구현됨.
페이스북이나 트위터 등의 SNS처럼 많은 사람들이 작성한 정보를 거의 실시간으로 보는 것이 중요. 그러나, HTTP에서는 서버의 정보 갱신 유무를 위해서는 클라이언트가 항상 서버 측에 확인하러 가야함. 이는 불필요한 통신이 발생하게 됨.
Ajax(Asynchronous Javascript+XML)은 JavaScript나 DOM(Document Object Model) 조작 등을 활용하는 방식, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법.
페이지의 일부분만 갱신되기 때믄에 리스폰스로 전송되는 데이터 양은 줄어든다는 장점.
Comet은 서버 측의 콘텐츠에 갱신이 있었을 경우, 클라이언트부터 리퀘스트를 기다리지 낳고 클라이언트에 보내기 위한 방법. 응답을 연장시킴으로써, 서버에서 통신을 개시하는 서버 푸시 기능을 유사하게 따름.
콘텐츠를 실시간으로 갱신할 수는 있으나 리스폰스를 보류하기 위해서 커넥션을 유지하는 시간이 길어짐.
Ajax와 Comet 등 사용성을 쾌적하게 하는 여러 가지 기술이 등장해서 어느정도 개선되었지만, HTTP라는 프로토콜의 제약은 없앨 수 없음.
근본적인 개선을 위해서는 프로토콜 레벨에서의 개선이 필요.
SPDY는 HTTP가 안고 있던 병목 현상을 프로토콜 레벨에서 해소하기 위해 개발이 진행되고 있는 프로토콜.
HTTP | 애플리케이션 계층 |
SPDY | 세션 계층 |
SSL | 프리젠테이션 계층 |
TCP | 트랜스포트 계층 |
SPDY는 HTTP의 병목 현상을 해결하는 좋은 기술이지만, 대부분 웹 사이트의 문제는 HTTP의 병목 현상 때문만은 아님. 웹 자신을 고속화하기 위해서는 웹 콘텐츠 제작을 개선하는 등 부수적으로 해야 할 일이 많음.
WebSocket은 웹 브라우저와 웹 서버를 위한 양방향 통신 규격으로 WebSocket 프로토콜을 IETF가 책정하고 WebSocket API를 W3C가 책정함.
WebSocket은 웹 서버와 클라이언트가 한 번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON이나 XML, HTML이나 이미지 등 임의 형식의 데이터를 보내게 됨.
HTTP/2.0은 사용자가 웹을 이용할 때의 체감 속도의 개선을 목표로 하고 있음. 아래의 프로토콜이 베이스가 되어 사양이 검토되고 있음.
HTTP/2.0은 주요한 7가지 기술에 대해 논의되고 있음. (변동 가능성)
압축 | SPDY 또는 Friendly |
다중화 | SPDY |
TLS의 의무화 | Speed+Mobility |
네고시에이션 | Speed+Mobility, 또는 Friendly |
클라이언트 풀/서버 푸시 | Speed+Mobility |
흐름 제어 | SPDY |
WebSocket | Speed+Mobility |
WebDAV(Web-based Distributed Authoring and Versioning)는 웹 서버의 콘텐츠에 대해서, 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템.
파일 작성이나 삭제 등 기본적인 기능 이외에 파일 작성자 등의 관리나 편집 중에 다른 유저가 다시 고쳐 쓰지 못하도록 잠금 기능, 갱신 정보를 관리하는 리버전 기능 등이 준비되어 있음.
PROPFIND : 프로퍼티 취득
PROPPATCH : 프로퍼티 변경
MKCOL : 컬렉션 작성
COPY : 리소스 및 프로퍼티 복제
MOVE : 리소스 이동
LOCK : 리소스 잠금
UNLOCK : 리소스 잠금 해제
102 Processing : 리퀘스트는 정상적으로 수신되었지만 아직 처리중이다
207 Multi-Status : 복수의 스테이터스를 가지고 있다
422 Unprocessable Entity : 서식은 올바르지만 내용이 틀리다
423 Locked : 리소스가 잠겨있다
424 Failed Dependency : 어떤 리퀘스트와 관련된 리퀘스트가 실패했기 때문에 의존 관계를 유지하지 못한다
507 Insufficient Storage : 기억 영역이 부족하다