웹소켓과 소켓의 차이점은 무엇입니까-일반적인 문제-php.cn

차이점: 소켓은 TCP/IP 네트워크의 API이며 TCP 또는 UDP의 사용을 용이하게 하기 위해 추상화된 계층입니다. 이는 애플리케이션 계층과 전송 제어 계층 사이의 인터페이스 집합입니다. 애플리케이션 계층 프로토콜.

웹소켓과 소켓의 차이점은 무엇입니까

이 튜토리얼의 운영 환경: Windows 7 시스템, Dell G3 컴퓨터.

관련 추천: "프로그래밍 비디오"

WebSocket 소개 및 원리

WebSocket 프로토콜은 HTML5의 새로운 프로토콜입니다. 브라우저와 서버 간의 전이중 통신을 구현합니다. 초기 핸드셰이크는 HTTP 요청을 통해 완료되어야 합니다.

——Baidu Encyclopedia

목적: 인스턴트 메시징, 폴링의 대안

웹사이트에서의 즉각적인 메시징은 웹 페이지의 QQ, 채팅 시스템 등과 같이 매우 일반적입니다. 이전 기술 역량에 따르면 이 문제를 해결하기 위해 일반적으로 폴링 및 Comet 기술이 사용됩니다.

HTTP 프로토콜은 연결이 설정된 후 서버가 해당 데이터를 반환하기 전에만 브라우저가 서버에 요청할 수 있는 비영구적 단방향 네트워크 프로토콜입니다. 인스턴트 메시징이 필요한 경우 브라우저는 특정 시간 간격(예: 1초)마다 폴링을 통해 서버에 요청 요청을 보낸 다음 최신 데이터를 브라우저에 반환합니다. 이 방법의 가장 분명한 단점은 지속적으로 요청을 보내야 한다는 점이며, 일반적으로 HTTP 요청의 헤더가 매우 길다는 점입니다. 적은 양의 데이터를 전송하려면 막대한 비용을 지불해야 하므로 매우 비경제적입니다. 그리고 대역폭을 많이 차지합니다.

단점: 불필요한 요청이 너무 많아 트래픽과 서버 리소스를 낭비하게 됩니다. 모든 요청과 응답은 동일한 헤더 정보에 일정량의 트래픽을 낭비합니다.

그러나 WebSocket의 등장은 이러한 단점을 보완할 수 있습니다. WebSocket에서는 서버와 브라우저가 HTTP 프로토콜을 통해 핸드셰이크 작업을 수행한 다음 데이터 전송을 위해 별도의 TCP 통신 채널을 설정하기만 하면 됩니다.

Principle

WebSocket은 HTTP와 같은 애플리케이션 계층 프로토콜이지만 TCP를 기반으로 구축된 양방향 통신 프로토콜입니다.

연결 프로세스 - 핸드셰이크 프로세스

1. 브라우저와 서버가 TCP 연결, 3방향 핸드셰이크를 설정합니다. 이는 통신의 기본인 전송 제어 계층에서 실패하면 나중에 실행되지 않습니다.
2. TCP 연결이 성공한 후 브라우저는 WebSocket이 지원하는 버전 번호 등의 정보를 HTTP 프로토콜을 통해 서버로 전송합니다. (시작 전 HTTP 핸드셰이크)
3. 클라이언트의 핸드셰이크 요청을 받은 후 서버도 HTTP 프로토콜을 사용하여 데이터를 피드백합니다.
4. 연결 성공 메시지를 받은 후 TCP 채널을 통해 통신이 전송됩니다.

WebSocket과 HTTP의 관계

동일점

1 둘 다 TCP를 기반으로 하며 둘 다 안정적인 전송 프로토콜입니다.
2. 모두 애플리케이션 계층 프로토콜입니다.

차이점

1. WebSocket은 소켓 프로토콜을 시뮬레이션하고 양방향으로 정보를 보내거나 받을 수 있는 양방향 통신 프로토콜입니다. HTTP는 단방향입니다.
2. WebSocket을 연결하려면 핸드셰이크가 필요합니다.

연락처

WebSocket 핸드셰이크를 설정할 때 데이터는 HTTP를 통해 전송됩니다. 그러나 설정 후 실제 전송 중에는 HTTP 프로토콜이 필요하지 않습니다.

WebSocket과 Socket의 관계

Socket은 실제로 프로토콜이 아니라 TCP 또는 UDP 사용의 편의를 위해 추상화된 계층입니다. 애플리케이션 계층과 전송 제어 계층 사이의 인터페이스 집합입니다.

Socket은 애플리케이션 계층과 TCP/IP 프로토콜 제품군 간의 통신을 위한 중간 소프트웨어 추상화 계층입니다. 디자인 모드에서 소켓은 실제로 소켓 인터페이스 뒤에 복잡한 TCP/IP 프로토콜 제품군을 숨기는 파사드 모드입니다. 사용자에게는 소켓이 지정된 프로토콜을 준수하도록 데이터를 구성할 수 있는 간단한 인터페이스 세트가 전부입니다.

두 호스트가 통신할 때는 소켓을 통해 연결해야 하며 소켓은 TCP/IP 프로토콜을 사용하여 TCP 연결을 설정합니다. TCP 연결은 기본 IP 프로토콜에 더 많이 의존하는 반면, IP 프로토콜 연결은 링크 계층과 같은 하위 계층에 의존합니다.

WebSocket은 일반적인 애플리케이션 계층 프로토콜입니다.

차이점

Socket은 전송 제어 계층 프로토콜이고 WebSocket은 애플리케이션 계층 프로토콜입니다.

HTML5와 WebSocket의 관계

WebSocket API는 HTML5 표준의 일부이지만 이것이 WebSocket을 HTML에서 사용해야 한다거나 브라우저 기반 애플리케이션에서만 사용할 수 있다는 의미는 아닙니다.

실제로 다음과 같은 많은 언어, 프레임워크 및 서버가 WebSocket 지원을 제공합니다.

* C 기반 libwebsocket.org
* Node.js 기반 Socket.io
* Python 기반 ws4py
* C++ 기반 WebSocket++
* WebSocket에 대한 Apache 지원: Apache 모듈 mod_proxy_wstunnel
* Ngin x WebSocket 지원: WebSocket 프록시로서의 NGINX, NGINX는 WebSocket 프로토콜, WebSocket 프록시에 대한 지원 발표
* lighttpd WebSocket 지원: mod_websocket

WebSocket 메커니즘

다음은 WebSocket에 대한 간략한 소개입니다. 메커니즘의 작동.

WebSocket은 HTML5의 새로운 프로토콜입니다. 브라우저와 서버 간의 전이중 통신을 실현하여 서버 리소스와 대역폭을 더 효율적으로 절약하고 실시간 통신을 실현합니다. TCP를 기반으로 하며 HTTP처럼 TCP를 통해 데이터를 전송합니다. 그러나 HTTP와의 가장 큰 차이점은 다음과 같습니다.

WebSocket은 연결이 설정된 후 소켓과 마찬가지로 WebSocket 서버와 브라우저/클라이언트 에이전트가 서로 적극적으로 데이터를 주고받을 수 있습니다.
WebSocket에는 TCP와 같은 클라이언트와 서버가 필요합니다. 두 끝은 핸드셰이크를 통해 연결되며 연결이 성공한 후에만 서로 통신할 수 있습니다.

WebSocket이 아닌 모드에서 기존 HTTP 클라이언트와 서버 간의 상호 작용은 아래 그림과 같습니다.

그림 1. 기존 HTTP 요청 응답 클라이언트-서버 상호 작용 다이어그램

图 1. 传统 HTTP 请求响应客户端服务器交互图

클라이언트와 서버 간의 상호 작용 WebSocket 모드는 다음과 같습니다.

그림 2. WebSocket 요청 응답 클라이언트-서버 상호 작용 다이어그램

图 2.WebSocket 请求响应客户端服务器交互图

위 그림의 비교는 각 요청-응답에서 클라이언트가 서버와의 연결에서 WebSocket은 소켓 TCP 긴 연결 통신 모드와 유사하며, WebSocket 연결이 설정되면 후속 데이터가 프레임 시퀀스 형식으로 전송됩니다. 클라이언트가 WebSocket 연결을 끊거나 서버가 연결을 끊기 전에 클라이언트와 서버가 연결 요청을 다시 시작할 필요가 없습니다. 클라이언트와 서버 간의 대규모 동시성 및 과도한 대화형 로드 트래픽의 경우 네트워크 대역폭 리소스 소비를 크게 절약하고 클라이언트가 동일한 영구 연결에서 실시간으로 메시지를 보내고 받을 수 있다는 확실한 성능 이점을 제공합니다. . 성적 이점은 분명합니다.

클라이언트와 서버 간의 대화형 메시지를 통해 WebSocket 통신과 기존 HTTP의 차이점을 살펴보겠습니다.

클라이언트에서 새 WebSocket은 새 WebSocket 클라이언트 개체를 인스턴스화하고 연결은 ws:/와 유사합니다. /yourdomain: 포트/경로의 서버 WebSocket URL, WebSocket 클라이언트 개체는 이를 WebSocket 요청으로 자동으로 구문 분석하고 식별하여 서버 포트를 연결하고 두 당사자 간에 핸드셰이크 프로세스를 수행합니다. 클라이언트는 유사합니다.

목록 1. WebSocket 클라이언트 연결 보고서

GET /webfin/websocket/ HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: xqBt3ImNzJbYqRINxEFlkg==
Origin: 
http://localhost
:8080
Sec-WebSocket-Version: 13
http://localhost
:8080
Sec-WebSocket-Version: 13

로그인 후 복사

기사에서 볼 수 있듯이 클라이언트가 시작한 WebSocket 연결 메시지는 기존 HTTP 메시지와 유사합니다. "Upgrade: websocket" 매개변수 값은 다음을 나타냅니다. 이는 WebSocket 유형 요청입니다. "Sec-WebSocket-Key"는 WebSocket 클라이언트가 보낸 요청입니다. base64로 인코딩된 암호문은 서버가 해당 암호화된 "Sec-WebSocket-Accept" 응답을 반환하도록 요구합니다. 그렇지 않으면 클라이언트가 오류를 발생시킵니다. "WebSocket 핸드셰이크 중 오류 발생" 오류가 발생하고 연결을 닫습니다.

메시지를 받은 후 서버가 반환하는 데이터 형식은 다음과 유사합니다.

목록 2. WebSocket 서버 응답 메시지

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

로그인 후 복사

"Sec-WebSocket-Accept" 값은 클라이언트와 동일한 키를 사용하여 서버에서 계산됩니다. 나온 후 클라이언트에 반환되는 "HTTP/1.1 101 Switching Protocols"는 서버가 WebSocket 프로토콜의 클라이언트 연결을 수락했음을 나타냅니다. 이러한 요청-응답 처리 후 클라이언트 서버의 WebSocket 연결 핸드셰이크가 성공하고 후속 TCP 통신이 가능해집니다. 수행됩니다.

개발 측면에서도 WebSocket API는 매우 간단합니다. WebSocket을 인스턴스화하고 연결만 생성하면 서버와 클라이언트가 서로 메시지를 보내고 응답할 수 있습니다. 아래 WebSocket 구현 및 사례 분석 섹션.

WebSocket 구현

위에서 언급했듯이 WebSocket의 구현은 클라이언트와 서버의 두 부분으로 나뉩니다. 클라이언트(일반적으로 브라우저)는 WebSocket 연결 요청을 발행하고 서버는 TCP 핸드셰이크와 유사한 구현 작업에 응답합니다. , 브라우저 클라이언트와 WebSocket 서버 사이에 HTTP 긴 연결 빠른 채널이 형성됩니다. 둘 사이의 후속 직접 데이터 전송을 통해 연결을 시작하고 응답할 필요가 없습니다.

다음은 WebSocket 서버 API와 클라이언트 API에 대한 간략한 설명입니다.

WebSocket 서버 API

WebSocket 서버는 기본적으로 JEE JSR356 표준 API를 준수하는 다양한 주류 애플리케이션 서버 제조업체에서 지원되었습니다. 다음은 WebSocket 서버에 대한 몇 가지 일반적인 상용 및 오픈 소스 애플리케이션 서버의 지원 목록입니다.

표 1 .WebSocket 서버 지원

Manufacturer	Application Server	Remarks
IBM	WebSphere	WebSphere 8.0 이상 지원, MQTT와 결합된 이전 버전 7.X는 유사한 HTTP 긴 연결을 지원합니다
오라클	WebLogic	WebLogic 12c 지원, 11g 및 10g 버전은 HTTP Publish
Microsoft	IIS	IIS 7.0+ 지원
Apache	Tomcat	Tomcat을 통해 유사한 HTTP 긴 연결을 지원합니다. 7.0.5+ 지원, 맞춤형 API를 통해 7.0.2X 및 7.0.3X 지원
	Jetty	Jetty 7.0+ 지원

以下我们使用 Tomcat7.0.5 版本的服务端示例代码说明 WebSocket 服务端的实现：

JSR356 的 WebSocket 规范使用 javax.websocket.*的 API，可以将一个普通 Java 对象（POJO）使用 @ServerEndpoint 注释作为 WebSocket 服务器的端点，代码示例如下：

清单 3.WebSocket 服务端 API 示例

 @ServerEndpoint("/echo")
 public class EchoEndpoint {

 @OnOpen
 public void onOpen(Session session) throws IOException {
 //以下代码省略...
 }
 
 @OnMessage
 public String onMessage(String message) {
 //以下代码省略...
 }

 @Message(maxMessageSize=6)
 public void receiveMessage(String s) {
 //以下代码省略...
 } 

 @OnError
 public void onError(Throwable t) {
 //以下代码省略...
 }
 
 @OnClose
 public void onClose(Session session, CloseReason reason) {
 //以下代码省略...
 } 
 
 }

로그인 후 복사

代码解释：

上文的简洁代码即建立了一个 WebSocket 的服务端，@ServerEndpoint("/echo") 的 annotation 注释端点表示将 WebSocket 服务端运行在 ws://[Server 端 IP 或域名]:[Server 端口]/websockets/echo 的访问端点，客户端浏览器已经可以对 WebSocket 客户端 API 发起 HTTP 长连接了。

使用 ServerEndpoint 注释的类必须有一个公共的无参数构造函数，@onMessage 注解的 Java 方法用于接收传入的 WebSocket 信息，这个信息可以是文本格式，也可以是二进制格式。

OnOpen 在这个端点一个新的连接建立时被调用。参数提供了连接的另一端的更多细节。Session 表明两个 WebSocket 端点对话连接的另一端，可以理解为类似 HTTPSession 的概念。

OnClose 在连接被终止时调用。参数 closeReason 可封装更多细节，如为什么一个 WebSocket 连接关闭。

更高级的定制如 @Message 注释，MaxMessageSize 属性可以被用来定义消息字节最大限制，在示例程序中，如果超过 6 个字节的信息被接收，就报告错误和连接关闭。

注意：早期不同应用服务器支持的 WebSocket 方式不尽相同，即使同一厂商，不同版本也有细微差别，如 Tomcat 服务器 7.0.5 以上的版本都是标准 JSR356 规范实现，而 7.0.2x/7.0.3X 的版本使用自定义 API （WebSocketServlet 和 StreamInbound，前者是一个容器，用来初始化 WebSocket 环境；后者是用来具体处理 WebSocket 请求和响应，详见案例分析部分），且 Tomcat7.0.3x 与 7.0.2x 的 createWebSocketInbound 方法的定义不同，增加了一个 HttpServletRequest 参数，使得可以从 request 参数中获取更多 WebSocket 客户端的信息，如下代码所示：

清单 4.Tomcat7.0.3X 版本 WebSocket API

public class EchoServlet extends WebSocketServlet {
@Override
protected StreamInbound createWebSocketInbound(String subProtocol,
HttpServletRequest request) {
 //以下代码省略....
return new MessageInbound() {
 //以下代码省略....
}
protected void onBinaryMessage(ByteBuffer buffer)
throws IOException {
 //以下代码省略...
}
protected void onTextMessage(CharBuffer buffer) throws IOException {
 getWsOutbound().writeTextMessage(buffer);
 //以下代码省略...
}
};
}
}

로그인 후 복사

因此选择 WebSocket 的 Server 端重点需要选择其版本，通常情况下，更新的版本对 WebSocket 的支持是标准 JSR 规范 API，但也要考虑开发易用性及老版本程序移植性等方面的问题，如下文所述的客户案例，就是因为客户要求统一应用服务器版本所以使用的 Tomcat 7.0.3X 版本的 WebSocketServlet 实现，而不是 JSR356 的 @ServerEndpoint 注释端点。

WebSocket 客户端 API

对于 WebSocket 客户端，主流的浏览器（包括 PC 和移动终端）现已都支持标准的 HTML5 的 WebSocket API，这意味着客户端的 WebSocket JavaScirpt 脚本具备良好的一致性和跨平台特性，以下列举了常见的浏览器厂商对 WebSocket 的支持情况：

表 2.WebSocket 客户端支持

浏览器	支持情况
Chrome	Chrome version 4+支持
Firefox	Firefox version 5+支持
IE	IE version 10+支持
Safari	IOS 5+支持
Android Brower	Android 4.5+支持

客户端 WebSocket API 基本上已经在各个主流浏览器厂商中实现了统一，因此使用标准 HTML5 定义的 WebSocket 客户端的 JavaScript API 即可，当然也可以使用业界满足 WebSocket 标准规范的开源框架，如 Socket.io。

以下以一段代码示例说明 WebSocket 的客户端实现：

清单 5.WebSocket 客户端 API 示例

var ws = new WebSocket(“ws://echo.websocket.org”); 
 ws.onopen = function(){ws.send(“Test!”); }; 
 ws.onmessage = function(evt){console.log(evt.data);ws.close();}; 
 ws.onclose = function(evt){console.log(“WebSocketClosed!”);}; 
 ws.onerror = function(evt){console.log(“WebSocketError!”);};

로그인 후 복사

第一行代码是在申请一个 WebSocket 对象，参数是需要连接的服务器端的地址，同 HTTP 协议开头一样，WebSocket 协议的 URL 使用 ws://开头，另外安全的 WebSocket 协议使用 wss://开头。

第二行到第五行为 WebSocket 对象注册消息的处理函数，WebSocket 对象一共支持四个消息 onopen, onmessage, onclose 和 onerror，有了这 4 个事件，我们就可以很容易很轻松的驾驭 WebSocket。

当 Browser 和 WebSocketServer 连接成功后，会触发 onopen 消息；如果连接失败，发送、接收数据失败或者处理数据出现错误，browser 会触发 onerror 消息；当 Browser 接收到 WebSocketServer 发送过来的数据时，就会触发 onmessage 消息，参数 evt 中包含 Server 传输过来的数据；当 Browser 接收到 WebSocketServer 端发送的关闭连接请求时，就会触发 onclose 消息。我们可以看出所有的操作都是采用异步回调的方式触发，这样不会阻塞 UI，可以获得更快的响应时间，更好的用户体验。

想要查阅更多相关文章，请访问PHP中文网！！

위 내용은 웹소켓과 소켓의 차이점은 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!