TCP/IP五層網絡結構模型

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

用圖說話：

傳輸層

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

TCP與UDP區分：

TCP協議：面向連接、可靠的流協議。連接是指兩個應用程序為了相互傳遞信息而專有的、虛擬的通信線路，也叫做虛擬電路。流是指不間斷的數據結構，類似于管道中的水流。可靠性指TCP協議提供可靠性傳輸，實行“順序控制”或“重發控制”機制。此外還具有“流量控制”、“擁塞控制”提供網絡利用率等眾多功能。

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

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

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

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

傳輸通信：

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

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

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

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

UDP詳解

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

UDP為何存在？有哪些優點呢？

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

UDP頭部：

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

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

TCP詳解

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

連接管理：

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

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

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

利用窗口控制提高速度

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

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

窗口控制與重發控制

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

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

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

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