HTTP에 기능 추가한 프로토콜

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

https://ko.javascript.info/websocket

(웹소켓 관련해서 공부하고 싶으면 위의 링크 다시 보기)

 

 

---

 

 

웹이 발달하면서 기존 HTTP만의 기능으로는 웹 사용자들의 수요를 충족할 수 없어 HTTP에 기능을 추가한 새로운 프로토콜 몇 가지가 탄생하게 됨

SPDY

• 구글이 2010년에 발표한 프로토콜
• HTTP의 병목 현상을 해결하기 위해 고안되었고, SPDY의 목표는 웹페이지 로딩 시간을 50% 단축하는 것

HTTP의 병목 현상

• 페이스북이나 트위터 등의 SNS는 수많은 사용자가 올린 대량의 정보를 실시간으로 확인해야 함
• 사용자에 의해 갱신된 정보를 사용자의 화면에 바로 반영하는 것은 HTTP의 사양에 의해 어려움

HTTP의 사양

• 1개의 커넥션으로 1개의 리퀘스트만 송신 가능
• 리퀘스트는 클라이언트에서만 시작 가능
  • 리퀘스트 없이 리스폰스만 받는 것은 불가능
• 리퀘스트/리스폰스 헤더를 압축하지 않고 전송하기에 헤더의 정보가 많을수록 통신의 지연이 심해짐
• 장황한 헤더 전송→불필요한 반복(통신 낭비) 발생
• 데이터 압축은 선택사항이므로 압축하고 보내는 것이 강제되지 않음

---

HTTP의 병목 현상을 해결하기 위한 노력으로 Ajax, Comet 등의 방법이 고안되었으나, HTTP 프로토콜 자체의 문제를 해결하지는 못함

Ajax

• 자바스트립트나 DOM 조작 등을 활용하여 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법
• 기존의 동기식 통신에 비해 페이지의 일부분만 갱신되기에 리스폰스로 전송되는 데이터량 감소
  • 갱신을 확인하기 위해 리퀘스트를 보내면 서버는 갱신된 페이지의 일부분만 전송하면 됨
• Ajax의 핵심 기술은 XMLHttpRequest라는 API로, 자바스크립트 등의 스크립트 언어로 서버와 HTTP 통신 가능
  • 이미 읽어들인 웹 페이지부터 리퀘스트 발행→페이지의 일부 데이터만 받는 것이 가능해짐

Ajax의 단점

• Ajax를 활용해 실시간으로 서버에서 정보 취득하려고 하면 대량의 리퀘스트 발생하는 문제
• HTTP 프로토콜 자신이 갖고 있는 사양 상의 문제가 해결되는 것은 아님

Comet

• 서버 측의 콘텐츠에 갱신이 있었을 경우 클라이언트로부터 리퀘스트 기다리지 않고 클라이언트에 보내기 위한 방법
• 클라이언트의 갱신 확인 요청에 바로 응답하는 대신 갱신될 때까지 기다렸다가(보류 상태), 갱신시 리스폰스 반환
  • 서버에서 갱신된 콘텐츠가 있으면 바로 클라이언트에 반영 가능

Comet의 단점

• 콘텐츠를 실시간으로 갱신 가능하나, 리스폰스를 보류하기 위해서 커넥션을 유지하는 시간이 길어짐
• 커넥션을 유지하는 동안 서버 측에서 리소스 소비
• HTTP 자체의 문제를 해결하는 것은 아님

---

SPDY 설계

• HTTP에 존재했던 병목 현상을 프로토콜 레벨에서 해소하기 위해 설계된 프로토콜
• HTTP를 완전히 바꾸는 것이 아님
• TCP/IP의 애플리케이션 게층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작
  • HTTP→SPDY→SSL(TLS)→TCP 의 계층 순서
  • TCP/IP의 관점에서 HTTP, SPDY, SSL은 애플리케이션 계층, TCP는 전송 계층

SPDY 기능

1) 다중화 스트림

• 단일 TCP 접속을 통해 복수의 HTTP 리퀘스트를 무제한으로 처리 가능
  • TCP의 효율 증가

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

• 복수의 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상 해결하기 위해 우선 순위 부여

3) HTTP 헤더 압축

• 보다 적은 패킷 수와 송신 바이트 수로 통신 가능

4) 서버 푸시 기능

• 서버에서 클라이언트로 데이터를 푸시(전달)하는 서버 푸시 기능 지원
• 클라이언트의 리퀘스트 없이 바로 데이터 전송 가능

5) 서버 힌트 기능

• 서버 측에서 클라이언트에게 리퀘스트해야 할 리소스 제안 가능
• 서버 힌트 기능으로 인해 클라이언트가 자원 발견하기 전에 리소스의 존재를 알게 되므로 이미 캐시를 갖고 있다면 불필요한 리퀘스트 전송 안해도 됨

SPDY가 웹 사이트의 병목 현상을 해결하는가?

• SPDY는 HTTP의 병목 현상을 해결하는 좋은 기술인것은 분명함
• 하지만 대부분 웹 사이트의 병목 문제의 원인이 HTTP에만 있는 것이 아니므로 웹 콘텐츠 제작을 개선하는 등이 노력 또한 필요

 

 

---

 

 

 

WebSocket

• 새로운 프로토콜과 API에 의해 병목 현상을 해결하기 위한 기술
  • Ajax나 Comet에서 사용하는 XMLHttpRequest의 결점을 해결하기 위한 목적
• 웹 브라우저와 웹 서버를 위한 양방향 통신 규격
• WebSocket 프로토콜을 IETF가 책정, WebSocket API를 W3C가 책정
• JSON, XML, HTML, 이미지 등 임의 형식으로 데이터 전송
• HTTP에 의한 접속의 출발점이 클라이언트에 있지만, 한 번 접속 확립시 WebSocket을 사용해 서버와 클라이언트 어느 쪽에서도 송신 가능

WebSocket 프로토콜의 특징

• 서버 푸시 기능
  • 서버에서 클라이언트로 데이터 푸시하는 서버 푸시 기능 제공→리퀘스트 안 기다리고 보내도 됨
• 통신량의 삭감
  • 한번 접속 확립후 명시적으로 접속 끊지 않는 한 접속 유지→HTTP에 의해 자주 접속을 하는 오버헤드 감소
  • 헤더의 사이즈가 작음
• 핸드쉐이크/리퀘스트

GET /CHAT HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: afsghjhfdjklajfsdafjlsd==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

• • HTTP의 Upgrade 헤더 필드 사용해 프로토콜 변경하는 것으로 핸드쉐이크 실시
  • Sec-WebSocket-Key는 보안을 위해 브라우저에서 생성한 키이며, 서버에서 웹소켓을 지원하는지 확인 위해 사용
  • Sec-WebSocket-Protocol에는 웹소켓 통신에 사용하는 서브 프로토콜이 저장
    • 주고받고 싶은 데이터 형태를 서버에 요구하기 위해 사용
  • Sec-WebSocket-Version에는 웹소켓의 버전이 명시

• 핸드쉐이크/리스폰스

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec_WebSocket-Accept: fghfhgafsdjklajfsdafjlsd==
Sec-WebSocket-Protocol: chat

• • 핸드쉐이크에 대한 리스폰스는 상태 코드 101 Switching Protocol로 반환
  • Sec-WebSocket-Accept에는 리퀘스트의 Sec-WebSocket-Key로부터 특별한 처리를 한 값이 저장됨
  • (더 정확히는, Sec-WebSocket-Key에 유니크 아이디를 더해서 SHA-1로 해싱한 후, base64로 인코딩한 결과가 저장)

• • • 브라우저는 이를 보고 서버가 웹소켓을 지원하는지 확인 가능(웹소켓 연결이 개시됨을 알림)

• • 핸드쉐이크에 의해 WebSocket 커넥션이 확립된 후에는 HTTP가 아닌 WebSocket 독자적인 데이터 프레임을 사용해 통신 진행
  • Sec-WebSocket-Protocol에는 서버가 주고받을 수 있는 프로토콜(데이터 형태) 정보가 담겨있음

• WebSocket API
  • 자바스크립트에서 WebSocket 프로토콜을 사용한 양방향 통신을 하기 위해 WebSocket API 사용 가능

// WebSocket API 사용해 50ms에 1번 데이터 송신하는 예
var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function() {
 setIntetval(function() {
   if(socket.bufferedAmount == 0)
     socket.send(getUpdateData());
   }, 50);
};

 

 

---

 

 

WebDAV

• 웹 서버의 콘텐츠에 대해, 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템
• HTTP/1.1을 확장한 프로토콜로 RFC4918로서 정의됨
• 파일 작성이나 삭제 등 기본 기능 외에 파일 작성자 관리, 편집 중에 다른 유저가 내용을 고치지 못하도록 잠그는 기능, 갱신 정보 관리 기능 등이 존재

WebDAV에 새롭게 추가된 개념

• 컬렉션(Collection)
  • 여러 개의 리소스를 한번에 관리하기 위한 개념
  • 각종 조작은 컬렉션 단위로 조작 가능
  • 컬렉션 속에 컬렉션을 두어 사용 가능
• 자원(Resource): 파일이나 컬렉션을 부르는 말
• 프로퍼티(Property)
  • 리소스의 프로퍼티를 정의한 것
  • “이름=값”의 형식으로 이루어짐
• 잠금(Lock)
  • 파일을 편집할 수 없는 상태로 만드는 것
  • 여러 명의 사람이 한 파일에 동시에 작성하는 것을 예방

WebDAV에 추가된 메소드와 상태 코드

• 리모트 파일 관리를 위해 HTTP/1.1의 사양에서 확장한, 아래의 메소드와 상태 코드 제공

메소드

• PROPFIND: 프로퍼티 취득
• PROPPATCH: 프로퍼티 변경
• MKCOL: 컬렉션 작성
• COPY: 리소스 및 프로퍼티 복사
• MOVE: 리소스 이동
• LOCK: 리소스 잠금
• UNLOCK: 리소스 잠금 해제

상태 코드

• 102 Processing: 리퀘스트 정상 수신되었지만, 아직 처리 중
• 207 Multi-Status: 복수의 스테이터스를 가지고 있음
• 422 Unprocessable Entity: 서식은 올바르지만 내용이 틀림
• 423 Locked: 리소스가 잠겨져 있음
• 424 Failed Dependency: 어떤 리퀘스트와 관련된 리퀘스트가 실패했기 때문에 의존 관계를 유지 못함
• 507 Insufficient Storage: 기억 영역이 부족함

 

 

---

 

 

HTTP 이외의 프로토콜이 고안되었음에도 HTTP가 주류인 이유

• 기업이나 조직 등의 방화벽 설정과 관련됨
  • 방화벽의 기본 기능 중에 지정된 프로토콜이나 포트번호 이외의 패킷은 통과시키지 않는 기능 존재
  • 새로운 프로토콜이나 포트 번호를 이용할 경우 설정을 변경해줘야 함
  • 인터넷에서 가장 많이 활용되는 분야인 웹이 HTTP에서 동작하기 때문에 웹 서버를 구축할 때나 웹사이트의 액세스에는 방화벽의 설정에서 HTTP(80)나 HTTPS(443)를 허가해둘 필요성 존재
• HTTP 클라이언트인 브라우저의 보급, HTTP 서버가 많이 보급되어 있는 것도 이유 중의 하나라고 추측