1.網(wǎng)絡協(xié)議在分布式中地位
分布式環(huán)境下重要的特點：任務分解和網(wǎng)絡通信，其中網(wǎng)絡協(xié)議在分布式環(huán)境中承擔著不可缺少的部分，不管是系統(tǒng)與系統(tǒng)之間的通信，或者是中間件之間的通信都與網(wǎng)絡協(xié)議有著密不可分的關系。
2.網(wǎng)絡模型
2.1.?OSI模型
OSI七層模型分別是：
應用層
網(wǎng)絡服務與最終用戶的一個接口。
協(xié)議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
表示層
數(shù)據(jù)的表示、安全、壓縮。（在五層模型里面已經(jīng)合并到了應用層）
格式有，JPEG、ASCll、DECOIC、加密格式等
會話層
建立、管理、終止會話。（在五層模型里面已經(jīng)合并到了應用層）
對應主機進程，指本地主機與遠程主機正在進行的會話
傳輸層
定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯校驗。
協(xié)議有：TCP UDP，數(shù)據(jù)包一旦離開網(wǎng)卡即進入網(wǎng)絡傳輸層
網(wǎng)絡層
進行邏輯地址尋址，實現(xiàn)不同網(wǎng)絡之間的路徑選擇。
協(xié)議有：ICMP IGMP IP（IPV4 IPV6） ARP RARP
數(shù)據(jù)鏈路層
建立邏輯連接、進行硬件地址尋址、差錯校驗[2]??等功能。（由底層網(wǎng)絡定義協(xié)議）
將比特組合成字節(jié)進而組合成幀，用MAC地址訪問介質(zhì)，錯誤發(fā)現(xiàn)但不能糾正。
物理層
建立、維護、斷開物理連接。（由底層網(wǎng)絡定義協(xié)議）
每一層為上層提供服務
2.2.?TCP/IP模型
TCP/IP協(xié)議參考模型把所有TCP/IP系列協(xié)議歸類到四個抽象層中，每一個抽象層建立在低一層提供的服務上，并且為高一層提供服務。
ICMP:控制報文協(xié)議
IGMP:internet組管理協(xié)議
ARP:地址解析協(xié)議
RARP:反向地址轉化協(xié)議
3.TCP/IP協(xié)議
3.1.?什么是TCP/IP協(xié)議
TCP/IP（Transmission Control Protocol/Internet Protocol）是一種可靠的網(wǎng)絡數(shù)據(jù)傳輸控制協(xié)議。定義了主機如何連入因特網(wǎng)以及數(shù)據(jù)如何在他們之間傳輸?shù)臉藴省?/p>
3.2.?TCP/IP應用場景
TCP/IP是可靠的連接傳輸，可靠性要求比較高，但傳輸效率慢。常用的應用場景有：文件傳輸、重要狀態(tài)的更新等
3.3.?TCP通信原理
對于TCP通信來說，每個TCP Socket的內(nèi)核中都有一個發(fā)送緩沖區(qū)和一個接收緩沖區(qū)，TCP的全雙工的工作模式及TCP的滑動窗口就是依賴于這兩個獨立的Buffer和該Buffer的填充狀態(tài)。
接收緩沖區(qū)把數(shù)據(jù)緩存到內(nèi)核，若應用進程一直沒有調(diào)用Socket的read方法進行讀取，那么該數(shù)據(jù)會一直被緩存在接收緩沖區(qū)內(nèi)。不管進程是否讀取Socket，對端發(fā)來的數(shù)據(jù)都會經(jīng)過內(nèi)核接收并緩存到Socket的內(nèi)核接收緩沖區(qū)。
Read所要做的工作，就是把內(nèi)核接收緩沖區(qū)中的數(shù)據(jù)復制到應用層用戶的Buffer里。
進程調(diào)用Socket的send發(fā)送數(shù)據(jù)的時候，一般情況下是講數(shù)據(jù)從應用層用戶的Buffer里復制到Socket的內(nèi)核發(fā)送緩沖區(qū)，然后send就會在上層返回。換句話說，send返回時，數(shù)據(jù)不一定會被發(fā)送到對端。
通信時序圖發(fā)送端：
通信時序圖接收端：
注：buffer大小在JAVA默認程序里為8192
3.4.?三次握手
三次握手（Three-Way Handshake）即建立TCP連接，就是指建立一個TCP連接時，需要客戶端和服務端總共發(fā)送3個包以確認連接的建立。
（1）第一次握手：Client將標志位SYN置為1，隨機產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進入SYN_SENT狀態(tài)，等待Server確認。
（2）第二次握手：Server收到數(shù)據(jù)包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認連接請求，Server進入SYN_RCVD狀態(tài)。
（3）第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。
SYN攻擊：
在三次握手過程中，Server發(fā)送SYN-ACK之后，收到Client的ACK之前的TCP連接稱為半連接（half-open connect），此時Server處于SYN_RCVD狀態(tài)，當收到ACK后，Server轉入ESTABLISHED狀態(tài)。SYN攻擊就是Client在短時間內(nèi)偽造大量不存在的IP地址，并向Server不斷地發(fā)送SYN包，Server回復確認包，并等待Client的確認，由于源地址是不存在的，因此，Server需要不斷重發(fā)直至超時，這些偽造的SYN包將產(chǎn)時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網(wǎng)絡堵塞甚至系統(tǒng)癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接狀態(tài)且源IP地址是隨機的，則可以斷定遭到SYN攻擊了，使用如下命令可以讓之現(xiàn)行：
??#netstat -nap | grep SYN_RECV
3.5.?四次揮手
所謂四次揮手（Four-Way Wavehand）即終止TCP連接，就是指斷開一個TCP連接時，需要客戶端和服務端總共發(fā)送4個包以確認連接的斷開。
由于TCP連接時全雙工的，因此，每個方向都必須要單獨進行關閉，這一原則是當一方完成數(shù)據(jù)發(fā)送任務后，發(fā)送一個FIN來終止這一方向的連接，收到一個FIN只是意味著這一方向上沒有數(shù)據(jù)流動了，即不會再收到數(shù)據(jù)了，但是在這個TCP連接上仍然能夠發(fā)送數(shù)據(jù)，直到這一方向也發(fā)送了FIN。首先進行關閉的一方將執(zhí)行主動關閉，而另一方則執(zhí)行被動關閉，上圖描述的即是如此。
（1）第一次揮手：Client發(fā)送一個FIN，用來關閉Client到Server的數(shù)據(jù)傳送，Client進入FIN_WAIT_1狀態(tài)。
（2）第二次揮手：Server收到FIN后，發(fā)送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），Server進入CLOSE_WAIT狀態(tài)。
（3）第三次揮手：Server發(fā)送一個FIN，用來關閉Server到Client的數(shù)據(jù)傳送，Server進入LAST_ACK狀態(tài)。
（4）第四次揮手：Client收到FIN后，Client進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態(tài)，完成四次揮手。
注：
單工：數(shù)據(jù)傳輸只支持數(shù)據(jù)在一個方向上傳輸。
半雙工：數(shù)據(jù)傳輸允許數(shù)據(jù)在兩個方向上傳輸，但是在某一時刻，只允許在一個方向上傳輸，實際上有點像切換方向的單工通信。
全雙工：數(shù)據(jù)通信允許數(shù)據(jù)同時在兩個方向上傳輸，因此全雙工是兩個單工通信方式的結合，它要求發(fā)送設備和接收設備都有獨立的接收和發(fā)送能力。
3.6.?滑動窗口
發(fā)送方和接收方都會維護一個數(shù)據(jù)幀的序列，這個序列被稱作窗口。發(fā)送方的窗口大小由接收方確認，目的是控制發(fā)送速度，以免接收方的緩存不夠大導致溢出，同時控制流量也可以避免網(wǎng)絡擁塞。
明白了Socket讀寫數(shù)據(jù)的底層原理，我們就很容易理解“阻塞模式”：對于讀取Socket數(shù)據(jù)的過程而言，如果接收緩沖區(qū)為空，則調(diào)用Socket的read方法的線程會阻塞，知道有數(shù)據(jù)進入接收緩沖區(qū)；而對于寫數(shù)據(jù)到Socket中的線程來說，如果待發(fā)送的數(shù)據(jù)長度大于發(fā)送緩沖區(qū)空余長度，則會阻塞在write方法上，等待發(fā)送緩沖區(qū)的報文被發(fā)送到網(wǎng)絡上，然后繼續(xù)發(fā)送下一段數(shù)據(jù)，循環(huán)上述過程直到數(shù)據(jù)都被寫入到發(fā)送緩沖區(qū)為止。
從前面分析的過程來看，傳統(tǒng)的Socket阻塞模式直接導致每個Socket都必須綁定一個線程來操作數(shù)據(jù)，參與通信的任意一方如果處理數(shù)據(jù)的速度較慢，會直接拖累到另一方，導致另一方的線程不得不浪費大量的時間在I/O等待上，所以這就是Socket阻塞模式的“缺陷”。但是這種模式在少量的TCP連接通信的情況下，雙方都可以快速的傳輸數(shù)據(jù)，這個時候的性能是最高的。
3.7.?IO模型
BIO模型
同步阻塞式IO，服務器端與客戶端三次握手簡歷連接后一個鏈路建立一個線程進行面向流的通信。這曾是jdk1.4前的唯一選擇。在任何一端出現(xiàn)網(wǎng)絡性能問題時都影響另一端，無法滿足高并發(fā)高性能的需求。
NIO模型
同步非阻塞IO，以塊的方式處理數(shù)據(jù)。采用多路復用Reactor模式。JDK1.4時引入。
AIO模型
異步非阻塞IO，基于unix事件驅(qū)動，不需要多路復用器對注冊通道進行輪詢，采用Proactor設計模式。JDK1.7時引入。
4.UDP/IP協(xié)議
4.1.?什么是UDP/IP
UDP 是User Datagram Protocol的簡稱， 中文名是用戶數(shù)據(jù)報協(xié)議，在網(wǎng)絡中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。在OSI模型中，在第四層——傳輸層，處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對數(shù)據(jù)包進行排序的缺點，也就是說，當報文發(fā)送之后，是無法得知其是否安全完整到達的。UDP用來支持那些需要在計算機之間傳輸數(shù)據(jù)的網(wǎng)絡應用。包括網(wǎng)絡視頻會議系統(tǒng)在內(nèi)的眾多的客戶/服務器模式的網(wǎng)絡應用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但是即使是在今天UDP仍然不失為一項非常實用和可行的網(wǎng)絡傳輸層協(xié)議。
4.2.?應用場景
實時通信、QQ、視頻、流媒體等應用
5.協(xié)議在分布式應用
