摘要：解決問題即時通信要解決三方面的問題雙全工通信低延時支持跨域各種即時通信技術(shù)輪詢客戶端定時向服務(wù)器發(fā)送請求，服務(wù)器接到請求后馬上返回響應(yīng)信息并關(guān)閉連接。優(yōu)點(diǎn)實(shí)現(xiàn)真正的即時通信，而不是偽即時。

即時通信要解決三方面的問題：

雙全工通信

低延時

支持跨域

客戶端定時向服務(wù)器發(fā)送Ajax請求，服務(wù)器接到請求后馬上返回響應(yīng)信息并關(guān)閉連接。
優(yōu)點(diǎn)：后端程序編寫比較容易。
缺點(diǎn)：請求中有大半是無用，浪費(fèi)帶寬和服務(wù)器資源。
實(shí)例：適于小型應(yīng)用。

客戶端向服務(wù)器發(fā)送Ajax請求，服務(wù)器接到請求后hold住連接，直到有新消息才返回響應(yīng)信息并關(guān)閉連接，客戶端處理完響應(yīng)信息后再向服務(wù)器發(fā)送新的請求。
優(yōu)點(diǎn)：在無消息的情況下不會頻繁的請求。
缺點(diǎn)：服務(wù)器hold連接會消耗資源。
實(shí)例：WebQQ、Hi網(wǎng)頁版、Facebook IM。

在頁面里嵌入一個隱蔵iframe，將這個隱蔵iframe的src屬性設(shè)為對一個長連接或是采用xhr請求的請求，服務(wù)器端就能源源不斷地往客戶端輸入數(shù)據(jù)。
優(yōu)點(diǎn)：消息即時到達(dá)，不發(fā)無用請求。
缺點(diǎn)：服務(wù)器維護(hù)一個長連接會增加開銷。
實(shí)例：Gmail聊天
技術(shù)細(xì)節(jié)：
● XHR 利用onreadystatechange=3去做一些事：當(dāng)它的readyState為3的時候，獲取它的responseText然后進(jìn)行處理，readyState為3表示數(shù)據(jù)傳送中，整個通信過程還沒有結(jié)束，所以它還在不斷獲取服務(wù)端發(fā)送過來的數(shù)據(jù)，直到readyState為4的時候才表示數(shù)據(jù)發(fā)送完畢，一次通信過程結(jié)束。
● 利用Iframe做一些事： 低版本的IE不允許在XHR的readyState為3的時候獲取其responseText屬性，為了達(dá)到在IE上使用這個技術(shù)，又出現(xiàn)了基于iframe的數(shù)據(jù)流通信方式。在瀏覽器中動態(tài)載入一個iframe,讓它的src屬性指向請求的服務(wù)器的URL，實(shí)際上就是向服務(wù)器發(fā)送了一個http請求，然后在瀏覽器端創(chuàng)建一個處理數(shù)據(jù)的函數(shù)，在服務(wù)端通過iframe與瀏覽器的長連接定時輸出數(shù)據(jù)給客戶端，但是這個返回的數(shù)據(jù)并不是一般的數(shù)據(jù)，而是一個類似于腳本執(zhí)行的方式，瀏覽器接收到這個數(shù)據(jù)就會將它解析成js代碼并找到頁面上指定的函數(shù)去執(zhí)行，實(shí)際上是服務(wù)端間接使用自己的數(shù)據(jù)間接調(diào)用了客戶端的代碼，達(dá)到實(shí)時更新客戶端的目的。
● 動態(tài)生成一個htmlfile對象，這個對象ActiveX形式的com組件，它實(shí)際上就是一個在內(nèi)存中實(shí)現(xiàn)的HTML文檔，通過將生成的iframe添加到這個內(nèi)存中的HTMLfile中，并利用iframe的數(shù)據(jù)流通信方式達(dá)到上面的效果。同時由于HTMLfile對象并不是直接添加到頁面上的，所以并沒有造成瀏覽器顯示正在加載的現(xiàn)象。代碼如下。

在頁面中內(nèi)嵌入一個使用了Socket類的 Flash 程序JavaScript通過調(diào)用此Flash程序提供的Socket接口與服務(wù)器端的Socket接口進(jìn)行通信，JavaScript在收到服務(wù)器端傳送的信息后控制頁面的顯示。
優(yōu)點(diǎn)：實(shí)現(xiàn)真正的即時通信，而不是偽即時。
缺點(diǎn)：客戶端必須安裝Flash插件；非HTTP協(xié)議，無法自動穿越防火墻。
實(shí)例：網(wǎng)絡(luò)互動游戲。

為了解決瀏覽器只能夠單向傳輸數(shù)據(jù)到服務(wù)端能夠?qū)崿F(xiàn)客戶端請求服務(wù)端，然后服務(wù)端利用與客戶端建立的這條通信連接push數(shù)據(jù)給客戶端，客戶端接收數(shù)據(jù)并處理的目的。從獨(dú)立的角度看，SSE技術(shù)提供的是從服務(wù)器單向推送數(shù)據(jù)給瀏覽器的功能，但是配合瀏覽器主動請求，實(shí)際上就實(shí)現(xiàn)了客戶端和服務(wù)器的雙向通信。它的原理是在客戶端構(gòu)造一個eventSource對象，該對象具有readySate屬性，分別表示如下：

在HTML5中，為了加強(qiáng)web的功能，提供了websocket技術(shù)，它不僅是一種web通信方式，也是一種應(yīng)用層協(xié)議。它提供了瀏覽器和服務(wù)器之間原生的雙全工跨域通信，通過瀏覽器和服務(wù)器之間建立websocket連接（實(shí)際上是TCP連接）,在同一時刻能夠?qū)崿F(xiàn)客戶端到服務(wù)器和服務(wù)器到客戶端的數(shù)據(jù)發(fā)送。
首先是客戶端new 一個websocket對象，該對象會發(fā)送一個http請求到服務(wù)端，服務(wù)端發(fā)現(xiàn)這是個webscoket請求，會同意協(xié)議轉(zhuǎn)換，發(fā)送回客戶端一個101狀態(tài)碼的response，以上過程稱之為一次握手，經(jīng)過這次握手之后，客戶端就和服務(wù)端建立了一條TCP連接，在該連接上，服務(wù)端和客戶端就可以進(jìn)行雙向通信了。這時的雙向通信在應(yīng)用層走的就是ws或者wss協(xié)議了，和http就沒有關(guān)系了。所謂的ws協(xié)議，就是要求客戶端和服務(wù)端遵循某種格式發(fā)送數(shù)據(jù)報文（幀），然后對方才能夠理解。

在HTTP/1.0中，默認(rèn)使用的是短連接。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當(dāng)瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。
但從 HTTP/1.1起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應(yīng)頭有加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的 TCP連接不會關(guān)閉，如果客戶端再次訪問這個服務(wù)器上的網(wǎng)頁，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。實(shí)現(xiàn)長連接要客戶端和服務(wù)端都支持長連接。
HTTP協(xié)議的長連接和短連接，實(shí)質(zhì)上是TCP協(xié)議的長連接和短連接。

Socket.IO是一個完全由JavaScript實(shí)現(xiàn)、基于Node.js、支持WebSocket的協(xié)議用于實(shí)時通信、跨平臺的開源框架，它包括了客戶端的JavaScript和服務(wù)器端的Node.js。Socket.IO除了支持WebSocket通訊協(xié)議外，還支持許多種輪詢（Polling）機(jī)制以及其它實(shí)時通信方式，并封裝成了通用的接口，并且在服務(wù)端實(shí)現(xiàn)了這些實(shí)時機(jī)制的相應(yīng)代碼。Socket.IO實(shí)現(xiàn)的Polling通信機(jī)制包括Adobe Flash Socket、AJAX長輪詢、AJAX multipart streaming、持久Iframe、JSONP輪詢等。

本文為網(wǎng)上資料匯總+自己的理解
Socket.IO介紹：支持WebSocket、用于WEB端的即時通訊框架
史上最全Web端即時通訊技術(shù)原理詳解
知乎回答