【一文完全搞懂】遠程網絡通信協議

遠程網絡通信協議

現代互聯網開發過程當中，不管是什麼架構系統，沒法避免的而且很重要的一個環節就是網絡通信，好的網絡通信方案和協議會讓整個程序效率和耗時變得更低，而JAVA開發過程當中咱們通常接觸到的都是基於TCP/IP的網絡協議，因此一個優秀的軟件工程師，必備技術棧之一就是對遠程網絡協議有必定的瞭解

OSI七層網絡模型

通常咱們說的網絡模型都是OSI網絡模型，而所謂的OSI網絡模型通常分爲七層，這七層從上到下分別爲（應用層-->表示層-->會話層-->傳輸層-->網絡層-->數據鏈路層-->物理層）:

應用層-->表示層-->會話層-->傳輸層-->網絡層-->數據鏈路層-->物理層

大概的訪問調用如圖所示:

有圖能夠看出，OSI的網絡模型將每個步驟分的特別細緻，而在咱們開發過程當中，最常接觸到的通常是基於OSI的二層協議--TCP/IP協議

TCP/IP四層(五層)網絡模型

看到這個標題必定會有人奇怪，究竟是四層仍是五層模型啊，其實TCP/IP基於OSI的模型，將其中一部分操做合併爲一個模型，而傳統認爲是四層模型，分別爲:

應用層-->傳輸層-->網絡層-->網絡接口層

即與OSI對應的模型關係以下:

而有些人認爲網絡接口層不該該合併數據鏈路層和物理層，這兩層在表現上是不一樣的，因此就有了五層模型，三種模型之間的比較圖以下:

TCP/IP請求流程

弄懂了TCP/IP大概的模型，咱們來思考一個問題，即這四層模型分別是用來幹啥的？又作了什麼處理？在思考這些問題以前，咱們先來了解這四層網絡模型分別包括哪些東西

應用層

超文本傳輸協議(HTTP):萬維網的基本協議

文件傳輸(TFTP簡單文件傳輸協議)

遠程登陸(Telnet),提供遠程訪問其它主機功能,它容許用戶登陸 

internet主機,並在這臺主機上執行命令. 

網絡管理(SNMP簡單網絡管理協議),該協議提供了監控網絡設備的方法,以及配置管理,統計信息收集,性能管理及安全管理等.

域名系統(DNS),該系統用於在internet中將域名及其公共廣播的網絡節點轉換成IP地址

網絡層

Internet協議(IP) 

Internet控制信息協議(ICMP)

地址解析協議(ARP)

反向地址解析協議(RARP)

網絡接口層

網絡訪問層又稱做主機到網絡層(host-to-network).網絡訪問層的功能包括IP地址與物理地址硬件的映射,以及將IP封裝成幀.基於不一樣硬件類型的網絡接口,網絡訪問層定義了和物理介質的鏈接

接下來，咱們看看一個完整請求打來後，TCP/IP的四層模型的大概處理流程是什麼:

從上圖咱們能夠看到，當客戶端發起請求的時候(應用層)，傳輸層會根據你發來的請求，將請求中添加Tcp頭信息，而且傳遞倒網絡層,在網絡層中，會將當前請求處理/計算(獲取出ip地址等信息)，添加Ip首部信息到請求中，接着傳遞到了數據鏈路層，在這一層中咱們會依照IP地址再去給當前請求計算出一個Mac碼，因爲IP還存在重複的狀況，而MAC地址是惟一的，這個時候將MAC首部信息加入請求中，根據當前的請求就能夠識別出惟一的請求了。

當數據傳輸到服務端的時候，會將傳遞來的request請求進行解析，可是須要注意的是這裏解析的順序與請求的順序相反，首先從數據鏈路層解析掉MAC首部信息，將剩下的請求信息繼續往上傳遞，而後解析Ip首部信息，再去解析Tcp首部信息、端口和請求報文參數等，根據端口等找到對應的進程，進行響應操做，這樣就是一個完整的調度流程

ARP尋址協議

上面咱們有介紹到封裝請求的過程當中，咱們首先將IP首部信息存入請求中，而後再去存入MAC首部信息，這裏不由會有一個疑惑，IP和MAC有什麼關係嗎？其實咱們任何一臺設備都會有一個MAC和一個IP信息進行對應，客戶端發起請求的時候，會利用一個ARP尋址協議的方式找到IP對應的MAC信息，此協議大至以下:當咱們已知機器的IP的時候，發起一個基於當前IP的廣播消息，而對應IP的機器收到廣播後會返回響應信息，即當前機器對應的MAC首部信息，這樣就能夠根據IP獲取到MAC首部信息

注意:爲了防止每一次都會發起ARP尋址，本地機器會有緩存策略，通常來講當咱們的IP信息進行變動之後，緩存信息就會失效，這個時候纔會從新進行ARP尋址

分層負載

分佈式開發的過程當中，常常聽到一個專業名詞即--二層負載/四層負載/七層負載，其實這裏的xxx層負載就是指的是負載均衡方案所在的網絡協議的層級（針對與服務端解析的層級--逆向層級）

二層負載

二層負載協議，通常來講是針對MAC首部信息作的負載均衡，例如當前有一個集羣，咱們但願外部訪問的時候IP地址是同樣的，可是機器的MAC不一致，保證請求分發到每一臺機器上，這時候能夠提供一個虛擬的MAC首部信息，解析請求中的MAC信息的時候，將MAC信息修改成集羣中須要被分發的機器的真實MAC首部信息，從而達到負載均衡的效果

三層負載

三層負載指的是針對IP層級的負載，和MAC負載(二層負載)很類似，負載均衡服務器對外提供一個虛擬IP首部信息，當解析請求的時候，修改虛擬IP爲真實的被分發的機器的IP，達到負載均衡的效果

四層負載

四層負載針對在OSI模型的傳輸層中，這一層中通常都是TCP/UDP這類的協議，而這一層通常都是封裝了當前客戶端的請求報文信息(包含源IP,目標IP，當前端口號以及目標端口號等)，因此四層負載的實現方案通常都是接受到請求信息之後，修改請求數據中的IP/端口號的信息，來分發到不一樣的應用程序中(此類負載均衡例如:Nginx)

七層負載

除了上面常見的幾種負載均衡之外，還有一種特殊的負載，叫七層負載，這種負載通常是在應用層作的操做，而應用層通常都是客戶端請求交互層，這一層中通常只有HTTP/DNS等協議，因此在當前層，咱們能夠作到的負載條件不少，好比根據不一樣的URL，不一樣的請求類型等均可以實現分發到不一樣的服務器上

TCP/IP的握手協議與揮手協議

三次握手

tcp的鏈接是經過三次握手協議完成有效鏈接創建的，所謂的三次握手就是客戶端和服務端在鏈接過程當中，總共發送三個包來相互之間確認並創建聯繫，而在sokect編程中，握手的過程由connect來觸發

從上圖咱們能夠看出來三次握手的過程爲:

第一次握手：客戶端發送了一個SYN爲1標誌包，指明客戶端將要鏈接的服務器端口，而且初始化序號X保存在序列號(Sequence Number)字段中，發送完畢之後，客戶端的狀態變動爲SYN-SENT

第二次握手：服務器收到了客戶端的請求，發送回確認包標誌ACK以及客戶端發送來的SYN應答爲1，而且服務端選擇ISN序列號Y，存放到Seq中，將確認的序列號(Acknowledgement Number)設置爲客戶端發來sql+1，當發送完畢後，服務端狀態變動爲SYN-RCVD

第三次握手：客戶端再次確認ACK，Ack爲1，而且把服務端的ACK+1放在序列seq中，將服務端的序列+1放入確認字段ack中，在發送完畢之後，客戶端俄日ESTAB-LISHED狀態,當服務端也收到這個確認包之後，也會進入ESTAB-LISHED狀態，此時握手結束

四次揮手

與鏈接的時候三次握手不一樣，斷開鏈接的時候須要四次揮手的過程才能保證必定是關閉鏈接:

第一次揮手：客戶端須要斷開鏈接的時候，發送一個FIN爲1的包，表示我已經沒有數據須要發送了，能夠準備斷開鏈接，可是這個時候我還能夠接受你的數據，當發送完畢後，狀態爲FIN-WAIT-1

第二次揮手：服務端拿到了客戶端發來的FIN標誌位，發送一個確認包，表示當前已經收到了你的關閉鏈接的請求，ACK爲1，生成seq序列，而且將客戶端發來的seq+1做爲ack確認字段進行應答，發送完畢後服務端狀態爲CLOSE-WIAT狀態，當客戶端受到應答之後，狀態變動爲FIN-WAIT-2，可是這個時候服務端還沒關閉，可能還存在須要發送的數據

第三次揮手:當服務端沒有數據須要發送的時候，會再次發送一個包，FIN爲1，ACK爲1，生成序列seq，而且將上一次的ack確認字段繼續發送過來，發送完畢後，服務端處於LAST-ACK狀態

第四次揮手:客戶端收到了來自服務端的將要關閉的包，併發出一個確認包，將服務端的ack做爲seq，而且將服務端的seq+1做爲ack確認字段再次發送過去，這個時候客戶端會進入TIME-WAIT狀態，並等待2MSL時間，這個時候服務端收到了響應，就會關閉鏈接，或者等待了2MSL之後，客戶端沒有收到響應，也會認爲服務端已經關閉，也會進行關閉操做

SYN攻擊

在三次握手的過程當中，服務端發送了ack確認字段給客戶端後，收到ack的客戶端鏈接稱之爲半鏈接，若是這個時候客戶端不返回確認包，那麼服務端會重發直到超時，可是若是段時間內僞造大量的不存在的客戶端ip發起鏈接請求，服務端等待客戶端確認一直等待不到，因此短期內大量無用的鏈接佔用隊列，致使正常的用戶鏈接阻塞致使網絡癱瘓，SYN攻擊是最多見的DDOS攻擊，因此有效的檢測SYN攻擊和防禦很重要，防禦方案常見以下：

1.過濾網關防禦 2.加固TCP/IP協議線

爲何TCP/IP是三次握手，不是二次也不是四次？

三次握手是由於由於當 Server 端收到 Client 端的 SYN 鏈接請求報文後，能夠直接發送 SYN+ACK 報文。其中 ACK 報文是用來應答的，SYN 報文是用來同步的。可是關閉鏈接時， 當 Server 端收到 FIN 報文時，極可能並不會當即關閉 SOCKET（由於可能還有消息沒處理 完），因此只能先回復一個 ACK 報文，告訴 Client 端，"你發的 FIN 報文我收到了"。只有等到 我 Server 端全部的報文都發送完了，我才能發送 FIN 報文，所以不能一塊兒發送。故須要四步 握手

爲何四次揮手之後還要等待2MSL才正式關閉？

網絡是不可靠的，雖然收到服務端的確認之後，客戶端發出確認之後已經能夠close，可是，可能出現失敗須要重試或者網絡卡頓致使，客戶端發出時間接近一次MSL時間,服務端返回也接近MSL時間，可能性都有，因此爲了保險起見，等待到兩個最大的時間後還收不到返回的消息，才能夠認爲是服務端關閉了

TCP的IO通訊原理

雙工協議

TCP 是一個全雙工協議，數據通訊容許數據同時在兩個方向上傳輸，所以全雙工是兩個單工 通訊方式的結合，它要求發送設備和接收設備都有獨立的接收和發送能力，常見的協議以下:

協議	概念
單工協議	數據傳輸只支持數據在一個方向傳輸
半雙工協議	數據傳輸容許數據在兩個方向傳輸，可是在某個時刻，只能在一個方向傳輸
全雙工協議	容許數據同時在兩個方向上傳輸，要求設備有獨立的接收和發送的能力

IO通訊過程

TCP、UDP 都是在基於Socket 概念上爲某類應用場景而擴展出的傳輸協議,而socket 是一種 抽象層，應用程序經過它來發送和接收數據，就像應用程序打開一個文件句柄，把數據讀寫 到磁盤上同樣。使用 socket 能夠把應用程序添加到網絡中，並與處於同一個網絡中的其餘應 用程序進行通訊。不一樣類型的 Socket 與不一樣類型的底層協議簇有關聯。主要的 socket 類型 爲流套接字（stream socket）和數據報文套接字（datagram socket）。 stream socket 把 TCP做爲端對端協議（底層使用 IP 協議），提供一個可信賴的字節流服務。數據報文套接字 （datagram socket）使用 UDP 協議（底層一樣使用 IP 協議）提供了一種「盡力而爲」的數據 報文服務，瞭解了Socket之後，咱們來了解下tcp的io通訊過程:

對於 TCP 通訊來講，每一個 TCP Socket 的內核中都有一個發送緩衝區和一個接收緩衝 區，TCP 的全雙工的工做模式及 TCP 的滑動窗口就是依賴於這兩個獨立的 Buffer 和該 Buffer 的填充狀態。而接收緩衝區把數據緩存到內核，若應用程序一直不調用Socket的read方法讀取，那麼則該數據一直存在緩衝區中，而read方法就是把數據複製到應用層的buffer中。而調用send方法的時候通常是把數據從應用層的buffer中，讀取到Socket內核緩衝區，將數據返回，可是若是應用一直不讀取，那麼buffer滿了之後，若是對端的窗口關閉，tcp緩存區的數據不會移除，這也證明了TC是可靠傳輸的。若是傳輸的數據超過了窗口的大小，那麼接收方會把剩下的數據丟棄

滑動窗口

早期的網絡通訊過程當中，因爲不會考慮到網絡擁擠的狀況致使數據丟失而直接發送數據，因此後來爲了解決這個問題，就出了一個流量控制技術--滑動窗口協議，發送方和接收方都要維護一個數據幀的序列，這個序列稱之爲窗口

窗口尺寸:能夠不等待應答而繼續發送數據的最大的幀稱之爲窗口尺寸

發送窗口：能夠不等待應答繼續發送的窗口

接受窗口：接受發送來的數據，落在當前窗口中的幀，必定會被處理，可是落在窗口外的數據，容許被丟棄的窗口

這點能夠參照在線的滑動窗口演示：

media.pearsoncmg.com/aw/ecs_kuro…