計算機網絡-自頂向下 第二章 應用層

 

2.1 應用層協議原理

研發網絡應用程序的核心是寫出可以運行在不一樣的端系統和經過網絡彼此通訊的程序。

2.1.1網絡應用程序體系結構

應用程序體系結構 主流體系結構：

1. 客戶-服務器結構
2. 對等（P2P）體系結構

 

客戶-服務器結構：有一個老是打開的主機稱爲服務器，它服務來自其餘稱爲客戶的主機的請求(ex: web應用程序）。

• a.在該體系結構中，客戶和客戶之間不會直接通訊。
• b.服務器具備固定的、周知的地址。該地址稱爲IP地址。

具體應用：web ftp telnet 電子郵件

服務器可能存在處理不堪重負。因而配備大量主機的數據中心被用於建立強大的虛擬服務器。

---

P2P結構：應用程序在間斷鏈接的主機對之間使用直接通訊，對數據中心依賴不多。

具體應用：BT 迅雷 Skype IPTV

特性：自擴展性。一個P2P文件共享應用中，儘管每一個對等方都因爲請求文件產生工做量，但每一個對等方經過向其餘對等方分發文件也爲

系統增長服務能力。

---

混合結構應用： 許多即時訊息應用，服務器用於跟蹤用戶IP，但用戶到用戶的報文在用戶主機之間直接發送。

---

2.1.2 進程通訊

1.客戶和服務進程

     在給定的一對進程之間的通訊會話場景中，發起通訊的進程被標識爲客戶，在會話開始時等待聯繫的進程是服務器。

2.進程和計算機網絡之間的藉口

進程經過一個稱謂套接字（socket）的軟件接口向網絡發送報文和從網絡接收報文。

3.進程尋址

在一臺主機上運行的進程爲了向在另外一臺主機上運行的進程發送分組，接收進程須要有一個地址。

爲了標識該接收進程，須要定義兩種信息。

1. 主機的地址  ip
2. 定義在目的主機中的接收進程的標識符  port

---

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

運輸層協議提供的服務要求分類

• 可靠數據傳輸 ：數據無差錯到達接收進程
• 吞吐量
• 定時：控制延遲
• 安全性

---

2.1.4 因特網提供的運輸服務

1.TCP服務

提供兩種服務：

面向鏈接的服務：

可靠的數據傳送服務：

2.UDP服務

UDP是一種不提供沒必要要服務的輕量級運輸協議，它僅提供最小服務。無鏈接、不可靠、亂序、無阻塞控制。

3.因特網運輸協議所不提供的服務

對吞吐量和定時的保證 不禁運輸層協議提供。

---

2.1.5 應用層報文

應用層協議 定義了運行在不用端系統上的應用程序如何相互傳遞報文。特別是應用層定義了：

• 交換的報文類型，例如請求報文和響應報文。
• 各類報文類型的語法，如報文中的各個字段及這些字段是如何描述的。
• 字段的語義，即這些字段中包含的信息的含義。
• 一個進程什麼時候以及如何發送報文，對報文進行響應的規則。

---

2.2 HTTP

2.2.1 HTTP概況

web的應用層協議是超文本傳輸協議（HTTP），HTTP由兩個程序實現：一個客戶端程序，和一個服務器程序。

web頁面是由對象組成。一個對象只是一個文件，如一個HTML文件，一個JPEG圖形，一個Java小程序等。

多數web頁面裏含有一個HTML基本文件（base HTML file）以及幾個引用對象。

HTML基本文件經過對象的URL地址引用頁面中的其餘對象。

每一個URL地址由兩部分組成：存放對象的服務器主機名和對象的路徑名。例如：www.example.com/default/1.gif

www.example.com 是主機名，/default/1.gif爲路徑名。

web瀏覽器實現了HTTP的客戶端，web服務器實現了HTTP的服務器端，用於存儲web對象，每一個對象由URL尋址。

服務器向客戶發送被請求的文件，而不存儲任何關於該客戶的狀態信息。因此咱們稱HTTP是一個無狀態的協議。

 

2.2.2  非持續鏈接和持續鏈接

每一個請求/響應都是一個單獨的TCP鏈接發送，非持續鏈接。

全部的請求/響應通過相同的TCP鏈接發送，持續鏈接。

 

2.2.3  HTTP報文格式

2.2.3.1 HTTP請求報文

 

GET /index.html HTTP/1.1       

Host: www.test.com                

Connection: close

User-agent: Mozilla/5.0

Accept-language: f r

 

第一行爲請求行：  方法字段、URL字段、HTTP版本字段。後續均爲首部行

首部行：Host:www.test.com    指明主機地址。該首部行提供的信息是Web代理告訴緩存所要求的。

Connection:close ,該瀏覽器告訴服務器不但願麻煩的使用持續鏈接，它要求服務器在發送完被請求的對象後就關閉這條鏈接。

User-agent 首部行指明用戶代理，即向服務器發送請求的瀏覽器的類型。上述例子中爲Firefox瀏覽器。服務器能夠根據不一樣類型的用戶代理髮送相同對象的不一樣版本。

Accept-language 首部行指明用戶想獲得該對象的法語版本。

 

2.2.3.2 HTTP響應報文

HTTP/1.1 200 OK

Connection: close

Date: Tue, 09 Aug 2011 15:44:04 GMT

Server： Apache/2.3.3 (Centos)

Last-Modified: Tue, 09 Aug 2011 1511:03 GMT

Content-Length: 6821

Content-Type: text/html

 

(data date date....)

第一行初始狀態行，6個首部行，而後是實體體，請求對象的實體。

狀態行有3個字段：協議版本字段、狀態碼和相應的信息。

首部行：

服務器用Connection:close 首部行告訴客戶，發送完報文後將關閉TCP鏈接。

Date：首部行指示服務器產生併發送該響應報文的日誌和時間，特指服務器從它的文件系統中檢索到該對象，插入到響應報文，併發送該響應報文的時間。

Server:l相似請求報文中的User-agent字段.

Last-Modified: 指示對象建立或者最後修改的日期和時間。

Content-Length：被髮送的對象中的字節數。

Content-Type：實體體中的對象是HTML文件。

 

2.2.4 用戶與服務器的交互：cookie

Web站點但願可以識別用戶，多是由於服務器但願限制用戶的訪問，或者由於它但願把內容與用戶身份聯繫起來，爲此使用cookie.

cookie技術有四個組件：

1. 在HTTP響應報文中的一個cookie首部行
2. 在HTTP請求報文中的一個cookie首部行
3. 在用戶端系統中保留有一個cookie文件，並由用戶的瀏覽器進行管理
4. 位於web站點的一個後端數據庫

cookie能夠標識一個用戶，用戶首次訪問一個站點的時候可能須要提供一個用戶標識，在後續的會話中，瀏覽器向服務器傳遞一個cookie首部，從而

向服務器標識了用戶。所以cookie能夠在無狀態的HTTP之上創建一個用戶會話層。

 

2.2.5 Web緩存

Web緩存 也稱爲代理服務器，它能表明初始的Web服務器來知足HTTP請求的網絡實體。Web緩存器有本身的磁盤存儲空間，而且在存儲空間中保存最近請求過的對象的副本。

 

2.2.6 條件get

引入高速緩存有相應的問題，即存放在緩存器中的對象副本多是陳舊的，可能已經被修改了。

HTTP協議有機制，容許緩存器證明它的對象是最新的，條件get方法。

若是請求報文是get方法，請求報文包含一個「if-Midified-Since:」 首部行，則該報文爲條件GET報文。

瀏覽器-> 緩存器->服務器-> 緩存器->瀏覽器

第一次交互過程當中服務器給緩存器的響應報文中含有Last-Modified。

第二次交互 緩存器把該值做爲 if-Midified-Since的值發給服務器，用來時間來判斷當前緩存是否能夠繼續使用。

 

2.3 FTP

 

用戶經過一個FTP代理與FTP交互。該用戶首先提供一個遠程主機的主機名，使本地主機的FTP客戶進程創建一個到

遠程主機FTP服務器進程的TCP鏈接。該用戶接着提供用戶標識和口令，做爲FTP命令的一部分在該TCP鏈接上傳送。

一旦該服務器向該用戶受權，用戶能夠將存放在本地文件系統中的一個或者多個文件複製到遠程文件系統（反之亦然）。

FTP使用兩個並行的TCP鏈接來傳輸文件，一個是控制鏈接，一個是數據鏈接。

控制鏈接用於在兩主機間傳輸控制信息，如用戶標識、口令、改變遠程目錄的命令以及get 、put命令。

數據鏈接用於實際發送一個文件。

當用戶主機與遠程主機開始一個FTP會話時，FTP的客戶端首先會在服務器21號端口與服務器端發起一個用於控制的TCP鏈接。

FTP的客戶端也經過該控制鏈接發送用戶的標識和口令，發送改變遠程目錄的命令。當FTP的服務器端從該鏈接上收到一個文件傳輸的

命令後，就發起一個到客戶端的TCP數據鏈接。FTP在該數據鏈接上準確的傳送一個文件，而後關閉該鏈接。在同一個會話期間，

若是用戶還須要傳輸另外一個文件，FTP則打開另外一個數據鏈接。

FTP服務器必須在整個會話期間保留用戶的狀態。

 

2.4 郵件協議（暫時跳過）

 

2.5 DNS：英特網的目錄服務