HTTP / 2는 웹 소켓을 더 이상 사용하지 않습니까?

HTTP / 2는 웹 소켓을 더 이상 사용하지 않습니까?

---

HTTP / 2 프로토콜에 대해 배우고 있습니다. 작은 메시지 프레임이있는 이진 프로토콜입니다. 단일 TCP 연결을 통한 스트림 멀티플렉싱이 가능합니다. 개념적으로 WebSockets와 매우 유사합니다.

더 이상 사용되지 않는 웹 소켓을 헤더가없는 HTTP / 2 요청 및 서버 시작 푸시 메시지로 대체 할 계획이 있습니까? 아니면 WebSocket이 HTTP / 2를 보완합니까?

---

내가 이해 한 바에 따르면 HTTP / 2는 웹 소켓을 대체하는 것이 아니라 SPDY 프로토콜을 표준화하는 것입니다.

HTTP / 2에서는 server-push가 뒤에서 사용되어 브라우저에서 클라이언트의 리소스로드를 향상시킵니다. 개발자는 개발 중에 실제로 신경 쓰지 않습니다. 그러나 Websocket을 사용하면 개발자는 고유 한 전이중 연결로 메시지를 사용하고 푸시 할 수있는 API를 사용할 수 있습니다.

이것들은 같은 것이 아니며 서로 보완해야합니다.

---

HTTP / 2 spec 읽기를 마친 후에 는 HTTP / 2가 대부분의 사용 사례에서 더 이상 사용되지 않는 웹 소켓을 사용한다고 생각합니다.

PUSH_PROMISE(구체적으로 서버 푸시라고 함)는 여기서 문제가되지 않습니다. 그것은 단지 성능 최적화 일뿐입니다.

브라우저에서 웹 소켓의 주요 사용 사례는 양방향 데이터 스트리밍을 가능하게하는 것입니다. 그래서 OP의 질문은 HTTP / 2가 브라우저에서 양방향 스트리밍을 활성화하는 데 더 나은 작업인지 여부가된다고 생각합니다. 그렇습니다.

우선, 그것은 이다 양방향 디. 스트림 섹션 소개를 읽으십시오 .

"스트림"은 HTTP / 2 연결 내에서 클라이언트와 서버간에 교환되는 독립적 인 양방향 시퀀스 프레임입니다. 스트림에는 몇 가지 중요한 특성이 있습니다.

단일 HTTP / 2 연결은 여러 스트림에서 엔드 포인트 인터리빙 프레임을 사용하여 동시에 열려있는 여러 스트림을 포함 할 수 있습니다.

스트림은 일방적으로 설정 및 사용되거나 클라이언트 또는 서버가 공유 할 수 있습니다.

스트림은 양쪽 끝점으로 닫을 수 있습니다.

같은 제품 이 (다른 답변에 연결)은 HTTP / 2의 이러한 측면에 대해 잘못이다. 그들은 그것이 bidi가 아니라고 말합니다. HTTP / 2에서는 불가능한 일이 있습니다. 연결이 열리면 서버는 일반 스트림을 시작할 수없고 푸시 스트림 만 시작할 수 있습니다. 그러나 클라이언트가 요청을 전송하여 스트림을 열면 양측은 언제든지 완전한 소켓으로 영구 소켓을 통해 DATA 프레임을 전송할 수 있습니다.

이는 웹 소켓과 크게 다르지 않습니다. 서버가 데이터를 전송하기 전에 클라이언트가 웹 소켓 업그레이드 요청을 시작해야합니다.

가장 큰 차이점은 웹 소켓과 달리 HTTP / 2는 자체 멀티플렉싱 의미를 정의한다는 것입니다. 즉, 스트림이 식별자를 얻는 방법과 프레임이 스트림의 ID를 전달하는 방법입니다. HTTP / 2는 또한 스트림 우선 순위 지정을위한 흐름 제어 시맨틱을 정의합니다. 이것은 대부분의 실제 bidi 응용 프로그램에서 중요합니다.

(이 잘못된 기사는 Websocket 표준에 멀티플렉싱이 있다고 말합니다. 아니요, 그렇지 않습니다. 실제로 찾기가 어렵지 않습니다. Websocket RFC 6455를 열고 ⌘-F를 누르고 "multiplex"를 입력하십시오.

프로토콜은 확장 가능하도록 고안되었습니다. 향후 버전에서는 멀티플렉싱과 같은 추가 개념이 도입 될 수 있습니다.

Websocket 멀티플렉싱을위한 2013 초안 확장이 있음 을 알 수 있습니다. 그러나 어떤 브라우저가 해당 브라우저를 지원하는지 모르겠습니다. 해당 확장의 뒷면에 SPA 웹 응용 프로그램을 만들려고하지 않습니다. 특히 HTTP / 2가 지원되면 지원이 도착하지 않을 수 있습니다.

멀티플렉싱은 반응 형으로 업데이트되는 단일 페이지 앱에 전원을 공급하기 위해 bidi 용 웹 소켓을 열 때마다 일반적으로 수행해야하는 종류입니다. HTTP / 2 사양에있어서 다행입니다.

HTTP / 2가 무엇을 할 수 있는지 알고 싶다면 gRPC를보십시오. gRPC는 HTTP / 2에서 구현됩니다. gRPC가 제공하는 반이중 및 전이중 스트리밍 옵션을 구체적으로 살펴보십시오. (gRPC는 현재 브라우저에서 작동하지 않지만 실제로 브라우저는 (1) HTTP / 2 프레임을 클라이언트 자바 스크립트에 노출하지 않으며 (2) 일반적으로 트레일러를 지원하지 않기 때문에 사용됩니다. gRPC 사양)

웹 소켓은 여전히 ​​어디에 있습니까? 필요하지 않은 경우 어떤 여분의 비트를 HTTP / 2 사양 아웃 (그것은 거대한, 복잡한 사양이다), 어쩌면 WebSocket을 더 있음. 구현의 어려움에 대한 우리의 손을 흔들며, 나는 웹 소켓 프로토콜을 준수하는 것이 항상 HTTP / 2보다 계산 비용이 적게들 것이라고 확신합니다-HTTP / 2는 더 많은 일을해야합니다.

프레임 크기는 매우 비슷합니다. 웹 소켓 프레임은 HTTP / 2의 고정 9에 비해 프레임 당 2-14 바이트의 오버 헤드가 약간 작습니다. 웹 소켓은 가변 길이 헤더를 선택했기 때문에 더 큰 프레임을 인코딩 할 수 있습니다 (프레임 당 최대 2 ^ 64-1 비트) 프레임 당 HTTP / 2 2 ^ 24-1 비트). 따라서 비디오 프레임과 같은 의식을하지 않고 뚱뚱한 것을 빨아들이는 소켓이 필요한 경우 웹 소켓이 여전히 합리적 일 수 있습니다. 대부분의 유스 케이스, 특히 웹 페이지와 관련된 것들에서 HTTP / 2는 앞으로 나아갈 것 같습니다.

---

나는 Nay라고 말합니다 (Websockets는 더 이상 사용되지 않습니다).

가장 일반적으로 무시되는 문제는 HTTP / 2 푸시가 적용되지 않으며 프록시, 라우터, 기타 중개자 또는 브라우저에 의해 무시 될 수 있다는 것 입니다.

즉 (HTTP2 초안에서) :

중개자는 서버에서 푸시를 수신하고 클라이언트로 푸시하지 않도록 선택할 수 있습니다. 다시 말해, 푸시 된 정보를 사용하는 방법은 해당 중개자에게 달려 있습니다. 마찬가지로 중개자는 서버에 의한 조치없이 클라이언트에 추가 푸시를 수행 할 수 있습니다.

또한 HTTP / 2 연결은 잠시 후에 닫힙니다.

표준에 따르면 다음과 같습니다.

HTTP / 2 연결은 영구적입니다. 최상의 성능을 위해서는 클라이언트가 서버와의 추가 통신이 필요하지 않다고 판단 될 때 (예 : 사용자가 특정 웹 페이지에서 다른 곳으로 이동할 때) 또는 서버가 연결을 닫을 때까지 연결을 닫지 않을 것으로 예상됩니다.

그러나...

서버는 가능한 한 오랫동안 열린 연결을 유지하는 것이 좋지만 필요한 경우 유휴 연결을 종료 할 수 있습니다. 어느 엔드 포인트가 전송 계층 TCP 연결을 닫으려고 선택하면, 종단 엔드 포인트는 먼저 GOAWAY (섹션 6.8) 프레임을 전송하여 두 엔드 포인트가 이전에 전송 된 프레임이 처리되었는지 여부를 확인하고 필요한 나머지 작업을 정상적으로 완료하거나 종료 할 수 있도록해야합니다.

동일한 연결이 컨텐츠가 열려있는 동안 컨텐츠를 푸시 할 수 있고 HTTP / 2가 HTTP / 1.1의 'keep-alive'에 의해 발생한 일부 성능 문제를 해결하더라도 HTTP / 2 연결이 무기한으로 열려 있지 않습니다. .

웹 페이지가 일단 닫힌 후에는 HTTP / 2 연결을 다시 시작할 수 없습니다.

편집 (2017 년, 2 년 후)

HTTP / 2를 구현하면 여러 개의 브라우저 탭 / 윈도우가 단일 HTTP / 2 연결을 공유한다는 것을 push알 수 있습니다. 즉, 어떤 탭 / 창이 속하는지 알 수 없으므로 push웹 소켓을 대체 할 필요가 없습니다.

---

내 대답은 아니오 야. 둘 사이의 목표는 매우 다릅니다. HTTP / 2를 통한 WebSocket 용 RFC도있어 단일 HTTP / 2 TCP 파이프를 통해 여러 개의 WebSocket을 연결할 수 있습니다.

HTTP over WS / 2는 새로운 연결을 여는 데 걸리는 시간을 줄이고 소켓, 소프트 IRQ 및 버퍼를 추가하지 않고도 더 많은 통신 채널을 허용함으로써 자원 절약 역할을합니다.

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

---

이 InfoQ 기사 에서 인용하자면 다음과 같습니다 .

우리가 위에서 본 것처럼 HTTP / 2는 서버 푸시를 서버가 클라이언트 캐시에 능동적으로 보낼 수있게하는 서버 푸시를 도입했습니다. 그러나 데이터를 클라이언트 응용 프로그램 자체로 푸시 할 수는 없습니다. 서버 푸시는 브라우저에 의해서만 처리되며 애플리케이션 코드에 팝업되지 않으므로 애플리케이션이 해당 이벤트에 대한 알림을받는 API가 없습니다.

따라서 HTTP2 푸시는 실제로 브라우저와 서버 사이의 무언가이며 웹 소켓은 실제로 실시간 데이터 전송을 위해 클라이언트 (브라우저에서 실행되는 경우 자바 스크립트)와 응용 프로그램 코드 (서버에서 실행되는) 모두에서 사용할 수있는 API를 노출합니다.

---

메시지 교환 및 간단한 스트리밍 (오디오, 비디오 스트리밍 아님)은 Http / 2 멀티플렉싱 및 WebSocket을 통해 수행 할 수 있습니다. 따라서 약간의 중복이 있지만 WebSockets는 프로토콜, 많은 프레임 워크 / API 및 헤더 오버 헤드가 적습니다. 여기 주제에 대한 좋은 기사가 있습니다.

---

HTTP / 2에는 WebSocket 구현이 있습니다. https://tools.ietf.org/html/rfc8441

참고 URL : https://stackoverflow.com/questions/28582935/does-http-2-make-websockets-obsolete