iBet uBet web content aggregator. Adding the entire web to your favor.
iBet uBet web content aggregator. Adding the entire web to your favor.



Link to original content: http://ko.wikipedia.org/wiki/웹소켓
웹소켓 - 위키백과, 우리 모두의 백과사전 본문으로 이동

웹소켓

위키백과, 우리 모두의 백과사전.

웹소켓
웹소켓을 사용한 연결을 나타낸 그림
국제 표준RFC 6455
개발사IETF
산업컴퓨터 과학
단자 유형TCP
웹사이트웹소켓 위키데이터에서 편집하기 - 공식 웹사이트

웹소켓(WebSocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 APIW3C에 의해 표준화되고 있다.

웹소켓은 HTTP와 구별된다. 두 프로토콜 모두 OSI 모델의 제7계층에 위치해 있으며 제4계층의 TCP에 의존한다. 이들에 차이가 있으나 "RFC 6455"에 따르면 웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계되었으며 HTTP 프록시 및 중간 층을 지원하도록 설계되었으므로 HTTP 프로토콜과 호환이 된다. 호환을 달성하기 위해 웹소켓 핸드셰이크HTTP 업그레이드 헤더를 사용하여[1] HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다.

웹소켓 프로토콜은 HTTP 폴링과 같은 반이중방식에 비해 더 낮은 부하를 사용하여 웹 브라우저(또는 다른 클라이언트 애플리케이션)과 웹 서버 간의 통신을 가능케 하며, 서버와의 실시간 데이터 전송을 용이케 한다. 이는 먼저 클라이언트에 의해 요청을 받는 방식이 아닌, 서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공함으로써, 또 연결이 유지된 상태에서 메시지들을 오갈 수 있게 허용함으로써 가능하게 되었다. 이러한 방식으로 양방향 대화 방식은 클라이언트와 서버 간에 발생할 수 있다. 통신은 TCP 포트 80(TLS 암호화 연결의 경우 443)를 통해 수행되며 방화벽을 통해 웹이 아닌 인터넷 연결을 차단하는 일부 환경에 도움이 된다. 단순 양방향 브라우저-서버 통신은 코멧 등의 스톱갭(stopgap) 기술을 사용하는 비표준 방식으로 수행된다.

구글 크롬, 마이크로소프트 에지, 인터넷 익스플로러, 파이어폭스, 사파리, 오페라 등 대부분의 브라우저가 이 프로토콜을 지원한다.

개요

[편집]

HTTP와 달리 웹소켓은 전이중 통신을 사용한다.[2][3] 또, 웹소켓은 TCP 위에서 메시지 스트리밍을 가능케 한다. TCP 단독으로는 메시지의 상속 개념 없이 바이트 스트림을 다룬다. 웹소켓 이전에는 포트 80 전이중 통신은 코멧 채널을 사용하여 수행이 가능했다. 그러나 코멧 구현체는 사소한 것이 아니었으며 TCP 핸드셰이크와 HTTP 헤더 부하로 인해 작은 메시지에는 비효율적이다. 웹소켓 프로토콜은 웹의 보안 문제를 타협하지 않고 이 문제를 해결하는 것을 목적으로 한다.

웹소켓 프로토콜 사양은 2개의 새로운 통합 자원 식별자(URI) 스킴으로 ws(WebSocket), wss(WebSocket Secure)를 정의하며[4] 이들은 암호화되지 않은 연결과 암호화된 연결에 각각 사용된다.

역사

[편집]

웹소켓은 TCP 기반 소켓 API를 대체할 목적으로 HTML5 사양에서 TCPConnection으로 처음 참조되었다.[5] 2008년 6월, 일련의 토론이 마이클 카터(Michael Carter)에 의해 주도되었으며, 웹소켓으로 알려진 최초 버전의 프로토콜이 탄생되었다.[6]

브라우저 구현체

[편집]
구현체 상태
프로토콜 초안일 인터넷 익스플로러 파이어폭스[7] (PC) 파이어폭스 (안드로이드) 크롬 (PC, 모바일) 사파리 (맥, iOS) 오페라 (PC, 모바일) 안드로이드 브라우저
hixie-75 2010년 2월 4일 4 5.0.0
hixie-76
hybi-00
2010년 5월 6일
2010년 5월 23일
4.0 (비활성화) 6 5.0.1 11.00 (비활성화)
7 hybi-07 2011년 4월 22일 6[8][a]
8 hybi-10 2011년 7월 11일 7[10][a] 7 14[11]
13 RFC 6455 2011년 12월 10[12] 11 11 16[13] 6 12.10[14] 4.4

프로토콜 핸드셰이크

[편집]

웹소켓을 연결하기 위해 클라이언트는 웹소켓 핸드셰이크 요청을 보내며, 이렇게 하면 서버는 웹소켓 핸드셰이크 응답을 아래의 예에서 보는 바와 같이 반환한다.[15]

클라이언트 요청:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

서버 응답:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

프록시 경유

[편집]

웹소켓 프로토콜 클라이언트 구현체는 목적지 호스트와 포트에 연결할 때 사용자 에이전트가 프록시를 사용하도록 구성되어 있는지 확인을 시도하며 만일 그러한 경우 HTTP CONNECT 메소드를 사용하여 영구적인 터널을 구성한다.

웹소켓 프로토콜 그 자체는 프록시 서버와 방화벽을 인지하지 못하지만 HTTP 호환 핸드셰이크의 기능을 제공하므로 HTTP 서버들이 기본 HTTP와 HTTPS 포트(80과 443)를 웹소켓 게이트웨이나 서버와 공유할 수 있게 한다. 웹소켓 프로토콜은 웹소켓과 웹소켓 안전 연결을 나타내기 위해 각각 ws://과 wss:// 두문자를 정의한다. 이 두 스킴은 HTTP 업그레이드 매커니즘을 사용하여 웹소켓 프로토콜로 업그레이드한다. 일부 프록시 서버는 투명(transparent)하며 웹소켓과 잘 동작한다. 다른 것들은 웹소켓이 정상 동작하지 못해 연결을 실패한다. 일부의 경우 추가 프록시 구성이 필요할 수 있으며 웹소켓 지원을 위해 특정 프록시 서버의 업그레이드가 필요할 수 있다.

암호화되지 않은 웹소켓 트래픽이 웹소켓을 지원하지 않는 명시적이거나 투명한 프록시 서버를 통해 경유하는 경우 연결이 실패할 가능성이 높다.[16]

암호화된 웹소켓 연결을 사용하는 경우 웹소켓 보안 연결에 전송 계층 보안(TLS)을 사용함으로써 브라우저가 명시적인 프록시 서버를 사용하도록 구성될 때 HTTP CONNECT 명령이 발행됨을 보증한다.

같이 보기

[편집]

각주

[편집]
내용주
  1. Gecko-based browsers versions 6–10 implement the WebSocket object as "MozWebSocket",[9] requiring extra code to integrate with existing WebSocket-enabled code.
참조주
  1. Ian Fette; Alexey Melnikov (December 2011). "Relationship to TCP and HTTP". RFC 6455 The WebSocket Protocol. IETF. sec. 1.7. RFC 6455. https://tools.ietf.org/html/rfc6455#section-1.7. 
  2. “Glossary:WebSockets”. Mozilla Developer Network. 2015. 
  3. “HTML5 WebSocket: A Quantum Leap in Scalability for the Web”. 2021년 4월 1일에 원본 문서에서 보존된 문서. 2019년 11월 21일에 확인함. 
  4. Graham Klyne, 편집. (2011년 11월 14일). “IANA Uniform Resource Identifer (URI) Schemes”. Internet Assigned Numbers Authority. 2011년 12월 10일에 확인함. 
  5. “HTML 5”. 《www.w3.org》. 2016년 4월 17일에 확인함. 
  6. “[whatwg] TCPConnection feedback from Michael Carter on 2008-06-18 (whatwg.org from June 2008)”. 《lists.w3.org》. 2016년 4월 17일에 확인함. 
  7. “WebSockets (support in Firefox)”. 《developer.mozilla.org》. Mozilla Foundation. 2011년 9월 30일. 2012년 5월 26일에 원본 문서에서 보존된 문서. 2011년 12월 10일에 확인함. 
  8. “Bug 640003 - WebSockets - upgrade to ietf-06”. Mozilla Foundation. 2011년 3월 8일. 2011년 12월 10일에 확인함. 
  9. “WebSockets - MDN”. 《developer.mozilla.org》. Mozilla Foundation. 2011년 9월 30일. 2012년 5월 26일에 원본 문서에서 보존된 문서. 2011년 12월 10일에 확인함. 
  10. “Bug 640003 - WebSockets - upgrade to ietf-07(comment 91)”. Mozilla Foundation. 2011년 7월 22일. 
  11. “Chromium bug 64470”. 《code.google.com》. Google. 2010년 11월 25일. 2011년 12월 10일에 확인함. 
  12. “WebSockets in Windows Consumer Preview”. 《IE Engineering Team》. Microsoft. 2012년 3월 19일. 2012년 7월 23일에 확인함. 
  13. “WebKit Changeset 97247: WebSocket: Update WebSocket protocol to hybi-17”. 《trac.webkit.org》. 2011년 12월 10일에 확인함. 
  14. “A hot Opera 12.50 summer-time snapshot”. Opera Developer News. 2012년 8월 3일. 2012년 8월 5일에 원본 문서에서 보존된 문서. 2012년 8월 3일에 확인함. 
  15. Ian Fette; Alexey Melnikov (December 2011). "Protocol Overview". RFC 6455 The WebSocket Protocol. IETF. sec. 1.2. RFC 6455. https://tools.ietf.org/html/rfc6455#section-1.2. 
  16. Peter Lubbers (2010년 3월 16일). “How Web Sockets Interact With Proxy Servers”. 《Infoq.com》. C4Media Inc. 2011년 12월 10일에 확인함. 

외부 링크

[편집]