【文章內(nèi)容簡介】 協(xié)議流程前，先來聲明兩個重要的概念： （ 1）客戶端，首先發(fā)送 TCP 請求的是客戶端，客戶端一般是服務(wù)（比如數(shù)據(jù)查詢服務(wù)）的請求者。 （ 2）服務(wù)器，在接收到客戶端的請求后（確保同客戶端的通信信道建立）服務(wù)器會向客戶端提供服務(wù)。服務(wù)器一般是服務(wù)的執(zhí)行者，會向客戶端返回服務(wù)執(zhí)行的結(jié)果。 為了實現(xiàn) 客戶端同服務(wù)器端的通信，客戶端首先發(fā)送一個“ SYN”數(shù)據(jù)包。如果服務(wù)器收到 SYN 標(biāo)記，它將發(fā)回一個“ SYN+ACK”數(shù)據(jù)包。接著，客戶端為了表示收到了這個 SYN+ACK 信息，會向服務(wù)器發(fā)送一個最終確認(rèn)信息（ ACK 包）。這種 SYN,SYN+ACK,ACK 的步驟被稱為 TCP 連接建立時的“三次握手”，在這之后，連接就建立起來了，這個連接將一直保持活動狀態(tài)，直到超時或者任何一方發(fā)出一個 FIN（結(jié)束）信號。這種通信模式也叫客戶端 /服務(wù)器（ C/S）模式。 主機 A 主機 B 圖 13 三次握手協(xié)議 由此可見，通過客戶端和服務(wù)器的“三次握手”，雙方可以建立暢通的通信ACK=1 第一次握手，主機 A 向主機 B 發(fā)送連接請求 第二次握手，主機 B 收到主機 A的請求，向主機 A回發(fā)一個確認(rèn)，同時向主機 A 發(fā)送一個連接請求 第三次握手，主機 A 收到主機 B 發(fā)送的數(shù)據(jù)包在向主機 B 發(fā)送一個確認(rèn)連接 SYN=1,SEQ= ACK=1,SYN=1,SEQ= aaaaaaaaaa 信道，在此信道上雙方互相傳輸數(shù)據(jù)。 服務(wù)器和客戶機 網(wǎng)絡(luò)最基本的目的就是讓兩臺機器連接到一起，并相互 “交談 ”或者 “溝通 ”。一旦兩臺機器都發(fā)現(xiàn)了對方，就可以展開一次令人愉快的雙向?qū)υ?。但它們怎樣才?“發(fā)現(xiàn) ”對方呢？這就像在游樂園里那樣：一臺機器不得不停留在一個地方，偵聽其他機器說： “嘿，你在哪里呢？ ” “停留在一個地方 ”的機器叫做 “服務(wù) 器 ”（ Server）；到處 “找人 ”的機器則叫做 “客戶機 ”（ Client）或者 “客戶 ”。它們之間的區(qū)別只有在客戶機試圖同服務(wù)器連接的時候才顯得非常明顯。一旦連通，就變成了一種雙向通信，誰來扮演服務(wù)器或者客戶機便顯得不那么重要了。 所以服務(wù)器的主要任務(wù)是偵聽建立連接的請求，這是由我們創(chuàng)建的特定服務(wù)器對象完成的。而客戶機的任務(wù)是試著與一臺服務(wù)器建立連接，這是由我們創(chuàng)建的特定客戶機對象完成的。一旦連接建好，那么無論在服務(wù)器端還是客戶機端，連接只是魔術(shù)般地變成了一個 IO 數(shù)據(jù)流對象。從這時開始，我們可以象讀寫一個普通的文件那樣對待連接。所以一旦建好連接，我們只需使用自己熟悉的 IO命令即可。這正是 Java 聯(lián)網(wǎng)最方便的一個地方。 圖 14 服務(wù)器和客戶機的連接 本文內(nèi)容安排 本論文內(nèi)容安排如下： 第二章為聊天系統(tǒng)的需求分析，主要介紹系統(tǒng)的可行性研究，需求分析流程圖等。 第三章為概要設(shè)計，分模塊介紹系統(tǒng)的具體實現(xiàn)過程。 第四章為詳細(xì)設(shè)計。 2 需求分析 可行性分析 經(jīng)濟可行性 :由于本 系統(tǒng) 的主要背景是畢業(yè)課程設(shè)計，不注重直接的經(jīng)濟效益和其后的發(fā)展方向，只在注重自身水平和能力的提高，對自 身的經(jīng)濟要求也不高，只要有一臺能運行 Java 軟件的電腦便可，所以不用考慮到經(jīng)濟問題。 技術(shù)可行性 : 本系統(tǒng)的開發(fā)利用 Microsoft SQL Server2020 作為本系統(tǒng)的數(shù)據(jù)庫 ,它是一個支持多用戶的新型數(shù)據(jù)庫 ,適用于大中規(guī)模的數(shù)據(jù)量需求。學(xué)校校園網(wǎng)的建設(shè)也為新系統(tǒng)服務(wù)器 /客戶端的結(jié)構(gòu)提供了硬件的支持。使用 Java作為系統(tǒng)開發(fā)的開發(fā)環(huán)境 ,它提供完善的指令控制語句、類與對象的支持及豐富的數(shù)據(jù)類型 ,給開發(fā)高性能系統(tǒng)提供的保障為開發(fā)滿足客戶要求的系統(tǒng) ,保證了代碼的模塊化要求 ,而代碼模塊化的提高 ,非常有利于以后 對新系統(tǒng)的擴展與修改。 運行 可行性 : 本系統(tǒng)為一個小型的即時聊天 系統(tǒng) ,所耗費的資源非常的小 ,現(xiàn)在一般的電腦無論是硬件還是軟件都能夠滿足條件 ,因此 ,本系統(tǒng)在運行上是可行的。 綜上所述 ,本系統(tǒng)的設(shè)計與開發(fā)在技術(shù)上和硬件設(shè)備上的條件都是滿足的 ,因此 ,它在技術(shù)上是可行的。 系統(tǒng)功能需求 本系統(tǒng)主要通過客戶端，服務(wù)器端來體現(xiàn)即時通訊 的基本功能。 （ 1）服務(wù)器端 （ 2）客戶端 系統(tǒng)性能需求 實用性：為信息交流 提供方便，有效進(jìn)行作業(yè)管理。 操作簡單：本系統(tǒng)應(yīng)該適用于不同水平的使用者，包括事業(yè)單位和企業(yè)單位，同時系統(tǒng)不應(yīng)太復(fù)雜和煩瑣，因此要求系統(tǒng)的操作盡可能簡單易行。 技術(shù)先進(jìn)：產(chǎn)品的系統(tǒng)設(shè)計和開發(fā)應(yīng)緊跟著整個計算機發(fā)展潮流，采用當(dāng)時最先進(jìn)的設(shè)計思想，利用最新的開發(fā)技術(shù)和開發(fā)工具。使系統(tǒng)能夠無論 在功能設(shè)計上，還是在技術(shù)實現(xiàn)上，都處于同行業(yè)的領(lǐng)先地位。 安裝使用簡便：服務(wù)器端的安裝簡潔明了，客戶機無需再裝任何軟件就可以直接注冊登陸聊天。 適應(yīng)性：應(yīng)該能廣泛應(yīng)用于不同類型的企事業(yè)單位。系統(tǒng)采用模塊化設(shè)計，用戶可以根據(jù)自己的實際情況自行組合，使系統(tǒng)在不同的硬件環(huán)境下都能得以應(yīng)用。 代碼可讀性好：文中的代碼將盡可能簡潔，易懂。 系統(tǒng)運行需求 移動客戶端需 500MHz 及以上的處理器 移動客戶端需 256MB 及以上的 ROM 空間 移動客戶端需 256MB 及以上的 RAM 空間 移動客戶端需具有 WiFi/GRPS 網(wǎng)絡(luò)接收模塊，能正常連接到網(wǎng)絡(luò) 服務(wù)端需具有 P4 及以上的處理器 服務(wù)端需具有 80GB 及以上的硬板空間 服務(wù)端需具有 1GB 及以上的內(nèi)存空間 數(shù)據(jù)流圖 頂層數(shù)據(jù)流圖 圖 21 頂層數(shù)據(jù)流圖 聊天用戶 即時通訊 系統(tǒng) 聊天用戶 一層數(shù)據(jù)流圖 . 圖 22 一層數(shù)據(jù)流圖 二層數(shù)據(jù)流圖 聊天用戶 客戶端 服務(wù)器端 數(shù)據(jù)流 聊天用戶 用戶登錄 用戶注冊 用戶 客戶端 圖 23 系統(tǒng)二層數(shù)據(jù)流圖 3 概要設(shè)計 系統(tǒng)實現(xiàn)原理 即時通訊 的設(shè)計跟普通網(wǎng)站設(shè)計有著許多不同的地 方，普通網(wǎng)站設(shè)計所考慮的因素 ，例如，普通網(wǎng)站需要對布局進(jìn)入大量美化以及動畫設(shè)計等等，而即時通訊 只要提供滿足訪客雙方直接實時聊天即可。因此，在設(shè)計聊天系統(tǒng)的過程中，必須要考慮好以下幾個設(shè)計要點： 在 Inter 上的聊天程序一般都是以服務(wù)器提供服務(wù)端連接響應(yīng)，使用者通過客戶端程序登錄到服務(wù)器，就可以與登錄在同一服務(wù)器上的用戶交談，這是一個面向連接的通信過程。因此，程序要在 TCP/IP 環(huán)境下，實現(xiàn)服務(wù)器端和客戶端兩部分程序。 圖 31 系統(tǒng)實現(xiàn)原理圖 系統(tǒng)實現(xiàn)層次圖： 圖 32 系統(tǒng)實現(xiàn)層次圖 各模塊詳細(xì)功能 服務(wù)器端結(jié)構(gòu) 即時通訊系統(tǒng) 客戶端 服務(wù)器端 實時聊天 好友信息請求 更新信息請求 好友添加 /刪除 注冊 /登錄請求 聊天消息轉(zhuǎn)發(fā) 好友信息查詢 用戶信息更新 好友添加 /刪除 用戶注冊 /登錄 圖 33 服務(wù)器端結(jié)構(gòu)圖 ：服務(wù)器啟動操作。 ： 服務(wù)器端 連接數(shù)據(jù)庫 ，負(fù)責(zé)服務(wù)器 端與數(shù)據(jù)庫連接讀取數(shù)據(jù)操作 。 ： 服務(wù)器端監(jiān)聽客戶端連接，并處理各種請求。 ： 服務(wù)器端接受客戶端消息鏈轉(zhuǎn)化為 json 格式的數(shù)據(jù)定義。 ： 服務(wù)器端發(fā)送客戶端消息鏈轉(zhuǎn)化為 json 格式的數(shù)據(jù)定義。 ： 服務(wù)器接受消息 處理的抽象類。 ： 服務(wù)器接受客戶端登錄請求操作。 ：服務(wù)器接收客戶端查找好友消息轉(zhuǎn)化為 json 格式的數(shù)據(jù)定義 ：服務(wù)器更新在線用戶鏈表的 json 格式的數(shù)據(jù)定義 ： 服務(wù)器端 接受客戶端聊天信息和請求并進(jìn)行轉(zhuǎn)發(fā)。 客戶端結(jié)構(gòu) 服務(wù)器監(jiān)聽控制窗體 ServerFrame 啟動服務(wù)器監(jiān)聽 AppServer 處理所有用戶請求 Connection 啟動客戶端 ChatClient 用戶窗體啟動 Login 用戶聊天窗體 ChatRoom 用戶窗體啟動 Login 用戶窗體監(jiān)聽 Close 圖 34 客戶端結(jié)構(gòu)圖 ：客戶端用戶登錄信息的記錄。 ：客戶端聊天消息列表數(shù)據(jù)。 ：客戶端在線列表數(shù)據(jù)成員。 ： 客戶端 主界面 topbar 圖標(biāo)數(shù)據(jù) 。 ：客戶端在線列表數(shù)據(jù)。 ：客戶端好友信息數(shù)據(jù)。 ：客戶端 自己信息數(shù)據(jù)成員。 ：客戶端注冊信息數(shù)據(jù)成員。 ：客戶端好友信息數(shù)據(jù)成員。 :客戶端用戶信息數(shù)據(jù)。 ：客戶端注冊界面及交互。 ：客戶端登錄界面及交互 。 ：負(fù)責(zé)客戶端聊天窗體及交互。 ：客戶端好友信息界面及交互。 ：客戶端自 己信息界面及交互。 ：負(fù)責(zé)客戶端好友查找 界面及交互。 ：客戶端在線 用戶界面與交互。 ：客戶端連接服務(wù)器及與服務(wù)器進(jìn)行交互。 ： 客戶端 主界面，負(fù)責(zé)各項窗體操作和數(shù)據(jù)分配 及交互。 4 詳細(xì)設(shè)計 系統(tǒng)流程圖 系統(tǒng)總體流程圖 開始 啟動服務(wù)器 判斷啟動信息 否 圖 41 系統(tǒng)總體流程圖