<h1><center> 네트워크 - WebSocket </center></h1>

###### title: `네트워크 - WebSocket`

###### tags: `💻 TIL`, `네트워크`, `WebRTC`, `Computer Science`, `WebSocket`

###### date: `2023-11-15T10:39:33.284Z`

> [color=#724cd1][name=데릭]

> [Websocket - 위키백과](https://ko.wikipedia.org/wiki/%EC%9B%B9%EC%86%8C%EC%BC%93)

> [Websocket - iOS 김종권](https://ios-development.tistory.com/1109)

## 개요

> Web RTC에 대해 학습하기 위해 WebSocket 대한 배경지식이 필요하다.

## WebSocket

> 하나의 TCP 접속에 전이중 통신(ex. 휴대폰) 채널을 제공하는 컴퓨터 통신 프로토콜이다. 또한, TCP 위에서 메세지 스트리밍을 가능케 한다. TCP 단독으로는 메세지의 상속 개념 없이 바이트 스트림을 다룬다.

웹소켓은 HTTP와 구별된다. 두 프로토콜은 모두 OSI 모델의 7계층에 위치하며 4계층(전송계층)의 TCP에 의존한다.

- `RFC 6455`에 따르면 웹소켓은 HTTP 포트 80과 443 위에 동작하도록 설계되어 있다.
- HTTP 프록시, 중간 층을 지원하도록 설계되어 HTTP 프로토콜과 호환이 된다.
- 호환되기 위해 웹소켓 핸드셰이크는 HTTP 업그레이드 헤더를 사용하여 HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다.

웹소켓은 HTTP 폴링과 같은 반이중방식(ex.무전기)에 비해 더 낮은 부하를 사용하여 웹 브라우저(또는 다른 클라이언트 애플리케이션)과 웹 서버 간의 통신을 가능케 하며, 서버와의 실시간 데이터 전송을 용이하게 한다.

이는 클라이언트에 의해 먼저 요청 받는 방식이 아닌, 서버가 내용을 클라이언트에 보내는 표준화된 방식을 제공한다. 또한, 연결이 유지된 상태에서 메세지가 송수신 할 수 있게 허용한다. 이런 양방향 대화 방식은 클라이언트와 서버간에 발생할 수 있다.

**NOTE**

> W3C: 월드 와이드 웹 컨소시엄(World Wide Web Consortium == WWW == W3C) 약칭 W3C는 월드 와이드 웹을 위한 표준을 개발하고 장려하는 조직으로 팀 버너스 리를 중심으로 설립<br>
> HTTP 폴링: 클라이언트가 주기적으로 서버에게 데이터를 요청하는 방식이다. 단순하고 구현이 비교적 쉽지만, 효율성과 실시간성에 제약이 있을 수 있다. 그 이유는, 데이터가 자주 변경되지 않아도 주기적인 폴링이 이루어져야 하고, 데이터를 주기적으로 확인해야 하기 때문에 상대적으로 낮은 실시간성을 가지기 때문이다.<br>
> HTTP 롱폴링: 폴링의 변형으로, 클라이언트가 서버에 데이터를 요청하면 서버는 새로운 데이터가 생길 때까지 응답을 보류시킨다. 데이터가 업데이트 되면 응답이 이루어지고, 클라이언트는 다시 새로운 데이터를 요청한다. 이를 통해 폴링에 비해 실시간성을 조금 더 향상시킬 수 있다.<br>
> HTTP 스트리밍: 실시간으로 데이터를 전송하는 방식 중 하나이다. 서버는 연결을 유지하고, 데이터가 생성되는 즉시 클라이언트에게 전송한다. 이를 통해 실시간으로 데이터를 수신하고 처리할 수 있으며, 높은 실시간성을 제공할 수 있다.<br>
> 바이트 스트림: 데이터를 여러 개의 작은 조각으로 나누어 처리하는 방법을 의미한다. `바이트`는 데이터의 가장 작은 단위를 나타내며, `스트림`은 데이터가 연속적으로 흐르는 것을 의미한다. <br>
즉, 데이터를 작은 조각(바이트)으로 나눠 하나씩 차례로 처리하는 것을 바이트 스트림이라 한다. 텍스트, 이미지, 음악, 동영상 등 모든 종류의 데이터를 0과 1의 조합인 바이트로 취급하는 방식이다.

- 웹소켓 이전에는 포트 80 전이중 통신은 코맷 채널을 사용하여 수행이 가능했다. 그러나 코맷 구현체는 TCP 핸드셰이크와 HTTP 헤더 부하로 인해 작은 메세지에는 비효율적이다. **웹소켓 프로토콜은 웹의 보안 문제를 타협하지 않고 이 문제를 해결하는 것을 목적으로 한다.**

## WebSocket이 TCP를 사용하는 이유?

> 단순히 스트리밍으로 생각했을 때, 그러니깐 실시간성이 중요하다고 할 때, UDP가 빠르게 데이터를 주고 받는 거지 않나? 왜 느린 TCP를 사용할까? 라는 의문이 생겼다.

WebSocket이 TCP(Transmission Control Protocol)를 사용하는 주된 이유는 신뢰성, 순서 보장, 오류 없는 데이터 전송을 보장하기 위함이다. WebSocket 프로토콜은 웹 어플리케이션에서 브라우저와 서버 간에 양방향 통신 채널을 제공하도록 설계되었으며, 이러한 통신은 실시간 데이터 전송을 필요로 하는 앱에서 매우 중요하다.

**주요 이유**

- 신뢰성: TCP는 데이터가 손실되거나 손상되지 않고 전송되도록 보장한다. 데이터 패킷은 송신자로부터 수신자에게 확인 응답을 받을 때까지 재전송되며, 이는 WebSocket 통신이 신뢰할 수 있음을 의미한다.
- 순서 보장: TCP는 패킷이 전송된 순서대로 도착하도록 보장한다. 이는 데이터의 일관성과 무결성을 유지하는 데 중요한 요소로, 실시간 통신에서 메시지 순서가 중요한 경우에 특히 필요하다.
- 연결 지향: TCP는 연결 기반 프로토콜인데, 통신을 시작하기 전에 송신자와 수신자 간에 연결을 설정한다. 이런 연결은 데이터 전송 중 안정성과 보안을 높여준다. WebSocket은 이러한 TCP의 연결 지향 특성을 활용하여 브라우저와 서버간의 지속적이고 안정적인 통신 채널을 제공해준다.
- 오류 체크 및 복구: TCP는 전송 중 발생할 수 있는 오류를 감지하고 복구하는 매커니즘을 제공한다. 이는 데이터가 정확하게 전송되었는지 확인하고 필요한 경우 재전송을 수행하여 데이터의 정확성을 보장한다.
- 혼잡 제어 및 흐름 제어: TCP는 네트워크 혼잡이 발생했을 때 데이터 전송 속도를 조절하고, 수신자의 수신 가능 상태에 따라 송신 속도를 조정한다. 이런 특성은 네트워크의 효율설을 높이고 전송 오류를 줄이는 데 기여한다.

UDP와 같은 비연결형 프로토콜이 더 낮은 지연시간을 제공할 수 있음에도 사용하지 않는 이유는 신뢰성과 순서 보장을 하지 않기 때문이다. 실시간 앱에서는 데이터의 정확성과 순서가 매우 중요할 수 있으므로 TCP기반의 WebSocket이 더 적합하다 할 수 있다.