web即時聊天系統的實現
第【0】頁
前言
該項目是我對大學三年究竟學習到了什麼進行的一次檢驗。在此寫出博客一是爲了記錄項目開發過程所遇到的坑和難題，二是爲了新手能夠在漫漫碎片化的知識裏面找到一個能知道大致的方向的指導書（(╯｀□′)╯~ ╧╧當然也不敢說我的是正確的）。從開始我會更新的比較慢，因爲我也是摸着路過河的。至於要用到的知識，我會在需要該技術時提及其相關的知識。博客也是時常會修改的，我想把它看作我的筆記本，通過修改填補空缺知識，成爲我的一個經驗書。
項目背景
即時聊天系統[Instant Messaging]，能想到的非常有名的QQ、微信這類型的客戶端應用。以前QQ還存在有網頁版，從2019年1月1日起停止服務，微信倒還存在有網頁版。於是乎，我想寫一個類似的應用，基於web端的即時聊天系統，能夠達到即時聊天，在線互動，離線留言的功能。我認爲該系統的泛用性很高，可以搭載在任何需要聊天留言功能的項目上。畢竟社交軟件在如今的使用率可謂是前所未有的高。
設計思路
稍微總結一下資料
早年QQ是基於TCP/IP協議的通訊軟件。聊天通訊採用UDP協議，通過服務器中轉方式。大家都知道，UDP 協議雖然是不可靠協議，它只管發送，不管對方是否收到的，但它的傳輸很高效。
這裏所說的TCP/IP根據百度百科TCP/IP協議_百度百科裏寫對他的解釋
TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議）是指能夠在多個不同網絡間實現信息傳輸的協議簇。TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇， 只是因爲在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱爲TCP/IP協議。
而這是QQ這款桌面平臺軟件使用到的網絡通訊協議，而我們web端的使用到的是HTTP（應用層裏定義的一種協議，它們的關係可以自行百度）
HTTP是一個簡單的請求-響應協議，它通常運行在TCP之上。它指定了客戶端可能發送給服務器什麼樣的消息以及得到什麼樣的響應。請求和響應消息的頭以ASCII碼形式給出；而消息內容則具有一個類似MIME的格式。這個簡單模型是早期Web成功的有功之臣，因爲它使得開發和部署是那麼的直截了當。
其中請求和相應對於web聊天系統來說就是最重要的一個步驟了，到後面我會一一說明，爲什麼請求和相應會是重要的步驟？
因爲任何web應用都逃不開這個步驟，C/S客戶-服務器結構是構建當前網絡應用的（B/S瀏覽器-服務器結構是特殊的c/s結構）基礎運行模式，客戶端通過請求從而從服務器獲取到想要的數據。
說到這裏，也就知道，web即時聊天系統其實也跟其他的web應用在底層實現思路上並沒有什麼不同。
即核心思想：用戶A發送消息到服務器，服務器進行一系列處理後（消息封裝、反封裝、過濾、保存、轉發）將消息轉發給用戶B（或羣體）。
傳統的思想既是如此，當然還有新的思路，接着看下去吧。
即時通訊方案
現在9012年了，我們還是看看比較新的技術吧，大致實現的方案有一下四種，本篇【0-1】只簡單介紹一下，具體介紹，請看以後的文章
- ajax輪詢
- ajax長輪詢
- web-socket長連接
- server-send-event（用這個方案的網上的資料很少）
ajax輪詢與ajax長輪詢都是基於HTTP的，兩者本身存在着缺陷:輪詢需要更快的處理速度；長輪詢則更要求處理併發的能力;兩者都是“被動型服務器”的體現:服務器不會主動推送信息，而是在客戶端發送ajax請求後進行返回的響應。
WebSocket 是 HTML5 開始提供的一種在單個 TCP 連接上進行全雙工通訊的協議，WebSocket 使得客戶端和服務器之間的數據交換變得更加簡單。webSocket允許服務端主動向客戶端推送數據。與傳統的http協議不同，該協議可以實現服務器與客戶端之間全雙工通信。簡單來說，首先需要在客戶端和服務器端建立起一個連接，這部分需要http。連接一旦建立，客戶端和服務器端就處於平等的地位，可以相互發送數據，不存在請求和響應的區別。
SSE是HTML5新增的功能，全稱爲Server-Sent Events。它可以允許服務推送數據到客戶端。SSE在本質上就與之前的長輪詢、短輪詢不同，雖然都是基於http協議的，但是輪詢需要客戶端先發送請求。而SSE最大的特點就是不需要客戶端發送請求，可以實現只要服務器端數據有更新，就可以馬上發送到客戶端。
這種“主動型”相較“被動型”的性能更加優越。
[2019-10-25]