TCP/IP五層網(wǎng)絡結(jié)構(gòu)模型

• 物理層：物理層建立在物理通信介質(zhì)的基礎上，作為系統(tǒng)和通信介質(zhì)的接口，用來實現(xiàn)數(shù)據(jù)鏈路實體間透明的比特 (bit) 流傳輸。只有該層為真實物理通信，其它各層為虛擬通信
• 數(shù)據(jù)鏈路層:在物理層提供比特流服務的基礎上，建立相鄰結(jié)點之間的數(shù)據(jù)鏈路，通過差錯控制提供數(shù)據(jù)幀（Frame）在信道上無差錯的傳輸，并進行各電路上的動作系列。數(shù)據(jù)的單位稱為幀（frame）
• 網(wǎng)絡層：選擇合適的路由，使數(shù)據(jù)分組（packet）可以交付到目的主機
• 傳輸層：負責主機中進程間的通信
• 應用層：直接為用戶的應用程序提供服務

用圖說話：

傳輸層

我們知道傳輸層是在進程間傳輸報文，同時TCP協(xié)議、UDP協(xié)議是TCP/IP中最具有代表性的傳輸層協(xié)議。下面就總結(jié)一下兩個協(xié)議的異同以及傳輸層的工作原理。

TCP與UDP區(qū)分：

TCP協(xié)議：面向連接、可靠的流協(xié)議。連接是指兩個應用程序為了相互傳遞信息而專有的、虛擬的通信線路，也叫做虛擬電路。流是指不間斷的數(shù)據(jù)結(jié)構(gòu)，類似于管道中的水流?？煽啃灾窽CP協(xié)議提供可靠性傳輸，實行“順序控制”或“重發(fā)控制”機制。此外還具有“流量控制”、“擁塞控制”提供網(wǎng)絡利用率等眾多功能。

UDP協(xié)議：不具有可靠性的數(shù)據(jù)報協(xié)議。只確保發(fā)送消息，其他處理都由上層應用來完成。

哇！TCP這么多特點，是不是一定比UDP厲害呢？其實不然，他們各有自己的應用場景。

TCP應用場景：效率要求相對低，但對準確性要求相對高的場景。因為傳輸中需要對數(shù)據(jù)確認、重發(fā)、排序等操作，相比之下效率沒有UDP高。舉幾個例子：文件傳輸（準確高要求高、但是速度可以相對慢）、接受郵件、遠程登錄。

UDP應用場景：效率要求相對高，對準確性要求相對低的場景。舉幾個例子：QQ聊天、在線視頻、網(wǎng)絡語音電話（即時通訊，速度要求高，但是出現(xiàn)偶爾斷續(xù)不是太大問題，并且此處完全不可以使用重發(fā)機制）、廣播通信（廣播、多播）。

傳輸通信：

兩個協(xié)議是進程間通信，也就是說應用間的通信，那么如何在眾多程序中找到自己的目的應用呢？在傳輸層，使用端口號來識別同一臺計算機中進行通信的不同應用程序。

一般情況下可以根據(jù)“源IP地址”、“目標IP地址”、“源端口號”、“目標端口號”來進行識別一個通信，但是有些特殊情況，比如IP地址和端口號都一樣，只是使用的傳輸協(xié)議不一樣，怎么進行區(qū)分？數(shù)據(jù)到達IP層（網(wǎng)絡層）之后，會先檢查IP頭部的協(xié)議號，然后再傳給相應協(xié)議的模塊。

因此，TCP/IP或UDP/IP通信中通常使用5個信息來識別一個通信：“源IP地址”、“目標IP地址”、“源端口號”、“目標端口號”以及“協(xié)議號”。(知名端口號與傳輸層協(xié)議沒有關系，例如53端口在TCP、UDP中都用于DNS服務)

端口號如何確定：標準既定的端口號，0-1023為知名端口號，其他已正式注冊的端口號是1024-49151；動態(tài)分配端口號，操作系統(tǒng)來為應用程序分配互不沖突的端口號，下一個端口號是在前一個分配號上加1，動態(tài)分配端口號范圍49152-65535.

UDP詳解

UDP是User Datagram Protocol縮寫。UDP不提供復雜的控制機制，利用IP提供面向無連接的通信服務。并且它是將應用程序發(fā)來的數(shù)據(jù)在收到的那一刻，立即按照原樣發(fā)送到網(wǎng)絡上的一種機制。

UDP為何存在？有哪些優(yōu)點呢？

• 無需建立連接（減少延遲）
• 實現(xiàn)簡單：無需維護連接狀態(tài)
• 頭部開銷小
• 沒有擁塞控制：應用可以更好的控制發(fā)送時間和發(fā)送速率

UDP頭部：

UDP的頭部是由源端口號、目標端口號、包長和校驗和組成。checksum主要是用來檢測UDP段在傳輸中是否發(fā)生了錯誤。還有就是，校驗和計算中也需要計算UDP偽頭部，偽頭部包含IP頭部的一些字段。我們剛才介紹了識別一個通信需要5項信息，而UDP頭部只有端口號，余下的三項在IP頭部，所以引入了偽頭部的概念。（IPv6的IP頭部沒有校驗和字段）

目前有一些場景需要兼顧可靠性和高效性，那么如何在UDP上實現(xiàn)可靠數(shù)據(jù)傳輸呢？

TCP詳解

TCP通過校驗和、序列號、確認應答、重發(fā)控制、連接管理以及窗口控制等機制實現(xiàn)可靠性傳輸。

連接管理：

數(shù)據(jù)通信之前必須先做好連接工作，在TCP中連接的建立需要三次握手，同時在通信結(jié)束時會進行斷開連接的處理（四次揮手）。一個連接的建立與斷開，正常過程至少需要來回送7個包才能完成。

在TCP中，當發(fā)送端的數(shù)據(jù)到達主機時，接收端主機會返回一個已收到消息的通知，這個消息叫ACK（確認應答，Positive Acknowledgement）。如果沒有收到ACK，那么很可能出現(xiàn)了丟包或者返回的確認在途中丟失，此外，也可能是由于其他原因，ACK延遲到達。發(fā)送方?jīng)]有收到ACK的話就會進行重發(fā)，但是針對延遲和ACK丟失的情況，會存在重復發(fā)送和接收。于是我們就引入了一種機制，來識別是否已經(jīng)接收數(shù)據(jù)，又能識別是否已經(jīng)接收。

上述重復控制的功能可以通過序列號來實現(xiàn)。序列號是按照順序給發(fā)送數(shù)據(jù)的每一個字節(jié)都標上號碼的編號，接收端查詢接收數(shù)據(jù)TCP首部中的序列號和數(shù)據(jù)的長度，將自己下一步應該接收的 序號作為確認應答號返送回去。通過序列號和確認應答號，TCP實現(xiàn)可靠傳輸。

利用窗口控制提高速度

如果我們每發(fā)送一個段就進行一次確認，那么包的往返時間越長，網(wǎng)絡的吞吐量量就會越差，通信性能就會越低。

為了解決這個問題，TCP引入了窗口的概念。確認應答不再是以每個片段，而是以更大的單位（窗口大?。┻M行確認，轉(zhuǎn)發(fā)時間就被大幅度的縮短。至于窗口的大小是由接收端主機決定的，也方便進行流控制。

窗口控制與重發(fā)控制

允許發(fā)送方在收到ACK之前連續(xù)發(fā)送多個分組，針對段丟失的情況，我們來討論窗口控制。

針對以前的延遲ACK，使用窗口控制之后，可以收到確認應答之前繼續(xù)發(fā)送報文，這樣整體速度就大大提高。

針對確認應答未能返回的情況。沒有使用窗口控制的時候，沒有收到確認應答的數(shù)據(jù)都會被重發(fā)，而使用了窗口控制，某些確認應答即便丟失也無需重發(fā)。可以根據(jù)自己的確認應答或者下一個確認應答來確認。

針對報文段丟失的情況。當一個報文丟失時，發(fā)送端會連續(xù)收到多個序號為1001的確認應答，來提醒發(fā)送端再次發(fā)送報文。對于發(fā)送端，如果連續(xù)三次收到同一個確認應答，將會對其對應的數(shù)據(jù)進行重發(fā)。