HTTP와 WebSocket은 모두 클라이언트-서버 통신에 사용되는 통신 프로토콜입니다.
HTTP 프로토콜: HTTP는 클라이언트가 요청을 보내고 서버가 응답을 보내는 단방향입니다. 사용자가 서버에 요청을 보낼 때 이 요청은 HTTP 또는 HTTPS 형식으로 진행됩니다. 요청을 받은 후 서버는 클라이언트에 응답을 보내고 각 요청은 응답을 보낸 후 해당 응답과 연결됩니다. 연결이 닫히면 각 HTTP 또는 HTTPS 요청은 매번 서버에 대한 새 연결을 설정하고 응답을 받은 후 연결이 자동으로 종료됩니다.
HTTP는 연결 지향 프로토콜인 TCP 위에서 실행되는 상태 비저장 프로토콜로, 3방향 핸드셰이킹 방법을 사용하여 데이터 패킷 전송 전달을 보장하고 손실된 패킷을 다시 전송합니다.
HTTP는 TCP, SCTP와 같은 안정적인 연결 지향 프로토콜 위에서 실행될 수 있습니다. 클라이언트가 서버에 HTTP 요청을 보내면 클라이언트와 서버 사이에 TCP 연결이 열리고 응답을 받은 후 TCP 연결이 종료되며 각 HTTP 요청은 서버에 대한 별도의 TCP 연결을 엽니다. 클라이언트가 서버에 10개의 요청을 보내면 10개의 별도 TCP 연결이 열립니다. 응답/대체를 받은 후 닫힙니다.
ASCII로 인코딩된 HTTP 메시지 정보, 각 HTTP 요청 메시지는 HTTP 프로토콜 버전(HTTP/1.1, HTTP/2), HTTP 메소드(GET/POST 등), HTTP 헤더(콘텐츠 유형, 콘텐츠 길이), 호스트 정보 등으로 구성됩니다. . 및 서버로 전송되는 실제 메시지가 포함된 본문입니다. HTTP 헤더의 크기는 200바이트에서 2KB까지 다양하며, HTTP 헤더의 일반적인 크기는 700-800바이트입니다. 웹 애플리케이션이 에이전트의 저장 기능을 확장하는 클라이언트 측에서 더 많은 쿠키와 기타 도구를 사용하면 HTTP 헤더 페이로드가 줄어듭니다.

웹소켓: WebSocket은 HTTP와 달리 클라이언트-서버 통신과 동일한 시나리오에서 사용되는 양방향 전이중 프로토콜입니다. ws:// 또는 wss:// . 이는 클라이언트와 서버 간의 연결이 한쪽(클라이언트 또는 서버)에 의해 종료될 때까지 유지된다는 것을 의미하는 상태 저장 프로토콜입니다. 클라이언트와 서버 중 어느 한 쪽에서 연결을 종료한 후 양쪽 끝에서 연결이 종료됩니다.
해시맵
클라이언트-서버 통신의 예를 들어 보겠습니다. 웹 브라우저인 클라이언트와 서버가 있습니다. 클라이언트와 서버 간의 연결을 시작할 때마다 클라이언트-서버는 핸드셰이킹을 수행하고 새 연결을 생성하기로 결정합니다. 그들 중 누구에 의해 종료될 때까지 살아남을 것입니다. 연결이 설정되고 활성화되면 종료될 때까지 동일한 연결 채널을 사용하여 통신이 이루어집니다.
이는 클라이언트-서버 핸드셰이크 후에 클라이언트-서버가 새로운 연결을 결정하여 이를 유지하는 방법이며, 이 새로운 연결은 WebSocket으로 알려져 있습니다. 통신 링크 설정 및 연결이 열리면 클라이언트-서버 간 연결이 지속될 때까지 양방향 모드로 메시지 교환이 이루어집니다. 그들 중 누군가(클라이언트-서버)가 죽거나 연결을 닫기로 결정하면 두 당사자 모두에 의해 연결이 종료됩니다. 소켓이 작동하는 방식은 HTTP가 작동하는 방식과 약간 다르며, 상태 코드 101은 WebSocket의 전환 프로토콜을 나타냅니다.

웹 소켓은 언제 사용할 수 있나요?
- 실시간 웹 애플리케이션: 실시간 웹 애플리케이션은 웹 소켓을 사용하여 백엔드 서버에서 지속적으로 전송되는 데이터를 클라이언트 측에 표시합니다. WebSocket에서는 이미 열려 있는 동일한 연결로 데이터가 지속적으로 푸시/전송되므로 WebSocket이 더 빠르고 애플리케이션 성능이 향상됩니다.
예를 들어 거래 웹사이트 또는 비트코인 거래에서는 가격 변동 및 이동 데이터를 표시하기 위해 WebSocket 채널을 사용하여 백엔드 서버에서 클라이언트 측으로 지속적으로 푸시됩니다.
게임 애플리케이션: 게임 애플리케이션에서는 데이터가 서버에서 지속적으로 수신되고 UI를 새로 고치지 않고도 화면에 적용되며 새 연결을 설정하지 않고도 UI가 자동으로 새로 고쳐진다는 점에 집중할 수 있습니다. 게임 응용 프로그램에 매우 유용합니다.
채팅 애플리케이션: 채팅 애플리케이션은 WebSocket을 사용하여 구독자 간의 메시지 교환, 게시 및 브로드캐스팅을 위해 한 번만 연결을 설정합니다. 메시지 전송 및 수신과 일대일 메시지 전송을 위해 동일한 WebSocket 연결을 재사용합니다.
WebSocket을 사용하지 말아야 할 경우: 네트워크를 통해 전송되는 실시간 업데이트 또는 지속적인 데이터 스트림을 원하는 경우 WebSocket을 사용할 수 있습니다. 오래된 데이터를 가져오고 싶거나 데이터를 한 번만 가져와서 애플리케이션으로 처리하고 싶다면 다음과 같이 해야 합니다. HTTP 프로토콜 , 자주 필요하지 않거나 한 번만 가져오는 오래된 데이터는 간단한 HTTP 요청으로 쿼리할 수 있으므로 이 시나리오에서는 WebSocket을 사용하지 않는 것이 좋습니다.
메모: RESTful 웹 서비스는 데이터를 한 번만 로드하는 경우 서버에서 데이터를 가져오는 데 충분합니다.
HTTP와 WebSocket 연결의 차이점:
| 웹소켓 연결 | HTTP 연결 |
|---|---|
| WebSocket은 설정된 연결 채널을 재사용하여 클라이언트에서 서버로 또는 서버에서 클라이언트로 데이터를 보낼 수 있는 양방향 통신 프로토콜입니다. 연결은 클라이언트나 서버에 의해 종료될 때까지 유지됩니다. | HTTP 프로토콜은 연결 지향 전송 계층 프로토콜인 TCP 프로토콜 위에서 작동하는 단방향 프로토콜입니다. HTTP 연결이 닫히면 응답을 받은 후 HTTP 요청 방법을 사용하여 연결을 생성할 수 있습니다. |
| (거래, 모니터링, 알림) 서비스와 같은 거의 모든 실시간 애플리케이션은 WebSocket을 사용하여 단일 통신 채널에서 데이터를 수신합니다. | 간단한 RESTful 애플리케이션은 상태 비저장 HTTP 프로토콜을 사용합니다. |
| 자주 업데이트되는 모든 애플리케이션은 HTTP 연결보다 빠르기 때문에 WebSocket을 사용했습니다. | 특정 시간 동안 연결을 유지하고 싶지 않거나 데이터 전송을 위해 연결을 재사용하고 싶지 않은 경우 HTTP 연결은 WebSocket보다 느립니다. |
메모: 프로젝트에 따라 WebSocket 또는 HTTP 연결 위치를 선택해야 합니다.