웹소켓

website = 공식 웹사이트 **웹소켓**(WebSocket)은 단일 TCP 연결로 동시양방향통신 채널을 제공하는 컴퓨터 통신 프로토콜이다. 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되었으며 웹 IDL의 웹소켓 API는 W3C에 의해 표준화되고 있다. 웹소켓은 HTTP와 구별된다. 두 프로토콜 모두 OSI 모델의 제7계층에 위치해 있으며 제4계층의 TCP에 의존한다. 이들에 차이가 있으나 "RFC 6455"에 따르면 웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계되었으며 HTTP 프록시 및 중간 층을 지원하도록 설계되었으므로 HTTP 프로토콜과 호환이 된다. 호환을 달성하기 위해 웹소켓 핸드셰이크는 HTTP 업그레이드 헤더를 사용하여author2=Alexey Melnikov HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다. 웹소켓 프로토콜은 HTTP 폴링과 같은 반이중방식에 비해 더 낮은 부하를 사용하여 웹 브라우저(또는 다른 클라이언트 애플리케이션)과 웹 서버 간의 통신을 가능케 하며, 서버와의 실시간 데이터 전송을 용이케 한다. 이는 먼저 클라이언트에 의해 요청을 받는 방식이 아닌, 서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공함으로써, 또 연결이 유지된 상태에서 메시지들을 오갈 수 있게 허용함으로써 가능하게 되었다. 이러한 방식으로 양방향 대화 방식은 클라이언트와 서버 간에 발생할 수 있다. 통신은 TCP 포트 80(TLS 암호화 연결의 경우 443)를 통해 수행되며 방화벽을 통해 웹이 아닌 인터넷 연결을 차단하는 일부 환경에 도움이 된다. 단순 양방향 브라우저-서버 통신은 코멧 등의 스톱갭(stopgap) 기술을 사용하는 비표준 방식으로 수행된다. 구글 크롬, 마이크로소프트 에지, 인터넷 익스플로러, 파이어폭스, 사파리, 오페라 등 대부분의 브라우저가 이 프로토콜을 지원한다.
# 개요
HTTP와 달리 웹소켓은 전이중 통신을 사용한다.title=Glossary:WebSocketsurl-status=dead 또, 웹소켓은 TCP 위에서 메시지 스트리밍을 가능케 한다. TCP 단독으로는 메시지의 상속 개념 없이 바이트 스트림을 다룬다. 웹소켓 이전에는 포트 80 전이중 통신은 코멧 채널을 사용하여 수행이 가능했다. 그러나 코멧 구현체는 사소한 것이 아니었으며 TCP 핸드셰이크와 HTTP 헤더 부하로 인해 작은 메시지에는 비효율적이다. 웹소켓 프로토콜은 웹의 보안 문제를 타협하지 않고 이 문제를 해결하는 것을 목적으로 한다. 웹소켓 프로토콜 사양은 2개의 새로운 통합 자원 식별자(URI) 스킴으로 `ws`(WebSocket), `wss`(WebSocket Secure)를 정의하며editor=Graham Klyne 이들은 암호화되지 않은 연결과 암호화된 연결에 각각 사용된다.
# 역사
웹소켓은 TCP 기반 소켓 API를 대체할 목적으로 HTML5 사양에서 TCPConnection으로 처음 참조되었다.access-date=2016-04-17 2008년 6월, 일련의 토론이 마이클 카터(Michael Carter)에 의해 주도되었으며, 웹소켓으로 알려진 최초 버전의 프로토콜이 탄생되었다.access-date=2016-04-17
# 브라우저 구현체
{| class="wikitable" |+ 구현체 상태 ! 프로토콜 ! 초안일 ! 인터넷 익스플로러 ! 파이어폭스archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets (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일 | | 6accessdate=2011-12-10archive-url=https://web.archive.org/web/20120526230019/https://developer.mozilla.org/en/WebSockets requiring extra code to integrate with existing WebSocket-enabled code. | | | | | |- ! 8 hybi-10 | 2011년 7월 11일 | | 7date=2011-07-22name="mozwebsocket" | 7 | 14accessdate=2011-12-10 | | | |- ! 13 RFC 6455 | 2011년 12월 | 10accessdate=2012-07-23 | 11 | 11 | 16accessdate=2011-12-10 | 6 | 12.10archivedate=2012-08-05 | 4.4 |}
# 프로토콜 핸드셰이크
웹소켓을 연결하기 위해 클라이언트는 웹소켓 핸드셰이크 요청을 보내며, 이렇게 하면 서버는 웹소켓 핸드셰이크 응답을 아래의 예에서 보는 바와 같이 반환한다.author2=Alexey Melnikov 클라이언트 요청: 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)하며 웹소켓과 잘 동작한다. 다른 것들은 웹소켓이 정상 동작하지 못해 연결을 실패한다. 일부의 경우 추가 프록시 구성이 필요할 수 있으며 웹소켓 지원을 위해 특정 프록시 서버의 업그레이드가 필요할 수 있다. 암호화되지 않은 웹소켓 트래픽이 웹소켓을 지원하지 않는 명시적이거나 투명한 프록시 서버를 통해 경유하는 경우 연결이 실패할 가능성이 높다.accessdate=2011-12-10 암호화된 웹소켓 연결을 사용하는 경우 웹소켓 보안 연결에 전송 계층 보안(TLS)을 사용함으로써 브라우저가 명시적인 프록시 서버를 사용하도록 구성될 때 HTTP CONNECT 명령이 발행됨을 보증한다.