1.網(wǎng)絡(luò)協(xié)議在分布式中地位

分布式環(huán)境下重要的特點(diǎn)：任務(wù)分解和網(wǎng)絡(luò)通信伤哺，其中網(wǎng)絡(luò)協(xié)議在分布式環(huán)境中承擔(dān)著不可缺少的部分被冒，不管是系統(tǒng)與系統(tǒng)之間的通信穿挨，或者是中間件之間的通信都與網(wǎng)絡(luò)協(xié)議有著密不可分的關(guān)系纹烹。

2.網(wǎng)絡(luò)模型

2.1.?OSI模型

OSI七層模型分別是：

應(yīng)用層

網(wǎng)絡(luò)服務(wù)與最終用戶的一個(gè)接口涌萤。

協(xié)議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP

表示層

數(shù)據(jù)的表示嘿歌、安全烟很、壓縮跃洛。（在五層模型里面已經(jīng)合并到了應(yīng)用層）

格式有此迅，JPEG盗蟆、ASCll镜撩、DECOIC预柒、加密格式等

會話層

建立、管理、終止會話宜鸯。（在五層模型里面已經(jīng)合并到了應(yīng)用層）

對應(yīng)主機(jī)進(jìn)程人灼，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會話

傳輸層

定義傳輸數(shù)據(jù)的協(xié)議端口號，以及流控和差錯(cuò)校驗(yàn)顾翼。

協(xié)議有：TCP UDP投放，數(shù)據(jù)包一旦離開網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層

網(wǎng)絡(luò)層

進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇适贸。

協(xié)議有：ICMP IGMP IP（IPV4 IPV6） ARP RARP

數(shù)據(jù)鏈路層

建立邏輯連接灸芳、進(jìn)行硬件地址尋址、差錯(cuò)校驗(yàn)[2]??等功能拜姿。（由底層網(wǎng)絡(luò)定義協(xié)議）

將比特組合成字節(jié)進(jìn)而組合成幀烙样，用MAC地址訪問介質(zhì)，錯(cuò)誤發(fā)現(xiàn)但不能糾正蕊肥。

物理層

建立谒获、維護(hù)、斷開物理連接壁却。（由底層網(wǎng)絡(luò)定義協(xié)議）

每一層為上層提供服務(wù)

2.2.?TCP/IP模型

TCP/IP協(xié)議參考模型把所有TCP/IP系列協(xié)議歸類到四個(gè)抽象層中批狱，每一個(gè)抽象層建立在低一層提供的服務(wù)上，并且為高一層提供服務(wù)展东。

ICMP:控制報(bào)文協(xié)議

IGMP:internet組管理協(xié)議

ARP:地址解析協(xié)議

RARP:反向地址轉(zhuǎn)化協(xié)議

3.TCP/IP協(xié)議

3.1.?什么是TCP/IP協(xié)議

TCP/IP（Transmission Control Protocol/Internet Protocol）是一種可靠的網(wǎng)絡(luò)數(shù)據(jù)傳輸控制協(xié)議赔硫。定義了主機(jī)如何連入因特網(wǎng)以及數(shù)據(jù)如何在他們之間傳輸?shù)臉?biāo)準(zhǔn)。

3.2.?TCP/IP應(yīng)用場景

TCP/IP是可靠的連接傳輸盐肃，可靠性要求比較高爪膊，但傳輸效率慢。常用的應(yīng)用場景有：文件傳輸砸王、重要狀態(tài)的更新等

3.3.?TCP通信原理

對于TCP通信來說推盛，每個(gè)TCP Socket的內(nèi)核中都有一個(gè)發(fā)送緩沖區(qū)和一個(gè)接收緩沖區(qū)，TCP的全雙工的工作模式及TCP的滑動(dòng)窗口就是依賴于這兩個(gè)獨(dú)立的Buffer和該Buffer的填充狀態(tài)谦铃。

接收緩沖區(qū)把數(shù)據(jù)緩存到內(nèi)核耘成，若應(yīng)用進(jìn)程一直沒有調(diào)用Socket的read方法進(jìn)行讀取，那么該數(shù)據(jù)會一直被緩存在接收緩沖區(qū)內(nèi)荷辕。不管進(jìn)程是否讀取Socket凿跳，對端發(fā)來的數(shù)據(jù)都會經(jīng)過內(nèi)核接收并緩存到Socket的內(nèi)核接收緩沖區(qū)。

Read所要做的工作疮方，就是把內(nèi)核接收緩沖區(qū)中的數(shù)據(jù)復(fù)制到應(yīng)用層用戶的Buffer里。

進(jìn)程調(diào)用Socket的send發(fā)送數(shù)據(jù)的時(shí)候茧彤，一般情況下是講數(shù)據(jù)從應(yīng)用層用戶的Buffer里復(fù)制到Socket的內(nèi)核發(fā)送緩沖區(qū)骡显，然后send就會在上層返回。換句話說，send返回時(shí)惫谤，數(shù)據(jù)不一定會被發(fā)送到對端壁顶。

通信時(shí)序圖發(fā)送端：

通信時(shí)序圖接收端：

注：buffer大小在JAVA默認(rèn)程序里為8192

3.4.?三次握手

三次握手（Three-Way Handshake）即建立TCP連接，就是指建立一個(gè)TCP連接時(shí)溜歪，需要客戶端和服務(wù)端總共發(fā)送3個(gè)包以確認(rèn)連接的建立若专。

（1）第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J蝴猪，并將該數(shù)據(jù)包發(fā)送給Server调衰，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)自阱。

（2）第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請求建立連接嚎莉，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1沛豌，隨機(jī)產(chǎn)生一個(gè)值seq=K趋箩，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請求，Server進(jìn)入SYN_RCVD狀態(tài)加派。

（3）第三次握手：Client收到確認(rèn)后叫确，檢查ack是否為J+1，ACK是否為1芍锦，如果正確則將標(biāo)志位ACK置為1启妹，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server醉旦，Server檢查ack是否為K+1饶米，ACK是否為1，如果正確則連接建立成功车胡，Client和Server進(jìn)入ESTABLISHED狀態(tài)檬输，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了匈棘。

SYN攻擊：

在三次握手過程中丧慈，Server發(fā)送SYN-ACK之后，收到Client的ACK之前的TCP連接稱為半連接（half-open connect）主卫，此時(shí)Server處于SYN_RCVD狀態(tài)逃默，當(dāng)收到ACK后，Server轉(zhuǎn)入ESTABLISHED狀態(tài)簇搅。SYN攻擊就是Client在短時(shí)間內(nèi)偽造大量不存在的IP地址完域，并向Server不斷地發(fā)送SYN包，Server回復(fù)確認(rèn)包瘩将，并等待Client的確認(rèn)吟税，由于源地址是不存在的凹耙，因此，Server需要不斷重發(fā)直至超時(shí)肠仪，這些偽造的SYN包將產(chǎn)時(shí)間占用未連接隊(duì)列肖抱，導(dǎo)致正常的SYN請求因?yàn)殛?duì)列滿而被丟棄，從而引起網(wǎng)絡(luò)堵塞甚至系統(tǒng)癱瘓异旧。SYN攻擊時(shí)一種典型的DDOS攻擊意述，檢測SYN攻擊的方式非常簡單，即當(dāng)Server上有大量半連接狀態(tài)且源IP地址是隨機(jī)的吮蛹，則可以斷定遭到SYN攻擊了荤崇，使用如下命令可以讓之現(xiàn)行：

??#netstat -nap | grep SYN_RECV

3.5.?四次揮手

所謂四次揮手（Four-Way Wavehand）即終止TCP連接，就是指斷開一個(gè)TCP連接時(shí)匹涮，需要客戶端和服務(wù)端總共發(fā)送4個(gè)包以確認(rèn)連接的斷開天试。

由于TCP連接時(shí)全雙工的，因此然低，每個(gè)方向都必須要單獨(dú)進(jìn)行關(guān)閉喜每，這一原則是當(dāng)一方完成數(shù)據(jù)發(fā)送任務(wù)后，發(fā)送一個(gè)FIN來終止這一方向的連接雳攘，收到一個(gè)FIN只是意味著這一方向上沒有數(shù)據(jù)流動(dòng)了带兜，即不會再收到數(shù)據(jù)了，但是在這個(gè)TCP連接上仍然能夠發(fā)送數(shù)據(jù)吨灭，直到這一方向也發(fā)送了FIN刚照。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉，而另一方則執(zhí)行被動(dòng)關(guān)閉喧兄，上圖描述的即是如此无畔。

（1）第一次揮手：Client發(fā)送一個(gè)FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送吠冤，Client進(jìn)入FIN_WAIT_1狀態(tài)浑彰。

（2）第二次揮手：Server收到FIN后，發(fā)送一個(gè)ACK給Client拯辙，確認(rèn)序號為收到序號+1（與SYN相同郭变，一個(gè)FIN占用一個(gè)序號），Server進(jìn)入CLOSE_WAIT狀態(tài)涯保。

（3）第三次揮手：Server發(fā)送一個(gè)FIN诉濒，用來關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入LAST_ACK狀態(tài)夕春。

（4）第四次揮手：Client收到FIN后未荒，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個(gè)ACK給Server撇他，確認(rèn)序號為收到序號+1茄猫，Server進(jìn)入CLOSED狀態(tài)狈蚤，完成四次揮手困肩。

注：

單工：數(shù)據(jù)傳輸只支持?jǐn)?shù)據(jù)在一個(gè)方向上傳輸划纽。

半雙工：數(shù)據(jù)傳輸允許數(shù)據(jù)在兩個(gè)方向上傳輸，但是在某一時(shí)刻锌畸，只允許在一個(gè)方向上傳輸勇劣，實(shí)際上有點(diǎn)像切換方向的單工通信。

全雙工：數(shù)據(jù)通信允許數(shù)據(jù)同時(shí)在兩個(gè)方向上傳輸潭枣，因此全雙工是兩個(gè)單工通信方式的結(jié)合比默，它要求發(fā)送設(shè)備和接收設(shè)備都有獨(dú)立的接收和發(fā)送能力。

3.6.?滑動(dòng)窗口

發(fā)送方和接收方都會維護(hù)一個(gè)數(shù)據(jù)幀的序列盆犁，這個(gè)序列被稱作窗口命咐。發(fā)送方的窗口大小由接收方確認(rèn)，目的是控制發(fā)送速度谐岁，以免接收方的緩存不夠大導(dǎo)致溢出醋奠，同時(shí)控制流量也可以避免網(wǎng)絡(luò)擁塞。

明白了Socket讀寫數(shù)據(jù)的底層原理伊佃，我們就很容易理解“阻塞模式”：對于讀取Socket數(shù)據(jù)的過程而言窜司，如果接收緩沖區(qū)為空，則調(diào)用Socket的read方法的線程會阻塞航揉，知道有數(shù)據(jù)進(jìn)入接收緩沖區(qū)塞祈；而對于寫數(shù)據(jù)到Socket中的線程來說，如果待發(fā)送的數(shù)據(jù)長度大于發(fā)送緩沖區(qū)空余長度帅涂，則會阻塞在write方法上议薪，等待發(fā)送緩沖區(qū)的報(bào)文被發(fā)送到網(wǎng)絡(luò)上，然后繼續(xù)發(fā)送下一段數(shù)據(jù)媳友，循環(huán)上述過程直到數(shù)據(jù)都被寫入到發(fā)送緩沖區(qū)為止斯议。

從前面分析的過程來看，傳統(tǒng)的Socket阻塞模式直接導(dǎo)致每個(gè)Socket都必須綁定一個(gè)線程來操作數(shù)據(jù)庆锦，參與通信的任意一方如果處理數(shù)據(jù)的速度較慢捅位，會直接拖累到另一方，導(dǎo)致另一方的線程不得不浪費(fèi)大量的時(shí)間在I/O等待上搂抒，所以這就是Socket阻塞模式的“缺陷”艇搀。但是這種模式在少量的TCP連接通信的情況下，雙方都可以快速的傳輸數(shù)據(jù)求晶，這個(gè)時(shí)候的性能是最高的焰雕。

3.7.?IO模型

BIO模型

同步阻塞式IO，服務(wù)器端與客戶端三次握手簡歷連接后一個(gè)鏈路建立一個(gè)線程進(jìn)行面向流的通信芳杏。這曾是jdk1.4前的唯一選擇矩屁。在任何一端出現(xiàn)網(wǎng)絡(luò)性能問題時(shí)都影響另一端辟宗，無法滿足高并發(fā)高性能的需求。

NIO模型

　同步非阻塞IO吝秕，以塊的方式處理數(shù)據(jù)泊脐。采用多路復(fù)用Reactor模式。JDK1.4時(shí)引入烁峭。

AIO模型

異步非阻塞IO容客，基于unix事件驅(qū)動(dòng)，不需要多路復(fù)用器對注冊通道進(jìn)行輪詢约郁，采用Proactor設(shè)計(jì)模式缩挑。JDK1.7時(shí)引入。

4.UDP/IP協(xié)議

4.1.?什么是UDP/IP

UDP 是User Datagram Protocol的簡稱鬓梅， 中文名是用戶數(shù)據(jù)報(bào)協(xié)議供置，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議绽快。在OSI模型中芥丧，在第四層——傳輸層，處于IP協(xié)議的上一層谎僻。UDP有不提供數(shù)據(jù)包分組娄柳、組裝和不能對數(shù)據(jù)包進(jìn)行排序的缺點(diǎn)，也就是說艘绍，當(dāng)報(bào)文發(fā)送之后赤拒，是無法得知其是否安全完整到達(dá)的。UDP用來支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用诱鞠。包括網(wǎng)絡(luò)視頻會議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議挎挖。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋航夺，但是即使是在今天UDP仍然不失為一項(xiàng)非常實(shí)用和可行的網(wǎng)絡(luò)傳輸層協(xié)議蕉朵。

4.2.?應(yīng)用場景

實(shí)時(shí)通信、QQ阳掐、視頻始衅、流媒體等應(yīng)用

5.協(xié)議在分布式應(yīng)用