初涉IM，首先我有這么幾個(gè)問題需要弄明白：

1. Socket 和 WebSocket 有哪些區(qū)別和聯(lián)系？
2. WebSocket 和 HTTP 有什么關(guān)系？
3. WebSocket 和 HTML5 是什么關(guān)系？
4. 什么是 長連接/短連接、長輪詢/短輪詢?
5. WebSocket在哪些場(chǎng)景下使用？
6. 如果想做IOS的即時(shí)通訊，是使用Socket還是WebSocket?

通過google查找了大量資料，覺得有必要把相關(guān)內(nèi)容做一個(gè)整理，上面幾個(gè)問題也會(huì)在敘述中逐漸清晰。

1. Socket 和 WebSocket 有哪些區(qū)別和聯(lián)系？

就像Java和JavaScript，北大和北大青鳥，雷鋒和雷峰塔一樣，沒有什么關(guān)系，除了在名字上沾親帶故的以外，就是兩個(gè)完全不同的東西。

WebSocket

WebSocket一種在單個(gè)TCP連接上進(jìn)行全雙工通訊的協(xié)議。WebSocket通信協(xié)議于2011年被IETF定為標(biāo)準(zhǔn)RFC 6455，并被RFC7936所補(bǔ)充規(guī)范。WebSocket API也被W3C定為標(biāo)準(zhǔn)?！S基百科

背景
現(xiàn)在，很多網(wǎng)站為了實(shí)現(xiàn)推送技術(shù)，所用的技術(shù)都是輪詢。輪詢是在特定的時(shí)間間隔（如每1秒）由客戶端對(duì)服務(wù)器發(fā)出HTTP請(qǐng)求，然后由服務(wù)器返回最新的數(shù)據(jù)給客戶端。這種傳統(tǒng)的模式帶來很明顯的缺點(diǎn)，即客戶端需要不斷的向服務(wù)器發(fā)出請(qǐng)求，然而HTTP請(qǐng)求可能包含較長的頭部，其中真正有效的數(shù)據(jù)可能只是很小的一部分，顯然這樣會(huì)浪費(fèi)很多的帶寬等資源。

而比較新的技術(shù)去做輪詢的效果是Comet。這種技術(shù)雖然可以雙向通信，但依然需要反復(fù)發(fā)出請(qǐng)求。而且在Comet中，普遍采用的長鏈接，也會(huì)消耗服務(wù)器資源。
在這種情況下，HTML5定義了WebSocket協(xié)議，能更好的節(jié)省服務(wù)器資源和帶寬，并且能夠更實(shí)時(shí)地進(jìn)行通訊。
Websocket使用ws或wss的統(tǒng)一資源標(biāo)志符，類似于HTTPS，其中wss表示在TLS之上的Websocket。如：

ws://example.com/wsapi
wss://secure.example.com/

Websocket使用和 HTTP 相同的 TCP 端口，可以繞過大多數(shù)防火墻的限制。默認(rèn)情況下，Websocket協(xié)議使用80端口；運(yùn)行在TLS之上時(shí)，默認(rèn)使用443端口。

WebSocket出現(xiàn)的目的：即時(shí)通訊，替代HTTP輪詢

WebSocket 使得客戶端和服務(wù)器之間的數(shù)據(jù)交換變得更加簡單，允許服務(wù)端主動(dòng)向客戶端推送數(shù)據(jù)。在 WebSocket API 中，瀏覽器和服務(wù)器只需要完成一次握手，兩者之間就直接可以創(chuàng)建持久性的連接，并進(jìn)行雙向數(shù)據(jù)傳輸。

（1）最初的輪詢(polling)階段

Polling.png

上圖表明，客戶端發(fā)送一個(gè)request，服務(wù)器不管有沒有新消息，都會(huì)立即返回一個(gè)response，然后關(guān)閉連接，這次HTTP請(qǐng)求結(jié)束。請(qǐng)記住 Request = Response ， 在HTTP1.0和HTTP1.1中都是這樣，也就是說一個(gè)request只能有一個(gè)response對(duì)應(yīng)。客戶端需要不斷執(zhí)行這個(gè)請(qǐng)求過程(也就是輪詢)，查詢服務(wù)端有沒有新的消息(數(shù)據(jù))。

輪詢場(chǎng)景：

Client：親親，有沒有新消息(Request)
Server：木有（Response）
Client：親親，有沒有新消息(Request)
Server：木有。。（Response）
Client：親親，有沒有新消息(Request)
Server：好煩，沒有。。（Response）
Client：那個(gè)。。有沒有新消息（Request）
Server: 有啦，給你（Response）
Client：親親，有沒有新消息（Request）
Server：。。沒。。。沒有（Response）
...
...

從上面可以看出來，客戶端不斷的建立HTTP連接，然后等待服務(wù)端處理，可以提現(xiàn)HTTP協(xié)議的另一個(gè)缺陷：被動(dòng)性，也就是服務(wù)端不能主動(dòng)聯(lián)系客戶端，只能有客戶端發(fā)起。而且，HTTP request的Header是很長的，為了傳輸一個(gè)很小的數(shù)據(jù)卻占用了很多的帶寬流量去傳輸Header?？梢姡喸冃枰?wù)器有很快的處理速度，且非常消耗資源，也不具備即時(shí)性。

（2）長輪詢 (Long polling) 階段

Long Polling.png

Long Polling 是對(duì) Polling 的改進(jìn)，原理跟 Polling 相似，都是采用輪詢的方式，不過Long Polling 采取的是阻塞模型：客戶端發(fā)起連接后，如果服務(wù)端沒有新消息，就一直不返回Response給客戶端。直到有新消息或者超時(shí)才返回給客戶端，返回之后這次請(qǐng)求結(jié)束?？蛻舳嗽俅谓⑦B接，重復(fù)這個(gè)過程。。。。

情景：
Client：親親，有沒有新消息? 沒有的話，等有了再給我吧 (Request)
Server：額。。。~~~ (1小時(shí)后) ~~~ 有新消息了，給你 (Response)
...
...

相比于 Polling ，Long Polling 在某種程度上減小了對(duì)網(wǎng)絡(luò)寬帶的消耗等問題，但缺陷也很明顯：假設(shè)服務(wù)器端的數(shù)據(jù)更新速度很快，服務(wù)器在傳送一個(gè)數(shù)據(jù)包給客戶端后必須等待客戶端的下一個(gè)Get請(qǐng)求到來，才能傳遞第二個(gè)更新的數(shù)據(jù)包給客戶端，那么這樣的話，客戶端顯示實(shí)時(shí)數(shù)據(jù)最快的時(shí)間為2×RTT（往返時(shí)間），而且如果在網(wǎng)絡(luò)擁塞的情況下，這個(gè)時(shí)間用戶是不能接受的，比如在股市的的報(bào)價(jià)上；另外，由于http數(shù)據(jù)包的頭部數(shù)據(jù)量往往很大（通常有400多個(gè)字節(jié)），但是真正被服務(wù)器需要的數(shù)據(jù)卻很少（有時(shí)只有10個(gè)字節(jié)左右），這樣的數(shù)據(jù)包在網(wǎng)絡(luò)上周期性的傳輸，難免對(duì)網(wǎng)絡(luò)帶寬是一種浪費(fèi)；而且 Long Polling 要求服務(wù)器具有高并發(fā)性，也就是同時(shí)接待大量客戶端的能力。

(3) WebSocket
從上面分析可以看出，Polling ，Long Polling 不是最好的方式，Polling 需要服務(wù)端更快的處理速度，Long Polling 需要高并發(fā)性。在這種情況下，WebSocket出現(xiàn)，解決了上面提到的 HTTP 協(xié)議存在的幾個(gè)缺陷。

下面三張圖，是WebSocket建立連接、傳輸數(shù)據(jù)以及關(guān)閉連接的模型，至于為什么放三張相似的圖，因?yàn)椤?。。我覺得這三張圖都挺好看的

1.png

2.jpg

3.png

情景：
Client：親親，我要建立WebSocket協(xié)議，需要的服務(wù)：chat，WebSocket協(xié)議版本:17 （HTTP Request）
Server：ok，確認(rèn)，已升級(jí)為WebSocket協(xié)議 （HTTP Protocols Switched）
Client：麻煩你有新消息的時(shí)候推送給我哦。。
Server：ok，有的時(shí)候會(huì)告訴你的。
Server：balabalabalabala
Server：balabalabalabala
Server：我看到一個(gè)笑話，哈哈哈
Server：哈哈哈哈哈哈哈。。。。。

Websocket是應(yīng)用層第七層上的一個(gè)應(yīng)用層協(xié)議，它必須依賴 HTTP 協(xié)議進(jìn)行一次握手 ，握手成功后，數(shù)據(jù)就直接從 TCP 通道傳輸，與 HTTP 無關(guān)了。
Websocket的數(shù)據(jù)傳輸是以 frame (幀) 形式傳輸?shù)模热鐣?huì)將一條消息分為幾個(gè) frame，按照先后順序傳輸出去。這樣做會(huì)有幾個(gè)好處：

1. 大數(shù)據(jù)的傳輸可以分片傳輸，不用考慮到數(shù)據(jù)大小導(dǎo)致的長度標(biāo)志位不足夠的情況。
2. 和 HTTP 的chunk一樣，可以邊生成數(shù)據(jù)邊傳遞消息，即提高傳輸效率。

一個(gè)典型的Websocket握手請(qǐng)求如下：

客戶端請(qǐng)求
GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: example.com
Origin: http://example.com
Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==
Sec-WebSocket-Version: 13

服務(wù)器回應(yīng)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Location: ws://example.com/

字段說明:

1. Connection必須設(shè)置Upgrade，表示客戶端希望連接升級(jí)。
2. Upgrade字段必須設(shè)置Websocket，表示希望升級(jí)到Websocket協(xié)議。
3. Sec-WebSocket-Key是隨機(jī)的字符串，服務(wù)器端會(huì)用這些數(shù)據(jù)來構(gòu)造出一個(gè)SHA-1的信息摘要。把“Sec-WebSocket-Key”加上一個(gè)特殊字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，然后計(jì)算SHA-1摘要，之后進(jìn)行BASE-64編碼，將結(jié)果做為“Sec-WebSocket-Accept”頭的值，返回給客戶端。如此操作，可以盡量避免普通HTTP請(qǐng)求被誤認(rèn)為Websocket協(xié)議。
4. Sec-WebSocket-Version 表示支持的Websocket版本。RFC6455要求使用的版本是13，之前草案的版本均應(yīng)當(dāng)被棄用。
5. Origin字段是可選的，通常用來表示在瀏覽器中發(fā)起此Websocket連接所在的頁面，類似于Referer。但是，于Referer不同的是，Origin只包含了協(xié)議和主機(jī)名稱。
6. 其他一些定義在HTTP協(xié)議中的字段，如Cookie等，也可以在Websocket中使用。

Socket

Socket并不是一個(gè)協(xié)議，而是為了方便使用TCP或UDP而抽象出來的一層，是位于應(yīng)用層和傳輸控制層之間的一組接口。如果你要使用HTTP來構(gòu)建服務(wù)，那么就不需要關(guān)心Socket，如果你想基于TCP/IP來構(gòu)建服務(wù)，那么Socket可能就是你會(huì)接觸到的API。

網(wǎng)絡(luò)上的兩個(gè)程序通過一個(gè)雙向的通信連接實(shí)現(xiàn)數(shù)據(jù)的交換，這個(gè)連接的一端稱為一個(gè)socket。
建立網(wǎng)絡(luò)通信連接至少要一對(duì)端口號(hào)(socket)。socket本質(zhì)是編程接口(API)，對(duì)TCP/IP的封裝，
TCP/IP也要提供可供程序員做網(wǎng)絡(luò)開發(fā)所用的接口，這就是Socket編程接口；
HTTP是轎車，提供了封裝或者顯示數(shù)據(jù)的具體形式;Socket是發(fā)動(dòng)機(jī)，提供了網(wǎng)絡(luò)通信的能力?！?百度百科

Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口。
在設(shè)計(jì)模式中，Socket其實(shí)就是一個(gè)門面模式，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，
對(duì)用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。 —— XX百科

Paste_Image.png

當(dāng)兩臺(tái)主機(jī)通信時(shí)，必須通過Socket連接，Socket則利用TCP/IP協(xié)議建立TCP連接。
TCP連接則更依靠于底層的IP協(xié)議，IP協(xié)議的連接則依賴于鏈路層等更低層次。
WebSocket則是一個(gè)典型的應(yīng)用層協(xié)議。

2. WebSocket 和 HTTP 有什么關(guān)系？

先看一下這兩個(gè)概念在維基百科中的解釋：

WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C.
WebSocket is designed to be implemented in web browsers and web servers, but it can be used by any client or server application. The WebSocket Protocol is an independent TCP-based protocol. Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an Upgrade request.[1]
The WebSocket protocol enables interaction between a browser and a web server with lower overheads, facilitating real-time data transfer from and to the server. This is made possible by providing a standardized way for the server to send content to the browser without being solicited by the client, and allowing for messages to be passed back and forth while keeping the connection open. In this way, a two-way (bi-directional) ongoing conversation can take place between a browser and the server. The communications are done over TCP port number 80 (or 443 in the case of TLS-encrypted connections), which is of benefit for those environments which block non-web Internet connections using a firewall.

—— From Wikipedia, the free encyclopedia

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, and hypermedia information systems.
HTTP is the foundation of data communication for the World Wide Web.
Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. HTTP is the protocol to exchange or transfer hypertext.
Development of HTTP was initiated by Tim Berners-Lee at CERN in 1989. Standards development of HTTP was coordinated by the Internet Engineering Task Force (IETF) and the World Wide Web Consortium (W3C), culminating in the publication of a series of Requests for Comments (RFCs). The first definition of HTTP/1.1, the version of HTTP in common use, occurred in RFC 2068 in 1997, although this was obsoleted by RFC 2616 in 1999 and then again by RFC 7230 and family in 2014.
A later version, the successor HTTP/2, was standardized in 2015, and is now supported by major web servers.

—— From Wikipedia, the free encyclopedia

相同點(diǎn)：
WebSocket 和 HTTP 都是基于TCP的應(yīng)用層協(xié)議，都是可靠性傳輸協(xié)議。

不同點(diǎn)：

1. 本來就是兩種完全不同的協(xié)議。。。
2. WebSocket 是全雙工協(xié)議，可以雙向發(fā)送或接受信息，連接建立之后，通信雙方都可以在任何時(shí)刻向另一方發(fā)送數(shù)據(jù)。HTTP請(qǐng)求需要等待客戶端發(fā)起請(qǐng)求服務(wù)端才能響應(yīng)。
3. 與 HTTP 不同的是，Websocket 需要先創(chuàng)建連接，這就使得其成為一種有狀態(tài)的協(xié)議，之后通信時(shí)可以省略部分狀態(tài)信息。而HTTP請(qǐng)求可能需要在每個(gè)請(qǐng)求都攜帶狀態(tài)信息（如身份認(rèn)證等）
4. Websocket定義了二進(jìn)制幀，相對(duì)HTTP，可以更輕松地處理二進(jìn)制內(nèi)容。
5. HTTP 協(xié)議要不斷的建立，關(guān)閉Request，由于HTTP是無狀態(tài)協(xié)議，每一次發(fā)送都是一次新的開始，所以每次都要重新傳輸identity info (鑒別信息)，來告訴服務(wù)端你是誰。Websocket 只需要一次HTTP握手，所以說整個(gè)通訊過程是建立在一次連接狀態(tài)中，也就避免了HTTP的非狀態(tài)性，服務(wù)端會(huì)一直知道你的信息，直到你關(guān)閉請(qǐng)求，這樣就可以避免反復(fù)解析HTTP協(xié)議，還要查看identity info（鑒別信息）。

聯(lián)系：
Websocket 通過 HTTP/1.1 協(xié)議的101狀態(tài)碼進(jìn)行握手。
為了創(chuàng)建Websocket連接，需要通過客戶端發(fā)出請(qǐng)求，之后服務(wù)器進(jìn)行回應(yīng)，這個(gè)過程通常稱為“握手”（handshaking）。

雖然WebSocket在握手的時(shí)候是通過 HTTP 進(jìn)行的（為了兼容性考慮，也許以后WebSocket會(huì)有自己的握手方式），但也僅僅是這樣而已，它們就是兩種不同的應(yīng)用層協(xié)議。

3. WebSocket 和 HTML5 是什么關(guān)系？

HTML5是指的一系列新的API，或者說新規(guī)范，新技術(shù)。而WebSocket就是HTML5中出的的一種協(xié)議。

4. 什么是 長連接/短連接、長輪詢/短輪詢?

查了許多資料，于是總結(jié)一下自己的理解：

長連接/短連接，長輪詢/短輪詢 本身就是不通層次的概念。

長/短連接 是針對(duì)TCP傳輸層的概念，也就是，TCP連接才有長/短連接之說。

短連接是指通訊雙方有數(shù)據(jù)交互時(shí)，就建立一個(gè)TCP連接，數(shù)據(jù)發(fā)送完成后，則斷開此連接，即每次連接只完成一項(xiàng)業(yè)務(wù)的發(fā)送。

長連接指在一個(gè)TCP連接上可以連續(xù)發(fā)送多個(gè)數(shù)據(jù)包，在連接保持期間，如果沒有數(shù)據(jù)包發(fā)送，需要TCP keep alive。TCP keep alive 的兩種方式：

1. 應(yīng)用層面的心跳機(jī)制
   自定義心跳消息頭 ： 一般客戶端主動(dòng)發(fā)送, 服務(wù)器接收后進(jìn)行回應(yīng)(也可以不回應(yīng)).
2. TCP協(xié)議自帶的 keep alive：打開keep-alive功能即可. 具體屬性也可以通過API設(shè)定.

TCP KeepAlive 是用于檢測(cè)TCP連接的狀態(tài)，而心跳機(jī)制有兩個(gè)作用：一是檢測(cè)TCP的狀態(tài)，二是檢測(cè)通訊雙方的狀體。

考慮一種情況，某臺(tái)服務(wù)器因?yàn)槟承┰驅(qū)е仑?fù)載超高，CPU 100%，無法響應(yīng)任何業(yè)務(wù)請(qǐng)求，但是使用 TCP 探針則仍舊能夠確定連接狀態(tài)，這就是典型的連接活著但業(yè)務(wù)提供方已死的狀態(tài)，對(duì)客戶端而言，這時(shí)的最好選擇就是斷線后重新連接其他服務(wù)器，而不是一直認(rèn)為當(dāng)前服務(wù)器是可用狀態(tài)，一直向當(dāng)前服務(wù)器發(fā)送些必然會(huì)失敗的請(qǐng)求。

從上面我們可以知道，KeepAlive 并不適用于檢測(cè)雙方存活的場(chǎng)景，這種場(chǎng)景還得依賴于應(yīng)用層的心跳。應(yīng)用層心跳有著更大的靈活性，可以控制檢測(cè)時(shí)機(jī)，間隔和處理流程，甚至可以在心跳包上附帶額外信息。從這個(gè)角度而言，應(yīng)用層的心跳的確是最佳實(shí)踐。

寫到這順便說一下 HTTP Keep Alive 和 TCP keep alive 這兩個(gè)看上去肯定有點(diǎn)兒啥關(guān)系的概念。事實(shí)上，HTTP keep-alive與TCP keep-alive 是兩個(gè)完全沒有關(guān)系的東西。

HTTP keep-alive是HTTP協(xié)議的一個(gè)特性，目的是為了讓TCP連接保持的更久一點(diǎn)，以便客戶端/服務(wù)端在同一個(gè)TCP連接上可以發(fā)送多個(gè)HTTP request/response。

TCP keep-alive是一種檢測(cè)連接狀況的保活機(jī)制。It keeps TCP connection opened by sending small packets. 當(dāng)網(wǎng)絡(luò)兩端建立了TCP連接之后，閑置idle（雙方?jīng)]有任何數(shù)據(jù)流發(fā)送往來）了tcp_keepalive_time后，服務(wù)器內(nèi)核就會(huì)嘗試向客戶端發(fā)送偵測(cè)包，來判斷TCP連接狀況(有可能客戶端崩潰、強(qiáng)制關(guān)閉了應(yīng)用、主機(jī)不可達(dá)等等)。如果沒有收到對(duì)方的回答(ack包)，則會(huì)在 tcp_keepalive_intvl后再次嘗試發(fā)送偵測(cè)包，直到收到對(duì)對(duì)方的ack,如果一直沒有收到對(duì)方的ack,一共會(huì)嘗試 tcp_keepalive_probes次，每次的間隔時(shí)間在這里分別是15s, 30s, 45s, 60s, 75s。如果嘗試tcp_keepalive_probes,依然沒有收到對(duì)方的ack包，則會(huì)丟棄該TCP連接。TCP連接默認(rèn)閑置時(shí)間是2小時(shí)，一般設(shè)置為30分鐘足夠了。

既然長/短連接是針對(duì)TCP的概念，但是我們卻經(jīng)?？吹?code>HTTP 長連接（HTTP persistent connection）這樣的說法，到底什么鬼？憋急，先看一段解釋：

HTTP persistent connection, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using a single TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new connection for every single request/response pair. The newer HTTP/2 protocol uses the same idea and takes it further to allow multiple concurrent requests/responses to be multiplexed over a single connection.

—— From Wikipedia, the free encyclopedia

可以發(fā)現(xiàn)，HTTP persistent connection就是上面我們解釋的HTTP Keep Alive。其實(shí)很簡單，TCP長連接是針對(duì)TCP層的概念，就是讓一個(gè)TCP連接長時(shí)間保持不要斷開。HTTP的長連接(keep alive)是HTTP協(xié)議的一個(gè)特性，也是希望保持住長時(shí)間的TCP連接，才能在這個(gè)TCP通道上發(fā)送多個(gè)HTTP請(qǐng)求，而不必每次請(qǐng)求都打開一個(gè)新的TCP連接。

長輪詢/短輪詢 在上文已經(jīng)介紹了，它是服務(wù)器的實(shí)現(xiàn)方式！由服務(wù)端編寫的代碼決定。

5. WebSocket在哪些場(chǎng)景下使用？

1.社交聊天

最著名的就是微信，QQ，這一類社交聊天的app。這一類聊天app的特點(diǎn)是低延遲，高即時(shí)。即時(shí)是這里面要求最高的，如果有一個(gè)緊急的事情，通過IM軟件通知你，假設(shè)網(wǎng)絡(luò)環(huán)境良好的情況下，這條message還無法立即送達(dá)到你的客戶端上，緊急的事情都結(jié)束了，你才收到消息，那么這個(gè)軟件肯定是失敗的。

2.彈幕

說到這里，大家一定里面想到了A站和B站了。確實(shí)，他們的彈幕一直是一種特色。而且彈幕對(duì)于一個(gè)視頻來說，很可能彈幕才是精華。發(fā)彈幕需要實(shí)時(shí)顯示，也需要和聊天一樣，需要即時(shí)。

3.多玩家游戲

4.協(xié)同編輯

現(xiàn)在很多開源項(xiàng)目都是分散在世界各地的開發(fā)者一起協(xié)同開發(fā)，此時(shí)就會(huì)用到版本控制系統(tǒng)，比如Git，SVN去合并沖突。但是如果有一份文檔，支持多人實(shí)時(shí)在線協(xié)同編輯，那么此時(shí)就會(huì)用到比如WebSocket了，它可以保證各個(gè)編輯者都在編輯同一個(gè)文檔，此時(shí)不需要用到Git，SVN這些版本控制，因?yàn)樵趨f(xié)同編輯界面就會(huì)實(shí)時(shí)看到對(duì)方編輯了什么，誰在修改哪些段落和文字。

5.股票基金實(shí)時(shí)報(bào)價(jià)

金融界瞬息萬變——幾乎是每毫秒都在變化。如果采用的網(wǎng)絡(luò)架構(gòu)無法滿足實(shí)時(shí)性，那么就會(huì)給客戶帶來巨大的損失。幾毫秒錢股票開始大跌，幾秒以后才刷新數(shù)據(jù)，一秒鐘的時(shí)間內(nèi)，很可能用戶就已經(jīng)損失巨大財(cái)產(chǎn)了。

6.體育實(shí)況更新

全世界的球迷，體育愛好者特別多，當(dāng)然大家在關(guān)心自己喜歡的體育活動(dòng)的時(shí)候，比賽實(shí)時(shí)的賽況是他們最最關(guān)心的事情。這類新聞中最好的體驗(yàn)就是利用Websocket達(dá)到實(shí)時(shí)的更新！

7.視頻會(huì)議/聊天

視頻會(huì)議并不能代替和真人相見，但是他能讓分布在全球天涯海角的人聚在電腦前一起開會(huì)。既能節(jié)省大家聚在一起路上花費(fèi)的時(shí)間，討論聚會(huì)地點(diǎn)的糾結(jié)，還能隨時(shí)隨地，只要有網(wǎng)絡(luò)就可以開會(huì)。

8.基于位置的應(yīng)用

越來越多的開發(fā)者借用移動(dòng)設(shè)備的GPS功能來實(shí)現(xiàn)他們基于位置的網(wǎng)絡(luò)應(yīng)用。如果你一直記錄用戶的位置(比如運(yùn)行應(yīng)用來記錄運(yùn)動(dòng)軌跡)，你可以收集到更加細(xì)致化的數(shù)據(jù)。

9.在線教育

在線教育近幾年也發(fā)展迅速。優(yōu)點(diǎn)很多，免去了場(chǎng)地的限制，能讓名師的資源合理的分配給全國各地想要學(xué)習(xí)知識(shí)的同學(xué)手上，Websocket是個(gè)不錯(cuò)的選擇，可以視頻聊天、即時(shí)聊天以及其與別人合作一起在網(wǎng)上討論問題…

10.智能家居

這也是我一畢業(yè)加入的一個(gè)偉大的物聯(lián)網(wǎng)智能家居的公司。考慮到家里的智能設(shè)備的狀態(tài)必須需要實(shí)時(shí)的展現(xiàn)在手機(jī)app客戶端上，毫無疑問選擇了Websocket。

從上面我列舉的這些場(chǎng)景來看，一個(gè)共同點(diǎn)就是，高實(shí)時(shí)性！

6. 如果想做IOS的即時(shí)通訊，是使用Socket還是WebSocket?

使用 Socket 和 WebSocket 都可以做即時(shí)通訊。具體怎么做呢？公司項(xiàng)目IOS端使用了第三方庫 CocoaAsynSocket ，它是對(duì)socket的OC封裝，支持TCP、UDP連接。CocoaAsynSocket 的使用非常簡單，也有官方和其他資料可以查找，這里就不啰嗦了。這篇文章只是對(duì)即時(shí)通訊涉及的一些基本概念，根據(jù)我自己的理解，做一個(gè)總結(jié)，如果有不對(duì)的地方還請(qǐng)不吝指正，感激不盡！