應用層
應用層是負責應用程序之間溝通的一層。由于不同的網(wǎng)絡應用的應用進程之間，有著不同的通信規(guī)則，因此自然就需要應用層協(xié)議來解決這些問題，這就構成了應用層的主要內容即：精確定義這些通信規(guī)則。
應用層有不少應用廣泛的協(xié)議，像域名系統(tǒng)（DNS）、文件傳輸協(xié)議（FIP）、網(wǎng)絡遠程訪問協(xié)議（Telent）等，（具體的協(xié)議規(guī)則這里不做介紹）除此之外，在日常程序員的工作中使用同樣頻繁的還有自定義應用層協(xié)議；
自定義應用層協(xié)議
什么是自定義應用層協(xié)議
所謂自定義，即程序的開發(fā)者自定義。自定義，包含著一個根據(jù)需要從無到有的過程。協(xié)議，則代表了某種約定。因此，自定義協(xié)議就可以簡單理解為由程序的開發(fā)者根據(jù)程序開發(fā)的需要去約定客戶端和服務器傳輸數(shù)據(jù)的格式；
自定義方式
在約定之前，首先要明確交互過程中傳遞的信息有哪些。以網(wǎng)上購物為例，用戶作為請求的發(fā)出方，就需要明確用戶的地址，電話號碼等信息；而商家則是作為請求的接收方，需要明確商家的一些具體情況，像商品類型，商品銷量、商品價格、接單時間等；
根據(jù)用戶需求明確了交互中涉及到的信息之后，就需要根據(jù)實際情況來確定這些信息的組織格式，自此，即真正開始了應用層協(xié)議的自定義。
實際需求下，信息的組織格式是有多種方式的：
-
使用簡單的分隔符來區(qū)分不同部分的信息；
仍然使用商品上網(wǎng)購物的例子，如上圖，[;]就是用來區(qū)分不同信息的簡單分隔符； -
使用固定長度確定不同信息；
使用固定長度來表示不同信息，也根據(jù)長度來區(qū)分不同信息； -
融合方式一和方式二，一部分字段信息使用分隔符來區(qū)分，一部分字段使用固定長度來區(qū)分；
-
使用xml格式來約定數(shù)據(jù)；
xml格式是一種標簽結構的用來展示數(shù)據(jù)的格式，它包含了開始標簽和結束標簽，標簽一般都是成對出現(xiàn)的；
- 使用json格式組織數(shù)據(jù)；
相比xml,json的使用更加廣泛，它是使用鍵值對的方式來組織數(shù)據(jù)，每個鍵值對之間使用逗號進行分割，每個鍵值對的鍵和值之間使用冒號進行分割；
json格式的鍵必須是字符串形式；
- 二進制數(shù)據(jù)組織格式，protobuffer,thrift；
這種數(shù)據(jù)組織格式較為復雜，盡管它的效率相比json或xml要更高，且占用的帶寬也要更低，但它的可讀性卻不如前者，在具體使用中，可以根據(jù)實際情況進行選擇。
運輸層
運輸層概述
運輸層是整個網(wǎng)絡體系結構中的關鍵層次之一，為應用層提供通信服務。其實，對于通信而言，如果是主機對主機之間的通信，網(wǎng)絡層即可實現(xiàn)?？墒歉嗟那闆r下，是端口與端口之間的通信，像主機A的應用程序1與主機B的應用程序2通信，如果在這種情況下，僅僅依靠網(wǎng)絡層就無法很好的實現(xiàn)，這時運輸層就在這樣的通信中起到了關鍵作用。
運輸層特點
一般而言，運輸層有2個特點，即復用(multiplexing)和分用(demultiplexing);
復用：即發(fā)送方不同的應用進程都可以使用同一個運輸層協(xié)議傳送數(shù)據(jù)；
分用：接收方的運輸層可以把傳送來的數(shù)據(jù)正確交付指定的應用進程；
運輸層協(xié)議
TCP/IP運輸層有2個主要協(xié)議，即用戶數(shù)據(jù)報協(xié)議UDP和傳輸控制協(xié)議TCP；
UDP協(xié)議
UDP協(xié)議，即用戶數(shù)據(jù)報協(xié)議。UDP數(shù)據(jù)報傳送實際是一種不可靠的傳輸，因為UDP在傳送數(shù)據(jù)之前不會有建立連接的操作，同時在主機B的運輸層收到報文以后也不需要對發(fā)送端給出任何確認。但盡管UDP是一種不可靠的傳輸，也不可避免在一些情況下是有效且便利的。
UDP的特點
-
UDP是無連接的
發(fā)送之前不需要建立連接； -
UDP是不可靠傳輸
其不可靠也是由于其是無連接的； -
UDP是面向數(shù)據(jù)報的
UDP不會對應用層交付的報文做任何處理，只會原樣發(fā)送，一次發(fā)送一個報文，同時接收端的UDP也是一次交付一個報文； -
UDP傳送報文的長度受限
過長的報文在被交付到IP層后可能會被分片，過短的報文被交付會使IP數(shù)據(jù)報的首部長度過長，都會較低IP層的效率； -
UDP支持一對一、一對多、多對一、多對多的交互通信
UDP首部格式
UDP用戶數(shù)據(jù)報的組成包括了2個字段，即首部字段和數(shù)據(jù)字段；
首部字段又包含了4個字段，8個字節(jié)，每個字段的長度為2個字節(jié)；
4個字段分別為：
源端口號：數(shù)據(jù)發(fā)送端的端口號；
目的端口號：數(shù)據(jù)接收端的端口號；
長度：UDP用戶數(shù)據(jù)報的長度；
校驗和：用于檢測UDP傳輸過程中是否出錯；
校驗規(guī)則
UDP校驗和是用來校驗UDP傳輸過程是否正確的主要指標。由于在數(shù)據(jù)通過網(wǎng)絡傳輸?shù)倪^程中，有可能會受到許多元素的影響。為了避免錯誤的數(shù)據(jù)在未知的情況下被傳輸，規(guī)定在發(fā)送數(shù)據(jù)時，將其校驗和和數(shù)據(jù)一起傳輸。在計算校驗和時，是在UDP用戶數(shù)據(jù)報之前增加了12個字節(jié)的偽首部。這個偽首部是臨時增加在數(shù)據(jù)報首部的，而不屬于數(shù)據(jù)報真正的首部，也不會被作為向下傳遞的一部分。
UDP使用的校驗和算法，是一種循環(huán)冗余校驗和(CRC)的方法,具體計算方法這里不做介紹。
TCP協(xié)議
TCP協(xié)議即傳輸控制協(xié)議。
TCP的特點
-
有連接
TCP在發(fā)送數(shù)據(jù)之前首先需要建立連接； -
可靠傳輸；
TCP的可靠傳輸是TCP的核心特點，所謂可靠傳輸并非是指一旦發(fā)送一定接收成功，而是，當數(shù)據(jù)發(fā)送成功后，對方是否接收成功，對于發(fā)送方來說是清晰的。通過TCP傳輸?shù)臄?shù)據(jù)，無差錯、不丟失、不重復、按序到達； -
面向字節(jié)流傳輸；
即在發(fā)送數(shù)據(jù)時對數(shù)據(jù)進行編號是依照字節(jié)來編；
TCP協(xié)議段格式
TCP協(xié)議段是由20個字節(jié)的固定首部加數(shù)據(jù)組成的：
源端口號：數(shù)據(jù)來源；
目的端口號：數(shù)據(jù)去處；
序列號：數(shù)據(jù)編號后得到的序列號；
確認序號：接收到數(shù)據(jù)后的應答；
首部長度：（4位）表示TCP頭部長度；
標志位：URG->緊急指針是否有效；ACK->確認號是否有效；PSH->提示接收端從緩沖區(qū)讀取數(shù)據(jù)；PST->對方要求重新建立連接；SYN->請求建立連接，同步報文段；FIN->結束報文段；
TCP的性質
TCP可靠傳輸?shù)谋ＷC，最主要的一點實際就是：確認應答。
確認序號
確認應答首先依靠確認序號來實現(xiàn)，即首先對需要發(fā)送的數(shù)據(jù)（普通報文）進行編號。假設發(fā)送的數(shù)據(jù)編號情況是1—500，則確認序號為501?？梢岳斫鉃?，發(fā)送端將編好號的數(shù)據(jù)發(fā)送給接收端后，由接收端給發(fā)送端發(fā)送一個應答報文，即確認序號，通過確認序號就可以確定當前接收端是對哪個普通報文做出了應答。也就代表接收端已經(jīng)接收到了該報文。
超時重傳
TCP數(shù)據(jù)的可靠性傳輸是依靠于應答報文的接收來確定的，而如果發(fā)送方發(fā)送數(shù)據(jù)之后等待一定時間但未收到接收方的應答報文，大概率就可以判定為數(shù)據(jù)傳輸失敗，于是觸發(fā)重傳。
使用超時重傳的方式在很大程度上就可以避免數(shù)據(jù)傳輸失敗的問題，但伴隨著超時重傳同樣也帶來了接收端難免會收到一些重復數(shù)據(jù)的問題；因此，接收方就需要對收到的數(shù)據(jù)進行去重，也就是根據(jù)之前數(shù)據(jù)的編號進行排查，如若發(fā)現(xiàn)收到了一份與之前相同的數(shù)據(jù)就自動丟棄，依次來保證最終在應用層讀到的數(shù)據(jù)是不重復的。
當然，初始傳輸?shù)臄?shù)據(jù)可能會丟失，如若處在同樣的網(wǎng)絡環(huán)境中，重傳的數(shù)據(jù)同樣也有可能會丟失。而TCP為了保證較高性能的通信，就會不斷動態(tài)地來計算最大等待時間。像一般情況下操作系統(tǒng)都是以500ms一個單位為基礎等待時間，假如在重發(fā)之后一個500ms任未得到應答，下次重傳就會在2個500ms之后。依次類推~~~
當然，若是多次重傳仍然得不到回應，就會強制關閉連接，不再進行傳輸。
連接管理
TCP作為一種有連接的可靠傳輸，與它的連接管理機制是分不開的；而所謂連接管理就是TCP經(jīng)過三次握手建立連接，四次揮手斷開連接。
三次握手
TCP通過“三次握手”建立連接，連接的建立一定是由客戶端首先主動發(fā)起的；
三次握手的主要過程和原理如圖，即首先由客戶端向服務器發(fā)送一個請求嘗試建立連接（第一次握手），服務器收到該請求之后向客戶端做出應答同時建立與客戶端的連接（第二次握手），最后再由客戶端對服務器的請求做出應答，至此連接建立成功（第三次握手）~
三次握手是保證數(shù)據(jù)正常傳輸?shù)闹匾疤?，只有在通信之前就確定通信鏈路的暢通，即驗證通信雙方的發(fā)送能力和接收能力，才可以更大程度的成功傳輸數(shù)據(jù)。同時在這樣一個過程中，客戶端與服務器雙方也會進行一些重要參數(shù)的協(xié)商，也是通信中不可避免的一個環(huán)節(jié)~
四次揮手
四次揮手實際就是通信雙方通知斷開連接的過程，與三次揮手不同，四次揮手既可以由客戶端一方發(fā)起，也可以由服務器方發(fā)起~
四次揮手的原理如圖，任意一方首先發(fā)送一個斷開連接的請求，對方做出回應之后再發(fā)送一個斷開連接的請求，待對方最初應答之后，連接斷開~
TCP的狀態(tài)
TCP的狀態(tài)實際有很多種，這里主要介紹下面幾種：
-
LISTEN
一般表示服務器的狀態(tài)，表示服務器已經(jīng)啟動完畢~ -
ESTABLISHED
表示通信雙方連接建立成功，可以進行通信~ -
CLOSE_WAIT
待斷開連接的狀態(tài)，對方發(fā)送了斷開連接的請求自己也做出了應答，待自己發(fā)送斷開連接的請求時就是該狀態(tài)；在Socket編程中，調用close()方法表示斷開連接； -
TIME_WAIT
主動發(fā)送斷開請求的一方的狀態(tài)，主動方在收到對方斷開連接請求同時做出應答之后就處于該狀態(tài)；該狀態(tài)持續(xù)一段時間后，連接徹底斷開~
滑動窗口
以上三種機制確實是保證了TCP傳輸?shù)目煽啃裕珡哪硞€角度來說，反復保證可靠傳輸?shù)牟僮饕膊豢杀苊獾亟档土薚CP通信的效率，因此為了盡可能地提高其傳輸效率，就產(chǎn)生了滑動窗口的機制。
最基本的TCP通信是主機A發(fā)送一條數(shù)據(jù)，待主機B返回應答報文后，主機A再繼續(xù)發(fā)送下一條數(shù)據(jù)，而添加了滑動窗口機制的TCP特性則是一次發(fā)送一批數(shù)據(jù)，這一批數(shù)據(jù)有可能包含了多條單個的數(shù)據(jù)，待對方返回了第一條數(shù)據(jù)的應答報文之后，主機A就繼續(xù)發(fā)送下一批數(shù)據(jù)，這就是滑動窗口的基本工作原理。
至于這里一批數(shù)據(jù)包含了多少條數(shù)據(jù)，就在于這個窗口的大小，窗口大小越大，一次發(fā)送的數(shù)據(jù)就越多，相應其發(fā)送速率也就越高。
與普通的TCP傳輸相同，增加了滑動窗口機制的TCP通信同樣有可能會出現(xiàn)丟包的問題，那么它們對于丟包的處理又會有什么不同呢？
第一種情況是傳輸?shù)臄?shù)據(jù)本身丟了：
發(fā)送方通過接收到的應答報文來判斷是否出現(xiàn)了丟包，假設發(fā)送方一次發(fā)送了1-1000、 1001-2000、 2001-3000三條數(shù)據(jù)，同時收到的多條應答報文都是1001，就可以斷定后面的2條數(shù)據(jù)發(fā)生了丟包，此時發(fā)送方就會重新發(fā)送后面的2條數(shù)據(jù)，而不會重復發(fā)送第一條數(shù)據(jù)。因此，對于數(shù)據(jù)本身丟包，原則就是丟哪條，重發(fā)哪條，對于成功傳輸?shù)臄?shù)據(jù)，則不會重復發(fā)送。
第二種情況是應答報文丟了：
一般情況下，無論網(wǎng)絡環(huán)境有多么復雜，丟包始終都是一個小概率事件，因此假設數(shù)據(jù)的發(fā)送情況與上面一致，但接收到的應答報文卻只有2001和3001，對于發(fā)送方來說，是可以認為1-1000的數(shù)據(jù)也是順利到達了的，即對于應答報文涵蓋的信息，后一個是會包含上一個的。
我們說滑動窗口的機制是提高TCP的通信效率，但這只是針對沒有滑動窗口時的普通的TCP通信，如果是與不保證可靠性的UDP相比，自然是不及UDP的效率的。因此，與其將滑動窗口機制看做是提高效率的方式，不如認為是對低效率的補救。
流量控制
流量控制實際就是對滑動窗口進行限制的一種機制，因為對于滑動窗口而言，窗口越大，數(shù)據(jù)的發(fā)送效率就越大。但如若這個效率過大，又會帶來丟包等一系列的問題，因此對其效率進行控制就是必要的。
由于接收端接收到數(shù)據(jù)之后，是將數(shù)據(jù)暫時存儲在緩沖區(qū)，等待接收端的應用程序來讀取數(shù)據(jù)，因此如果發(fā)送方發(fā)送數(shù)據(jù)過多過快，就會出現(xiàn)接收端的緩沖區(qū)被占滿的情況，若是在這種情況下，發(fā)送方仍然不停地發(fā)送數(shù)據(jù)，丟包現(xiàn)象的產(chǎn)生也就是必然的了。而流量控制就是TCP根據(jù)接收端的處理能力，來制約發(fā)送端的發(fā)送速度。
如何制約呢？
前面我們再介紹TCP協(xié)議段格式時，就包含了一個代表窗口大小的字段，這里的制約方式實際就是接收端將自己剩余的緩沖區(qū)的大小存取該字段中，再通過ACK應答報文來告知發(fā)送端，發(fā)送端就可以根據(jù)這個窗口大小來調整自己的發(fā)送效率，避免接收端緩沖區(qū)滿倉。
關于流量控制機制需要注意這樣幾個點：
窗口大小的字段越大，就說明網(wǎng)絡的吞吐量越高；
當窗口大小為0時，發(fā)送方就不會再發(fā)送數(shù)據(jù)；但在一段時間后，發(fā)送方一般會嘗試發(fā)送一個探測包，來查驗接收端此時的數(shù)據(jù)處理能力；
實際的窗口大小是窗口字段的值左移M位，M代表窗口擴大因子；
擁塞控制
如果說，前面的流量控制是站在接收方的角度控制發(fā)送速率，那么擁塞控制就是站在整個發(fā)送過程的角度來調整發(fā)送速率。
一般為了數(shù)據(jù)傳輸效率和可靠性的保證，TCP是采用慢啟動的機制的，即在網(wǎng)絡狀況未知的情況下，先發(fā)少量的數(shù)據(jù)來探路，再根據(jù)實際情況來確定實際的傳輸速率。
可以理解為整個發(fā)送過程就是這樣的：初始發(fā)送時按照較小的窗口大小來發(fā)送，如果沒有出現(xiàn)丟包的問題，就判定網(wǎng)絡環(huán)境良好，可以嘗試發(fā)大發(fā)送窗口的大小，在不斷發(fā)大的過程中，如若出現(xiàn)丟包的情況，就立即減小發(fā)送的窗口，利用這樣反復試探的操作，來尋求一個動態(tài)平衡的局面；
在TCP中，具體的操作是這樣的：
此處可以引入一個擁塞窗口的概念；假定第一次發(fā)送時，擁塞窗口的初始值為1，每次發(fā)送方收到一個ACK應答，擁塞窗口值加1，具體的發(fā)送速率就由擁塞窗口和之前流量控制中的窗口的較小值來決定；
一般TCP擁塞窗口的初始增長速度是非常快的，基本是指數(shù)級別的增長，到達一定的閥值后，就變?yōu)榫€性增長；
延遲應答
延時應答同樣是一個用來提高TCP通信效率的機制，它更像是對前面流量控制的一種緩解。顧名思義，延時應答就是接收端在接收到數(shù)據(jù)以后等待一定時間再像發(fā)送端返回應答，而在這樣一個等待的時間里，接收端的接收緩沖區(qū)仍在不停地被應用程序讀取，緩沖區(qū)的剩余容量也在不斷增加，等到真正返回ACK報文時，可以返回的窗口大小也就會更大；
但是對于延時應答，也是有一定限制的：
數(shù)量限制：每隔N個包就應答一次；因為后面的應答報文時可以涵蓋前面的數(shù)據(jù)接收情況的，即2001的應答報文表示收到了1-2000的所有數(shù)據(jù)；
時間限制：超過最大延遲時間就應答一次；這一點對于不同的操作系統(tǒng)有不同的時間限制，超過該時間限制則應答一次；
捎帶應答
捎帶應答同樣是一種提高傳輸效率的機制，是基于延時應答而實現(xiàn)的；因為正常情況下，ACK報文是接收端接收到請求之后，由內核立即返回的，而具體的響應數(shù)據(jù)則是由代碼實現(xiàn)來控制的，但是如果基于延時應答的機制，ACK報文延時發(fā)送，在時間上就可能與響應數(shù)據(jù)重合，也就達到了捎帶的目的。
TCP的通信整體而言是比較復雜的，因為它在保證可靠性的同時又在盡可能的提高性能。在其整個機制系統(tǒng)中，校驗和、序列號、確認應答、超時重傳、連接管理都是在保證其可靠性，而滑動窗口、延時應答、捎帶應答則是在提高其傳輸性能。
粘包問題
TCP是基于字節(jié)流的傳輸層通信協(xié)議。這里的基于字節(jié)流實際是指在讀取接收端緩沖區(qū)的數(shù)據(jù)時以“字節(jié)流”的方式來讀取，但是面向字節(jié)流的方式勢必會帶來一個問題，即粘包問題；
由于“流”數(shù)據(jù)是沒有明確的開始和結尾邊界的，對于同一進入到接收端緩沖區(qū)的眾多數(shù)據(jù)而言，更是難以區(qū)分這些數(shù)據(jù)來自何處，結束于何處，因此在進行數(shù)據(jù)的讀取時，就有可能會出現(xiàn)在一條消息中讀取到了另一條消息的部分數(shù)據(jù)，這就是粘包問題。
如何解決粘包問題呢？
常見的解決辦法主要有2種：
- 約定長度： 發(fā)送方和接收方固定發(fā)送數(shù)據(jù)的大小，明確邊界；
- 使用分隔符，類似于前面的自定義應用層協(xié)議；
異常情況處理
異常情況主要就是發(fā)送方與接收方以非正常四次揮手的方式斷開連接，主要有下面幾種情況：
-
主機關機
如果是按照正常程序逐步關機，會首先釋放進程，然后釋放文件描述表上對應的文件資源，然后觸發(fā)結束報文段，開啟四次揮手的流程，若流程順利結束，無影響繼續(xù)關機，若流程未完成，就重新發(fā)送FIN結束報文段，得不到回應就自行斷開，放棄~ -
程序崩潰，進程終止；
與上面流程基本一致~ -
機器掉電/網(wǎng)線斷開
極端情況下，當來不及進行四次揮手操作時，對于接收方突發(fā)異常而言，對方發(fā)送數(shù)據(jù)得不到ACK，就嘗試重傳，如此多次之后仍無法成功就放棄操作；對于發(fā)送方突發(fā)異常而言，接收方無法得知具體情況（是暫未發(fā)送數(shù)據(jù)還是發(fā)送方故障了），在長時間等待不到數(shù)據(jù)的情況下，就會通過發(fā)送心跳包的方式周期性地去判定對方是否仍然存活，如果可以得到回應，證明只是暫未發(fā)送數(shù)據(jù)，若得不到回應，表示發(fā)送方故障；文章來源：http://www.zghlxwxcb.cn/news/detail-404925.html
至此，關于網(wǎng)絡五層模型中最重要的應用層與傳輸層重點協(xié)議就介紹完畢啦，over~~文章來源地址http://www.zghlxwxcb.cn/news/detail-404925.html
到了這里，關于應用層與傳輸層~的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
