1) WebSockets 프로토콜이 더 좋은 이유는 무엇입니까?
WebSockets는 대기 시간이 짧은 통신, 특히 클라이언트와 서버 메시지의 대기 시간이 짧은 상황에 적합합니다. 서버 대 클라이언트 데이터의 경우 장기간 연결 및 청크 전송을 사용하여 대기 시간을 상당히 줄일 수 있습니다. 그러나 이것은 클라이언트 대 서버 대기 시간에 도움이되지 않으므로 각 클라이언트 대 서버 메시지에 대해 새 연결을 설정해야합니다.
48 바이트 HTTP 핸드 셰이크는 많은 헤더와 쿠키 데이터를 포함하여 요청의 일부로 (양방향으로) 전송되는 데이터가 종종있는 실제 HTTP 브라우저 연결에는 현실적이지 않습니다. 다음은 Chrome 사용에 대한 요청 / 응답의 예입니다.
요청 예 (쿠키 데이터를 포함한 2800 바이트, 쿠키 데이터가없는 490 바이트) :
GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]
응답 예 (355 바이트) :
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip
HTTP와 WebSocket 모두 동일한 크기의 초기 연결 핸드 셰이크를 갖지만 WebSocket 연결을 사용하면 초기 핸드 셰이크가 한 번 수행 된 후 작은 메시지에는 6 바이트의 오버 헤드 (헤더의 경우 2, 마스크 값의 경우 4) 만 있습니다. 지연 시간 오버 헤드는 헤더의 크기가 아니라 해당 헤더를 구문 분석 / 처리 / 저장하는 논리에서 비롯됩니다. 또한 TCP 연결 설정 대기 시간은 각 요청의 크기 또는 처리 시간보다 큰 요인 일 수 있습니다.
2) HTTP 프로토콜을 업데이트하는 대신 왜 구현 되었습니까?
SPDY , HTTP 2.0 및 QUIC 와 같이 더 나은 성능과 낮은 대기 시간을 달성하기 위해 HTTP 프로토콜을 다시 엔지니어링하려는 노력이 있습니다 . 이렇게하면 일반적인 HTTP 요청의 상황이 개선되지만 WebSocket 및 / 또는 WebRTC DataChannel은 여전히 HTTP 프로토콜보다 클라이언트에서 서버로의 데이터 전송에 대한 대기 시간이 낮을 수 있습니다 (또는 WebSocket과 매우 유사한 모드에서 사용됨). 어쨌든).
업데이트 :
웹 프로토콜에 대한 생각을위한 프레임 워크는 다음과 같습니다.
- TCP : 저수준, 양방향, 전이중 및 보장 된 주문 전송 계층. 브라우저 지원 없음 (플러그인 / 플래시 제외)
- HTTP 1.0 : TCP에서 계층화 된 요청-응답 전송 프로토콜. 클라이언트는 하나의 전체 요청을하고 서버는 하나의 전체 응답을 제공 한 다음 연결을 닫습니다. 요청 메소드 (GET, POST, HEAD)는 서버의 자원에 대한 특정 트랜잭션 의미를 갖습니다.
- HTTP 1.1 : HTTP 1.0의 요청-응답 특성을 유지하지만 여러 개의 전체 요청 / 전체 응답 (요청 당 하나의 응답)에 대해 연결을 열어 둘 수 있습니다. 요청 및 응답에 여전히 전체 헤더가 있지만 연결이 재사용되고 닫히지 않습니다. HTTP 1.1은 또한 특정 트랜잭션 의미를 갖는 몇 가지 추가 요청 메소드 (OPTIONS, PUT, DELETE, TRACE, CONNECT)를 추가했습니다. 에서 언급 그러나, 소개 는 HTTP 2.0 제안서 초안, HTTP이 크게 브라우저와 서버 사이의 대기 시간을 해결하기 위해 HTTP 1.1의 유틸리티를 제한하므로 1.1 파이프 라인은 널리 배포되지 않습니다.
- 장기 여론 : 서버가 클라이언트 요청에 즉시 응답하지 않거나 헤더로 부분적으로 만 응답하는 HTTP (1.0 또는 1.1)에 대한 "해킹"의 일종. 서버 응답 후 클라이언트는 즉시 HTTP 1.1을 통해 동일한 연결을 사용하여 새 요청을 보냅니다.
- HTTP 스트리밍 : 서버가 단일 클라이언트 요청에 둘 이상의 응답을 보낼 수있는 다양한 기술 (멀티 파트 / 청크 응답). W3C는 이것을 MIME 유형을 사용하여 서버가 보낸 이벤트 로 표준화하고
text/event-stream있습니다. 브라우저 API (WebSocket API와 상당히 유사한)를 EventSource API라고합니다.
- 혜성 / 서버 푸시 : 장기 폴링과 HTTP 스트리밍을 모두 포함하는 포괄적 인 용어입니다. 혜성 라이브러리는 일반적으로 브라우저 간 및 서버 간 지원을 시도하고 최대화하기 위해 여러 가지 기술을 지원합니다.
- WebSockets : HTTP 친화적 업그레이드 핸드 셰이크를 사용하는 전송 계층 내장 TCP. 스트리밍 전송 인 TCP와 달리 WebSockets는 메시지 기반 전송입니다. 메시지는 유선으로 구분되며 응용 프로그램에 전달되기 전에 전체적으로 다시 어셈블됩니다. WebSocket 연결은 양방향, 전이중 및 오래 지속됩니다. 초기 핸드 셰이크 요청 / 응답 후에는 트랜잭션 시맨틱이 없으며 메시지 당 오버 헤드가 거의 없습니다. 클라이언트와 서버는 언제든지 메시지를 보낼 수 있으며 메시지 수신을 비동기 적으로 처리해야합니다.
- SPDY : Google은보다 효율적인 유선 프로토콜을 사용하지만 모든 HTTP 의미 (요청 / 응답, 쿠키, 인코딩)를 유지하면서 HTTP를 확장하기위한 제안을 시작했습니다. SPDY는 길이 프레 픽스가있는 새로운 프레이밍 형식을 도입하고 새로운 프레이밍 레이어에 HTTP 요청 / 응답 쌍을 레이어링하는 방법을 지정합니다. 연결이 설정된 후 헤더를 압축하고 새 헤더를 보낼 수 있습니다. 브라우저와 서버에는 실제 SPDY 구현이 있습니다.
- HTTP 2.0 : SPDY와 비슷한 목표 : HTTP 의미를 유지하면서 HTTP 대기 시간 및 오버 헤드를 줄입니다. 현재 초안은 SPDY에서 파생되었으며 핸드 셰이크 및 프레이밍에 대한 WebSocket 표준과 매우 유사한 업그레이드 핸드 셰이크 및 데이터 프레이밍을 정의합니다. 대체 HTTP 2.0 초안 제안 (httpbis-speed-mobility)은 실제로 전송 계층에 WebSocket을 사용하고 SPDY 멀티플렉싱 및 HTTP 매핑을 WebSocket 확장으로 추가합니다 (WebSocket 확장은 핸드 셰이크 중에 협상됩니다).
- WebRTC / CU-WebRTC : 브라우저 간 피어 투 피어 연결을 허용하기위한 제안. 기본 전송이 TCP가 아닌 SDP / 데이터 그램이므로 평균 및 최대 대기 시간 통신이 더 낮을 수 있습니다. 이를 통해 패킷 / 메시지의 순서가 잘못된 전달을 허용하여 패킷이 손실되어 발생하는 지연 스파이크의 TCP 문제를 피하여 모든 후속 패킷의 전달을 지연시킵니다 (순서 전달 보장).
- QUIC : TCP보다 웹 대기 시간을 줄이는 것을 목표로하는 실험적인 프로토콜입니다. 표면적으로 QUIC는 UDP에 구현 된 TCP + TLS + SPDY와 매우 유사합니다. QUIC는 HTTP / 2에 해당하는 멀티플렉싱 및 흐름 제어, TLS에 해당하는 보안, TCP에 해당하는 연결 의미, 안정성 및 혼잡 제어를 제공합니다. TCP는 운영 체제 커널 및 미들 박스 펌웨어에서 구현되므로 TCP를 크게 변경하는 것은 불가능합니다. 그러나 QUIC는 UDP를 기반으로 구축되므로 이러한 제한이 없습니다. QUIC는 HTTP / 2 시맨틱에 맞게 설계되고 최적화되었습니다.
참고 문헌 :
- HTTP :
- 서버가 보낸 이벤트 :
- 웹 소켓 :
- SPDY :
- HTTP 2.0 :
- WebRTC :
- QUIC :
