---

前言

本期內容重點復習一下以下三層：網(wǎng)絡層，運輸層，應用層
參考教材：計算機網(wǎng)絡（博客中部分圖片來自本書）
參考：chatgpt4

一、計算機網(wǎng)絡層次結構

計算機網(wǎng)絡的層次結構通常根據(jù)OSI（開放系統(tǒng)互聯(lián)）模型或TCP/IP模型來進行劃分。

OSI（開放系統(tǒng)互聯(lián)）模型：該模型將計算機網(wǎng)絡分為七層，自下而上依次是：

物理層：負責傳輸比特流（即電壓的高低、光的閃爍等）。

數(shù)據(jù)鏈路層：負責在網(wǎng)絡設備之間傳輸數(shù)據(jù)幀（也就是數(shù)據(jù)包），并能夠檢測和糾正數(shù)據(jù)傳輸?shù)腻e誤。

網(wǎng)絡層：負責處理數(shù)據(jù)包的發(fā)送和接收，包括包的路由選擇。

傳輸層：負責處理端到端的數(shù)據(jù)傳輸。

會話層：負責在數(shù)據(jù)傳輸中設置和維護網(wǎng)絡連接。

表示層：負責處理操作系統(tǒng)中數(shù)據(jù)的表示、安全和壓縮問題。

應用層：負責處理特定應用程序的協(xié)議。

TCP/IP模型：該模型將計算機網(wǎng)絡分為四層，自下而上依次是：

網(wǎng)絡接口層：相當于OSI模型中的物理層和數(shù)據(jù)鏈路層，負責處理和網(wǎng)絡媒體的硬件接口相關的所有事務。

網(wǎng)絡層：相當于OSI模型中的網(wǎng)絡層，負責處理IP地址和路由。

傳輸層：相當于OSI模型中的傳輸層，負責處理TCP和UDP協(xié)議。

應用層：相當于OSI模型中的會話層、表示層和應用層，負責處理所有特定的應用程序細節(jié)。

實際應用中，我們經(jīng)常使用一個簡化的五層網(wǎng)絡模型，這個模型把OSI的七層模型進行了合并簡化。五層模型自下而上依次是：

物理層：負責將比特流（即電壓的高低、光的閃爍等）在物理媒介（如電纜、光纖）上進行傳輸。

數(shù)據(jù)鏈路層：負責在網(wǎng)絡設備之間傳輸數(shù)據(jù)幀（也就是數(shù)據(jù)包），并能夠檢測和糾正數(shù)據(jù)傳輸?shù)腻e誤。

網(wǎng)絡層：負責處理數(shù)據(jù)包的發(fā)送和接收，包括包的路由選擇。

傳輸層：負責處理端到端的數(shù)據(jù)傳輸，例如TCP協(xié)議和UDP協(xié)議都工作在這一層。

應用層：這一層包含了OSI模型中的會話層、表示層和應用層，負責處理所有特定的應用程序細節(jié)。例如HTTP、FTP等協(xié)議都工作在這一層。

二、網(wǎng)絡層

三、運輸層

3.1、TCP/IP協(xié)議介紹

TCP（Transmission Control Protocol，傳輸控制協(xié)議）和UDP（User Datagram Protocol，用戶數(shù)據(jù)報協(xié)議）都是網(wǎng)絡傳輸層的兩種重要協(xié)議，它們都是用來發(fā)送數(shù)據(jù)包的，但是各自的特性和使用場景有很大的不同。

TCP（傳輸控制協(xié)議）:

TCP是一種面向連接的協(xié)議，這意味著在數(shù)據(jù)傳輸前，發(fā)送方和接收方需要先建立連接，然后才能進行數(shù)據(jù)的發(fā)送和接收。這種方式可以確保數(shù)據(jù)的完整性和準確性。

TCP提供了數(shù)據(jù)包的順序控制、流量控制、擁塞控制和錯誤檢查等功能。這些控制機制確保了數(shù)據(jù)包能夠正確、有序地到達目的地。

TCP的這些特性使它非常適合于對數(shù)據(jù)傳輸質量要求高的應用，例如網(wǎng)頁瀏覽、文件傳輸、電子郵件等。

UDP（用戶數(shù)據(jù)報協(xié)議）:

UDP是一種無連接的協(xié)議，這意味著發(fā)送方發(fā)送數(shù)據(jù)時，不需要先建立連接。這種方式雖然不能保證數(shù)據(jù)包的到達和順序，但是由于省去了建立連接的過程，使得數(shù)據(jù)傳輸?shù)难舆t更低。

UDP不提供數(shù)據(jù)包的順序控制、流量控制、擁塞控制和錯誤檢查等功能。這些特性使得UDP非常適合于實時性要求高，但對數(shù)據(jù)丟失可以容忍的應用，例如語音和視頻通話、實時游戲等。

UDP的另一個特性是它支持廣播和多播，這使得UDP非常適合于多點通信。

總的來說，TCP和UDP各有優(yōu)劣，具體使用哪種協(xié)議取決于應用的具體需求。

3.2、端口（協(xié)議端口號）

在網(wǎng)絡通信中，端口是一種抽象的軟件結構，用來區(qū)分不同的進程或服務。端口是與IP地址配合使用的，一起構成了網(wǎng)絡通信中的"地址和端口"的概念。在TCP/IP協(xié)議中，端口被標識為一個16位的數(shù)字，范圍從0到65535。
通常，端口可以分為三個范圍：

已知端口（Well Known Ports）：這些是最常用的端口，范圍是0-1023。許多常見的協(xié)議都在這個范圍內，例如HTTP的端口80，HTTPS的端口443，FTP的端口21，SMTP的端口25等。

注冊端口（Registered Ports）：這些端口的范圍是1024-49151。它們不是預留給特定服務的，但通常用于某些已知的應用。例如，MySQL默認的端口就是3306。

動態(tài)或私有端口（Dynamic or Private Ports）：這些端口的范圍是49152-65535。它們通常被用于動態(tài)端口分配，當一個客戶端應用程序需要與服務器建立連接時，操作系統(tǒng)通常會從這個范圍內選擇一個可用的端口號。

當我們說一個服務器在監(jiān)聽某個端口，實際上就是說服務器上的某個服務正在等待從那個端口號上到來的連接請求。同樣，當一個客戶端程序連接到服務器的某個端口時，實際上是在請求使用服務器上綁定到那個端口的服務。
使用不同的端口號，我們可以在同一臺計算機上運行多個網(wǎng)絡服務，每個服務可以獨立地接收和處理連接請求。這就是端口的主要作用。

另外，你也需要確保你的程序在運行時具有足夠的權限來監(jiān)聽你選擇的端口。在許多操作系統(tǒng)中，監(jiān)聽1024以下的端口需要管理員或root權限，但1024以上的端口通?？梢杂扇魏斡脩舯O(jiān)聽。

3.3、套接字

套接字（Socket）是計算機網(wǎng)絡中用于描述IP地址和端口，以便能夠進行網(wǎng)絡通信的一種抽象概念。它是網(wǎng)絡應用程序進行數(shù)據(jù)發(fā)送和接收的接口。簡單來說，套接字就像是一個電話插孔，你可以通過它來接通電話線（網(wǎng)絡連接），并進行通話（數(shù)據(jù)傳輸）。
套接字最初由伯克利（Berkeley）UNIX操作系統(tǒng)開發(fā)并引入，現(xiàn)在已經(jīng)被所有主流的操作系統(tǒng)所采用。在編程中，我們通常通過套接字API（應用程序接口）來進行網(wǎng)絡編程。套接字API提供了一組函數(shù)，使得程序員能夠在他們的程序中創(chuàng)建套接字、連接到遠程套接字、發(fā)送和接收數(shù)據(jù)等。
套接字可以支持不同的通信協(xié)議，最常見的有TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報協(xié)議）。TCP套接字提供了一種面向連接的、可靠的數(shù)據(jù)傳輸服務，而UDP套接字則提供了一種無連接的、不可靠的數(shù)據(jù)傳輸服務。
一個套接字被定義為一個IP地址和一個端口號的組合 例如，如果你的計算機的IP地址是192.168.1.100，你的Web服務器程序正在監(jiān)聽端口80，那么你可以說你的Web服務器的套接字是192.168.1.100:80。當一個客戶端程序想要連接到你的服務器時，它需要知道這個套接字，以便能夠正確地向你的服務器發(fā)送請求。

3.4、TCP實現(xiàn)原理

3.4.1、TCP的特點

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。以下是TCP的一些主要特點和工作原理：

面向連接 在數(shù)據(jù)傳輸開始之前，TCP需要在發(fā)送端和接收端之間建立一個連接。這個過程通常被稱為"三次握手"。一旦連接建立，所有的數(shù)據(jù)傳輸都在這個連接上進行，直到連接被關閉。

可靠傳輸 TCP通過使用確認（ACK）機制、序列號、重傳機制和錯誤檢查來確保數(shù)據(jù)的可靠傳輸。如果發(fā)送端沒有收到數(shù)據(jù)包的確認，那么它會重新發(fā)送數(shù)據(jù)包。

流量控制 TCP使用窗口機制來進行流量控制，防止接收端被發(fā)送端發(fā)送的數(shù)據(jù)淹沒。窗口的大小表明了接收端當前能接受的數(shù)據(jù)量。

擁塞控制 當網(wǎng)絡出現(xiàn)擁塞時，TCP會減少數(shù)據(jù)的發(fā)送速率，避免無效的重傳和網(wǎng)絡資源的浪費。當網(wǎng)絡恢復正常時，TCP會逐漸增加數(shù)據(jù)的發(fā)送速率。

全雙工通信 TCP連接的兩端都能發(fā)送和接收數(shù)據(jù)。這意味著在一個TCP連接中，數(shù)據(jù)可以在兩個方向上同時傳輸。

字節(jié)流 TCP不關心應用層的消息邊界，把應用層傳下來的數(shù)據(jù)看作僅僅是一個連續(xù)的字節(jié)流。

這些特點使得TCP非常適合那些需要高可靠性的應用，例如Web瀏覽、電子郵件、文件傳輸?shù)?。然?#xff0c;這些特性也使得TCP比一些其他的傳輸協(xié)議（如UDP）更復雜，有時候也更慢。

---

3.4.2、停止等待協(xié)議

停止等待協(xié)議是一種基本的流量控制協(xié)議，它也是TCP中可靠數(shù)據(jù)傳輸?shù)幕A。在停止等待協(xié)議中，發(fā)送端每次只發(fā)送一個數(shù)據(jù)包，然后停止發(fā)送并等待接收端的確認。在收到確認后，發(fā)送端再發(fā)送下一個數(shù)據(jù)包。
以下是停止等待協(xié)議的基本步驟：

發(fā)送端發(fā)送一個數(shù)據(jù)包到接收端。

發(fā)送端啟動一個定時器，等待接收端的確認。這個定時器的時間通常比數(shù)據(jù)包在網(wǎng)絡中傳輸?shù)钠骄鶗r間要長一些，以便給接收端處理數(shù)據(jù)包和發(fā)送確認的時間。

如果在定時器超時之前，發(fā)送端收到了接收端的確認，那么它會發(fā)送下一個數(shù)據(jù)包。

如果定時器超時，但發(fā)送端還沒有收到確認，那么發(fā)送端會認為數(shù)據(jù)包已經(jīng)丟失，然后重新發(fā)送這個數(shù)據(jù)包。

停止等待協(xié)議的優(yōu)點是它簡單易懂，實現(xiàn)也相對簡單。它能夠確保數(shù)據(jù)包不會因為網(wǎng)絡的問題而丟失，并且能夠防止發(fā)送端發(fā)送數(shù)據(jù)的速度過快，導致接收端無法處理。
然而，停止等待協(xié)議的效率不高，特別是在網(wǎng)絡延遲大的情況下。發(fā)送端每次只發(fā)送一個數(shù)據(jù)包，然后就停下來等待確認，這意味著網(wǎng)絡的利用率很低，尤其是當網(wǎng)絡的帶寬很大，而數(shù)據(jù)包的大小相對較小的時候。為了解決這個問題，人們開發(fā)了一些更高效的流量控制協(xié)議，例如滑動窗口協(xié)議。

3.4.3、滑動窗口協(xié)議

滑動窗口協(xié)議是一種流量控制協(xié)議，它可以提高網(wǎng)絡的利用率，并且還能保證數(shù)據(jù)的可靠傳輸。這種協(xié)議在TCP（傳輸控制協(xié)議）中被廣泛使用。
滑動窗口協(xié)議的基本思想是，發(fā)送端和接收端各自維護一個窗口。發(fā)送窗口包含了可以發(fā)送的數(shù)據(jù)段，接收窗口包含了可以接收的數(shù)據(jù)段。窗口的大小可以動態(tài)調整，以適應網(wǎng)絡的條件。
以下是滑動窗口協(xié)議的基本步驟：

在開始時，發(fā)送端的窗口包含了一些數(shù)據(jù)段，這些數(shù)據(jù)段可以立即發(fā)送。發(fā)送端發(fā)送窗口中的數(shù)據(jù)段后，將這些數(shù)據(jù)段標記為已發(fā)送但未確認。

當接收端收到一個數(shù)據(jù)段，它會發(fā)送一個確認回去。確認中包含了接收端期望接收的下一個數(shù)據(jù)段的序列號，以及接收窗口的剩余大小。

當發(fā)送端收到一個確認，它會更新它的窗口。已被確認的數(shù)據(jù)段會從窗口中移除，窗口會向前滑動，以包含新的可以發(fā)送的數(shù)據(jù)段。窗口的大小可能會根據(jù)接收端的反饋（即接收窗口的剩余大小）進行調整。

如果一個數(shù)據(jù)段的確認在一定時間內沒有收到，那么發(fā)送端會重新發(fā)送這個數(shù)據(jù)段。這是通過超時重傳機制來實現(xiàn)的。

滑動窗口協(xié)議不僅可以保證數(shù)據(jù)的可靠傳輸（通過確認和重傳機制），而且還可以有效地控制數(shù)據(jù)的發(fā)送速度（通過窗口大小的調整），以防止發(fā)送端發(fā)送數(shù)據(jù)過快，導致接收端無法處理。這使得滑動窗口協(xié)議在各種網(wǎng)絡條件下都能提供高效的數(shù)據(jù)傳輸。

---

流量控制是計算機網(wǎng)絡中的一個關鍵概念，它指的是一種技術或一組機制，用于防止發(fā)送端發(fā)送數(shù)據(jù)的速度超過接收端處理數(shù)據(jù)的能力。
如果沒有流量控制，發(fā)送端可能會以接收端無法處理的速度發(fā)送數(shù)據(jù)，這將導致接收端的緩沖區(qū)溢出，進而丟失數(shù)據(jù)。因此，流量控制是網(wǎng)絡通信中保證數(shù)據(jù)可靠傳輸?shù)闹匾侄沃弧?br /> 流量控制可以在不同的網(wǎng)絡層次實現(xiàn)，例如在數(shù)據(jù)鏈路層（如X.25協(xié)議）或者傳輸層（如TCP協(xié)議）。
在TCP中，流量控制是通過滑動窗口協(xié)議來實現(xiàn)的。每個TCP連接都有一個關聯(lián)的接收窗口，該窗口的大小表示接收端當前還能接收多少數(shù)據(jù)。當接收端處理完一部分數(shù)據(jù)并釋放了緩沖區(qū)空間后，它會通過確認信息告訴發(fā)送端，從而增大發(fā)送端的發(fā)送窗口。通過動態(tài)調整窗口大小，TCP可以根據(jù)接收端的處理能力和網(wǎng)絡的擁塞程度來控制數(shù)據(jù)的發(fā)送速度。
總的來說，流量控制是一個非常重要的網(wǎng)絡功能，它可以保護網(wǎng)絡資源，防止網(wǎng)絡擁塞，以及保證數(shù)據(jù)的可靠傳輸。

3.4.4、擁塞控制

擁塞控制是TCP（傳輸控制協(xié)議）的一種機制，用于防止網(wǎng)絡擁塞。當網(wǎng)絡中的數(shù)據(jù)包數(shù)量過多，超過網(wǎng)絡的承載能力時，就會出現(xiàn)網(wǎng)絡擁塞。網(wǎng)絡擁塞可能導致數(shù)據(jù)包的延遲增加，甚至丟失。因此，擁塞控制的目標是避免過多的數(shù)據(jù)進入網(wǎng)絡，以保持網(wǎng)絡的質量。
TCP的擁塞控制主要有四種算法：慢啟動、擁塞避免、快重傳和快恢復。這些算法共同工作，以動態(tài)地調整每個TCP連接的擁塞窗口大小。擁塞窗口決定了發(fā)送端可以在沒有收到確認的情況下發(fā)送多少數(shù)據(jù)。
以下是這四種算法的基本工作原理：

慢啟動：當一個TCP連接開始時，擁塞窗口的大小被設置為一個很小的值。然后，每當發(fā)送端接收到一個確認，它就會將擁塞窗口大小加倍。這樣，擁塞窗口的大小就會以指數(shù)方式增長，直到達到一個閾值，或者發(fā)生了數(shù)據(jù)包丟失。

擁塞避免：當擁塞窗口達到閾值后，發(fā)送端就會進入擁塞避免階段。在這個階段，每當接收到一個確認，擁塞窗口的大小就會線性地增加。這樣，擁塞窗口的增長速度就會減慢，以避免過快地增加網(wǎng)絡的負載。

快重傳：當發(fā)送端連續(xù)收到三個重復的確認（這通常表示有一個數(shù)據(jù)包丟失）時，它不會等待超時重傳定時器，而是立即重新發(fā)送丟失的數(shù)據(jù)包。這樣，就可以更快地恢復丟失的數(shù)據(jù)包。

快恢復：當發(fā)送端重新發(fā)送了丟失的數(shù)據(jù)包后，它會將閾值減半，然后立即進入擁塞避免階段，而不是慢啟動階段。這樣，就可以更快地恢復傳輸速度。

這四種算法共同工作，以適應網(wǎng)絡的條件，保持高效的數(shù)據(jù)傳輸，同時避免網(wǎng)絡擁塞。

3.4.5、TCP連接的三個階段

一個TCP（傳輸控制協(xié)議）連接的生命周期主要包括以下幾個階段：

連接建立（Connection Establishment）：這個階段通常被稱為“三次握手”（Three-Way Handshake）。首先，客戶端發(fā)送一個帶有SYN（Synchronize）標志的數(shù)據(jù)包給服務器，請求建立連接。然后，服務器回應一個帶有SYN和ACK（Acknowledgement）標志的數(shù)據(jù)包，確認收到請求并同意建立連接。最后，客戶端再發(fā)送一個帶有ACK標志的數(shù)據(jù)包，確認收到服務器的回應。此時，TCP連接就被成功建立，可以開始傳輸數(shù)據(jù)。

數(shù)據(jù)傳輸（Data Transfer）：在這個階段，客戶端和服務器可以互相發(fā)送數(shù)據(jù)。TCP保證了數(shù)據(jù)的可靠傳輸，通過序列號和確認機制保證數(shù)據(jù)按照正確的順序到達，并通過流量控制和擁塞控制機制來適應網(wǎng)絡的條件。

連接終止（Connection Termination）：這個階段通常被稱為“四次揮手”（Four-Way Handshake）。首先，一方（通常是客戶端）發(fā)送一個帶有FIN（Finish）標志的數(shù)據(jù)包，請求關閉連接。然后，另一方（通常是服務器）回應一個帶有ACK標志的數(shù)據(jù)包，確認收到請求。然后，另一方也發(fā)送一個帶有FIN標志的數(shù)據(jù)包，請求關閉連接。最后，第一方再回應一個帶有ACK標志的數(shù)據(jù)包，確認收到請求。此時，TCP連接就被成功關閉。

在這些階段中，TCP通過復雜的算法和機制，保證了數(shù)據(jù)的可靠傳輸，使得應用程序可以像使用可靠的字節(jié)流一樣使用網(wǎng)絡。

3.5、UDP實現(xiàn)原理

UDP（用戶數(shù)據(jù)報協(xié)議，User Datagram Protocol）是一個簡單的無連接的傳輸層協(xié)議。與TCP相比，UDP更簡單，開銷更小，但是它不提供數(shù)據(jù)的可靠傳輸，也不提供流量控制或擁塞控制。因此，UDP通常用于那些對實時性要求高，但對數(shù)據(jù)丟失容忍度較高的應用，例如VoIP（語音通話）和在線游戲。
以下是UDP的基本實現(xiàn)原理：

封裝數(shù)據(jù)：UDP將應用程序發(fā)送的數(shù)據(jù)封裝在UDP數(shù)據(jù)報中。每個UDP數(shù)據(jù)報包括一個頭部和一個數(shù)據(jù)部分。頭部包含了源端口號、目標端口號、長度和校驗和，這些信息用于數(shù)據(jù)的傳輸和接收。數(shù)據(jù)部分就是應用程序發(fā)送的數(shù)據(jù)。

發(fā)送數(shù)據(jù)：UDP數(shù)據(jù)報被封裝在IP數(shù)據(jù)包中，然后通過IP網(wǎng)絡發(fā)送給接收端。由于UDP是無連接的，所以發(fā)送數(shù)據(jù)時不需要建立和終止連接。UDP只是簡單地將數(shù)據(jù)報發(fā)送出去，而不關心數(shù)據(jù)報是否能成功到達。

接收數(shù)據(jù)：當UDP數(shù)據(jù)報到達接收端時，接收端會根據(jù)頭部的端口號將數(shù)據(jù)報傳遞給相應的應用程序。如果數(shù)據(jù)報的校驗和錯誤，或者應用程序的接收緩沖區(qū)滿了，那么數(shù)據(jù)報可能會被丟棄。

處理數(shù)據(jù)：應用程序接收到數(shù)據(jù)報后，可以立即處理數(shù)據(jù)。由于UDP不提供數(shù)據(jù)的順序保證，所以應用程序需要自己處理數(shù)據(jù)的順序問題。

總的來說，UDP提供了一種簡單快速的數(shù)據(jù)傳輸方式，但是它不提供數(shù)據(jù)的可靠傳輸，也不提供流量控制或擁塞控制。因此，使用UDP的應用程序需要自己處理這些問題。