計算機網路學習筆記：第二章

學習書籍：《計算機網路：自頂向下方法》

前言

本章介紹有關網路應用的原理和實作方法；定義關鍵的應用層概念，包括程式所需要的網路服務、客戶和服務器、行程和運輸層介面；詳細考察幾種網路應用程式，包括WEB、電子郵件、DNS、對等檔案分發和視頻流；并設計開發運行在TCP和UDP上的網路應用程式；

2.1、應用層協議原理

研發網路應用的核心是寫出能夠運行在不同端系統和通過網路彼此通信的程式；值得注意的是，我們不需要寫在網路核心設備如路由器或者鏈路層交換機上運行的軟體，這種設計方式（將應用程式限制在端系統的方法），促進了大量網路應用程式的迅速研發和部署；

2.1.1 網路應用程式體系結構

應用程式的體系結構不同于網路的體系結構，從應用程式研發者的角度來看，網路體系結構是固定的，并為應用程式提供特定的服務集合；換言之，應用程式體系結構使用應用程式開發設計的，它規定了在端系統上如何組織應用程式，兩種常見的現代網路應用程式所采用的體系結構為：客戶-服務器體系結構和對等體系結構；

客戶-服務器體系結構

在該體系結構中，有一個總是打開的主機，即服務器，它接收和服務來自其他許多被稱為客戶的主機請求；值得注意的是，在該體系結構中，客戶之間是不直接通信的；該服務器具有固定的、周知的地址；

客戶-服務器體系結構的著名應用有：Web、FTP、Telnet和電子郵件，

通常，如果僅有一臺服務器處理所有的請求，那么服務器系統將很快變得不堪重負，為此，配備大量主機的資料中心常被用于創建強大的虛擬的服務器，一個資料中心可以有數十萬臺服務器，它們需要供電和維護，同時服務提供商還需要支付不斷出現的互聯和帶寬費用，以及發送和接收到達/來自資料中心的資料；

P2P體系結構

在P2P體系結構中，對位于資料中心的專用服務器有著最小（或者沒有）依賴，應用程式在間斷連接的主機對之間使用直接通信，這些主機被稱為對等方，對等方并不為服務提供商所擁有，因為這種對等方通信不需要通過專門的服務器，所以該體系結構也被稱為對等方到對等方結構;

目前，流量密集型應用都是P2P體系結構的，這些應用包括檔案共享（例如BitTorrent）、協助下載（例如迅雷）、因特網電話（例如Skype）和 IPTV(例如迅雷看看)，

值得注意的是，某些應用具有混合的體系結構，它們結合了客戶-服務器和P2P這兩種體系結果，比如許多的即時通訊工具，服務器用來跟蹤用戶IP地址，但是用戶之間的通信則使用直接發送

P2P體系結構最引人入勝的特性之一就是它們的自擴展性，比如在檔案共享應用中，對等方可能通過向檔案的原始擁有者發出請求而產生作業量，但是對等方也有可能通過為其他對等方傳送檔案而為原始擁有者分擔壓力；P2P體系結構也是成本有效的，因為他通常不需要龐大的服務器基礎設施和服務帶寬，

P2P面臨以下三個問題：

1. ISP友好，大多數住宅ISP受制于非對稱帶寬應用，也就是下載比上傳要多得多，但是P2P視頻和檔案分發應用改變了從服務器到住宅ISP的上載流量，因而給ISP帶來壓力；
2. 安全性，因為其高度的分布和開放式，P2P應用也可能給安全帶來挑戰；
3. 激勵，如何說服用戶資源向應用提供帶寬、存盤和計算資源？這是一個問題；

2.1.2 行程通信

在作業系統中，實際進行通信的是行程而不是應用程式；當行程運行在同一個端系統上時，它們使用行程間通信機制相互通信；而行程間通信的規則是由端系統上的作業系統確定的，當行程運行在不同的端系統上時，它們通過跨越計算機網路的報文相互通信；發送行程產生報文并且向網路中發送，接收行程接收報文并對此作出回應（不回應也是一種回應）;

客戶與服務器行程

網路應用程式由成對的行程組成，這些行程通過網路互相發送報文，對于每對通信行程，我們通常將這兩個行程之一標識為客戶，而另一個行程標識為服務器，
需要注意的是，在某些P2P應用中，一個行程可能既是客戶也是服務器，因為在一個檔案共享應用中，一個行程的確既能請求檔案也能發送檔案，所以從行程所扮演的角色來區分是客戶行程還是服務器行程不夠精確，所以我們從發起通信的順序來定義它們：在給定的一對行程之間，首先發起通信的行程被標記為客戶行程，在會話開始時等待聯系的行程被稱為服務器行程，

行程與計算機網路之間的介面

多數應用程式是由通信行程對組成的，運行在不同端系統上的行程對之間通過計算機網路來實作通信，所以，在應用程式行程和計算機網路之間存在一個介面，該介面被稱為套接字，更為準確的說，套接字是同一臺主機內應用層和運輸層之間的介面，由于該套接字是建立網路應用程式的可編程介面，因此套接字也被稱為應用程式和網路之間的應用編程介面（Application Programming Interface, API .

應用程式開發者可以控制套接字在應用層的一切內容，但是對于運輸層的相關部分，幾乎沒有控制權，可以做的只有：

1. 選擇傳輸層協議；
2. 設定幾個傳輸層引數，比如最大快取和最長傳輸層報文長度；

行程尋址

為了向特定目的行程發送報文，發送機行程需要知道接收行程（更為準確的說是，接收行程對應的套接字）的標記，該標記由兩部分組成：接收行程所在的主機地址和在目的主機中指定接收行程的識別符號；在因特網中，主機由IP地址標記，其中IP地址是一個32位（IPV4）標記；而接收行程（或者說是接收套接字）使用埠號標記；一些常用的應用程式有著固定的埠號，比如Web服務器使用80埠、郵件服務器（運行SMTP協議）使用25埠等；

2.1.3 可供應用程式使用的運輸服務

傳輸層協議的特點大致可以從以下這四個方面考量：可靠資料傳輸、吞吐量、定時和安全性；

可靠資料傳輸

如同在第一章中介紹的，分組在傳輸程序中可能會丟失，比如，分組因為路由器中的快取溢位而被丟棄或者分組在傳輸的程序中發生了損壞等情況；有些應用是不允許資料發生丟失的，比如電子郵件、檔案傳輸、遠程主機訪問、Web檔案傳輸以及金融應用等，為了支持這些應用，必須做一些作業以確保應用程式一段發送的資料正確、完全地交付給接收資料的行程，如果一個協議提供了這樣得確保資料交付的服務，就認為該協提供了可靠資料傳輸，當應用程式使用可靠資料傳輸的傳輸層協議時，只要將要發送的資料傳輸進套接字就可以完全相信該資料可以完整無差錯地到達接收方；

當一個運輸層協議不提供可靠資料傳輸時，由發送方發送的資料就可能不能夠到達接收行程，這可能被丟失允許的應用所接受，這類應用常見的有：交談式音頻和視頻，它們能夠承擔丟失一定量的資料損失，在這些應用中，如果丟失少量資料將出現小干擾，但是不會出現致命的損傷，這些應用為容忍丟失的應用，

吞吐量

在一條網路路徑上的兩個行程之間的通信會話中，可用吞吐量就是指能夠向接收行程交付位元的速率，因為會有其他會話共享該網路的路徑的帶寬，并且因為這些會話的到來和離開，可用吞吐量將發生變化；這就導致另一種自然的服務，即運輸層協議能夠提供確切的可用吞吐量，使用這種服務時，應用程式就能以明確的速度接收資料，并且運輸層應當保證可用吞吐量必須總是至少為該速度；

對吞吐量有明確要求的應用程式被稱為帶寬敏感的應用，許多多媒體應用是帶寬敏感的，比如因特網電話，而彈性應用則對吞吐量沒有嚴格的要求，這類應用包括：電子郵件、檔案傳輸以及web傳送等，值得注意的是，吞吐量當然是越多越好了;

定時

定時和吞吐量都是關于速度的，一個提供定時服務的例子是：發送方注入套接字中的每個位元到達接收方的套接字不遲于100ms，也就是說，定時是對資料從發送到到達所需時間的要求，而吞吐量是對資料交付速度的要求，有些應用為了服務的有效性而對資料到達時間有嚴格的要求，常見的應用有：因特網電話、多方在線游戲等；

安全性

運輸層可以提供一些安全服務，以防止傳輸的資料以某種方式在這兩個行程之間被察覺到，這些安全服務包括：數據的加解密、資料的完整性和端點鑒別等；

2.1.4 因特網提供的傳輸層服務

因特網（更一般的是TCP/IP網路）為應用程式提供連個運輸層協議，即UDP和TCP，每個協議對應用程式提供了不同服務的組合，以下為常見的因特網應用的特點：

TCP服務
TCP服務模型包括了面向連接的服務和可靠資料傳輸服務，

面向連接的服務：在應用層資料報文開始流動之前，TCP會在客戶端和服務器端相互交換傳輸層控制資訊，這個握手程序將提示客戶端和服務器端，讓它們為即將到來的大量分組做好準備；握手階段接收后將建立一個TCP連接，這條鏈接是全雙工的，即連接雙方使用該條鏈接可以同時進行報文的收發，這條連接將在通訊結束后拆除；
可靠的資料傳輸：應用程式使用TCP協議可實作無差錯、按適當順序交付所有發送的資料，沒有位元組的丟失和冗余；

TCP服務還提供了擁塞控制機制，該機制不一定會給通行雙方帶來好處，但是會給網路帶來整體好處；當發送方和接收方之間的網路出現擁塞時，TCP將使用擁塞控制機制來使網路恢復正常 ；

UDP服務

UDP服務是一種不提供不必要服務的輕量級運輸協議，它僅提供最小服務，UDP是無連接的也就是說通信之前沒有握手；UDP不提供資料的可靠傳輸；UDP也沒有擁塞控制機制，所以UDP的發送端可以用它選定的任何速率向其下層（網路層）注入資料，有些應用場景下，UDP協議將帶來更多的便利和效率，比如DNS和一些因特網電話服務（為了避免擁塞控制協議的控制而使用UDP）；

傳輸層無法提供的服務

從可靠資料傳輸、吞吐量、定時、安全性等四個角度來看運輸層提供的服務，我們發現，運輸層無法對吞吐量和定時做出保證（因為因特網已經被設計成盡可能最大可能對付這種保證的缺乏），總之，今天的因特網能夠為時間敏感的應用提供滿意的服務，盡管它并不提供任何定時或者帶寬保證；

流行的因特網應用及其應用層協議和支撐的運輸協議

電子郵件、遠程終端訪問、Web、檔案傳輸都使用了TCP（TCP提供了可靠資料傳輸服務，確保所有資料最終到達目的地）；而因特網電話應用通常能忍受某些丟失但要求一定的最小速率才能有效作業，故通常使用UDP（有些防火墻被配置成阻擋UDP流量，則使用TCP作為備份）以避開TCP的擁塞控制機制和分組開銷；

2.1.5 應用層協議

應用層協議定義運行在不同端系統上的應用程式行程如何相互傳遞資訊，涉及的內容包括：交換的報文型別（請求或者回應）、報文中包含哪些欄位、欄位如何被解釋、一個行程何時收發報文并如何對報文進行回應等內容‘
區分網路應用和應用層協議很重要，應用層協議只是網路應用的一部分；（例如對于一個Web應用，包括檔案格式標準HTML、Web瀏覽器、WEb服務器，以及一個應用層協議HTTP；）

2.1.6 本書涉及的網路應用

即將介紹的應用包括：Web、檔案傳輸、電子郵件、目錄服務、流式視頻和P2P，Web部分將介紹HTTP協議，它比較簡單和易于理解；FTP則和HTTP形成了對照；電子郵件是比Web更為復雜的應用，因為它使用了多個應用層協議；大多數用戶不會直接和DNS接觸，但是DNS很好地說明了一種核心的網路功能是如何在應用層實作的；最后便是P2P應用的簡單介紹了；

2.2 Web和HTTP

對于大多數用戶來說，最具吸引力的就是Web的按需操作；

2.2.1 HTTP概述

HTTP（HyperText Transfer Protocol）是Web的應用層協議，它是Web的核心；HTTP有兩部分實作，一個客戶端程式和一個服務器程式；HTTP定義了客戶和服務器進行報文交換的方法；

Web頁面（也叫檔案）是由物件組成的，一個物件是一個檔案，它們通過一個URL地址進行尋址，客戶和服務器互動的核心思想是客戶通過HTTP請求對服務器發出對Web頁面的請求報文，服務器收到該報文后將回傳包含該物件的HTTP回應報文，URL地址由兩部分組成：存放物件的服務器主機名和物件的路徑名；

HTTP使用TCP作為它的傳輸層協議；HTTP客戶首先發起一個與服務器的TCP連接，需要注意的是，服務器根據請求作出回應，但是不存盤任何關于該客戶的狀態資訊；也正因為這樣，HTTP被稱為無狀態協議，同時，Web使用了客戶端-服務器的應用體系結構；其中web服務器總是開著的；

2.2.2 持續連接和非持續連接

在因特網應用程式中，客戶端和服務器將在很長的時間范圍里通信；應用程式將根據自身的特點，選擇以規則的間隔周期性性發出請求也可以間斷性一個個發出請求，當通信是使用TCP協議時，服務器端需要做出一個決定：這些請求是使用一個TCP連接完成還是通過獨立的TCP連接完成，前者稱應用程式使用持續連接，后者則稱為非持續連接；

HTTP既可使用持續連接也可以使用非持續連接，盡管HTTP在靜默情況下使用持續連接；

采用非持續連接的HTTP

使用非持續連接時，每個TCP連接在服務器發送一個物件后就會關閉，也就是每個TCP只傳送一個請求報文和回應報文；

為了描述持續連接和非持續連接的特點，我們引入往返時間(Round-Trip Time, RTT)，RTT指的是，一個短分組從客戶端到服務器，然后再回傳客戶端所用的時間，RTT包括分組的傳播時延、排隊時延、處理時延（因為是短分組，所以其傳輸時延可不計）；因為客戶端和服務器建立TCP連接的時候，會通過一個三次握手的程序來交換傳輸控制資訊，三次握手的前兩次占用了一個RTT，客戶結合第三次握手通行會通過該連接發送一個HTTP請求報文，一旦該分組到達服務器，服務器便開始使用TCP傳輸HTML物件，因此，粗略地說，回應時間是兩個RTT加上傳輸HTML的時間（不是傳播），

采用持續連接的HTTP

勺ò干見非持續連接的一些缺點：第一，必須為每個請求新建一個TCP連接，而每個TCP連接將占用系統資源，包括緩沖區和變數等，這樣服務器的負擔就很重了；第二，一個物件將通過兩個RTT的時延才能交付；

如果使用持續連接，那么服務器在發送回應報文后將保持該TCP打開，后續客戶端可以使用該連接來向服務器發出請求，不但一個完整的頁面可以通過同一個連接傳送，同一臺服務器上的多個頁面也可以通過同一個連接發送，這就提高了效率；
一般來說，如果一條連接在一定的時間間隔后沒被使用的話，就會被關閉，HTTP默認使用的是帶流水線的持續連接；

2.2.3 HTTP報文格式

HTTP報文有兩種：請求報文和回應報文；

HTTP請求報文

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mosilla/5.0
Accept-language: fr

一個請求報文具有至少一行的內容，請求報文的第一行稱為請求行，其后繼的各行被稱為首部行，請求行包含三個內容：方法欄位、URL欄位、HTTP版本；其中方法欄位可為：GET、POST、PUT、DELETE、HEAD等，URL欄位里可以傳遞請求物件的標志；

首部行包含是否在發送完回應報文后關閉TCP連接的Connection；請求的主機地址（該頭部資訊被Web高速快取所要求）；瀏覽器版本；可接受的語言等頭部資訊；

在首部行之后一個空行，之后便是請求的“物體體”，使用GET方法時物體體為空，使用POST方法的時候才用該物體體；該物體體可以在POST方法里傳遞Form表單內容或者傳遞其它一些二進制流資料等，值得注意的是，表單也不一定必須使用POST方法，如果使用GET圖，物體體為空，會顯示在URL中；

HEAD類似于GET方法，將會用一個HTTP報文進行回應，但是不回傳請求物件，經常用作除錯跟蹤，PUT方法常與Web發行工具聯合使用，允許用戶上傳物件到指定的Web服務器上指定的路徑，DELETE方法允許用戶或應用程式洗掉Web服務器上的物件，

HTTP回應報文

HTTP/1.1 200 OK
Connection: close
Date: True, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS) // 類似于請求報文的User-agent
Last-Modified: True, 18 Aug 2015 15:11:03 GMT 
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

回應報文總體上也分三個部分，第一部分是狀態行，包含HTTP版本、狀態以及狀態資訊等內容；第二部分是首部行，包含發送日期、服務器型別、上一次修改請求資源的時間、內容的型別等內容，第三部分是物體體，物體體包含請求物件本身，

這里的Date是從檔案系統中檢索到該物件，插入到回應報文，并發送該回應報文的時間，Last-Modified則是物件創建或者最后修改的日期和時間；

常見狀態碼

200 OK：請求成功，處理方式：資訊在回傳的回應報文中；
301 Moved Permanently：請求的物件被永久轉移了，首部行中；處理方式：重定向到分配的URL；
400 Bad Request：非法請求，處理方式：丟棄；
404 Not Found：沒有找到，處理方式：丟棄；
505 HTTP Version Not Supported：服務器不支持請求報文使用的HTTP版本；

2.2.4 用戶與服務器的互動：Cookie

前面提到，HTTP是無狀態協議，但是Web站點為了識別用戶身份或者限制用戶訪問的時間或者將用戶訪問的內容同用戶身份相關聯，Web站點可以使用Cookie技術；

Cookie技術包含4個組件:

1. HTTP回應報文里增加一個關于Cookie的首部行；
2. HTTP請求報文里增加一個關于Cookie的首部行；
3. 用戶端系統保留一個Cookie檔案，由瀏覽器保存維護；
4. Web站點建立Cookie和用戶身份的關聯；

雖然，Cookie的使用方便了用戶也方便了服務端，但是它的使用存在爭議，因為使用Cookie被認為是對用戶隱私的一種侵犯，因為Web站點可以通過Cookie得到很多用戶的資訊，并有可能將這部分資訊賣給第三方等；

2.2.5 Web快取

Web快取器也被稱為代理服務器，它代表初始web服務器來滿足HTTP請求，它有自己的存盤空間，并在存盤空間里保持有最近請求過的物件的副本；可以通過配置瀏覽器，將所有指向初始服務器的請求首先指向代理服務器，

當代理服務器收到一個HTTP請求后，它將檢查本地是否快取過該物件，如果快取過該物件，將檢查是否過期，如果沒有過期，則直接將該物件回傳給瀏覽器；如果本地不存在或者存在已過期，則代理服務器將根據請求報文里的Host首部行以及請求行里的URL欄位向初始服務器發出請求，然后將回應物件回傳給瀏覽器并快取在本地，

通常，代理服務器與客戶端的通信速度要快于初始服務器與客戶端的連接速度；因特網部署Web快取器有兩個原因：1）Web代理服務器可以大起大減少對客戶請求的回應時間；2）快取器能從整體上大大降低因特網上的Web流量，從而有助于提高所有應用程式的性能；

通過使用內容分發網路（Content Distribution Network, CDN），Web快取器正在因特網中發揮越來越重要的作用；

Web快取即是客戶又是服務器；

2.2.6 條件GET方法

高速快取器的使用，帶來很多好處，但是有一個問題：存放在快取器傷的物件副本可能是舊的，即保存在服務器中的物件自該副本快取在客戶上以后可能被修改了；

其實HTTP提供了一種機制，允許快取器證實其使用的物件是最新的，這種機制就是條件GET方法，使用條件GET方法只需在使用GET方法的時候，增加一個If-Modified-Since：首部行，其對應的內容是一個時間，如果所請求的資源在指定日期后被修改了，那么服務器將回傳新的物件，否則服務器將回傳一個包含空物體體的報文，這樣代理服務器就可以確認快取是否過期了，