计算机网络-应用层
一、應用層協議原理
????1.網絡應用程序體系結構
????應用程序的體系結構明顯不同于網絡的體系結構。從應用程序研發者的角度看，網絡體系結構是固定的，并為應用程序提供了特定的服務集合。
????應用程序體系結構(application architecture)由應用程序研發者設計，規定了如何在各種端系統上組織該應用程序。
????現代網絡應用程序的兩種主流體系結構：客戶機/服務器體系結構和對等(P2P)體系結構。
????客戶機/服務器體系結構(client-sever architecture):有一個總是打開的主機稱為服務器，它服務于來自許多其他稱為客戶機的主機請求?？蛻魴C主機既可以有時打開，也可能總是打開。一個典型的例子是Web應用程序，其中總是打開的Web服務器服務于運行在客戶機主機上的瀏覽器的請求。當Web服務器接收到來自某客戶機對某對象的請求時，它向該客戶機發送所請求的對象作為響應。注意到客戶機/服務器體系結構中，客戶機相互之間不能直接通信，例如，在Web應用中兩個瀏覽器不能直接通信?？蛻魴C/服務器體系結構的另一個特征是服務器具有固定的、周知的地址，稱為IP地址。因為服務器具有固定的、周知的地址，并且總是處于打開狀態，所以客戶機總是能夠通過向該服務器的地址發送分組來與其聯系。某些具有客戶機/服務器體系結構的更為著名的應用程序包括Web、FTP、Telnet和電子郵件。
????在P2P體系結構(P2P architecture)中，對總是打開的基礎設施服務器有最小的依賴。任意間斷連接的主機對稱為對等方，直接相互通信。對等方并不為服務提供商所有，而是為用戶控制的桌面機和膝上機所有，大多數對等方駐留在家庭、大學和辦公室。因為這種對等方通信不必通過專門的服務器所以體系結構被稱為對等方到對等方（簡稱為對等）。目前，大多數流行的流量密集型應用程序都是P2P體系結構的，包括文件分發、文件搜索/共享、因特網電話和IPTV(PPLive).某些應用具有混合的體系結構，由客戶機/服務器和P2P元素結合而成。例如，對于許多即時通訊而言，服務器場用于跟蹤用戶的IP地址，但用戶到用戶的報文在用戶主機之間直接發送(無需通過中間服務器)。P2P體系結構的最突出特性之一是它的自擴展性(self-scalability)。例如，在一個P2P文件共享應用中，盡管每個對等方都由請求文件產生負載，但每個對等方向其他對等方分發文件也為系統增加了服務能力。P2P體系結構也是成本有效的，因為它們通常不需要龐大的服務器基礎設施和服務器帶寬。為了降低成本，服務提供商(MSN、Yahoo等)對于P2P體系結構用于系統的興趣越來越大。另一方面，由于P2P應用程序具有高度分布和開放的性質，因此要格外關注系統的安全。
????2.進程通信
????2.1?客戶機和服務器進程：
????網絡應用程序由成對的進程組成，這些進程通過網絡相互發送報文。例如，在Web應用程序中，一個客戶機瀏覽器進程與一臺Web服務器進程交換報文。在一個P2P文件共享系統中，文件從一個對等方中的進程傳輸到另一個對等方中的進程。對每對進程通信，通常將這兩個進程之一表示為客戶機(client),而另一個進程表示為服務器(server)。在Web中，瀏覽器是一個客戶機進程，Web服務器是一個服務器進程。對于P2P文件共享，下載文件的對等方被標示為客戶機，上載文件的對等方的對等方稱為服務器。
????在給定的一對進程之間的通信會話中，發起通信的進程被標示為客戶機，在會話開始時等待聯系的進程是服務器。
????2.2??進程與計算機網絡之間的接口：
????多數應用程序由通信進程對組成，每對中的兩個進程互相發送報文。從一個進程向另一個進程發送的報文必須通過下面的網絡。進程通過一個稱為套接字(socket)的軟件接口在網絡上發送和接收報文。
????進程類比于一座房子，而它的套接字可以類比于它的門。當一個進程想向位于另外一臺主機上的另一個進程發送報文時，它把報文推出門(socket)。該發送進程假定門到另一側之間有運輸的基礎設施，該設施將把報文傳送到目的進程的門口。一旦報文抵達目的主機，它通過報文接收進程的門(socket)傳遞，然后接收進程對報文進行相應的處理。
????由于套接字是在網絡上建立網絡應用程序的可編程接口，因此也將套接字稱為應用程序和網絡之間的應用程序編程接口(Application Programming Interface,API)。應用程序開發者可以控制套接字在應用層端的所有東西，但是對該套接字的運輸層端幾乎沒有控制。
????應用程序開發者對運輸層的控制僅限于：選擇運輸層協議 也許能設定及格運輸層參數，如最大緩存、最大報文長度等。一旦應用程序開發者選擇了一個運輸層協議（若可供選擇），則應用程序就建立在由該協議提供的運輸層服務之上。
????2.3 ?可供應用程序使用的運輸服務：
????套接字是應用程序進程和運輸層協議之間的接口。發送端的應用程序通過套接字發送報文。在套接字的另一側，運輸層協議負責將該報文傳輸到接收套接字的“門”中。
????可從四個方面對應用程序服務要求進行分類：可靠數據傳輸、吞吐量、定時和安全性。
????可靠數據傳輸(reliable data transfer)：分組能在計算機網絡中丟失。例如，分組能夠使路由器中的緩存溢出，或者當分組中的某些比特損壞后可能被丟棄。像電子郵件、文件傳輸、遠程主機訪問、Web文檔傳輸以及金融應用等應用，數據丟失可能會造成災難性的后果。因此，對于這些應用，必須確保由應用程序的一端發送的數據正確地、完全地交付給該應用程序的另一端。如果一個協議提供了這樣的確保數據交付服務，就提供了可靠數據傳輸(reliable data transfer)。運輸層協議能夠潛在地向應用程序提供的一個重要服務是進程到進程的可靠數據傳輸。當一個運輸層協議提供這種服務時，發送進程只要將其數據傳遞到套接字，就可以相信該數據將能無差錯地到達接收進程。
????吞吐量：兩個進程在一條網絡路徑上進行通信會話時，可用吞吐量就是發送進程能夠向接收進程交付比特的速率。因為其他會話將共享沿著該網絡路徑上的帶寬，并且這些其他會話將會到達和離開，所以可用吞吐量將隨時間波動。自然就有了另一種服務，即運輸層協議能夠以某種特定的速率提供確保的可用吞吐量。具有吞吐量要求的應用程序稱為帶寬敏感的應用(bandwidth-sensitive application)。
????定時：運輸層協議可以提供定時保證。例如，在多方游戲和虛擬互動環境中，在做出動作及看到來自環境的響應之間，較長的時延會時游戲失去真實感。在非實時的應用中，較低的時延總要比較高的時延好，但對端到端的時延沒有嚴格的約束。
????安全性：運輸層協議能夠為應用程序提供一種或多種安全性服務。例如，在發送主機中，運輸層協議能夠加密由發送進程傳輸的所有數據；在接收主機中，運輸層協議能夠在將數據交付給接收進程之前解密這些數據。這種服務將對發送進程和接收進程保密，以防發送進程和接收進程以某種方式觀察到數據。運輸層協議也提供除了機密性以外的其他安全性服務，包括數據完整性和端點鑒別。
????2.4 ?因特網提供的運輸服務
????TCP服務：包括面向連接服務和可靠數據傳輸服務。
????面向連接服務：使用TCP協議時，在應用層數據報文開始流動之前，其客戶機程序和服務器程序之間相互交換運輸層控制信息。這個所謂的握手過程提示客戶機和服務器做好傳輸分組的準備。在握手階段后，就在兩個進程的套接字之間建立了一個TCP連接(TCP connection)。這個連接是全雙工的，即連接雙方的進程可以在此連接上同時進行報文收發。當應用程序結束報文發送時，必須拆除該連接。之所以稱之為“面向連接”的服務，而不是“連接”服務，是因為兩個進程之間是以一種非常松散的方式進行連接的。
????可靠數據傳輸服務：進行通信的進程依靠TCP協議，無差錯、按適當順序交付發送的數據。當應用程序的一端通過套接字傳送一個字節流時，它能夠依靠TCP協議將相同的字節流交付給接收方的套接字，而沒有字節的丟失和冗余。
????TCP協議還具有擁塞控制機制，這種服務不一定能為通信進程帶來直接好處，但能為因特網帶來整體好處。當發送方和接收方之間的網絡出現擁塞時，TCP協議的擁塞控制機制會抑制發送進程（客戶機或服務器）。TCP協議的擁塞控制試圖限制每個TCP連接，使它們達到公平共享網絡帶寬的目的。對有最低要求帶寬限制的實時音頻/視頻應用而言，抑制傳輸速率具有非常有害的影響。況且，實時應用是可以容忍數據丟失的，并不需要完全可靠的傳輸服務。出于這些原因，實時應用的開發者們通常將他們的應用放在UDP協議而不是TCP協議之上。
????UDP服務：UDP是一種不提供不必要服務的輕量級運輸層協議，它僅提供最小服務。UDP是無連接的，因此在兩個進程通信前沒有握手過程。UDP協議提供的是不可靠數據傳輸服務，也就是說，當進程通過UDP套接字發送報文時，UDP協議并不保證該報文能夠被接收進程接收到。不僅如此，接收進程收到的報文也可能是亂序到達的。
????UDP沒有擁塞控制機制，所以發送端可以以任何速率向其下面的層（網絡層）注入數據。
????因特網運輸層協議所不提供的服務：可靠數據傳輸、吞吐量、定時和安全性是四種可能的運輸層協議服務。TCP提供了可靠的端到端數據傳輸服務，并且TCP在應用層可以很容易通過SSL來提供安全服務。但在對TCP和UDP的描述中，缺少對吞吐量和定時保證的討論，即目前的因特網運輸層協議并沒有提供這兩種服務。但是這并不意味著因特網電話等時間敏感應用就不能運行在今天的因特網上了，因為在因特網上時間敏感應用已經存在多年了。這些應用運行的很好是因為設計時盡最大可能彌補了這些保證的缺乏。因特網通常能夠為時間敏感應用提供使之滿意的服務，但是不能提供任何有關定時或帶寬的保證。
????進程尋址：兩個進程之間進行通信時，一個發送進程為了識別特定接收進程，需要定義兩種信息：該主機的名稱或地址 ?用來指定目的主機上接收進程的標識。
????在因特網中，主機是用IP地址(IP address)進行標識的。IP地址是用來唯一標識主機的32比特數（然而，網絡地址轉換(NAT)的廣泛部署意味著實際中32比特的IP地址不僅僅唯一地用于尋址一臺主機）。
????除了知道報文去往目的主機的IP地址外，發送程序也必須識別運行在主機上的接收進程。之所以需要該信息，是因為通常在一臺主機上能夠運行許多網絡應用程序。目的地端口號(port number)就是服務于這個目的的。已經給流行的應用程序分配了特定的端口號。例如，Web服務進程用的是80號端口。郵件服務進程（使用SMTP協議）用的是25號端口。當開發者創建了一個新的網絡應用時，必須為該應用程序分配一個新的端口號。
????2.5 ?應用層協議
? ? 應用層協議(application-layer protocol)定義了運行在不同端系統上的應用程序進程如何相互傳遞報文。特別是應用層協議定義了：
????交換的報文類型，如請求報文和相應報文。
????各種報文類型的語法，如報文中的各個字段及其詳細描述。
????字段的語義，即包含在字段中的信息的含義。
????進程何時、如何發送報文及對報文相應的規則。
????注意區分網絡應用和應用層協議。應用層協議知識網絡應用的一部分。Web應用是一種客戶機/服務器應用程序，它允許客戶機按照需求從Web服務器獲得文檔。Web應用有很多組成部分，包括文檔格式的標準（即HTML）、Web瀏覽器、Web服務器，以及一個應用層協議。Web的應用層協議是HTTP，它定義了在瀏覽器和Web服務器之間傳輸的報文格式和序列。因此，HTTP只是Web應用的一部分。
二、Web應用和HTTP協議
????1.HTTP概況
????Web的應用層協議是超文本傳輸協議(HyperText Transfer Protocol,HTTP),它是Web的核心。HTTP協議由兩部分程序實現：一個客戶機程序和一個服務器程序，它們運行在不同的端系統中，通過交換HTTP報文進行會話。HTTP定義了這些報文的格式以及客戶機和服務器是如何進行報文交換的。
????一些Web中的常用術語：
????Web頁面（Web page，也叫文檔）是由對象組成的。對象(object)簡單來說就是文件，如HTML文件，JPEG圖形文件，Java小程序或視頻片段文件，這些文件可通過一個URL地址尋址，多數Web頁面含有一個基本HTML文件(base HTML file)以及幾個引用對象。例如，如果一個Web頁面包含HTML文本和5個JPEG圖形文件，那么這個Web頁面有6個對象：一個基本HTML文件加五個圖形。在基本HTML文件中通過對象的URL地址對對象進行引用。每個URL地址由兩部分組成：存放對象的服務器主機名和對象的路徑名。例如，URL地址http://www.someSchool.edu/someDepartment/picture.gif中的www.someSchool.edu就是主機名，/someDepartment/picture.gif就是路徑名。因為Web瀏覽器（Web Browser）實現了HTTP的客戶機端，所以在Web環境中，我們經常交替使用“瀏覽器”和“客戶機”這兩個術語。Web服務器(Web server)用于存儲Web對象，每個對象由URL尋址。Web服務器實現了HTTP服務器端。
????HTTP定義了Web客戶機是如何向Web服務器請求Web頁面，以及服務器如何將Web頁面傳送給客戶機的。當用戶請求一個Web頁面時，瀏覽器向服務器發出對該頁面中所包含對象的HTTP請求報文，服務器接受請求并用包含這些對象的HTTP響應報文進行響應。
????HTTP使用TCP（而不是UDP）作為它的支撐運輸層協議。HTTP客戶機發起一個與服務器的TCP連接，一旦連接建立，瀏覽器和服務器進程就可以通過套接字接口訪問TCP?？蛻魴C從套接字接口發送HTTP請求報文和接收HTTP響應報文。服務器從套接字接口接收HTTP請求報文和發送HTTP響應報文。一旦客戶機發送了一個請求報文，該報文就“脫離客戶機控制”并“進入TCP的控制”。TCP為HTTP提供可靠數據傳輸服務。這意味著，一個客戶機進程發出的每個HTTP請求報文最終都能完整地到達服務器；服務器進程發出的每個HTTP響應報文最終也都能完整地到達客戶機。
????注意到一個重要的現象：服務器向客戶機發送被請求的文件時，并不存儲任何關于該客戶機的狀態信息。假如某個特定的客戶機在短短的幾秒鐘內兩次請求同一個對象，服務器并不會因為剛剛為該用戶提供了該對象就不再做出反應，而是重新發送該對象，就像該服務器已經完全忘記不久之前所做過的事一樣。因為一個HTTP服務器并不保存關于客戶機的任何信息，所以我們說HTTP是一個無狀態協議(stateless protocol)。還注意到，Web使用了客戶機/服務器應用程序體系結構。Web服務總是打開的，具有一個固定的IP地址，它服務于數以百萬計的不同瀏覽器。
????2.非持久連接和持久連接
????在許多因特網應用中，客戶機和服務器進行長時間通信，其中客戶機發出一系列請求，服務器對每個請求進行響應。根據不同的應用程序以及應用程序使用的方式，這一系列請求可以一個接一個發出，也可以間斷性地發出。當這種客戶機/服務器的交互運行于TCP協議之上時，應用程序的研制者需要確定每個請求/響應對是經一個單獨的TCP連接發送，還是所有的請求及響應經相同的TCP連接發送。如果采用前一種方法，該應用程序被稱為使用非持久連接(non-persistent connection)；如果采用后一種方法，該應用程序被稱為使用持久連接(persistent connection)。HTTP既可以使用非持久連接，也可以使用持久連接，默認方式下HTTP使用持久連接。
????2.1 ?非持久連接
????在非持久連接的情況下，從服務器向客戶機傳送一個Web頁面的步驟：
????假設該頁面含有一個基本HTML文件和10個JPEG圖形，并且這11個對象位于同一臺服務器上。該HTML文件的URL為：http://www.someSchool.edu/someDepartment/home.index。 ?
????HTTP客戶機進程在端口號80發起一個到服務器www.someSchool.edu的TCP連接，該端口號是HTTP的默認端口?？蛻魴C和服務器上分別有一個套接字與該連接相關聯。
????HTTP客戶機經它的套接字向服務器發送一個HTTP請求報文。請求報文中包含了路徑名/someDepartment/home.index。
????HTTP服務器進程經它的套接字接收該請求報文，從其存儲器中檢索出對象someDepartment/home.index，在一個HTTP響應報文中封裝對象，并通過其套接字向客戶機發送響應報文。
????HTTP服務器進程通知TCP斷開該TCP連接。（但是直到TCP確認客戶機已經完整地收到響應報文為止，它才會真正中斷連接。）
????HTTP客戶機接收響應報文，TCP連接關閉。報文中指出封裝的對象是一個HTML文件，客戶機從響應報文中提取出該文件，檢查該文件，得到對10個JPEG圖形的引用。
????對每個引用的JPEG圖形對象重復前四步。
????當瀏覽器收到Web頁面后，把它顯示給用戶。兩個不同的瀏覽器也許會以不同的方式解釋該頁面。HTTP協議并不管客戶機如何解釋一個Web頁面。HTTP規約僅定義了在HTTP客戶機程序與HTTP服務器程序之間的通信協議。
????每個TCP連接在服務器返回對象后關閉，該連接并不為其他的對象而持續下來。注意到每個TCP連接只傳輸一個請求報文和一個相應報文。因此在本例中，用戶請求該Web頁面，要建立11個TCP連接。
????在上面描述的步驟中，我們有意沒有明確客戶機獲得這10個JPEG圖形對象，是使用10個串行的TCP連接還是使用并行的TCP連接。事實上，用戶可以設置瀏覽器以控制并行度。默認方式下，大部分瀏覽器打開5到10個并行的TCP連接，而每個連接處理一個請求-響應事務。還可以將最大并行連接數設置為1，這樣10個連接就會以串行方式建立。使用并行連接將會大大縮短響應時間。
????往返時間(Round-Trip Time,RTT)：一個小分組從客戶機到服務器再回到客戶機所花費的時間。
????RTT包括分組傳播時延、分組在中間路由器和交換機上的排隊時延以及分組處理時延。
????當用戶點擊超鏈接時，瀏覽器在瀏覽器和Web服務器之間發起一個TCP連接，這涉及一個“三次握手”的過程，即客戶機向服務器發送一個小TCP報文段，服務器用一個小TCP報文段做出確認和響應，最后，客戶機向服務器返回確認。一個RTT等于三次握手中前兩個部分所耗的時間。完成了三次握手的前兩個部分后，客戶機將三次握手的第三部分（確認）與一個HTTP請求報文結合起來發送到該TCP連接。一旦請求報文到達服務器，服務器向該TCP連接發送HTML文件。該HTTP請求/響應又耗掉一個RTT。因此，粗略地講，總的響應時間就是兩個RTT加上服務器傳輸HTML文件的時間。
????2.2 ?持久連接
????非持久連接有一個缺點。首先，必須為每一個請求的對象建立和維護一個全新的連接。對于每個這樣的連接，在客戶機和服務器都要分配TCP的緩沖區和變量，這給服務器帶來了嚴重的負擔，因為一臺Web服務器可能同時服務于數以百計的客戶機請求。其次，就像我們剛描述的那樣，每一個對象的傳輸時延為兩個RTT，即一個RTT用于建立TCP，另一個RTT用于請求和接收一個對象。
????在持久連接的情況下，服務器在發送響應后保持該TCP連接打開。特別是一個完整的Web頁面（如上例中的基本HTML文件加上10個圖形）可以用單個持久TCP連接進行傳送。更有甚者，位于同一臺服務器的多個Web頁面在從該服務器發送給同一個客戶機時，可以在單個持久TCP連接上進行?？梢栽趩蝹€持久TCP連接上進行。對這些對象的請求可以一個接一個地發出，而不必等待未決請求的回答（流水線）。一般來說，如果一個連接經過一定時間間隔（一個可配置的超時間隔）仍未被使用，HTTP服務器就關閉該連接。HTTP默認模式使用了流水線方式的持久連接。
????3.HTTP報文格式
????HTTP規約包含了對HTTP報文格式的定義。HTTP報文有兩種：請求報文和響應報文。
????3.1 ?HTTP請求報文
????一個典型的HTTP請求報文? ?
| 1 2 3 4 5 | GET?/somedir/page.html?HTTP/1.1 Host:?www.someschool.edu Connection:?close User-agent:?Mozilla/4.0 Accept-language:?fr |
????首先，我們看到該報文是用普通的ASCII文本書寫的，這樣有一定計算機知識的人就能夠閱讀它。其次，我們看到該報文含有5行，每行用一個回車換行符結束，最后一行后跟有附加的回車換行符。該報文只有5行，而實際的請求報文可以有更多的行或僅有一行。HTTP請求報文的第一行叫做請求行(request line)。請求行有三個字段：方法字段、URL字段和HTTP協議版本字段。方法字段可以取值GET、POST、HEAD、和DELETE。絕大部分的HTTP請求報文使用GET方法。當瀏覽器請求一個對象時，使用GET方法，在URL字段填寫該對象的URL地址。在本例中，瀏覽器請求對象/somedir/page.html。其版本字段是自解釋的，在本例中，瀏覽器實現的是HTTP/1.1版本。
????首部行Host:www.someschool.edu定義了目標所在的主機。你也許認為該首部行是不必要的，因為在該主機中已經有一個TCP連接了。但是，該首部行提供的信息是Web代理高速緩存所要求的。通過包含Connection:?colse?首部行，瀏覽器告訴服務器不希望麻煩地使用持久連接，它要求服務器在發送完請求的對象后就關閉連接。User-agent:首部行用來定義用戶代理，即向服務器發送請求瀏覽器的類型。這里瀏覽器的類型是Mozilla/4.0,即Netscape瀏覽器。這個首部行是有用的，因為服務器可以正確地為不同類型的用戶代理實際發送相同對象的不同版本。（每個版本都由相同的URL處理。）最后，Accept-language:首部行表示用戶想得到對象的法語版本（如果服務器中有這樣的對象），否則，使用服務器的默認版本。Accept-language：首部行僅是HTTP中眾多可選內容協商首部之一。
????4.用戶與服務器的交互：cookie
????5.Web緩存
????6.條件GET方法
三、文件傳輸協議：FTP
四、因特網中的電子郵件
五、DNS:因特網的目錄服務
六、P2P應用
七、TCP套接字編程
八、UDP套接字編程
本文轉自yeleven 51CTO博客，原文鏈接:http://blog.51cto.com/11317783/1783253
總結
- 上一篇： 2017-2018-1 20155229
- 下一篇： nginx自定义500、404错误页面