當(dāng)前與網(wǎng)絡(luò)相關(guān)的業(yè)務(wù)主要是基于tcp/ip或http，熟悉j2ee的同學(xué)一定會對http場景下的開發(fā)比較了解。但是，精通tcp/ip以及如何構(gòu)建一個直接基于tcp/ip層通訊的知識卻不太多見。恰巧，最近一年來我參與了一些基于tcp/ip應(yīng)用的開發(fā)工作。總算有所收獲，今天在博客中做些分享，希望對有興趣的同學(xué)有所幫助。
比較常見的4層網(wǎng)絡(luò)模型（圖）如下：
基于應(yīng)用層的開發(fā)難度是相對比較低的，因為絕大部分與連接和數(shù)據(jù)傳輸、校驗相關(guān)的事情已經(jīng)交給（系統(tǒng)）來完成，使得開發(fā)人員只需要專注于業(yè)務(wù)即可。這種分層的技術(shù)結(jié)構(gòu)是非常高級和有效的。基于應(yīng)用層的開發(fā)雖然方便，但是當(dāng)我們需要在功能上實現(xiàn)某些特殊需求的時候，就難免有些掣肘。例如，我們需要從一些傳感器上采集數(shù)據(jù)或希望他們能夠主動將數(shù)據(jù)上送，并在經(jīng)過了中心系統(tǒng)處理后推送到其它響應(yīng)裝置。這樣的需求使用http來開發(fā)，反而增大了難度。
操作系統(tǒng)實際已經(jīng)為我們提供了一種基于傳輸層的通訊方式：套接字（socket）。使用套接字可以讓我們自由定義通訊協(xié)議并選擇合適的連接方式。
利用socket實現(xiàn)網(wǎng)絡(luò)通信分為服務(wù)端和客戶端，服務(wù)端綁定端口并主動監(jiān)聽連接，客戶端需要向服務(wù)端發(fā)起連接。建立一次tcp連接需要進過“三次”握手：
第一次握手：客戶端發(fā)送syn包(syn=j)到服務(wù)器，并進入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)；
第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務(wù)器進入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務(wù)器的SYN＋ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ack=k+1)，此包發(fā)送完畢，客戶端和服務(wù)器進入ESTABLISHED狀態(tài)，完成三次握手。
三次握手被抽象成socket連接，這個過程服務(wù)端和客戶端會分別生成一個socket并通過在這個套接字上的連接收發(fā)數(shù)據(jù)。那么問題產(chǎn)生了，假如我們知道服務(wù)端對8081端口進行監(jiān)聽，客戶端會隨機打開一個高位端口進行連接。連接建立后，服務(wù)端是在哪個端口上監(jiān)聽數(shù)據(jù)的呢？答案是8081端口，服務(wù)端會根據(jù)端口上數(shù)據(jù)的源地址和端口判斷從而將數(shù)據(jù)分發(fā)到正確的應(yīng)用上去。
理解這一點其實很重要，如果此時通信的雙方?jīng)]有任何數(shù)據(jù)交換，socket也無法判斷連接是否被斷開。任意一方必須首先通知socket斷開連接，整個通信過程才算結(jié)束。如果中間網(wǎng)絡(luò)中斷，連接會一直處于等待狀態(tài)。
利用socket編程的另一個難點是，由于通信的雙方完全對等任何一方都可以主動發(fā)送數(shù)據(jù)，如何實現(xiàn)在http應(yīng)用中常見的請求/應(yīng)答會比較麻煩。為此我專門查閱了http1.0和http1.1的相關(guān)資料，基本的解決方案總結(jié)如下：
- 客戶端等待：客戶端發(fā)送請求后，都需要進行堵塞并直到接收到應(yīng)答或超時為止。這個是http1.0的協(xié)議規(guī)范，整個數(shù)據(jù)的交互方式是串行的。
- 服務(wù)端等待：串行的運行方式實際上浪費了大量的系統(tǒng)運算時間，使得網(wǎng)絡(luò)通訊很容易成為整個系統(tǒng)的瓶頸。于是http1.1協(xié)議做了更改，客戶端只要準(zhǔn)備好請求就可以直接發(fā)送，服務(wù)端可能會一次性接收到多條請求，但是只能按照請求的順序依次應(yīng)答。
服務(wù)器的運算能力通常都比客戶端強，第二種解決方案能更加有效的利用網(wǎng)絡(luò)。但是，如果有一條請求需要請求占用服務(wù)端大量的運算時間，后續(xù)應(yīng)答都會被堵塞，因此在某些情況下也會引發(fā)比較嚴(yán)重的問題。
為了解決這個問題，我借鑒了spring kafka在實現(xiàn)消息交互的時候提供的一種解決思路：為每一條請求指定一個ID，經(jīng)過服務(wù)端處理后的應(yīng)答都需要帶上這個ID。這樣在回復(fù)給客戶端的時候，客戶端就可以根據(jù)這條ID值來調(diào)用不同的回調(diào)處理業(yè)務(wù)。
