websocket和socket的差別是什麼-常見問題-PHP中文網

區別：Socket是TCP/IP網路的API，是為了方便使用TCP或UDP而抽像出來的一層，是位於應用層和傳輸控制層之間的一組介面；而WebSocket則是一個典型的應用層協定。

websocket和socket的差別是什麼

本教學操作環境：windows7系統、Dell G3電腦。

目的：即時通訊，替代輪詢

網站上的即時通訊是很常見的，例如網頁的QQ，聊天系統等。依照以往的技術能力通常是採用輪詢、Comet技術解決。

HTTP協定是非持久化的，單向的網路協議，在建立連線後只允許瀏覽器向伺服器發出請求後，伺服器才能傳回對應的資料。當需要即時通訊時，透過輪詢在特定的時間間隔（如1秒），由瀏覽器向伺服器發送Request請求，然後將最新的資料傳回瀏覽器。這樣的方法最明顯的缺點就是需要不斷的發送請求，而且通常HTTP request的Header是非常長的，為了傳輸一個很小的資料需要付出巨大的代價，是很不合算的，佔用了很多的寬頻。

缺點：會導致過多不必要的請求，浪費流量和伺服器資源，每一次請求、應答，都浪費了一定流量在相同的頭部資訊上

然而WebSocket的出現可以彌補這一缺點。在WebSocket中，只需要伺服器和瀏覽器透過HTTP協定進行一個握手的動作，然後單獨建立一條TCP的通訊通道進行資料的傳送。

原理

WebSocket同HTTP一樣也是應用層的協議，但是它是一種雙向通訊協議，是建立在TCP之上的。

連接過程 —— 握手過程

1. 瀏覽器、伺服器建立TCP連接，三次握手。這是通訊的基礎，傳輸控制層，若失敗後續都不執行。
2. TCP連線成功後，瀏覽器透過HTTP協定向伺服器傳送WebSocket支援的版本號等資訊。（開始前的HTTP握手）
3. 伺服器收到客戶端的握手請求後，同樣採用HTTP協定回饋資料。
4. 當收到了連接成功的訊息後，透過TCP通道進行傳輸通訊。

WebSocket與HTTP的關係

相同點

1. 都是一樣基於TCP的，都是可靠性傳輸協定。
2. 都是應用層協定。

不同點

1. WebSocket是雙向通訊協議，模擬Socket協議，可以雙向發送或接受訊息。 HTTP是單向的。
2. WebSocket是需要握手才能建立連線的。

聯繫

WebSocket在建立握手時，資料是透過HTTP傳送的。但是建立之後，真正傳輸時候是不需要HTTP協定的。

WebSocket與Socket的關係

Socket其實不是協議，而是為了方便使用TCP或UDP而抽像出來的一層，是位於應用層和傳輸控制層之間的一組介面。

Socket是應用層與TCP/IP協定族通訊的中間軟體抽象層，它是一組介面。在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協定族隱藏在Socket介面後面，對使用者來說，一組簡單的介面就是全部，讓Socket去組織數據，以符合指定的協定.

當兩台主機通訊時，必須透過Socket連接，Socket則利用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
* Apache 對WebSocket 的支援： Apache Module mod_proxy_wstunnel
* Nginx 對WebSockets 的支援： NGINX as a WebSockets Proxy 、 NGINX Announces Support for WebSocket Protocol 、Web#Set projicing * lighttpd 對WebSocket 的支援：mod_websocket

##WebSocket 機制

##以下簡單介紹一下WebSocket 的原理及運作機制。 WebSocket 是 HTML5 一種新的協定。它實現了瀏覽器與伺服器全雙工通信，能更好的節省伺服器資源和頻寬並達到即時通訊，它建立在TCP 之上，同HTTP 一樣透過TCP 來傳輸數據，但是它和HTTP 最大不同是：

WebSocket 是一種雙向通訊協議，在建立連接後，WebSocket 伺服器和Browser/Client Agent 都能主動的向對方發送或接收數據，就像Socket 一樣；

WebSocket 需要類似TCP 的客戶端和伺服器端透過握手連接，連接成功後才能相互通訊。

非WebSocket 模式傳統HTTP 用戶端與伺服器的互動如下圖所示：
圖1. 傳統HTTP 請求回應用戶端伺服器互動圖

#使用WebSocket 模式客戶端與伺服器的互動如下圖：

图 1. 传统 HTTP 请求响应客户端服务器交互图圖2.WebSocket 請求回應客戶端伺服器互動圖

#上圖比較可以看出，相對於傳統HTTP 每次請求-應答都需要客戶端與服務端建立連線的模式，WebSocket 是類似Socket 的TCP 長連線的通訊模式，一旦WebSocket 連線建立後，後續數據都以幀序列的形式傳輸。在用戶端中斷 WebSocket 連線或 Server 端中斷連線前，不需要用戶端和服務端重新發起連線請求。在大量並發及客戶端與伺服器交互負載流量大的情況下，極大的節省了網路頻寬資源的消耗，有明顯的效能優勢，且客戶端發送和接受訊息是在同一個持久連線上發起，即時性優勢明顯。

图 2.WebSocket 请求响应客户端服务器交互图我們再透過客戶端和服務端互動的封包看一下WebSocket 通訊與傳統HTTP 的不同：

在客戶端，new WebSocket 實例化一個新的WebSocket 用戶端對象，連接類似ws://yourdomain:port/path 的服務端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」應答，否則客戶端會拋出「Error during WebSocket handshake」錯誤，並關閉連線。

服務端收到封包後回傳的資料格式類似：

清單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 API 及程式碼實作。

WebSocket 實作

如上文所述，WebSocket 的實作分為客戶端和服務端兩部分，客戶端（通常為瀏覽器）發出WebSocket 連線請求，服務端回應，實現類似TCP 握手的動作，從而在瀏覽器用戶端和WebSocket 服務端之間形成一條HTTP 長連線快速通道。兩者之間後續進行直接的資料互相傳送，不再需要發起連線和對應。

以下簡要描述 WebSocket 服務端 API 及客戶端 API。

WebSocket 服務端API

WebSocket 服務端在各個主流應用伺服器廠商中已基本獲得符合JEE JSR356 標準規範API 的支持，以下列舉了部分常見的商用及開源應用伺服器對WebSocket Server 端的支援情況：

表1.WebSocket 服務端支援

###IBMWebSphereWebSphere 8.0 以上版本支持，7.X 先前版本結合MQTT 支援類似的HTTP 長連接甲骨文WebLogicWebLogic 12c 支持，11g 及10g 版本透過HTTP Publish 支援類似的HTTP 長連線##微軟Apache

以下我们使用 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 客户端支持

廠商	應用程式伺服器	備註


#IIS	IIS 7.0支持
Tomcat	#Tomcat 7.0.5＋支持，7.0.2X 及7.0.3X 透過自訂API 支援
Jetty	Jetty 7.0＋支援

浏览器	支持情况
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中文网！！

以上是websocket和socket的差別是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！