분류 기타

WebSockets: 개념적 개요

컨텐츠 정보

  • 조회 547 (작성일 )

본문

✔ 소개 


실시간 커뮤니케이션은 인터넷 세상을 형성하는 데 엄청난 속도로 발전했습니다. 포스트 코로나 시대에는 이메일을 보내고 클라이언트의 응답을 기다리는 것부터 Slack 커뮤니티에서 클라이언트와 상호 작용하는 것까지 모든 유형의 커뮤니케이션이 변경되었습니다.


이 인스턴트 메시징, 영상/음성 통화 및 기타 유사한 기술은 점차 시간 관리를 개선하고 전체 응답 시간을 줄이는 데 도움이 되었습니다.


WebSocket 🔌 덕분에 이러한 혁신이 가능해졌습니다.


이 기사에서는 WebSocket의 몇 가지 놀라운 개념과 유창한 실시간 통신을 위해 API를 구현하는 방법을 살펴보겠습니다.


✔ 웹소켓이란? 


WebSocket은 클라이언트와 서버 간의 지속적인 연결을 제공하는 전송 계층 프로토콜입니다. 이 WebSocket은 TCP/IP 소켓 연결을 통해 작동하며 통신을 위한 전이중 및 양방향 기능을 제공합니다.


예를 들어, 두 사람이 서로 통신하기를 원하는(즉, A가 B와 대화하기를 원하는) 유선 연결을 만들고 싶다고 가정해 봅시다. 이제 대화를 시작하려면 한쪽 끝(A)이 다른 쪽 끝(B)에 연결하기 위한 다이얼 인 번호(핸드셰이크 역할)가 있어야 합니다.


communication 

여기에서 A가 B에 성공적으로 전화를 걸었다고 가정하면, 정보가 양쪽 끝에서 흐를 수 있는 터널처럼 A와 B 사이에 지속적인 연결이 설정됩니다.


메시징 응용 프로그램은 연결이 생성되고 메시지 시퀀스가 ​​빠른 속도로 교환되는 위에서 논의한 유선 연결과 동일하게 작동합니다.


하지만 잠깐만... ⏳


REST API를 사용하여 이러한 메시지를 보낼 수 없습니까? 개발자가 WebSocket으로 전환하는 것을 선호하는 이유는 무엇입니까? REST API에 문제가 있습니까?


글쎄요, 걱정 마세요! REST API가 있을 때 WebSocket이 도입된 이유를 더 파고 들어 이해해 볼까요?


✔ 왜 WebSocket인가? 


API는 두 애플리케이션이 서로 통신할 수 있도록 하는 HTTP 기반 기술입니다. 이 HTTP 기반 기술은 단방향 프로토콜에서 엄격하게 작동합니다. 여기에서 서버는 전송된 모든 응답 데이터가 클라이언트에서 요청되어야 하는지 확인합니다.


이제 두 사람이 API를 사용하여 채팅하는 메시징 애플리케이션으로 돌아가 보겠습니다. HTTP API는 단방향이기 때문에 클라이언트와 서버는 응답 데이터(A에서 B로 또는 그 반대로 메시지 중계)를 얻기 위해 각각 작동하고 계속해서 연결해야 합니다. 이러한 연결은 처리하기가 지루합니다.


이 지저분한 연결을 피하기 위해 긴 폴링이라는 개념이 있습니다. 이 긴 폴링은 클라이언트가 시간 초과 기간이 긴 HTTP 요청을 보낼 수 있고 서버가 클라이언트에 데이터를 계속 푸시할 수 있는 위의 시나리오에 대한 해결 방법으로 작동합니다.


이것은 단지 해결 방법일 뿐이므로 몇 가지 단점도 예상할 수 있습니다. 예를 들어 클라이언트와 서버가 지속적으로 데이터를 전송할 때 긴 폴링이 완벽하게 작동하지만 클라이언트로 다시 보낼 수 있는 데이터가 없을 때 문제가 발생합니다. 서버는 폴링(시간 초과) 기간 동안 리소스를 불필요하게 보유합니다.


위와 같은 HTTP 기반 기술의 한계를 극복하기 위해 *WebSockets가 탄생했습니다*. 


자원은 HTTP의 폴링 기간 동안 서버에 불필요하게 묶여 있습니다. 반면에 WebSocket은 네트워크를 통해 자유롭게 통신할 수 있습니다. 이 통신은 UDP와 매우 유사하지만 TCP의 보안이 있습니다.


✔ WebSocket의 수명 주기 


WebSocket은 RFC 6455를 따릅니다. 프로토콜은 TCP를 통해 계층화된 기본 메시지 프레이밍이 뒤따르는 오프닝 핸드셰이크를 요청합니다.


webSocket cycle 

WebSocket은 위 이미지와 같이 표준 HTTP 요청 및 응답을 시작하여 수명 주기를 시작합니다. 이 요청 내에서 클라이언트는 서버에 웹 연결을 열도록 요청합니다. 서버가 동의하면 초기 핸드셰이크가 성공적으로 설정됩니다.


이 핸드셰이크는 클라이언트와 서버가 WebSocket 연결로 통신하기 위해 TCP/IP 소켓을 공유하기로 동의했다는 증거입니다. 이제 정보는 기본 메시지 프레이밍 프로토콜을 사용하여 흐를 수 있습니다. 소켓을 닫으려면 양쪽 끝이 TCP 연결을 거부했음을 확인해야 합니다.


이 시간까지 REST API 대신 WebSocket이 사용되는 이유를 이해하셨기를 바랍니다.


✔ WebSockets 프로토콜 개요 


WebSockets URI는 HTTP URI와 동일하지만 찾을 수 있는 유일한 차이점은 체계입니다. WebSocket은 HTTP/HTTPS 체계를 사용하지 않습니다. 대신 ws/wss(웹 소켓 보안)를 사용하여 호스트/엔드포인트에 연결합니다. 예를 들어


HTTP URIs: 


http://domain-name[:port]/resource-path/resource-id
{secured} https://domain-name[:port]/resource-path/resource-id


WebSocket URIs: 


ws://domain-name[:port]/resource-path/resource-id
{secured} wss://domain-name[:port]/resource-path/resource-id


보안 WebSocket 연결을 설정하려면 HTTP 요청/응답 호출을 업그레이드해야 합니다. 따라서 클라이언트/서버는 모두 WebSocket 연결을 지원하고 몇 가지 요청 헤더를 전달해야 합니다.


GET ws://localhost2.com:3000/ HTTP/1.1
Host: localhost:8000
Connection: Upgrade
Pragma: no-cache
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: q3xPeO32u5496gldTuKaSAh==


WebSocket 연결을 설정하는 데 필요한 각 헤더를 이해합시다.


  • GET ws://localhost2.com:3000/ HTTP/1.1: HTTP 프로토콜의 첫 번째 버전을 사용하여 엔드포인트가 localhost2.com:3000인 WebSocket을 안전하지 않게 {ws} 연결하는 실제 GET 호출입니다.
  • Host: localhost:8000: 요청이 시작된 호스트입니다. 현재 로컬 머신 localhost:8000입니다.
  • Connection: 업그레이드: 연결 헤더는 HTTP 호출 후 네트워크 연결의 개폐를 관리합니다. 일반적으로 HTTP 호출 중에 연결을 지속적으로 유지하는 데 도움이 되는 연결 유지로 설정됩니다. 업그레이드를 사용하면 연결을 활성 상태로 유지하고 HTTP가 아닌 요청에 대해서만 통신이 열릴 것임을 알립니다.
  • Pragma: no-cache: 브라우저가 새로운 버전의 리소스를 원한다고 서버와 중간 캐시에 알리는 수단이며, 서버가 브라우저에 리소스를 캐시하지 않도록 지시하는 것은 아닙니다.
  • Upgrade: websocket: 헤더는 클라이언트가 연결을 위해 프로토콜 중 하나를 따르도록 서버에 요청하는 데 사용됩니다. 이 경우 클라이언트는 WebSocket 연결을 요청합니다.
  • Sec-WebSocket-Version: 13: WebSocket 프로토콜은 버전 13의 사용만 허용하며, 다른 버전은 여기에서 유효하지 않은 것으로 간주됩니다.
  • Sec-WebSocket-Key: q3xPeO32u5496gldTuKaSAh==: 이것은 16바이트 및 base64로 인코딩된 한 번 무작위로 생성된 고유 키입니다.

클라이언트가 WebSocket 연결을 안전하게 설정하면 HTTP 101 스위칭 프로토콜이 있는 서버의 응답을 기다립니다. 서버의 응답 헤더는 아래와 같습니다.

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: aGVsbG8gZXZlcnlvbmUg=


HTTP 101 Switching Protocols 응답은 서버가 클라이언트가 업그레이드 요청 헤더에서 요청한 프로토콜로 전환하고 있음을 나타냅니다. 또한 서버는 연결이 성공적으로 업그레이드 되었는지 확인하는 HTTP 헤더를 포함해야 합니다.


✔ WebSocket APIs 


WebSocket API를 사용하면 두 애플리케이션이 서로 유창하게 상호 작용할 수 있도록 양방향 전이중 영구 연결을 생성할 수 있습니다.


이는 서로의 응답을 기다리지 않고 지속적으로 데이터를 송수신할 수 있는 터널로 시각화할 수 있습니다.


✔ 웹소켓의 장점 


  • 양방향: HTTP에서 클라이언트는 모든 요청 후에 서버의 응답을 기다려야 하는 반면 WebSocket은 클라이언트/서버가 비동기식으로 실시간 업데이트를 보내고 받을 수 있도록 합니다. 예를 들어 데이터가 지속적으로 푸시되고 그래프가 이에 대해 그려지는 주식 대시보드.
  • 짧은 대기 시간: WebSockets는 모든 요청에 ​​대해 새로운 연결을 생성하지 않으므로 네트워크 대기 시간이 자동으로 감소됩니다. 표준 HTTP 헤더 정보를 포함하는 초기 핸드셰이크 이후의 모든 후속 메시지에는 관련 정보만 포함됩니다. 이러한 대기 시간 감소로 번개처럼 빠른 통신이 가능합니다.
  • 확장 가능: WebSocket API는 WAMP, XMPP, AMQP 및 MQTT와 같은 40개의 하위 프로토콜과 다음과 같은 강력한 기능을 가능하게 하는 확장 다중화 및 데이터 압축.
  • 보안: WSS(WebSocket Secure) 프로토콜은 표준 SSL 및 TLS 암호화를 사용하여 보안 연결을 설정합니다. 클라이언트와 서버 사이. 보안되지 않은 WebSocket은 TLS 포트 번호 80을 사용하지만 WSS는 포트 443을 사용합니다.

✔ 결론 


이 기사에서는 WebSocket의 소개로 시작하여 WebSocket이 배후에서 어떻게 사용되는지와 실시간 애플리케이션을 구축하여 우리의 삶을 더 빠르고 단순하게 만드는 방법을 배웠습니다.


다음으로 WebSocket 프로토콜의 몇 가지 기술적인 개념을 살펴보았습니다. 또한 WebSocket이 HTTP 기반 기술과 어떻게 다른지 실제 사례를 통해 비교합니다.


이 기사를 마치면서 WebSocket과 향후 애플리케이션에서 WebSocket을 사용할 수 있는 방법을 명확하게 이해해야 합니다.


출처 : https://dev.to/snipperbytes/websockets-a-conceptual-overview-41m