Hacker News 의견

• HTTP 스트리밍이 이 패턴을 염두에 두고 설계된 것이 아니라고 생각함. HTTP 스트리밍은 큰 데이터를 조각으로 나누는 용도임. 스트리밍을 pub/sub 메커니즘처럼 사용하면 후회할 수 있음. HTTP 중개자들은 이 트래픽 패턴을 예상하지 않음(NGINX, CloudFlare 등). WiFi 연결이 끊길 때마다 fetch API가 요청 실패로 오류를 발생시킬 것 같음

  • WebSockets가 필요 없는 경우가 많음. 서버 전송 이벤트(SSE)가 더 간단한 해결책임. SSE가 주목받지 못한 것이 아쉬움

• RequestID를 서버에 보내서 요청/응답 주기를 얻는 것은 이상하거나 지나친 것이 아님. 진지한 앱에서는 send(message).then(res => ...) 같은 API를 갖추는 것이 항상 가치 있음

  • 업그레이드 요청은 혼란스러움. 웹소켓 서버가 HTTP 서버 안에 내장되어 통합되지 않는 것이 짜증남
  • 웹소켓 요청에서 headers['authorization']를 읽는 미들웨어를 재사용하는 대신, 요청 헤더인 척하는 connectionParams 객체를 접근해야 함
  • 웹소켓 브라우저 API가 EventSource보다 다루기 좋음

• 비디오 스트리밍은 클라이언트가 범위로 청크를 요청하며, 단일 HTTP 연결이 아님

• 이벤트킷 대신 SSE를 사용하는 것이 좋음

• POC에서 전통적인 HTTP 폼 제출을 사용할 예정임. 다른 것이 필요하지 않음

  • 아키텍트는 웹소켓이 필요하다고 주장함
  • POC에는 XHR이나 웹소켓이 필요하지 않음. 순차적인 구매 흐름임
  • 결국 불필요한 웹소켓을 제공하게 됨

• HTTP2의 문제는 서버 푸시가 기존 프로토콜 위에 추가된 것임. HTTP는 리소스 전송 프로토콜로, 불필요한 오버헤드를 추가함. HTTP2의 주요 목적은 서버가 파일/리소스를 클라이언트에 미리 푸시하여 왕복 지연을 줄이는 것임

  • WebSockets는 양방향 통신을 위해 설계된 더 간단한 프로토콜임. 단일 연결로 데이터 흐름을 제어하기 쉬움. 상태 관리와 연결 손실 복구가 용이함. 인증 및 접근 제어가 단순해짐

• WebSockets는 스트림으로 보내는 것이 아니라 데이터그램(패킷)으로 보내는 것임. JavaScript 라이브러리의 WebSockets API는 백프레셔를 처리할 수 없고, 모든 오류를 처리할 수 없음. TCP 스트림으로 사용하려면 주의가 필요함

• WebSockets를 프로덕션에 배포한 후 후회함. NGINX가 4/8시간 후 연결을 종료하고, 브라우저가 수면 후 재연결하지 않는 등의 문제가 있었음. 가능하면 WebSockets와 장기 연결을 피해야 함

• WebSockets에 대한 이상적인 인식이 있음. 스트리밍/실시간 사용 사례에 WebSockets를 사용하려는 경향이 있음. WebSockets는 HTTP 도구의 단순함과 이점을 잃음. 스트리밍 서버 변경의 해결책은 h2/h3와 SSE임. 클라이언트당 최대 0.5req/s로 배치할 수 있는 경우 WebSockets가 필요하지 않음

• HTTP 스트리밍에 관심 있는 사람들은 Braid-HTTP를 확인해야 함. HTTP에 이벤트 스트리밍을 우아하게 확장하여 강력한 상태 동기화 프로토콜을 제공함