TCP/IP協議

原文鏈接:https://baike.baidu.com/item/TCP/IP%E5%8D%8F%E8%AE%AE#reference-[4]-7649-wrap

TCP/IP協議在一定程度上參考了OSI的體系結構。

OSI模型共有七層,從下到上分別是物理層、數據鏈路層、網絡層、運輸層、會話層、表示層和應用層。但是這顯然是有些複雜的,所以在TCP/IP協議中,它們被簡化爲了四個層次

鏈路層

以太網協議規定,接入網絡的設備都必須安裝網絡適配器,即網卡,數據包必須是從一塊網卡傳送到另一塊網卡。而網卡地址就是數據包的發送地址和接收地址,有了MAC地址以後,以太網採用廣播形式,把數據包發給該子網內所有主機,子網內每臺主機在接收到這個包以後,都會讀取首部裏的目標MAC地址,然後和自己的MAC地址進行對比,如果相同就做下一步處理,如果不同,就丟棄這個包。 

所以鏈路層的主要工作就是對電信號進行分組並形成具有特定意義的數據幀,然後以廣播的形式通過物理介質發送給接收方。 

網絡層

IP協議

網絡層引入了IP協議,制定了一套新地址,使得我們能夠區分兩臺主機是否同屬一個網絡,這套地址就是網絡地址,也就是所謂的IP地址。IP協議將這個32位的地址分爲兩部分,前面部分代表網絡地址,後面部分表示該主機在局域網中的地址。如果兩個IP地址在同一個子網內,則網絡地址一定相同。爲了判斷IP地址中的網絡地址,IP協議還引入了子網掩碼,IP地址和子網掩碼通過按位與運算後就可以得到網絡地址。 

ARP協議

即地址解析協議,是根據IP地址獲取MAC地址的一個網絡層協議。其工作原理如下:ARP首先會發起一個請求數據包,數據包的首部包含了目標主機的IP地址,然後這個數據包會在鏈路層進行再次包裝,生成以太網數據包,最終由以太網廣播給子網內的所有主機,每一臺主機都會接收到這個數據包,並取出標頭裏的IP地址,然後和自己的IP地址進行比較,如果相同就返回自己的MAC地址,如果不同就丟棄該數據包。ARP接收返回消息,以此確定目標機的MAC地址;與此同時,ARP還會將返回的MAC地址與對應的IP地址存入本機ARP緩存中並保留一定時間,下次請求時直接查詢ARP緩存以節約資源。 

路由協議

首先通過IP協議來判斷兩臺主機是否在同一個子網中,如果在同一個子網,就通過ARP協議查詢對應的MAC地址,然後以廣播的形式向該子網內的主機發送數據包;如果不在同一個子網,以太網會將該數據包轉發給本子網的網關進行路由。網關互聯網上子網與子網之間的橋樑,所以網關會進行多次轉發,最終將該數據包轉發到目標IP所在的子網中,然後再通過ARP獲取目標機MAC,最終也是通過廣播形式將數據包發送給接收方。而完成這個路由協議的物理設備就是路由器,路由器扮演着交通樞紐的角色,它會根據信道情況,選擇並設定路由,以最佳路徑來轉發數據包。 

所以,網絡層的主要工作是定義網絡地址、區分網段、子網內MAC尋址、對於不同子網的數據包進行路由。 

傳輸層

鏈路層定義了主機的身份,即MAC地址,而網絡層定義了IP地址,明確了主機所在的網段,有了這兩個地址,數據包就從可以從一個主機發送到另一臺主機。但實際上數據包是從一個主機的某個應用程序發出,然後由對方主機的應用程序接收。而每臺電腦都有可能同時運行着很多個應用程序,所以當數據包被髮送到主機上以後,是無法確定哪個應用程序要接收這個包。因此傳輸層引入了UDP協議來解決這個問題,爲了給每個應用程序標識身份

UDP協議

UDP協議定義了端口,同一個主機上的每個應用程序都需要指定唯一的端口號,並且規定網絡中傳輸的數據包必須加上端口信息,當數據包到達主機以後,就可以根據端口號找到對應的應用程序了。UDP協議比較簡單,實現容易,但它沒有確認機制,數據包一旦發出,無法知道對方是否收到,因此可靠性較差,爲了解決這個問題,提高網絡可靠性,TCP協議就誕生了。

TCP協議

TCP即傳輸控制協議,是一種面向連接的、可靠的、基於字節流的通信協議。簡單來說TCP就是有確認機制的UDP協議,每發出一個數據包都要求確認,如果有一個數據包丟失,就收不到確認,發送方就必須重發這個數據包。爲了保證傳輸的可靠性,TCP協議在UDP基礎之上建立了三次對話的確認機制,即在正式收發數據前,必須和對方建立可靠的連接。TCP數據包和UDP一樣,都是由首部和數據兩部分組成,唯一不同的是,TCP數據包沒有長度限制,理論上可以無限長,但是爲了保證網絡的效率,通常TCP數據包的長度不會超過IP數據包的長度,以確保單個TCP數據包不必再分割。 

傳輸層的主要工作是定義端口,標識應用程序身份,實現端口到端口的通信,TCP協議可以保證數據傳輸的可靠性。 

應用層

理論上講,有了以上三層協議的支持,數據已經可以從一個主機上的應用程序傳輸到另一臺主機的應用程序了,但此時傳過來的數據是字節流,不能很好的被程序識別,操作性差,因此,應用層定義了各種各樣的協議來規範數據格式,常見的有http,ftp,smtp等,在請求Header中,分別定義了請求數據格式Accept和響應數據格式Content-Type,有了這個規範以後,當對方接收到請求以後就知道該用什麼格式來解析,然後對請求進行處理,最後按照請求方要求的格式將數據返回,請求端接收到響應後,就按照規定的格式進行解讀。 

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章