《電腦網路-自頂向下方法》學習筆記

• 2022 年 9 月 4 日
• 筆記
• 初探電腦網路

TCP 和 UDP

TCP 服務

TCP 服務模型包括面向連接和可靠數據傳輸服務。當某個應用程式調用TCP作為其運輸服務協議時，該應用程式就能獲得來自TCP 的這兩種服務。

• 面向連接的服務：在應用層數據報文開始流動之前，TCP 讓客戶和伺服器互相交換運輸層控制資訊。這個所謂的握手過程提醒客戶和伺服器，讓它們為大量分組的到來做好準備。在握手階段後，一個 TCP 連接 就在兩個進程的套接字之間建立了。這種鏈接是全雙工的，即連接雙方的進程可以在此連接上同時進行報文收發。當應用程式結束報文發送時，必須拆除該連接。
• 可靠的數據傳送服務：通訊進程能夠依靠 TCP ，無差錯、按適當順序交付所有發送的數據。當應用程式的一端將位元組流傳進套接字時，它能夠依靠 TCP 將相同的位元組流交付給接收方的套接字，而沒有位元組的丟失和冗餘。

UDP 服務

UDP 是一種不提供不必要服務的輕量級運輸協議，它僅提供最小服務。UDP 是無連接的，因此在兩個進程通訊前沒有握手過程。UDP協議提供一直不可靠數據傳輸服務，也就是說，當進程將一個報文發送進UDP 套接字時，UDP協議並不保證該報文將到達接受進程。不僅如此，到達接受進程的報文也可能是亂序到達的。

HTTP

概況

HTTP 定義了 Web 客戶端向 Web 伺服器請求 Web 頁面的方式，以及伺服器向客戶端傳送 Web 頁面的方式。

HTTP 使用 TCP 作為它的支撐運輸協議。HTTP 客戶端首先發起一個與伺服器的 TCP 連接。一旦連接建立，該瀏覽器和伺服器進程就可以通過套接字介面訪問 TCP 。客戶端的套接字介面是客戶端進程與 TCP 連接之間的門，在伺服器端的套接字介面則是伺服器進程與 TCP 連接之間的門。客戶端向它的套接字介面發送 HTTP 請求報文並從它的套接字介面接收HTTP響應報文。類似地，伺服器從它的套接字介面接收 HTTP 請求報文和它的套接字介面發送 HTTP 響應報文。一旦客戶向它的套接字介面發送了一個請求報文，該報文就脫離了客戶端控制並進入 TCP 的控制。

TCP 為 HTTP 提供可靠數據傳輸服務。這意味著，一個客戶端進程發送的每個 HTTP 請求報文最終能完整地到達伺服器；類似地，伺服器進程發出的每個 HTTP 響應報文最終能完整地到達客戶端。

伺服器向客戶端發送被請求的文件，而不存儲任何關於該客戶的狀態資訊。假定某個特定的客戶在短短几秒內兩次請求同一個對象，伺服器並不會因為剛剛為該客戶提供了該對象就不再做出反應，而是重新發送該對象，就像伺服器完全忘記不久之前所做過的事一樣。因為HTTP伺服器並不保存關於客戶端的任何資訊，所以HTTP是一個 無狀態協議。

非持續連接和持續連接

在許多網際網路應用程式中，客戶端和伺服器在一個相當長的時間範圍內通訊，其中客戶端發出一系列請求並且伺服器對每個請求進行響應。依據應用程式以及該應用程式的使用方式，這一系列請求可以以規則的間隔周期性地或者間斷性地一個接一個發出。當這種客戶-伺服器的交互是經 TCP 進行的，應用程式的研製者就需要做一個重要決定，即每個請求/響應對是經一個單獨的TCP連接發送，還有所有的請求及其響應經相同的TCP連接發送？前一種稱為非持續連接，後一種稱為持續連接。HTTP在默認方式下使用持續連接，但同時，HTTP客戶和伺服器也能配置成使用非持續連接。

HTTP 請求報文

GET /user/info.html HTTP/1.1
Host: www.hyxiao.com
Connection: close
User-agent: Mozilla/5.0
Accept-language: zh-CN,zh;q=0.9,en-GB;q=0.8,en-US;q=0.7,en;q=0.6

• Connection: close -> 首部行，該瀏覽器告訴伺服器不要麻煩地使用持續連接，它要求伺服器在發送被請求的對象後就關閉這條連接。
• User-agent: Mozilla/5.0 -> 首部行用來指明用戶代理，即向伺服器發送請求的瀏覽器的類型。
• Accept-language: -> 得到該對象的語言版本，這裡是中文

HTTP響應報文

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data ... ...)

上面的響應報文分為三個部分：一個初始狀態行（status line），6個首部行（header line），實體體（entity body）。

實體體部分是報文的主要部分，即它包含了所請求的對象本身（即data）。狀態行有3個欄位：協議版本欄位、狀態碼和相應狀態資訊。以上中，狀態行指示伺服器正在使用 HTTP /1.1 ，並且一切正常（即伺服器已經找到並正在發送所請求的對象）。

• Connection: close -> 首部行告訴客戶端，發送完報文後將關閉該TCP連接。
• Date -> 首部行指示伺服器產生並發送該響應報文的日期和時間。這個日期指的是伺服器從它的文件系統中檢索到該對象，並將該對象插入響應報文，並發送該響應報文的時間。
• Server -> 首部行指示該報文是一台 Apache Web 伺服器產生的，它類似於HTTP 請求報文中的User-agent：首部行。
• Last-Modified -> 首部行指示了對象創建或者最後修改的日期和時間。
• Content-Length -> 首部行指示了被發送對象中的位元組數。
• Content-Type -> 首部行指示了實體體中的對象是HTML文本。

Web快取

Web 快取器 也叫代理伺服器，它是能夠代表初始 Web 伺服器來滿足 HTTP 請求的網路實體。Web 快取器有自己的磁碟存儲空間，並在存儲空間中保存最近請求過的對象的副本。如上圖所示，可以配置用戶的瀏覽器，使得用戶的所有HTTP請求首先指向Web快取器。一旦某瀏覽器被配置，每個對某對象的瀏覽器請求首先被定向到該Web快取器。

1. 瀏覽器創建一個到 Web 快取器的TCP連接，並向Web快取器中的對象發送給一個HTTP請求。
2. Web快取器進行檢查，看看本地是否存儲了該對象副本。如果有，Web快取器就向客戶瀏覽器用HTTP響應報文返回該對象。
3. 如果Web快取器中沒有該對象，它就打開一個與該對象的初始伺服器的TCP連接。Web快取器則在這個快取器到伺服器的TCP連接上發送一個對該對象的HTTP請求。在收到該請求後，初始伺服器向該Web快取器發送具有該對象的HTTP響應。
4. 當 Web 快取器接收到該響應對象時，它在本地存儲空間存儲一份副本，並向客戶的瀏覽器用HTTP響應報文發送該副本（通過現有的客戶瀏覽器和Web快取器之間的TCP連接）。

值得注意的是Web快取器既是伺服器又是客戶端。當它接收瀏覽器的請求並發迴響應時，它是一個伺服器。當它向初始伺服器發出請求時並接收響應時，它是一個客戶端。

在網際網路部署Web快取器有兩個原因。首先，Web快取器可以大大減少對客戶端請求的響應時間。其次，Web快取器能夠大大減少一個機構的接入鏈路到網際網路的通訊量。兩點可以看出，Web快取器能從整體上大大減低網際網路上的Web流量，從而改善了所有應用的性能。

條件GET方法

儘管高速快取能減少用戶感受到的響應時間，但也引入了一個新的問題，即存放在快取器中的對象副本可能是舊的。換句話說，保存在伺服器中的對象自該副本快取在客戶端上以後可能已經被修改了。但同時，HTTP協議有一種機制，允許Web快取器證實它的對象是否是最新的。這種機制便是條件GET方法。如果：①請求報文使用GET方法；並且②請求報文中包含一個”If-Modified-Since:” 首部行。那麼，這個HTTP請求報文就是一個條件GET請求報文。

下面看一個例子，首先，一個Web快取器代表一個請求瀏覽器（即客戶端），向某Web伺服器發送一個請求報文：

GET /fruit/kiwi.gif HTTP /1.1
Host: www.exotiquecuisine.com

其次，該Web伺服器向快取器發送具有被請求的對象的響應報文：

HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data... ...)

該快取器在將該對象轉發到請求的瀏覽器的同時，也在本地快取了該對象。重要的是，快取器在存儲該對象時也會存儲最後修改日期。所以，快取器可以通過發送一個條件GET執行最新檢查，發送報文如下

GET /fruit/kiwi.gif HTTP /1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

值得注意的是If-Modified-Since:首部行的值剛好等於上次伺服器發送的響應報文中的Last-Modified：首部行的值。則證明該對象沒有被修改過，接下來Web伺服器則向Web快取器發送一個響應報文：

HTTP/1.1 304 Not Modified
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

可以看出，作為對該條件GET方法的響應，該Web伺服器仍發送一個響應報文，但並沒有在該響應報文中包含所請求的對象。畢竟包含對象，會浪費額外的頻寬，還會增加響應時間。並且在狀態欄中可以看出，狀態碼為304 Not Modified，它可以告訴快取器，可以繼續使用該對象。

網際網路中的電子郵件

網際網路電子郵件系統組成部分：用戶代理（user agent）、郵件伺服器（mail server）和簡單郵件傳輸協議（Simple Mail Transfer Protocol，SMTP）。

SMTP

SMTP 是網際網路電子郵件中主要的應用層協議。它使用TCP可靠數據傳輸服務，從發送方的郵件伺服器向接收方的郵件伺服器發送郵件。像大多數應用層協議一樣，SMTP有兩個部分：運行在發送方郵件伺服器的客戶端和運行在接收方郵件伺服器的伺服器端。每台郵件伺服器上既運行SMTP的客戶端也運行SMTP的伺服器端。當一個郵件伺服器向其他郵件伺服器發送郵件時，它就表現為SMTP的客戶端；當郵件伺服器從其他郵件伺服器上接收郵件時，它就表現為一個SMTP的伺服器。

SMTP 採用的是持續連接：如果發送郵件伺服器有幾個報文發往同一個接受郵件伺服器，它可以通過同一個TCP連接發送這些所有的報文。

與HTTP的對比

相同點

• 都用於從一台主機向另一台主機發送文件
• 都是用持續連接

不同點

• HTTP 主要是拉協議，即用戶使用 HTTP 協議從該伺服器拉取資訊；而SMTP是推協議，即發送郵件伺服器把文件推向接收郵件伺服器。
• SMTP 要求每個報文採用 7比特ASCII 碼格式。HTTP 不受限制
• HTTP 把每個對象封裝到它自己的HTTP響應報文中；而SMTP 則把所有報文對象放在一個報文之中。

DNS 網際網路的目錄服務

DNS：域名系統（Domain Name System），能夠將主機名轉換成IP地址的目錄服務。

1. 是一個由分層的 DNS 伺服器實現的分散式資料庫；
2. 是一個使得主機能夠查詢分散式資料庫的應用層協議；

DNS 伺服器是運行BIND 軟體的UNIX 機器。DNS 協議運行在UDP之上，使用53號埠。

當主機將HTTP請求報文發送到Web伺服器時，瀏覽器從URL中抽取出主機名，並將這台主機名傳給DNS應用的客戶端；DNS 客戶端向DNS伺服器發送一個包含主機名的請求；DNS 客戶端最終會收到一份回答報文，其中含有對應該主機名的IP地址；一旦瀏覽器接收到來自DNS的該IP地址，它能夠向位於該IP地址80埠的HTTP伺服器進程發起一個TCP連接。