9장 HTTP에 기능을 추가한 프로토콜
9.1 HTTP를 기본으로 하는 프로토콜
HTTP의 규격이 만들어졌을 때는 주로 HTML을 주고 받는 용도로 생각했기 때문에 스펙이 간단한 편이었지만, 최근에 용도가 달라지면서 새로운 기능들이 필요해졌다.
9.2 HTTP의 병목 현상을 해소하는 SPDY
Google은 2010년에 HTTP의 병목 현상을 해소하고 웹 페이지의 로딩 시간을 50% 단축하는 목표를 세운 SPDY가 있었다. (결과적으로 SPDY와는 폐기되었고 HTTP/2를 지원하는 것으로 결정했다)
9.2.1 HTTP의 병목 현상
트위터같은 사용자가 많은 실시간 서비스를 구현하기 위해서는 HTTP 사양은 한계가 있었다.
- 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.
- 리퀘스트는 클라이언트에서만 시작할 수 있다.
- 리퀘스트/리스폰스 헤더를 압축하지 않은 체로 보낸다.
Ajax에 의한 해결 방법
웹페이지의 일부만 갱신할 수 있다.
XMLHttpRequest라는 API로 HTTP 통신을 한다.
HTTP 프로토콜의 문제 자체를 해결하지는 못한다.
Comet에 의한 해결 방법
리퀘스트가 오면 리스폰스를 보류 상태로 해두고 서버의 콘텐츠가 갱신되었을 때 리스폰스를 반환한다.
커넥션을 길게 유지해야 하는 문제가 있다.
HTTP 프로토콜의 문제 자체를 해결하지는 못한다.
SPDY의 목표
프로토콜 레벨에서의 개선이 필요하다.
9.2.2 SPDY 설계와 기능
TCP/IP의 어플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다.
보안을 위해서 표준으로 SSL을 사용한다.
다중화 스트림
단일 TCP 접속을 통해서 복수의 HTTP 리퀘스트를 무한으로 처리할 수 있다.
리퀘스트의 우선 순위 부여
각 리퀘스트에 우선 순위를 할당할 수 있다.
복수의 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상을 해결하기 위함이다.
HTTP 헤더 압축
리퀘스트와 리스폰스의 HTTP 헤더를 압축한다.
서버 푸시 기능
서버에서 클라이언트로 데이터를 푸쉬할 수 있다.
서버 힌트 기능
서버가 클라이언트에게 리퀘스트 해야 할 리소스를 제안할 수 있다.
9.2.3 SPDY는 웹의 병목 현상을 해결하는가?
웹 브라우저와 웹 서버는 SPDY에 따로 대응해야 한다.
SPDY는 HTTP의 병목 현상을 해결하는 좋은 기술이지만, 대부분 웹 사이트의 문제는 HTTP의 병목 현상 때문만은 아니다. (잘못 작성된 코드, 쿼리 성능 저하등)
9.3 브라우저에서 양방향 통신을 하는 WebSocket
9.3.1 WebSocket의 설계와 기능
웹 브라우저와 웹 서버를 위한 양방향 통신 규격이다.
9.3.2 WebSocket 프로토콜
웹 서버와 클라이언트가 한번 접속을 확립하면 그 이후의 통신을 모두 전용 프로토콜로 하는 방식이다.
서버 푸시 기능
서버에서 클라이언트에 데이터를 푸시하는 서버 푸시 기능을 제공한다.
통신량의 삭감
접속을 한번 확립하면 계속 유지하려고 한다.
WebSocket으로 통신을 하려면 한번 HTTP에 접속을 확립하고, WebSocket에 의해 통신을 하기 위해서 핸드쉐이크 절차가 필요하다.
핸드쉐이크/리퀘스트
WebSocket으로 통신을 하려면 HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 실시한다.
핸드쉐이크/리스폰스
앞선 리퀘스트에 대한 리스폰스는 상태 코드 101 Switching Protocols로 반환된다.
WebSocket 커넥션이 확립된 후에는 HTTP가 아닌 WebSocket 독자적인 데이터 프레임을 이용해 통신한다.
WebSocket API
JavaScript에서 WebSocket 프로토콜을 사용한 양방향 통신을 하기 위해서는 W3C에서 제공되고 있는 WebSocket 인터페이스를 사용한다.
9.4 등장이 기다려지는 HTTP/2.0
HTTP/2.0의 특징
웹을 이용할 때 체감 속도의 개선을 목표로 하고 있다.
HTTP/2.0에서 논의되는 7가지 기술
- 다중화
- TLS의 의무화
- 네고시에이션
- 클라이언트 풀/서버 푸시
- 흐름 제어
- WebSocket
9.5 웹 서버 상의 파일을 관리하는 WebDAV
웹 서버의 콘텐츠에 대해서 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1을 확장한 프로토콜이다.
파일 작성이나 삭제등 기본적인 기능 외에 파일 작성자 등의 관리나 잠금 기능, 리비전 기능 등이 있다.
9.5.1 HTTP/1.1을 확장한 WebDAV
컬렉션: 여러 개의 리소스를 한꺼번에 관리하기 위한 개념
자원(Resource): 파일이나 컬렉션을 리소스라고 부른다.
프로퍼티: 리소스의 프로퍼티를 정의한 것, 이름=값 형식
잠금(Lock): 파일을 편집할 수 없는 상태로 한다.
9.5.2 WebDAV에서 추가된 메소드와 상태 코드
PROPFIND: 프로퍼티 취득
…
'TIL > 개발' 카테고리의 다른 글
누군가 나를 멘토라고 부르기 시작했다 (1) | 2024.01.07 |
---|---|
그림으로 배우는 Http & Network Basic - 10장 (1) | 2024.01.06 |
그림으로 배우는 Http & Network Basic - 8장 (1) | 2023.12.28 |
그림으로 배우는 Http & Network Basic - 7장 (1) | 2023.12.28 |
그림으로 배우는 Http & Network Basic - 6장 (0) | 2023.12.25 |
9장 HTTP에 기능을 추가한 프로토콜
9.1 HTTP를 기본으로 하는 프로토콜
HTTP의 규격이 만들어졌을 때는 주로 HTML을 주고 받는 용도로 생각했기 때문에 스펙이 간단한 편이었지만, 최근에 용도가 달라지면서 새로운 기능들이 필요해졌다.
9.2 HTTP의 병목 현상을 해소하는 SPDY
Google은 2010년에 HTTP의 병목 현상을 해소하고 웹 페이지의 로딩 시간을 50% 단축하는 목표를 세운 SPDY가 있었다. (결과적으로 SPDY와는 폐기되었고 HTTP/2를 지원하는 것으로 결정했다)
9.2.1 HTTP의 병목 현상
트위터같은 사용자가 많은 실시간 서비스를 구현하기 위해서는 HTTP 사양은 한계가 있었다.
- 1개의 커넥션으로 1개의 리퀘스트만 보낼 수 있다.
- 리퀘스트는 클라이언트에서만 시작할 수 있다.
- 리퀘스트/리스폰스 헤더를 압축하지 않은 체로 보낸다.
Ajax에 의한 해결 방법
웹페이지의 일부만 갱신할 수 있다.
XMLHttpRequest라는 API로 HTTP 통신을 한다.
HTTP 프로토콜의 문제 자체를 해결하지는 못한다.
Comet에 의한 해결 방법
리퀘스트가 오면 리스폰스를 보류 상태로 해두고 서버의 콘텐츠가 갱신되었을 때 리스폰스를 반환한다.
커넥션을 길게 유지해야 하는 문제가 있다.
HTTP 프로토콜의 문제 자체를 해결하지는 못한다.
SPDY의 목표
프로토콜 레벨에서의 개선이 필요하다.
9.2.2 SPDY 설계와 기능
TCP/IP의 어플리케이션 계층과 트랜스포트 계층 사이에 새로운 세션 계층을 추가하는 형태로 동작한다.
보안을 위해서 표준으로 SSL을 사용한다.
다중화 스트림
단일 TCP 접속을 통해서 복수의 HTTP 리퀘스트를 무한으로 처리할 수 있다.
리퀘스트의 우선 순위 부여
각 리퀘스트에 우선 순위를 할당할 수 있다.
복수의 리퀘스트를 보낼 때 대역폭이 좁으면 처리가 늦어지는 현상을 해결하기 위함이다.
HTTP 헤더 압축
리퀘스트와 리스폰스의 HTTP 헤더를 압축한다.
서버 푸시 기능
서버에서 클라이언트로 데이터를 푸쉬할 수 있다.
서버 힌트 기능
서버가 클라이언트에게 리퀘스트 해야 할 리소스를 제안할 수 있다.
9.2.3 SPDY는 웹의 병목 현상을 해결하는가?
웹 브라우저와 웹 서버는 SPDY에 따로 대응해야 한다.
SPDY는 HTTP의 병목 현상을 해결하는 좋은 기술이지만, 대부분 웹 사이트의 문제는 HTTP의 병목 현상 때문만은 아니다. (잘못 작성된 코드, 쿼리 성능 저하등)
9.3 브라우저에서 양방향 통신을 하는 WebSocket
9.3.1 WebSocket의 설계와 기능
웹 브라우저와 웹 서버를 위한 양방향 통신 규격이다.
9.3.2 WebSocket 프로토콜
웹 서버와 클라이언트가 한번 접속을 확립하면 그 이후의 통신을 모두 전용 프로토콜로 하는 방식이다.
서버 푸시 기능
서버에서 클라이언트에 데이터를 푸시하는 서버 푸시 기능을 제공한다.
통신량의 삭감
접속을 한번 확립하면 계속 유지하려고 한다.
WebSocket으로 통신을 하려면 한번 HTTP에 접속을 확립하고, WebSocket에 의해 통신을 하기 위해서 핸드쉐이크 절차가 필요하다.
핸드쉐이크/리퀘스트
WebSocket으로 통신을 하려면 HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 실시한다.
핸드쉐이크/리스폰스
앞선 리퀘스트에 대한 리스폰스는 상태 코드 101 Switching Protocols로 반환된다.
WebSocket 커넥션이 확립된 후에는 HTTP가 아닌 WebSocket 독자적인 데이터 프레임을 이용해 통신한다.
WebSocket API
JavaScript에서 WebSocket 프로토콜을 사용한 양방향 통신을 하기 위해서는 W3C에서 제공되고 있는 WebSocket 인터페이스를 사용한다.
9.4 등장이 기다려지는 HTTP/2.0
HTTP/2.0의 특징
웹을 이용할 때 체감 속도의 개선을 목표로 하고 있다.
HTTP/2.0에서 논의되는 7가지 기술
- 다중화
- TLS의 의무화
- 네고시에이션
- 클라이언트 풀/서버 푸시
- 흐름 제어
- WebSocket
9.5 웹 서버 상의 파일을 관리하는 WebDAV
웹 서버의 콘텐츠에 대해서 직접 파일 복사나 편집 작업 등을 할 수 있는 분산 파일 시스템으로 HTTP/1.1을 확장한 프로토콜이다.
파일 작성이나 삭제등 기본적인 기능 외에 파일 작성자 등의 관리나 잠금 기능, 리비전 기능 등이 있다.
9.5.1 HTTP/1.1을 확장한 WebDAV
컬렉션: 여러 개의 리소스를 한꺼번에 관리하기 위한 개념
자원(Resource): 파일이나 컬렉션을 리소스라고 부른다.
프로퍼티: 리소스의 프로퍼티를 정의한 것, 이름=값 형식
잠금(Lock): 파일을 편집할 수 없는 상태로 한다.
9.5.2 WebDAV에서 추가된 메소드와 상태 코드
PROPFIND: 프로퍼티 취득
…
'TIL > 개발' 카테고리의 다른 글
누군가 나를 멘토라고 부르기 시작했다 (1) | 2024.01.07 |
---|---|
그림으로 배우는 Http & Network Basic - 10장 (1) | 2024.01.06 |
그림으로 배우는 Http & Network Basic - 8장 (1) | 2023.12.28 |
그림으로 배우는 Http & Network Basic - 7장 (1) | 2023.12.28 |
그림으로 배우는 Http & Network Basic - 6장 (0) | 2023.12.25 |