[计算机网络]应用层协议,HTTP,SMTP,DNS
應用層
應用層協議原理
網絡應用程序體系結構
規定如何在各種端系統上組織應用程序,由研發者設計
客戶機/服務器
服務器:對外提供服務的一系列硬件和軟件
客戶機:使用服務器提供的服務
服務器
- 7*24小時提供服務
- 永久性訪問地址/域名
- 利用大量服務器實現可擴展性
客戶機
- 與服務器通信,使用服務器提供的服務
- 間歇性接入網絡
- 可能使用動態IP地址
- 不會與其他客戶機直接通信
P2P
常見:文件分發,因特網電話
- 無或最少打開的服務器
- 任意端系統/節點之間可以直接通訊
- 節點間歇性接入網絡
- 節點可能改變IP地址
-
優點:高度可伸縮
-
缺點:難于管理
混合結構
Napster
-
文件傳輸使用P2P結構
-
文件的搜索采用C/S結構——集中式
-
每個節點向中央服務器登記自己的內容
-
每個節點向中央服務器提交查詢請求,
查找感興趣的內容
網絡進程通信
*進程(process):*主機上運行的程序
同一個主機上運行的進程通信方式:
- 進程間的通信機制
- 操作系統提供
不同主機上運行的進程間通信方式:
- 消息交換
客戶機進程:發起通信的進程
服務器進程:等待通信請求的進程
Socket(套接字)
Socket=(IP地址:端口號)
同一臺主機內應用層與運輸層之間的接口。
也叫應用程序和網絡之間的應用程序接口API ,是在網絡上建立網絡應用程序的可編程接口。
類似于寄信
- 發送方將消息送到門外郵箱
- 發送方依賴(門外的)傳輸基礎設施將消息傳到接收方所在主機,并送到接收方的門外
- 接收方從門外獲取消息
傳輸基礎設施向進程提供API
- 傳輸協議的選擇
- 參數的設置
進程尋址
根據進程識別信息找到對應進程
不同主機上的進程間通信,每個進程必須擁有標識符
-
使用IP地址尋址主機
-
使用端口號Port
為每個主機上需要通信的進程分配一個端口號
HTTP Server:80
Mail Server:25
-
進程的標識符
IP地址+端口號 用于唯一標識一個網絡上的進程
用戶代理(user agent)
是用戶與網絡應用程序之間的接口。
如:
Web應用的用戶代理:是一些瀏覽器軟件。
一個通過套接字收發報文,并提供用戶接口的進程。
電子郵件應用程序用戶代理:是“郵件閱讀器”。
允許用戶進行郵件的撰寫和閱讀。
應用層協議
定義運行在不同端系統上的應用程序進程間傳遞報文的格式和方式。
公開協議
- 由RFC(Request For Comments)定義
- 允許互操作
- HTTP, SMTP, ……
私有協議
- 多數P2P文件共享應用
內容
-
消息的類型(type)
請求響應
響應消息
-
消息的語法(syntax)/格式
消息中具有的字段(field)
每個字段的描述
-
字段的語義(semantics)
字段中信息的含義
-
規則(rules)
進程何時發送/響應消息
進程如何發送/響應消息
網絡應用的需求與傳輸層服務
要求
-
某些網絡應用能夠容忍一定的數據丟失:網絡電話
-
某些網絡應用要求100%可靠的數據傳輸:文件傳輸,telnet
- 有些應用只有在延遲足夠低時才“有效”
- 網絡電話/網絡游戲
- 某些應用只有在帶寬達到最低要求時才“有效”:網絡視頻
- 某些應用能夠適應任何帶寬——彈性應用:email
Internet提供的傳輸服務
| 面向連接 | 劃分三階段 建立連接(握手過程): 客戶機程序和服務器程序之間互相交換控制信息,在兩個進程的套接字之間建立一個TCP連接。 *傳輸報文:*連接是全雙工的,即連接雙方的進程可以在此連接上同時進行報文收發。 拆除連接: 應用程序報文發送結束。 | 無連接 | |
| 可靠的傳輸 | 通信進程可以無差錯,按適當順序交付發送的數據。無數據丟失和重復 | 不可靠的傳輸服務 | 不保證報文能夠被接收,或收到的報文是亂序到達。 |
| 流量控制 | 發送方不會發送速度過快,超過接收方的處理能力 | 沒有擁塞控制機制 | 發送進程可以任何速率發送數據 |
| 擁塞控制 | 當網絡負載過重時能夠限制發送方的發送速度 | 不提供時延保證 | |
| 無時間/延遲保障 | 數據傳輸的時間不確定。 | ||
| 不提供最小帶寬保障 | 發送進程受擁塞控制機制制約。 | ||
| 特點 | TCP協議能保證交付所有的數據,但并不保證這些數據傳輸的速率以及期待的傳輸時延。 | 適于實時應用。 |
Web和HTTP
World Wide Web:Tim Berners - Lee
網頁且網頁相互連接
Web Page 包含多個對象(objects)
- 對象:HTML文件,JPEG圖片,視頻文件,動態腳本
- 基本HTML文件:包含對其他對象引用的連接
對象的尋址(addressing)
-
URL(Uniform Resoure Locator):統一資源定位器
-
Scheme://host:port/path
格式記牢
HTTP協議
基本概念
超文本傳輸協議 HyperText Transfer Protocol
無狀態(stateless)
服務器不維護任何有關客戶端過去所發請求的信息
C/S結構
- 瀏覽器(客戶機):是Web應用的用戶代理。
- 用于顯示所請求的Web頁,提供導航功能和配置屬性。
- 實現了HTTP協議的客戶機端。
- Web服務器:用于存貯Web對象(由URL尋址)
- 實現HTTP協議的服務器端。
有狀態協議更復雜:
傳輸層協議
使用TCP傳輸服務
- 服務器在80端口等待客戶的請求
- 瀏覽器發起到服務器的TCP連接(創建套接字Socket)
- 服務器接受來自瀏覽器的TCP連接
- 瀏覽器(HTTP客戶端)與Web服務器(HTTP服務器)交換HTTP消息
- 關閉TCP連接
HTTP連接
類型
- 每個TCP連接最多允許傳輸一個對象
- HTTP 1.0版本使用非持久性連接
- 每個TCP連接允許傳輸多個對象
- HTTP 1.1版本默認使用持久性連接
非持久性連接工作過程
響應時間分析與建模
-
RTT(Round Trip Time)
客戶端發送一個很小的數據包到服務器并返回所經歷的時間
-
響應時間(Respone time)
- 發起、建立TCP連接:1個RTT
- 發送HTTP請求消息到HTTP響應消息的前幾個字節到達:1個RTT
- 響應消息中所含的文件/對象傳輸時間
Total = 2RTT + 文件發送時間
非持久性連接問題
| *每一個對象的傳輸時延長:*每個對象需要2個RTT | 發送響應后,服務器保持TCP連接的打開 | HTTP 1.1的默認選項 |
| *服務器負擔重:*操作系統需要為每個TCP連接開銷資源(overhead) | 后續的HTTP消息可以通過這個連接發送 | 客戶端只要遇到一個引用對象就盡快發出請求 |
| 理想情況下,收到所有的引用對象只需耗時約1個RTT | ||
| 瀏覽器做法 | 無流水(pipelining)的持久性連接 | |
| 打開多個并行的TCP連接以獲取網頁所需對象 | 客戶端只有收到前一個響應后才發送新的請求 | |
| 每個被引用的對象耗時1個RTT |
HTTP消息格式
HTTP中的方法
| GET | 請求一個對象。實體主體為空。 | GET,POST,HEAD | |
| POST | 將實體信息交給服務器,用于提交表單 | PUT | 向服務器URL指定的路徑上載實體中的文件。 |
| HEAD | 請Server不要將所有請求的對象放入響應消息中 | DELETE | 刪除服務器URL指定的文件。 |
請求消息(request)
ASCII:人直接可讀
要考
上傳輸入的方法
- 網頁經常需要填寫表格(form)
- 在請求消息的消息體(entity body)中上傳客戶端的輸入
- 使用GET方法
- 輸入信息通過request行的URL字段上傳
響應消息(response)
-
200 OK
-
301 Moved Permanently
-
400 Bad Request
-
404 Not Found
-
505 HTTP Version Not Supported
Cookie技術
HTTP協議無狀態
很多應用需要服務器掌握客戶端的狀態
某些網站為了辨別用戶身份、進行session跟蹤而儲存在用戶本地終端上的數據(通常經過加密)。
Cookie組件
- HTTP響應消息的cookie頭部行
- HTTP請求消息的cookie頭部行
- 保存在客戶端主機的cookie文件,由瀏覽器管理
- Web服務器的后臺數據庫
Cookie原理
Cookie使用范圍
- 身份認證
- 購物車
- 推薦
- Web e-mail
隱私問題
Web緩存/代理服務器技術
目標:在不訪問服務器的前提下滿足客戶端的HTTP請求
Web緩存器(Web cache):也叫代理服務器。
代表起始服務器來滿足HTTP請求的網絡實體。
-
保存最近請求過的對象的副本。
-
可在客戶機或服務器工作,也可在中間系統工作。
起始(原始)服務器(origin server):對象最初存放并始終保持其拷貝的服務器。
作用
- 縮短客戶請求的響應時間
- 減少機構/組織的流量
- 在大范圍內(Internet)實現有效的內容分發 CDN(內容分發網絡)
組成
Web緩存/代理服務器
-
用戶設定瀏覽器通過緩存進行Web訪問
-
瀏覽器向緩存/代理服務器發送所有的HTTP請求
如果所請求對象在緩存中,緩存返回對象
否則,緩存服務器向原始服務器發送HTTP請求,獲取對象,然后返回給客戶端并保存該對象
-
緩存既充當客戶端,也充當服務器
-
一般由ISP架設
優缺點
減少機構內部網絡與因特網連接鏈路上的通信量:
降低開銷,改善各種應用的性能。
FTP
本地主機上的用戶,向遠程主機上傳或者下載文件。
文件傳送協議FTP:用于從一臺主機到另一臺主機傳送文件的協議。
用戶通過一個FTP用戶代理與FTP服務器交互。
文件傳輸過程
建立TCP連接:用戶提供遠程主機的主機名或者IP地址。在FTP客戶機進程與FTP服務器進程之間建立。
身份認證:輸入用戶名和口令。向FTP服務器傳送。
服務器驗證成功:進行文件傳送(雙向)
將本地文件系統中的文件傳送到遠程文件系統(上傳)
或從遠程文件系統中得到文件(下載)
控制連接與數據連接
控制連接
作用:用于在兩主機間傳輸控制信息。如用戶名、口令;上載或下載文件命令等。
控制連接由客戶先發起,建立后一直保持:
FTP會話開始前,FTP的客戶機與服務器在21號端口上建立。
FTP的客戶機通過該連接發送用戶名和口令,或改變遠程目錄命令、上載或下載文件命令。
數據連接
作用:用于準確傳輸文件。
服務器收到一個文件傳輸的命令:上載或下載
在20端口建立一個到客戶機的數據連接。
在該數據連接上傳送一個文件并關閉連接
每個數據連接只傳一個文件,每個文件都要建立和釋放數據連接。
控制連接與數據連接差異
FTP與HTTP比較
| 控制信息 | 帶外傳送(out-of-band) | 使用分離的控制連接。 | 帶內傳輸(in-band) | 請求和響應都是在傳輸文件的TCP連接中發送。 |
| 狀態 | 有狀態 | FTP服務器對每個活動用戶會話的狀態進行追蹤,并保留;限制同時會話的總數。 | 無狀態 | 不對用戶狀態進行追蹤 |
Email應用
電子郵件快速、多方接收,包含附件、超鏈接、圖像、聲音、視頻等。
電子郵件系統總體結構
用戶代理(user agent)
郵件閱讀器。允許用戶閱讀、回復、發送、保存和撰寫報文。
- 發郵件:郵件代理向其郵件服務器發送郵件,并存放在發送隊列中。
- 收郵件:郵件代理從其郵件服務器的郵箱中獲取該報文。
郵件服務器(mail server)
郵箱:發送給用戶的報文。
報文隊列:用戶要發出的郵件報文。
郵件發送主要過程:
郵件保存到發送方輸出報文隊列
通過SMTP協議轉發到接收方郵件服務器,保存到相應郵箱中
若投遞失敗仍保存,以后每30分鐘發送一次,若幾天后仍未成功,將該報文刪除,并通知發送方。
用戶訪問自己郵箱時,郵件服務器對其身份進行驗證(用戶名和口令)
SMTP
簡單郵件傳送協議
從發送方的郵件服務器向接收方的郵件服務器發送郵件。
每個郵件服務器上都有SMTP的客戶機端和服務器端。
應用層協議。
使用TCP可靠數據傳輸服務。
包括兩部分:
客戶機端:在發送方郵件服務器上運行;
服務器端:在接收方郵件服務器上運行。
SMTP
SMTP過程
說明
客戶使用TCP來可靠傳輸郵件報文到服務器端口號25
建立TCP連接
握手:指明收發雙方的郵件地址
郵件報文的傳送
結束:關閉TCP連接
SMTP不使用中間郵件服務器發送郵件,TCP連接是發送方到接收方的直接連接
若接收方的郵件服務器未開機,該郵件仍然保存在發送方的郵件服務器上,并在關機后進行再次傳送
郵件不會在某個中間郵件服務器上停留
SMTP和HTTP比較
| 相同點 | 都從一臺主機向另一臺主機傳送文件 | 從Web服務器想Web客戶機(瀏覽器)傳送文件(對象) | 從一個郵件服務器向另一個服郵件服務器傳送文件(電子郵件報文) |
| 都使用持久連接 | |||
| 不同點 | 拉協議; | 推協議; | |
| 用戶使用HTTP協議從服務器 拉取信息。 | 發送郵件服務器吧文件推向接受有加你服務器; | ||
| TCP連接由想獲取文件的機器發起 | TCP連接是由 要發送文件的機器發起 | ||
| 數據傳送方式 | 無限制 | 使用7位ASCII碼格式;對包含非7位ASCII字符的報文或二進制數據(如圖片、聲音),需要按照7位ASCII碼進行編碼(MIME實現) ,再傳送。在接收方需要解碼還原為原有報文。 | |
| 對含有文本和圖形 (或其他媒體類型)的文檔: | 把每個對象封裝在它各自的HTTP響應報文中發送。 | 所有報文對象放在一個報文中。 |
郵件報文格式和MIME
郵件報文格式
MIME
多用途因特網郵件擴展
用于非ASCII數據傳輸
STMP:
MIME:
附加MIME郵件首部
說明采用何種編碼
MIME是SMTP的一個擴展,不能替代SMTP
MIME首部
Content-Transfer-Encoding:告訴接收用戶代理,該報文主體采用了ASCII碼及相應編碼類型,并以此還原成非ASCII碼。
常用編碼:
- base64編碼:將二進制文件轉換為ASCII碼格式。
- 可打印內容轉換編碼:將一個8位ASCII報文轉換為7位ASCII碼格式。
Content-Type:告訴接收用戶代理報文類型及應采取的動作。
如jpeg:要對jpeg文件解壓縮。
郵件訪問協議
用戶代理從接收方郵件服務器上讀取郵件。
起效過程
發送方:
- 用戶代理用SMTP將郵件推入其郵件服務器
- 郵件服務器用SMTP將郵件轉發到接收方的郵件服務器
接收方:
-
通過其用戶代理使用一個郵件訪問協議,從其郵件服務器上取回郵件。
取郵件是一個拉操作,而SMTP協議是一個推協議。
POP3
第三版郵局協議
簡單,功能有限
讀取郵件過程:
-
建立TCP連接:服務器通過110端口偵聽TCP請求,與客戶機建立TCP連接。
-
開始POP3會話讀取郵件,分為3個步驟。
*特許階段:*用戶代理發送用戶名和口令獲得下載郵件的特許。(身份認證)
*事務處理階段:*用戶代理取回報文,可對郵件進行某些操作。
? 如:下載并保留,下載并刪除等。
更新階段:郵件服務器刪除帶有刪除標記的報文,結束POP會話。
IMAP
因特網郵件訪問協議
功能強
-
在用戶機上運行IMAP客戶程序,并與郵件服務器上的IMAP服務器程序建立TCP連接。
-
用戶在自己的PC機上就可以操作郵件服務器的郵箱,就如同本地操縱一樣,是一個聯機協議。
如:建立文件夾,查詢,移動郵件等。
-
未發出刪除命令前,一直保存在郵件服務器。
-
實現復雜
基于Web的電子郵件
用戶使用瀏覽器收發電子郵件。
1995年12月Hotmail 引入該技術。
-
用戶代理是普通的瀏覽器,用戶和其遠程郵箱之間的通信通過HTTP進行:
發件人使用HTTP 將電子郵件報文從其瀏覽器發送到其郵件服務器上。
收件人使用HTTP從其郵箱中取一個報文到瀏覽器。
-
郵件服務之間發送和接收郵件時,使用SMTP
-
用戶可以再遠程服務器上以層次目錄方式組織報文。
DNS
域名系統(Domain Name System):進程主機名到IP地址的轉換。
DNS
- 一個分層的DNS服務器實現的分布式數據庫
- 允許主機查詢分布式數據庫的應用層協議
- 采用C/S方式
名詞
| DNS協議 | 運行在UDP之上,使用53號端口 |
| DNS | 直接由其他的應用層協議 (包括HTTP、SMTP 和FTP)使用,以將用戶提供的主機名解析為IP地址。 |
| 用戶只是間接使用 |
標識主機方式
標識主機的兩種方式:
報文在網絡中傳輸,使用IP地址。
| 由不定長的字母和數字組成。 | 由4個字節組成,有嚴格的層次結構 |
| 便于記憶。路由器處理困難。 | 路由器容易處理。 |
域名解析過程
用戶主機上運行DNS客戶機端。
瀏覽器從URL中解析出主機地址,傳給DNS客戶機端
DNS客戶機向DNS服務器發送一個包含主機名的請求
DNS客戶機收到含有對應主機名的IP地址的回答報文
瀏覽器向該IP地址指定的HTTP服務器發起一個TCP連接。
1234稱為域名解析
增加一定時延
DNS服務
主機名到IP地址的轉換
主機別名和規范名的轉換:通過DNS可以得到主機別名對應的規范主機名和IP地址
規范名:主機真正的名字。如host1.njust.edu.cn
別名:主機上運行的某種應用服務。如 www.njust.edu.cn 表示Web服務器
同一臺主機可運行多個應用,多個別名與一臺主機聯系。如 ftp.njust.edu.cn 表示FTP服務器
郵件服務器別名和規范名轉換
負載均衡:Web服務器
DNS查詢方式
迭代查詢
被查詢服務器返回域名解析服務器的名字,逐個查找。
請求主機向本地DNS服務器發送請求,向連接的DNS服務器查找所需要的IP地址,沒有則返回本地域名服務器,再向其他DNS服務器發出請求
遞歸查詢
請求主機向本地DNS服務器發送請求,若沒有則直接向其他域名服務器發出請求直到查找到依次返回到本地DNS服務器,最終響應請求。
P2P應用
位于網絡邊緣的PC機(對等方peer)互相之間可以直接獲取對象
P2P文件分發
從單個源向大量對等方分發文件
C/S與P2P對比
| 服務器向每個對等方發送該文件的副本,負擔重。 | 每個對等方都能夠重新分發其所有文件的任何部分,協助服務器分發。 |
| 當一個對等方收到文件數據時,用其上載能力重新將數據分發給其他對等方。下載同時上載 |
BT協議
BitTorrent協議
Torrent:洪流。參與一個特定文件分發的所有對等方的集合。
- 一個洪流中,對等方彼此下載等長度的文件塊。
- 一個對等方最初加入到洪流時,沒有文件塊,之后累積越來越多。
- 下載文件塊同時,也為其他Torrent上載文件塊。
- 對等方可以在獲得整個文件后離開,也可以留下,繼續提供上載。
- 對等方可以任何時候加入到洪流或離開。
tracker追蹤器
跟蹤洪流中的對等方
交換原理
-
一個新對等方加入洪流時,追蹤器從中隨機選擇一些對等方,并發送含有IP地址的對等方列表給新加入的對等方。
-
新對等方依次與列表中的對等方建立TCP連接,連接成功即獲取相關文件塊;
-
可以從多個對等方獲取文件的各個塊;
-
下載完成后,組裝還原為一個完整的文件。
P2P文件共享
對等方之間共享文件
每個參與的對等方既是內容的消費者也是內容的發布者(下載同時也向其他用戶上載)
集中式目錄(索引)
源于Napster公司(第一家世界范圍內從事MP3對等應用程序)設計。
目錄服務器(大型服務器或服務器場):提供目錄服務。
收集可共享的對象,建立集中式的動態數據庫(對象名稱到IP地址的映射)。
屬于客戶機/服務器與P2P的混合結構。
工作
- 通知:對等方啟動時,將其IP地址及可共享內容通知目錄服務器。
- 查詢內容:用戶查詢需要共享的對象,獲得列表。
如 Alice 查詢某首歌。 - 獲取內容:來自Bob。
- 更新:當對等方獲得新對象或刪除對象時,通知目錄服務器更新。
問題
查詢洪泛
建立在Gnutella協議基礎上:一個公共域文件共享應用程序協議。
全分布方式:無中心服務器。
許多Gnutella客戶機實現協議:運行在對等方。
對等方X加入方法
實現
對等方先形成一個抽象的邏輯網絡(覆蓋網絡)
通過洪泛查詢,找到所需對象:
如,某個對等方Alice想得到一個對象。
特點
- 設計簡單。
- 擴展性差。
- “查詢報文”在網絡中產生很大的流量。
限范圍的洪泛查詢:
-
在“查詢報文”中設置一個對等方計數字段,并給定一個特定值。
-
可能減少對等方數量。
層次覆蓋
與Gnutella類似,*無專用服務器,但對等方地位不平等。*如KaZaA。
實現
- 對等方先形成一個層次的覆蓋網絡
- 通過查詢,找到所需對象。
對等方根據通信關系劃分若干組,組成層次結構。
每組包括若干組員,一個組長
組長追蹤其所有子節點上的內容
- 組員與其組長有一個TCP連接,將共享內容告訴組長。
- 組長維護一個數據庫,包括該組的共享內容及相關對等方的IP地址。
- 相關組長之間建立TCP連接
查詢定位
對等方確定某個特定對象。
- 向組長發出查詢:組長用本組中含有該對象的對等方列表響應;
- 或與其他組長聯系:請它們向該對等方發送含有該對象的對等方列表。
特點
- 層次覆蓋網絡
- 查詢流量不大
- 設計技巧
請求排隊:限制并行上載數量
激勵優先權:上載文件比下載文件多的用戶優先
并行下載:從多個對等方請求并下載同一個文件的不同部分。
P2P因特網電話
應用廣泛
提供PC到PC、PC到電話、電話到PC電話服務
PC 到PC視頻會議服務。
屬于即時通訊IM(Instant Messaging)
采用混合模式
集中式和分布式結合。
- 邊緣節點(普通節點SC)和超級節點SN之間采用集中式結構
- 超級節點之間采用分布式的結構
- 注冊服務器:負責客戶端注冊。存儲用戶名、密碼。登錄時身份認證。
總結
以上是生活随笔為你收集整理的[计算机网络]应用层协议,HTTP,SMTP,DNS的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Beam Search的学习笔记(附代码
- 下一篇: 基于EasyExcel模板填充方式进行二