分散式通訊協議分析

• 網路協議： TCP/IP 和UDP/IP
• TCP/IP
• TCP的五層模型
• OSI的七層模型
• 3次握手協議
• 4次揮手協議
• TCP通訊原理
• 分散式Java應用
• 什麼是滑動視窗協議
• 應用傳輸圖示
• socket通訊的過程
• Multicast(組播)

網路協議： TCP/IP 和UDP/IP

TCP/IP

TCP/IP（Transmission Control Protocol/Internet Protocol）是一種可靠的網路資料傳輸控制協議。定義了主機如何連入因特網以及資料如何在他們之間傳輸的標準。TCP/IP協議參考模型把所有TCP/IP系列協議歸類到四個抽象層中；每一個抽象層建立在低一層提供的服務上，並且為高一層提供服務

TCP的五層模型

OSI的七層模型

3次握手協議

所謂三次握手（Three-Way Handshake）即建立TCP連線，就是指建立一個TCP連線時，需要客戶端和服務端總共傳送3個包以確認連線的建立

（1）第一次握手：Client將標誌位SYN置為1，隨機產生一個值seq=J，並將該資料包傳送給Server，Client進入SYN_SENT狀態，等待Server確認。
（2）第二次握手：Server收到資料包後由標誌位SYN=1知道Client請求建立連線，Server將標誌位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，並將該資料包傳送給Client以確認連線請求，Server進入SYN_RCVD狀態。
（3）第三次握手

：Client收到確認後，檢查ack是否為J+1，ACK是否為1，如果正確則將標誌位ACK置為1，ack=K+1，並將該資料包傳送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連線建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client與Server之間可以開始傳輸資料了。
SYN攻擊：
在三次握手過程中，Server傳送SYN-ACK之後，收到Client的ACK之前的TCP連線稱為半連線（half-open connect），此時Server處於SYN_RCVD狀態，當收到ACK後，Server轉入ESTABLISHED狀態。SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，並向Server不斷地傳送SYN包，Server回覆確認包，並等待Client的確認，由於源地址是不存在的，因此，Server需要不斷重發直至超時，這些偽造的SYN包將產時間佔用未連線佇列，導致正常的SYN請求因為佇列滿而被丟棄，從而引起網路堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連線狀態且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現行：
#netstat -nap | grep SYN_RECV

4次揮手協議

三次握手耳熟能詳，四次揮手估計就聽得比較少了，所謂四次揮手（Four-Way Wavehand）即終止TCP連線，就是指斷開一個TCP連線時，需要客戶端和服務端總共傳送4個包以確認連線的斷開

由於TCP連線時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料傳送任務後，傳送一個FIN來終止這一方向的連線，收到一個FIN只是意味著這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連線上仍然能夠傳送資料，直到這一方向也傳送了FIN。首先進行關閉的一方將執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。
（1）第一次揮手：Client傳送一個FIN，用來關閉Client到Server的資料傳送，Client進入FIN_WAIT_1狀態。
（2）第二次揮手：Server收到FIN後，傳送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
（3）第三次揮手：Server傳送一個FIN，用來關閉Server到Client的資料傳送，Server進入LAST_ACK狀態。
（4）第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接著傳送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。

---

TCP通訊原理

首先，對於TCP通訊來說，每個TCP Socket的核心中都有一個傳送緩衝區和一個接收緩衝區，TCP的全雙工的工作模式及TCP的滑動視窗就是依賴於這兩個獨立的Buffer和該Buffer的填充狀態。
接收緩衝區把資料快取到核心，若應用程序一直沒有呼叫Socket的read方法進行讀取，那麼該資料會一直被快取在接收緩衝區內。不管程序是否讀取Socket，對端發來的資料都會經過核心接收並快取到Socket的核心接收緩衝區。
read索要做的工作，就是把核心接收緩衝區中的資料複製到應用層使用者的Buffer裡。

程序呼叫Socket的send傳送資料的時候，一般情況下是講資料從應用層使用者的Buffer裡複製到Socket的核心傳送緩衝區，然後send就會在上層返回。換句話說，send返回時，資料不一定會被髮送到對端。

分散式Java應用

什麼是滑動視窗協議

傳送方和接收方都會維護一個數據幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接收方確認，目的是控制傳送速度，以免接收方的快取不夠大導致溢位，同時控制流量也可以避免網路擁塞。
下面圖中的4,5,6號資料幀已經被髮送出去，但是未收到關聯的ACK，7,8,9幀則是等待發送。可以看出傳送端的視窗大小為6，這是由接受端告知的（事實上必須考慮擁塞視窗cwnd，這裡暫且考慮cwnd>rwnd）。此時如果傳送端收到4號ACK，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴充套件，此時視窗就向前“滑動了”，即資料幀10也可以被髮送

明白了Socket讀寫資料的底層原理，我們就很容易理解“阻塞模式”：對於讀取Socket資料的過程而言，如果接收緩衝區為空，則呼叫Socket的read方法的執行緒會阻塞，知道有資料進入接收緩衝區；而對於寫資料到Socket中的執行緒來說，如果待發送的資料長度大於傳送緩衝區空餘長度，則會阻塞在write方法上，等待發送緩衝區的報文被髮送到網路上，然後繼續傳送下一段資料，迴圈上述過程直到資料都被寫入到傳送緩衝區為止

從前面分析的過程來看，傳統的Socket阻塞模式直接導致每個Socket都必須繫結一個執行緒來操作資料，參與通訊的任意一方如果處理資料的速度較慢，會直接拖累到另一方，導致另一方的執行緒不得不浪費大量的時間在I/O等待上，所以這就是Socket阻塞模式的“缺陷”。但是這種模式在少量的TCP連線通訊的情況下，雙方都可以快速的傳輸資料，這個時候的效能是最高的。

應用傳輸圖示

socket通訊的過程

Multicast(組播)

1. 單播
2. 廣播
3. 組播