웹 소켓

WebSocket
웹 소켓
Websocket connection.png
WebSocket을 사용한 접속을 나타내는 그림
국제 표준RFC 6455
개발자IETF
산업컴퓨터 공학
커넥터 타입TCP
웹 사이트공식 웹사이트

WebSocket은 단일 TCP 연결을 통해 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜입니다.WebSocket 프로토콜은 2011년에 IETF에 의해 RFC 6455로 표준화되었습니다.웹 응용 프로그램이 이 프로토콜을 사용할 수 있도록 허용하는 현재 API 사양을 [1]웹소켓이라고 합니다.WHATWG에 의해 유지되는 생활표준으로 W3C의 [2]WebSocket API를 계승하고 있습니다.

Web Socket은 HTTP와 다릅니다.두 프로토콜 모두 OSI 모델의 계층 7에 위치하며 계층 4의 TCP에 의존합니다.서로 다르지만 RFC 6455는 WebSocket이 HTTP 프록시 및 중간자를 지원할 뿐만 아니라 HTTP 포트 443 및 80을 통해 작동하도록 설계되어 있으므로 HTTP와 호환성이 있다고 기술하고 있습니다.호환성을 확보하기 위해 WebSocket 핸드쉐이크는 HTTP Upgrade[3] 헤더를 사용하여 HTTP 프로토콜에서 WebSocket 프로토콜로 변경합니다.

WebSocket 프로토콜은 HTTP 폴링과 같은 반이중 방식보다 오버헤드가 낮은 웹 브라우저(또는 다른 클라이언트 애플리케이션)와 웹 서버 간의 상호작용을 가능하게 하여 서버 간의 실시간 데이터 전송을 용이하게 합니다.이것은, 클라이언트가 최초로 요구하지 않고, 서버에 컨텐츠를 클라이언트에 송신하는 표준화된 방법을 제공해, 접속을 열어 둔 채로 메세지를 주고 받을 수 있도록 하는 것으로 실현됩니다.이렇게 하면 클라이언트와 서버 간에 양방향 대화가 진행됩니다.통신은 보통 TCP 포트 번호443(시큐어하지 않은 접속의 경우는 80)을 통해 이루어지며 방화벽을 사용하여 웹 이외의 인터넷 접속을 차단하는 환경에서는 편리합니다.Comet 또는 Adobe Flash [4]Player와 같은 미봉책 기술을 사용하여 비표준적인 방법으로 유사한 양방향 브라우저-서버 통신이 실현되었습니다.

Google Chrome, Firefox, Microsoft Edge, Internet Explorer, Safari 및 [5]Opera를 포함한 대부분의 브라우저는 프로토콜을 지원합니다.

HTTP와 달리 WebSocket은 전이중 [6][7]통신을 제공합니다.또한 WebSocket은 TCP 상에서 메시지 스트림을 가능하게 합니다.TCP 만으로는 메시지의 고유한 개념이 없는 바이트 스트림을 처리합니다.WebSocket 이전에는 Comet 채널을 사용하여 포트 80 전이중 통신이 가능했지만 Comet의 실장은 중요하지 않으며 TCP 핸드쉐이크 및 HTTP 헤더 오버헤드로 인해 작은 메시지에는 비효율적입니다.WebSocket 프로토콜은 웹의 보안 가정에 영향을 주지 않고 이러한 문제를 해결하는 것을 목표로 합니다.

WebSocket 프로토콜 사양은 다음을 정의합니다.ws(Web Socket) 및wss(WebSocket Secure)는 암호화되지 않은 연결과 암호화된 연결에 각각 사용되는2개의 새로운 Uniform Resource[8] Identifier(URI; 유니폼자원 식별자) 스킴으로 사용됩니다.스킴명과 fragment(즉, 스킴명 및 fragment)를 제외합니다.#는 지원되지 않습니다). 나머지 URI 컴포넌트는 URI 범용 [9]구문을 사용하도록 정의되어 있습니다.

개발자는 브라우저 개발자 도구를 사용하여 WebSocket 핸드쉐이크 및 WebSocket [10]프레임을 검사할 수 있습니다.

역사

WebSocket은 HTML5 사양에서 TCP 기반 소켓 [11]API의 플레이스 홀더로서 TCP Connection으로 처음 언급되었습니다.2008년 6월, Michael Carter가 일련의 논의를 주도하여 WebSocket으로 [12]알려진 프로토콜의 첫 버전을 만들었습니다.

"WebSocket"이라는 이름은 얼마 지나지 않아 #whatwg IRC 채팅 [13]룸에서 공동 작업을 통해 Ian Hickson과 Michael Carter에 의해 만들어졌으며, 이후 Ian Hickson이 HTML5 사양에 포함시키기 위해 작성되었습니다.2009년 12월,[14] Google Chrome 4는 WebSocket이 기본적으로 활성화되어 있는 상태에서 이 표준을 완전히 지원하는 최초의 브라우저가 되었습니다.WebSocket 프로토콜의 개발은 이후 2010년 2월에 W3C 및 WHATWG 그룹에서 IETF로 옮겨졌고 Ian Hickson에 [15]의해 두 가지 리비전을 위해 작성되었습니다.

프로토콜이 출하되어 여러 브라우저에서 기본적으로 활성화된 후, RFC 6455는 2011년 12월에 Ian Fette에 의해 최종 결정되었습니다.

RFC 7692에서는 메시지 단위로 DEFLATE 알고리즘을 사용하여 WebSocket에 압축 확장을 도입했습니다.

브라우저 구현

WebSocket 프로토콜의 보안 버전은 Firefox [16]6, Safari 6, Google Chrome 14,[17] Opera 12.10 및 Internet Explorer [18]10에 구현되어 있습니다.상세 프로토콜 테스트 스위트[19] 보고서에는 특정 프로토콜 측면에 대한 브라우저의 호환성이 나열됩니다.

Opera 11과 Safari 5에서는 보안성이 낮은 오래된 버전의 프로토콜이 구현되었으며 iOS 4.[20]2에서는 모바일 버전의 Safari가 구현되었습니다.OS7의 BlackBerry Browser는 WebSockets를 [21]구현합니다.취약성으로 인해 Firefox 4 및 5 [22]및 Opera [23]11에서는 사용하지 않도록 설정되었습니다.

구현현황
프로토콜, 버전 드래프트 날짜 인터넷 익스플로러 파이어폭스[24](PC) 파이어폭스(Android) 크롬(PC, 모바일) Safari (Mac, iOS) Opera (PC, 모바일) 안드로이드 브라우저
힉시-75 2010년 2월 4일 4 5.0.0
힉시-76
hybi-00 		2010년 5월 6일
2010년 5월 23일		 4.0(디세이블) 6 5.0.1 11.00(디세이블)
hybi-07, v7 2011년 4월 22일 6개[25][a]
hybi-10, v8 2011년 7월 11일 7개[27][a] 7 열네[28] 개
RFC 6455, v13 2011년 12월 10개[29] 11 11 열여섯[30] 살 6 12.10[31] 4.4

JavaScript 클라이언트 예시

// wss URI를 매개 변수로 하여 새로운 WebSocket 개체를 만듭니다. 컨스턴트 소켓 = 신규 웹 소켓(wss://game.example.com/ws/updates');  // WebSocket과의 접속이 열렸을 때 기동됩니다. 소켓.오픈 = 기능. () {   set Interval(기능.() {     한다면 (소켓.버퍼링 금액 == 0)       소켓.보내세요(get Update Data(데이터 갱신)());   }, 50); };  // WebSocket을 통해 데이터를 수신할 때 부팅됩니다. 소켓.메시지 = 기능.(이벤트) {   handle Update Data(데이터 갱신)(이벤트.데이터.); };  // WebSocket과의 접속이 닫혀 있을 때 기동됩니다. 소켓.근접한 = 기능.(이벤트) {   온소켓 클로즈(이벤트); };  // 오류로 인해 WebSocket과의 연결이 닫혔을 때 실행됩니다. 소켓.온에러 = 기능.(이벤트) {   온소켓 에러(이벤트); };

웹 서버 구현

Nginx는 2013년부터 WebSockets를 지원하며 버전 1.3.13에서 구현되었으며,[33] 여기에는 WebSocket 애플리케이션의 역방향 프록시 및 로드밸런서 기능도 포함됩니다.

Apache HTTP Server는 2013년 7월부터 WebSockets를 지원하며 버전 2.4.5에서 구현되었습니다.

Internet Information Services는 Windows Server [36]2012와 함께 출시된 버전 8에서 WebSockets에 대한 지원을 추가했습니다.

lighttpd는 버전 1.4.[37]46에서 구현된 2017년부터 WebSockets를 지원해왔다. lighttpd mod_proxy는 WebSocket 애플리케이션의 역방향 프록시 및 로드 밸런서 역할을 할 수 있다.lighttpd mod_wstunnel은 WebSocket 터널을 구축하여 JSON 형식을 포함한 임의의 데이터를 백엔드 응용 프로그램에 전송할 수 있습니다.

Tempesta FW는 [38]2022년부터 HTTP/1.1 및 HTTPS 연결을 위한 WebSockets를 지원합니다.RFC 8441에 의해 HTTP/2를 통한 WebSockets는 개발자들에 의해 충분히 광범위하게 배치되지 않은 것으로 간주되어 구현되지 않았습니다.

프로토콜 핸드쉐이크

WebSocket 접속을 확립하기 위해서 클라이언트는 WebSocket 핸드쉐이크 요구를 송신합니다.이것에 대해서,[39] 서버는 WebSocket 핸드쉐이크 응답을 반환합니다(아래 예 참조).

클라이언트 요구(HTTP와 마찬가지로 각 행은 다음과 같이 끝납니다).\r\n그리고 마지막에는 여분의 공백 줄이 있어야 합니다.) 

얻다 /채팅 HTTP/1.1 주인: server.example.com 개선하다: 웹 소켓 연결: 개선하다 Sec-WebSocket-키: x3JHMbDL1EzLkh9GBHXDw== Sec-WebSocket-프로토콜: 채팅, 슈퍼챗 Sec-WebSocket 버전: 13 기원.: http://example.com

서버 응답:

HTTP/1.1 101 스위칭 프로토콜 개선하다: 웹 소켓 연결: 개선하다 Sec-WebSocket-Accept: HSMC0sMLYUAGmm5OPPG2HaGWk= Sec-WebSocket-프로토콜: 채팅

핸드쉐이크는 HTTP 요청/응답으로 시작되며, 서버가 동일한 포트 상의 HTTP 연결 및 WebSocket 연결을 처리할 수 있습니다.접속이 확립되면 통신은 HTTP 프로토콜에 준거하지 않는 양방향 바이너리 프로토콜로 전환됩니다.

에 더하여Upgrade헤더, 클라이언트는,Sec-WebSocket-Keybase64-module 랜덤바이트를 포함하는 헤더와 서버는 키 해시를 사용하여 응답합니다.Sec-WebSocket-Accept header를 클릭합니다.이는 캐싱 프록시가 이전 WebSocket [40]컨버세이션의 재발송을 방지하는 것을 목적으로 하며 인증, 프라이버시 또는 무결성은 제공하지 않습니다.해시 함수는 고정 문자열을 추가합니다.258EAFA5-E914-47DA-95CA-C5AB0DC85B11(UUID)의 값을 지정합니다.Sec-WebSocket-Key헤더(base64에서 디코딩되지 않음)는 SHA-1 해시 기능을 적용하여 base64를 [41]사용하여 결과를 인코딩합니다.

RFC6455에서는 임의의 16바이트 값(base64 부호화),[42] 즉 base64로 24바이트(마지막 2바이트)로 구성된 난스여야 합니다.==). 일부 완화된 HTTP 서버에서는 보다 짧은 키를 표시할 수 있지만 대부분의 최신 HTTP 서버에서는 "invalid Sec-WebSocket-Key header" 오류와 함께 요청을 거부합니다.

접속이 확립되면 클라이언트와 서버는 WebSocket 데이터 또는 텍스트프레임을 전이중 모드로 송수신 할 수 있습니다.데이터는 최소 프레임에 포함되며 작은 헤더가 [43]그 뒤에 payload가 이어집니다.Web Socket 전송은 「메시지」라고 불리며, 1개의 메시지를 복수의 데이터 프레임으로 분할할 수도 있습니다.이를 통해 초기 데이터를 사용할 수 있지만 메시지의 전체 길이를 알 수 없는 경우 메시지를 전송할 수 있습니다(종료에 도달하여 FIN 비트를 사용하여 커밋될 때까지 데이터 프레임이 하나씩 전송됩니다).프로토콜 확장 기능을 사용하면 여러 스트림을 동시에 다중화하는 데도 사용할 수 있습니다(예를 들어 하나의 큰 [44]페이로드에 소켓을 독점적으로 사용하는 것을 방지하기 위해).

보안에 관한 고려 사항

일반 교차 도메인 HTTP 요청과 달리 WebSocket 요청은 동일한 발신기지 정책에 의해 제한되지 않습니다.따라서 WebSocket 서버는 cookie 또는 HTTP 인증을 사용하여 접속을 인증할 때 발생할 수 있는 사이트 간 WebSocket 하이잭 공격(사이트 간 요청 위조와 유사)을 피하기 위해 "오리진" 헤더를 예상되는 원본과 대조하여 검증해야 합니다.중요한(개인) 데이터가 WebSocket을 [45]통해 전송되는 경우 토큰 또는 이와 유사한 보호 메커니즘을 사용하여 WebSocket 연결을 인증하는 것이 좋습니다.취약성의 실제 예는 2020년에 케이블 혼신의 형태로 발견되었습니다.

프록시 트래버설

WebSocket 프로토콜 클라이언트 구현에서는 대상 호스트 및 포트에 연결할 때 프록시를 사용하도록 사용자 에이전트가 구성되어 있는지 여부를 감지하고, 프록시를 사용할 경우 HTTP CONNECT 메서드를 사용하여 영구 터널을 설정합니다.

WebSocket 프로토콜 자체는 프록시 서버 및 방화벽을 인식하지 못하지만 HTTP 호환 핸드쉐이크를 지원하므로 HTTP 서버는 기본 HTTP 및 HTTPS 포트(각각 80 및 443)를 WebSocket 게이트웨이 또는 서버와 공유할 수 있습니다.WebSocket 프로토콜은 각각 ws://와 wss:// 접두사를 정의하여 WebSocket 및 WebSocket Secure 연결을 나타냅니다.두 방식 모두 HTTP 업그레이드 메커니즘을 사용하여 WebSocket 프로토콜로 업그레이드합니다.프록시 서버 중에는 투과성이 있어 WebSocket에서 정상적으로 동작하는 것도 있습니다.또한 WebSocket이 정상적으로 동작하지 않아 접속이 실패합니다.경우에 따라서는 추가 프록시 서버 구성이 필요할 수 있으며 WebSocket을 지원하기 위해 특정 프록시 서버를 업그레이드해야 할 수도 있습니다.

암호화되지 않은 WebSocket 트래픽이 WebSockets를 지원하지 않는 명시적 프록시 서버 또는 투명 프록시 서버를 통과하면 연결이 [46]실패할 수 있습니다.

암호화된 WebSocket 접속을 사용하는 경우 WebSocket Secure 접속에 TLS(Transport Layer Security)를 사용하면 다음 보안과 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안, 보안HTTP CONNECT명령어는 명시적 프록시 서버를 사용하도록 브라우저가 설정되어 있을 때 발행됩니다.이로 인해 WebSocket Secure 클라이언트와 WebSocket 서버 간에 HTTP 프록시를 통해 낮은 수준의 엔드 투 엔드 TCP 통신을 제공하는 터널이 설정됩니다.트랜스페어런트프록시 서버의 경우 브라우저는 프록시 서버를 인식하지 못하기 때문에 no.HTTP CONNECT송신됩니다.다만, 와이어 트래픽은 암호화되어 있기 때문에, 중간 투과 프록시 서버에서는 암호화된 트래픽의 통과를 허가하는 경우가 있기 때문에, WebSocket Secure 를 사용하면 WebSocket 접속이 성공할 가능성이 높아집니다.암호화 사용에는 자원 비용이 들지 않지만 안전한 터널을 통과하기 때문에 대부분의 경우 가장 높은 성공률을 제공합니다.

2010년 중반의 드래프트(버전hixie-76)에서는 헤더 뒤에 8바이트의 키 데이터를 포함하지만 그 데이터를 애드버타이즈하지 않음으로써 리버스 프록시 및 게이트웨이와의 호환성이 깨졌습니다.Content-Length: 8header를 [47]클릭합니다.이 데이터는 모든 중간에서 전달되지 않았으며 프로토콜 오류로 이어질 수 있습니다.최신 초안(예: hybi-09[48])은 주요 데이터를Sec-WebSocket-Keyheader를 사용하여 이 문제를 해결합니다.

「 」를 참조해 주세요.

메모들

  1. ^ a b Gecko 기반 브라우저 버전 6-10은 "MozWebSocket"[26]으로 WebSocket 개체를 구현하므로 기존 WebSocket 지원 코드와 통합하려면 추가 코드가 필요합니다.

레퍼런스

  1. ^ "WebSockets Standard". websockets.spec.whatwg.org. Retrieved 2022-05-16.
  2. ^ "The WebSocket API". www.w3.org. Retrieved 2022-05-16.
  3. ^ Ian Fette; Alexey Melnikov (December 2011). "Relationship to TCP and HTTP". RFC 6455 The WebSocket Protocol. IETF. sec. 1.7. doi:10.17487/RFC6455. RFC 6455.
  4. ^ "Adobe Flash Platform – Sockets". help.adobe.com. Retrieved 2021-07-28. TCP connections require a “client” and a “server”. Flash Player can create client sockets.{{cite web}}: CS1 maint :url-status (링크)
  5. ^ "WebSockets – Lista Web API". Mozilla Developer Network. Retrieved 2021-07-28.
  6. ^ "Glossary: WebSockets". Mozilla Developer Network. 2015.
  7. ^ "HTML5 WebSocket – A Quantum Leap in Scalability for the Web". www.websocket.org.
  8. ^ Graham Klyne, ed. (2011-11-14). "IANA Uniform Resource Identifer (URI) Schemes". Internet Assigned Numbers Authority. Retrieved 2011-12-10.
  9. ^ Ian Fette; Alexey Melnikov (December 2011). "WebSocket URIs". RFC 6455 The WebSocket Protocol. IETF. sec. 3. doi:10.17487/RFC6455. RFC 6455.
  10. ^ Wang, Vanessa; Salim, Frank; Moskovits, Peter (February 2013). "APPENDIX A: WebSocket Frame Inspection with Google Chrome Developer Tools". The Definitive Guide to HTML5 WebSocket. Apress. ISBN 978-1-4302-4740-1. Retrieved 7 April 2013.
  11. ^ "HTML 5". www.w3.org. Retrieved 2016-04-17.
  12. ^ "[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)". lists.w3.org. Retrieved 2016-04-17.
  13. ^ "IRC logs: freenode / #whatwg / 20080618". krijnhoetmer.nl. Retrieved 2016-04-18.
  14. ^ "Web Sockets Now Available In Google Chrome". Chromium Blog. Retrieved 2016-04-17.
  15. ^ <ian@hixie.ch>, Ian Hickson (6 May 2010). "The WebSocket protocol". tools.ietf.org. Retrieved 2016-04-17.
  16. ^ Dirkjan Ochtman (May 27, 2011). "WebSocket enabled in Firefox 6". Mozilla.org. Retrieved 2011-06-30.
  17. ^ "Chromium Web Platform Status". Retrieved 2011-08-03.
  18. ^ "WebSockets (Windows)". Microsoft. 2012-09-28. Retrieved 2012-11-07.
  19. ^ "WebSockets Protocol Test Report". Tavendo.de. 2011-10-27. Retrieved 2011-12-10.
  20. ^ Katie Marsal (November 23, 2010). "Apple adds accelerometer, WebSockets support to Safari in iOS 4.2". AppleInsider.com. Retrieved 2011-05-09.
  21. ^ "Web Sockets API". BlackBerry. Archived from the original on June 10, 2011. Retrieved 8 July 2011.
  22. ^ Chris Heilmann (December 8, 2010). "WebSocket disabled in Firefox 4". Hacks.Mozilla.org. Retrieved 2011-05-09.
  23. ^ Aleksander Aas (December 10, 2010). "Regarding WebSocket". My Opera Blog. Archived from the original on 2010-12-15. Retrieved 2011-05-09.
  24. ^ "WebSockets (support in Firefox)". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Retrieved 2011-12-10.
  25. ^ "Bug 640003 - WebSockets - upgrade to ietf-06". Mozilla Foundation. 2011-03-08. Retrieved 2011-12-10.
  26. ^ "WebSockets - MDN". developer.mozilla.org. Mozilla Foundation. 2011-09-30. Retrieved 2011-12-10.
  27. ^ "Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)". Mozilla Foundation. 2011-07-22.
  28. ^ "Chromium bug 64470". code.google.com. 2010-11-25. Retrieved 2011-12-10.
  29. ^ "WebSockets in Windows Consumer Preview". IE Engineering Team. Microsoft. 2012-03-19. Retrieved 2012-07-23.
  30. ^ "WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17". trac.webkit.org. Retrieved 2011-12-10.
  31. ^ "A hot Opera 12.50 summer-time snapshot". Opera Developer News. 2012-08-03. Archived from the original on 2012-08-05. Retrieved 2012-08-03.
  32. ^ "Archived copy". nginx.org. Archived from the original on 17 July 2012. Retrieved 3 February 2022.{{cite web}}: CS1 maint: 제목으로 아카이브된 복사(링크)
  33. ^ "Using NGINX as a WebSocket Proxy". NGINX. May 17, 2014.
  34. ^ "Overview of new features in Apache HTTP Server 2.4". Apache.
  35. ^ "Changelog Apache 2.4". Apache Lounge.
  36. ^ "IIS 8.0 WebSocket Protocol Support". Microsoft Docs. 28 November 2012. Retrieved 2020-02-18.
  37. ^ "Release-1 4 46 - Lighttpd - lighty labs".
  38. ^ "Tempesta FW Handling clients WebSockets". Tempesta FW wiki. Retrieved 6 June 2022.
  39. ^ Ian Fette; Alexey Melnikov (December 2011). "Protocol Overview". RFC 6455 The WebSocket Protocol. IETF. sec. 1.2. doi:10.17487/RFC6455. RFC 6455.
  40. ^ "Main Goal of WebSocket protocol". IETF. Retrieved 25 July 2015. The computation [...] is meant to prevent a caching intermediary from providing a WS-client with a cached WS-server reply without actual interaction with the WS-server.
  41. ^ Ian Fette; Alexey Melnikov (December 2011). "Opening Handshake". RFC 6455 The WebSocket Protocol. IETF. p. 8. sec. 1.3. doi:10.17487/RFC6455. RFC 6455.
  42. ^ Ian Fette; Alexey Melnikov (December 2011). "Opening Handshake". RFC 6455 The WebSocket Protocol. IETF. p. 21. sec. 1.3. doi:10.17487/RFC6455. RFC 6455.
  43. ^ Ian Fette; Alexey Melnikov (December 2011). "Base Framing Protocol". RFC 6455 The WebSocket Protocol. IETF. sec. 5.2. doi:10.17487/RFC6455. RFC 6455.
  44. ^ John A. Tamplin; Takeshi Yoshino (2013). A Multiplexing Extension for WebSockets. IETF. I-D draft-ietf-hybi-websocket-multiplexing.
  45. ^ Christian Schneider (August 31, 2013). "Cross-Site WebSocket Hijacking (CSWSH)". Web Application Security Blog.
  46. ^ Peter Lubbers (March 16, 2010). "How HTML5 Web Sockets Interact With Proxy Servers". Infoq.com. C4Media Inc. Retrieved 2011-12-10.
  47. ^ Willy Tarreau (2010-07-06). "WebSocket -76 is incompatible with HTTP reverse proxies". ietf.org (email). Internet Engineering Task Force. Retrieved 2011-12-10.
  48. ^ Ian Fette (June 13, 2011). "Sec-WebSocket-Key". The WebSocket protocol, draft hybi-09. sec. 11.4. Retrieved June 15, 2011.

외부 링크