Http&Network Basic - 8

haechi·2022년 9월 27일
네트워크
0

Web

목록 보기
68/69

Chapter#9

HTTP를 기본으로 하는 프로토콜

시대를 거치며 웹의 용도는 상당히 커지고 많이 변했다. 이에 따라 요구하는 기능이 많아졌다. HTTP의 기능이 부족하다고 한다면 그걸 보완하는 새로운 프로토콜을 만들 수도 있겠지만, 이미 웹 브라우저가 널리 퍼졌기에 HTTP라는 프로토콜을 무시할 수 없게되었다. 그래서 HTTP를 기반으로 해서 여기에 추가하는 형태로 새로운 프로토콜이 구현되었다.

HTTP의 병목 현상을 해소하는 SPDY

Google이 발표한 SPDY는 HTTP의 병목 현상을 해소하고 웹 페이지 로딩 시간을 단축한다는 목표로 개발되고 있다.

  • HTTP의 병목 현상
    페이스북, 트위터 등 SNS는 수백만, 수처만 명의 유저가 사용하기에 단시간에 대량의 갱신 정보가 발생한다. 이렇게 갱신된 정보를 가능한 빨리 실시간으로 표시하기 위해서는 서버상의 정보가 갱신되었을 때, 클라이언트의 화면에 반영할 필요가 있다.

    HTTP에서는 이 처리르 제대로 할 수 없다. HTTP 에서는 서버의 정보가 갱신되었는지 아닌지 알기 위해 클라이언트가 항상 서버 측에 확인하러 가야한다. 만약 여기서 서버 상의 정보가 갱신되지 않았다면 불필요한 통신이 발생한 것이다. 

    1. Ajax에 의한 해결 방법
Ajax(Asynchronous JavaScript + XML)은 JavaScript나 DOM 조작 등을 활용하는 방식으로, 웹 페이지의 일부분만 고쳐쓸 수 있는 비동기 통신 방법이다. 
페이지의 일부분만 갱신되기 때문에 리스폰스로 전송되는 데이터 양은 줄어든다는 장점.
Ajax의 핵심 기술은 API로 JavaScript 등의 스크립트 언어로 서버와 HTTP 통신을 할 수 있다. -> 실시간으로 서버에서 정보를 취득하려고 하면 대량의 리퀘스트가 발생한다는 문제가 있음.

2. Comet에 의한 해결 방법
Comet은 서버 측의 콘텐츠에 갱신이 있었을 경우, 클라이언트로부터 리퀘스트를 기다리지 않고 클라이언트에 보내기 위한 방법이다. 
Comet에서는 리퀘스트가 오면 리스폰스를 보류 상태로 해 두고, 서버의 콘텐츠가 갱신되었을 때 리스폰스를 반환한다. 
이것에 의해 서버에서 갱신된 콘텐츠가 있다면 바로 클라이언트에 반영할 수 있다. -> 콘텐츠를 실시간으로 갱신할 수는 있지만, 리스폰스를 보류하기 위해 커넥션을 유지하는 시간이 길어진다.
여기서 커넥션을 유지하는 동안은 리소스를 소비한다.

  • SPDY의 목표
    Ajax, Comet 등 사용성을 쾌적하게 하는 여러 가지 기술이 등장하여 개선이 되었지만, HTTP라는 프로토콜의 제약은 없앨 수 없다. 근본적인 개선을 위해서는 프로토콜 레벨에서의 개선이 필요하게 된다.
    -> SPDY의 설계와 기능
    TCP/IP의 애플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작. 또한, 보안을 위해서 표준으로 SSL을 사용하도록 되어있다. SPDY가 세션 계층으로서 그 사이에 들어감으로써 데이터의 흐름을 제어한다. 

    - 다중화 스트림
	단일 TCP접속을 통해서 복수의 HTTP 리퀘스트를 무제한으로 처리할 수 있다. -> TCP의 효율이 높아진다.
- 리퀘스트의 우선 순위 부여
	무제한으로 리퀘스트를 병렬 처리할 수 있지만, 각 리퀘스트에 우선순위를 할당할 수 있어서, 복수의 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상을 해결할 수 있다.
- HTTP 헤더 압축
	리퀘스트와 리스폰스의 HTTP 헤더를 압축한다. 이로 인해 보다 적은 패킷 수와 송신 바이트 수로 통신이 가능하다.
- 서버 푸시 기능
	서버에서 클라이언트로 데이터를 푸쉬하는 서버 푸시 기능을 지원. 서버 측은 클라이언트 측에서 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다.
- 서버 힌트 기능
	서버가 클라이언트에게 리퀘스트 해야 할 리소스를 제안할 수 있다. 클라이언트가 자원을 발견하기 전에 리소스의 존재를 알 수 있기 때문에, 이미 캐시를 가지고 있는 상태라면 불필요한 리퀘스트를 보내지 않아도 된다.

브라우저에서 양뱡향 통신을 하는 WebSocket

Ajax와 Comet을 사용한 통신은 웹 브라우징을 고속화하지만 HTTP라는 프로토콜을 사용하고 있는 이상, 병목 현상을 해결할 수 없다. WebSocket은 새로운 프로토콜과 API에 의해 이 문제를 해결하기 위한 기술이다.
-> WebSocket의 설계와 기능
웹 브라우저와 웹 서버를 위한 양방향 통신 규격으로 WebSocket 프로토콜을 IETF가 책정하고 WebSocket API를 W3C가 책정하고 있다. 주로 Ajax나 Comet에서 사용하는 XMLHttpRequest의 결점을 해결하기 위한 기술이다.
-> WebSocket 프로토콜
웹 서버와 클라이언트가 한번 접속을 확립하면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON이나 XML, HTML이나 이미지 등 임의 형식의 데이터를 보내게 된다. -> 서버와 클라이언트 어느 쪽에서도 송신을 할 수 있게 된다.
-> WebSocket의 주요 특징

  • 서버 푸시 기능
    서버에서 클라이언트에 데이터를 푸시하는 서버 푸시 기능 제공. 서버는 클라이언트의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다.
  • 통신량의 삭감
    접속을 한번 확립하면 접속을 유지하려고 한다. HTTP에 비해서 자주 접속을 하는 오버헤드가 적어지고, 헤더의 사이즈도 작기 때문에 통신량을 줄 일 수 있다. -> 핸드쉐이크 절차를 밟을 필요가 있다.
  • 핸드쉐이크/리퀘스트
    HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 실시한다.
    GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dhHADMEKIidFMekEighq==
Origin: http://example.com
Sec-WebSocket-Protocol: chat. superchat
Sec-WebSocket-Version: 13
    Sec-WebSocket-Key 에는 핸드쉐이크에 필요한 키가 저장. Set-WebSocket-Protocol에 사용하는 서브 프로토콜이 저장.
    서브 프로토콜은 WebSocket 프로토콜에 의한 커넥션을 여러 개로 구분하고 싶을 때 이름을 붙여 정의한다.
  • 핸드쉐이크/리스폰스
    HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3DeknfK3kkeiqwekdnkf=
Sec-WebSocket-Protocol: chat
    Sec-WebSocket-Accept는 Sec-WebSocket-Key의 값에서 생성된 값이 저장. 핸드쉐이크에 의해 WebSocket 커넥션이 확립된 후에는 HTTP가 아닌, WebSocket 독자적인 데이터 프레임을 이용해 통신.

HTTP/2.0

HTTP/1.1의 차기버전

  • 특징
    기존에 Plain Text(평문)를 사용하고, 개행으로 구별되던 HTTP/1.x 프로토콜과 달리, 2.0에서는 바이너리 포멧으로 인코딩 된 Message, Frame으로 구성된다.

웹 서버 상의 파일을 관리하는 WebDAV

Web-based Distributed Authoring and Versioning은 웹 서버의 콘텐츠에 대해서, 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1를 확장한 프로토콜로 RFC4918로서 정의되어 있다.
파일 작성, 삭제 등 기본 기능 외 파일 작성자 등의 관리, 잠금, 갱신 정보 관리 기능 등 준비되어 있다.

  • HTTP/1.1을 확장한 WebDAV
    추가한 개념
    -> 컬렉션 : 여러 개의 리소스를 한꺼번에 관리하기 위한 개념. 각종 조작은 컬렉션 단위로 가능.
    -> 리소스 : 파일이나 컬렉션을 칭함
    -> 프로퍼티 : 리소스의 프로퍼티를 정의한 것
    -> 잠금 : 파일을 편집할 수 없는 상태로 한다.
    추가된 메소드, 상태 코드
    -> PROPFIND : 프로퍼티 취득
    -> PROPPATCH : 프로퍼티 변경
    -> MKCOL : 컬렉션 작성
    -> COPY : 리소스 및 프로퍼티 복제
    -> MOVE : 리소스 이동
    -> LOCK : 리소스 잠금
    -> UNLOCK : 리소스 잠금 해제
    상태코드 확장
    -> 102 Processing : 정상 리퀘스트 수신, 아직 처리중
    -> 207 Multi-Status : 복수의 스테이터스 가지고 있음
    -> 422 Unprocessable Entity : 서식은 올바르나 내용이 틀림
    -> 423 Locked : 리소스 잠겨있음
    -> 424 Failed Dependency : 어떤 리퀘스트와 관련 리퀘스트가 실패했기 때문에 의존 관계 유지 X
    -> 507 Insufficient Storage : 기억 영역 부족
profile
haechi
공부중인 것들 기록
이전 포스트

Http&Network Basic - 7

다음 포스트

Http&Network Basic - 9

0개의 댓글

관련 채용 정보