TCP/IP五層網(wǎng)絡(luò)結(jié)構(gòu)模型
用圖說話:![]() 五層網(wǎng)絡(luò)模型
傳輸層我們知道傳輸層是在進程間傳輸報文,同時TCP協(xié)議、UDP協(xié)議是TCP/IP中最具有代表性的傳輸層協(xié)議。下面就總結(jié)一下兩個協(xié)議的異同以及傳輸層的工作原理。 TCP與UDP區(qū)分:TCP協(xié)議:面向連接、可靠的流協(xié)議。連接是指兩個應(yīng)用程序為了相互傳遞信息而專有的、虛擬的通信線路,也叫做虛擬電路。流是指不間斷的數(shù)據(jù)結(jié)構(gòu),類似于管道中的水流??煽啃灾窽CP協(xié)議提供可靠性傳輸,實行“順序控制”或“重發(fā)控制”機制。此外還具有“流量控制”、“擁塞控制”提供網(wǎng)絡(luò)利用率等眾多功能。 UDP協(xié)議:不具有可靠性的數(shù)據(jù)報協(xié)議。只確保發(fā)送消息,其他處理都由上層應(yīng)用來完成。 哇!TCP這么多特點,是不是一定比UDP厲害呢?其實不然,他們各有自己的應(yīng)用場景。 TCP應(yīng)用場景:效率要求相對低,但對準確性要求相對高的場景。因為傳輸中需要對數(shù)據(jù)確認、重發(fā)、排序等操作,相比之下效率沒有UDP高。舉幾個例子:文件傳輸(準確高要求高、但是速度可以相對慢)、接受郵件、遠程登錄。 UDP應(yīng)用場景:效率要求相對高,對準確性要求相對低的場景。舉幾個例子:QQ聊天、在線視頻、網(wǎng)絡(luò)語音電話(即時通訊,速度要求高,但是出現(xiàn)偶爾斷續(xù)不是太大問題,并且此處完全不可以使用重發(fā)機制)、廣播通信(廣播、多播)。 傳輸通信:兩個協(xié)議是進程間通信,也就是說應(yīng)用間的通信,那么如何在眾多程序中找到自己的目的應(yīng)用呢?在傳輸層,使用端口號來識別同一臺計算機中進行通信的不同應(yīng)用程序。 一般情況下可以根據(jù)“源IP地址”、“目標(biāo)IP地址”、“源端口號”、“目標(biāo)端口號”來進行識別一個通信,但是有些特殊情況,比如IP地址和端口號都一樣,只是使用的傳輸協(xié)議不一樣,怎么進行區(qū)分?數(shù)據(jù)到達IP層(網(wǎng)絡(luò)層)之后,會先檢查IP頭部的協(xié)議號,然后再傳給相應(yīng)協(xié)議的模塊。 因此,TCP/IP或UDP/IP通信中通常使用5個信息來識別一個通信:“源IP地址”、“目標(biāo)IP地址”、“源端口號”、“目標(biāo)端口號”以及“協(xié)議號”。(知名端口號與傳輸層協(xié)議沒有關(guān)系,例如53端口在TCP、UDP中都用于DNS服務(wù)) 端口號如何確定:標(biāo)準既定的端口號,0-1023為知名端口號,其他已正式注冊的端口號是1024-49151;動態(tài)分配端口號,操作系統(tǒng)來為應(yīng)用程序分配互不沖突的端口號,下一個端口號是在前一個分配號上加1,動態(tài)分配端口號范圍49152-65535. UDP詳解UDP是 UDP為何存在?有哪些優(yōu)點呢?
UDP頭部:![]() UDP頭部
UDP的頭部是由源端口號、目標(biāo)端口號、包長和校驗和組成。 ![]() UDP偽頭部
目前有一些場景需要兼顧可靠性和高效性,那么如何在UDP上實現(xiàn)可靠數(shù)據(jù)傳輸呢? TCP詳解TCP通過校驗和、序列號、確認應(yīng)答、重發(fā)控制、連接管理以及窗口控制等機制實現(xiàn)可靠性傳輸。 連接管理:數(shù)據(jù)通信之前必須先做好連接工作,在TCP中連接的建立需要三次握手,同時在通信結(jié)束時會進行斷開連接的處理(四次揮手)。一個連接的建立與斷開,正常過程至少需要來回送7個包才能完成。 ![]() 連接的建立和斷開
在TCP中,當(dāng)發(fā)送端的數(shù)據(jù)到達主機時,接收端主機會返回一個已收到消息的通知,這個消息叫ACK(確認應(yīng)答, 上述重復(fù)控制的功能可以通過序列號來實現(xiàn)。序列號是按照順序給發(fā)送數(shù)據(jù)的每一個字節(jié)都標(biāo)上號碼的編號,接收端查詢接收數(shù)據(jù)TCP首部中的序列號和數(shù)據(jù)的長度,將自己下一步應(yīng)該接收的 序號作為確認應(yīng)答號返送回去。通過序列號和確認應(yīng)答號,TCP實現(xiàn)可靠傳輸。 ![]() 序列號與確認應(yīng)答號
利用窗口控制提高速度如果我們每發(fā)送一個段就進行一次確認,那么包的往返時間越長,網(wǎng)絡(luò)的吞吐量量就會越差,通信性能就會越低。 為了解決這個問題,TCP引入了窗口的概念。確認應(yīng)答不再是以每個片段,而是以更大的單位(窗口大?。┻M行確認,轉(zhuǎn)發(fā)時間就被大幅度的縮短。至于窗口的大小是由接收端主機決定的,也方便進行流控制。 窗口控制與重發(fā)控制允許發(fā)送方在收到ACK之前連續(xù)發(fā)送多個分組,針對段丟失的情況,我們來討論窗口控制。 針對以前的延遲ACK,使用窗口控制之后,可以收到確認應(yīng)答之前繼續(xù)發(fā)送報文,這樣整體速度就大大提高。 針對確認應(yīng)答未能返回的情況。沒有使用窗口控制的時候,沒有收到確認應(yīng)答的數(shù)據(jù)都會被重發(fā),而使用了窗口控制,某些確認應(yīng)答即便丟失也無需重發(fā)。可以根據(jù)自己的確認應(yīng)答或者下一個確認應(yīng)答來確認。 ![]() 窗口控制
針對報文段丟失的情況。當(dāng)一個報文丟失時,發(fā)送端會連續(xù)收到多個序號為1001的確認應(yīng)答,來提醒發(fā)送端再次發(fā)送報文。對于發(fā)送端,如果連續(xù)三次收到同一個確認應(yīng)答,將會對其對應(yīng)的數(shù)據(jù)進行重發(fā)。 ![]() 報文丟失的情況
更多TCP/UDP協(xié)議知識:計算機網(wǎng)絡(luò)中的TCP/UDP協(xié)議到底是怎么回事(二) |
|
|
來自: 愛IT愛科技 > 《學(xué)習(xí)》