웹소켓 - 위키백과, 우리 모두의 백과사전 웹소켓 위키백과, 우리 모두의 백과사전. 둘러보기로 가기 검색하러 가기 웹소켓 ( WebSocket ) 은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 API는 W3C에 의해 표준화되고 있다. 목차 1 역사 2 브라우저 구현체 3 프로토콜 핸드셰이크 4 프록시 경유 5 같이 보기 6 각주 7 외부 링크 역사 [ 편집 ] 웹소켓은 TCP 기반 소켓 API를 대체할 목적으로 HTML5 사양에서 TCPConnection으로 처음 참조되었다. [ 1 ] 2008년 6월, 일련의 토론이 마이클 카터 ( Michael Carter ) 에
T 메소드를 사용하여 영구적인 터널을 구성한다. 웹소켓 프로토콜 그 자체는 프록시 서버와 방화벽을 인지하지 못하지만 HTTP 호환 핸드셰이크의 기능을 제공하므로 HTTP 서버들이 기본 HTTP와 HTTPS 포트 ( 80과 443 ) 를 웹소켓 게이트웨이나 서버와 공유할 수 있게 한다. 웹소켓 프로토콜은 웹소켓과 웹소켓 안전 연결을 나타내기 위해 각각 ws wss : / / 두문자를 정의한다. 이 두 스킴은 HTTP 업그레이드 매커니즘을 사용하여 웹소켓 프로토콜로 업그레이드한다. 일부 프록시 서버는 투명 ( transparent ) 하며 웹소켓과 잘 동작한다. 다른 것들은 웹소켓이 정상 동작하지 못해 연결을 실패한다. 일부의 경우 추가 프록시 구성이 필요할 수 있으며 웹소켓
hixie - 76hybi - 00 2010년 5월 6일2010년 5월 23일 4. 0 ( 비활성화 ) 6 5. 0. 1 11. 00 ( 비활성화 ) 7 hybi - 07 2011년 4월 22일 6 [ 4 ] [ a ] 8 hybi - 10 2011년 7월 11일 7 [ 6 ] [ a ] 7 14 [ 7 ] 13 RFC 6455 2011년 12월 10 [ 8 ] 11 11 16 [ 9 ] 6 12. 10 [ 10 ] 4. 4 프로토콜 핸드셰이크 [ 편집 ] 웹소켓을 연결하기 위해 클라이언트는 웹소켓 핸드셰이크 요청을 보내며, 이렇게 하면 서버는 웹소켓 핸드셰이크 응답을 아래의 예에서 보는 바와 같이 반환한다. [ 11 ] 클라이언트 요청 : GET / chat HTTP / 1. 1 Host : server.
[ whatwg ] TCPConnection feedback from Michael Carter on 2008 - 06 - 18 ( whatwg. org from June 2008 ) ". 《 lists. w3. org 》. 2016년 4월 17일에 확인함. ↑ " WebSockets ( support in Firefox ) ". 《 developer. mozilla. org 》. Mozilla Foundation. 2011년 9월 30일. 2011년 12월 10일에 확인함. ↑ " Bug 640003 - WebSockets - upgrade to ietf - 06 ". Mozilla Foundation. 2011년 3월 8일. 2011년 12월 10일에 확인함. ↑ " WebSockets - MDN ". 《 developer. moz
P 기반 소켓 API를 대체할 목적으로 HTML5 사양에서 TCPConnection으로 처음 참조되었다. [ 1 ] 2008년 6월, 일련의 토론이 마이클 카터 ( Michael Carter ) 에 의해 주도되었으며, 웹소켓으로 알려진 최초 버전의 프로토콜이 탄생되었다. [ 2 ] 브라우저 구현체 [ 편집 ] 구현체 상태 프로토콜 초안일 인터넷 익스플로러 파이어폭스 [ 3 ] ( PC ) 파이어폭스 ( 안드로이드 ) 크롬 ( PC, 모바일 ) 사파리 ( 맥, iOS ) 오페라 ( PC, 모바일 ) 안드로이드 브라우저 hixie - 75 2010년 2월 4일 4 5. 0. 0 hixie - 76hybi - 00 2010년 5월 6일2010년 5월 23일 4. 0 ( 비활성화 ) 6 5. 0. 1 11. 00 ( 비활성화 ) 7 hyb
google. com 》. Google. 2010년 11월 25일. 2011년 12월 10일에 확인함. ↑ " WebSockets in Windows Consumer Preview ". 《 IE Engineering Team 》. Microsoft. 2012년 3월 19일. 2012년 7월 23일에 확인함. ↑ " WebKit Changeset 97247 : WebSocket : Update WebSocket protocol to hybi - 17 ". 《 trac. webkit. org 》. 2011년 12월 10일에 확인함. ↑ " A hot Opera 12. 50 summer - time snapshot ". Opera Developer News. 2012년 8월 3일. 2012년 8월 5일에 원본 문서에서 보존된 문서.
hot Opera 12. 50 summer - time snapshot ". Opera Developer News. 2012년 8월 3일. 2012년 8월 5일에 원본 문서에서 보존된 문서. 2012년 8월 3일에 확인함. ↑ Ian Fette ; Alexey Melnikov ( December 2011 ). " Protocol Overview ". RFC 6455 The WebSocket Protocol. IETF. sec. 1. 2. RFC 6455.. ↑ Peter Lubbers ( 2010년 3월 16일 ). " How Web Sockets Interact With Proxy Servers ". 《 Infoq. com 》. C4Media Inc. 2011년 12월 10일에 확인함. 외부 링크 [ 편집 ] IETF Hypertext - B
응답 : HTTP / 1. 1 101 Switching Protocols Upgrade : websocket Connection : Upgrade Sec - WebSocket - Accept : HSmrc0sMlYUkAGmm5OPpG2HaGWk = Sec - WebSocket - Protocol : chat 프록시 경유 [ 편집 ] 웹소켓 프로토콜 클라이언트 구현체는 목적지 호스트와 포트에 연결할 때 사용자 에이전트가 프록시를 사용하도록 구성되어 있는지 확인을 시도하며 만일 그러한 경우 HTTP CONNECT 메소드를 사용하여 영구적인 터널을 구성한다. 웹소켓 프로토콜 그 자체는 프록시 서버와 방화벽을 인지하지 못하지만 HTTP 호환 핸드셰이크의 기능을 제공하므로 HTTP 서버
, 이렇게 하면 서버는 웹소켓 핸드셰이크 응답을 아래의 예에서 보는 바와 같이 반환한다. [ 11 ] 클라이언트 요청 : 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 / 1. 1 101 Switching Protocols Upgrade : websocket Connection : Upgrade Sec - WebSocket - Accept :
( transparent ) 하며 웹소켓과 잘 동작한다. 다른 것들은 웹소켓이 정상 동작하지 못해 연결을 실패한다. 일부의 경우 추가 프록시 구성이 필요할 수 있으며 웹소켓 지원을 위해 특정 프록시 서버의 업그레이드가 필요할 수 있다. 암호화되지 않은 웹소켓 트래픽이 웹소켓을 지원하지 않는 명시적이거나 투명한 프록시 서버를 통해 경유하는 경우 연결이 실패할 가능성이 높다. [ 12 ] 암호화된 웹소켓 연결을 사용하는 경우 웹소켓 보안 연결에 전송 계층 보안 ( TLS ) 을 사용함으로써 브라우저가 명시적인 프록시 서버를 사용하도록 구성될 때 HTTP CONNECT 명령이 발행됨을 보증한다. 같이 보기 [ 편집 ] 네트워크 소켓 각주 [ 편집 ] 내용주 ↑ 가 나 Gecko
웹소켓(WebSocket)은 하나의 TCP 접속에 전이중 통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 API는 W3C에 의해 표준화되고 있다. 웹소켓은 HTTP와 구별된다. 두 프로토콜 모두 OSI 모델의 제7계층에 위치해 있으며 제4계층의 TCP에 의존한다. 이들에 차이가 있으나 "RFC 6455"에 따르면 웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계되었으며 HTTP 프록시 및 중간 층을 지원하도록 설계되었으므로 HTTP 프로토콜과 호환이 된다. 호환을 달성하기 위해 웹소켓 핸드셰이크는 HTTP 업그레이드 헤더를 사용하여 HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다. 웹소켓 프로토콜은 HTTP 폴링과 같은 반이중방식에 비해 더 낮은 부하를 사용하여 웹 브라우저(또는 다른 클라이언트 애플리케이션)과 웹 서버 간의 통신을 가능케 하며, 서버와의 실시간 데이터 전송을 용이케 한다. 이는 먼저 클라이언트에 의해 요청을 받는 방식이 아닌, 서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공함으로써, 또 연결이 유지된 상태에서 메시지들을 오갈 수 있게 허용함으로써 가능하게 되었다. 이러한 방식으로 양방향 대화 방식은 클라이언트와 서버 간에 발생할 수 있다. 통신은 TCP 포트 80(TLS 암호화 연결의 경우 443)를 통해 수행되며 방화벽을 통해 웹이 아닌 인터넷 연결을 차단하는 일부 환경에 도움이 된다. 단순 양방향 브라우저-서버 통신은 코멧 등의 스톱갭(stopgap) 기술을 사용하는 비표준 방식으로 수행된다. 구글 크롬, 마이크로소프트 에지, 인터넷 익스플로러, 파이어폭스, 사파리, 오페라 등 대부분의 브라우저가 이 프로토콜을 지원한다.