計算機網絡學習（二） 網絡應用（應用層）Ⅰ

正在學習計算機網絡課程，以下是學習《計算機網絡-自頂向下方法》的一些筆記，部分圖片來自mooc網 哈爾濱工業大學 計算機網絡課程：https://www.icourse163.org/course/HIT-154005。

1.網絡應用的基本原理

1.1網絡應用的體系結構

• 客戶機/服務器結構（Client / Server）
  • 服務器：永久性訪問地址和域名；利用大量服務器實現可擴展性；7*24小時提供服務
  • 客戶機：與服務器通信，使用服務器提供的服務；間歇性接入網絡；可能是有動態IP地址；不會與其他客戶機直接通信
• 點對點結構（Peer-to-Peer，P2P）
  • 沒有永遠在線的服務器
  • 任意端系統/節點之間可直接通信
  • 節點間歇性接入網絡
  • 節點可能改變IP地址
• 混合結構（Hybrid）

1.2網絡應用的進程通信

• 同一主機上的不同進程如何通信？：由操作系統負責調度，遵循進程間通信機制
• 不同主機上運行的進程如何通信？：消息交換/報文交換
• 進程間通信使用Socket套接字進行接收/發送消息，是操作系統提供的網絡編程的API，過程類似與日常生活中的寄信。
  
• 進程間通信要依賴消息交換，那底層的基礎設施如何進行尋址的呢？（進程的標識符：IP地址 + 端口號）
  • IP地址唯一標識主機；
  • 端口號（Port Number）標識主機上的不同進程：HTTP Server 80，Mail Server 25…
• 消息交換的格式、順序等規則？
  • 網絡應用需要遵循應用層協議
    • 公開協議，如HTTP、SMTP…，由RFC：Request For Comments定義，只要遵循這個協議，就允許相互操作訪問
    • 當然也有一些私有協議
  • 應用層協議的內容
    • 消息的類型：請求消息、相應信息
    • 消息的語法格式：要包含哪些字段、字段如何描述
    • 字段的語義：字段中信息的含義
    • 規則：進程何時發送/響應消息、進程如何發送/響應消息

1.3網絡應用的需求

• 網絡應用對傳輸服務 的需求：
• Internet 提供的傳輸服務

2.Web應用

2.1 Web應用概述

• 網頁（Web Page）包含多個對象：HTML文件、JPEG圖片、視頻文件、動態腳本等
• 對象的尋址：統一資源定位符（URL，Uniform Resource Locator）
  • Scheme : // host : port / path
• 萬維網Web應用遵循的協議：超文本傳輸協議（HTTP，HyperText Transfer Protocol）
  • 該協議採用C/S架構
  • 客戶 Browser：請求、接收、展示Web對象
  • 服務器 Server：響應客戶的請求，發送對象
  • HTTP版本：
    • 1.0：RFC 1945；
    • 1.1：RFC 2068
• HTTP應用層協議採用的傳輸層協議：TCP
  1. 服務器在80端口等待
  2. 瀏覽器發起到服務器的TCP連接（創建套接字Socket）
  3. 服務器接受來自瀏覽器的TCP連接
  4. 瀏覽器與服務器交換HTTP消息
  5. 關閉TCP連接
• 服務器不維護任何有關客戶端過去所發請求的消息：HTTP是一個無狀態（stateless）協議

2.2HTTP連接類型

• 非持久性連接（Nonpersistent HTTP）
  • 每個TCP連接最多允許傳輸一個對象
  • HTTP 1.0 版本使用
• 持久性連接（Persistent HTTP）
  • 每個TCP連接允許傳輸多個對象
  • HTTP 1.1 版本使用
• RTT（Round Trip Time）：從客戶端發送一個小的數據包到服務器並返回所經歷的時間
• 非持久性連接獲得一個對象的時間：Total = 2*RTT+文件發送時間。太慢！開銷資源太多。改進：採用持久性連接。
  
• 持久性連接
  • 無流水的持久性連接：客戶端只有收到前一個響應後才發送新的請求，獲得每個被引用的對象需要一個RTT
  • 流水機制的持久性連接：HTTP 1.1默認選項，客戶端只要遇到一個應用對象就儘快發出請求，理想情況下收到所有引用對象只需要耗時1個RTT

2.3 HTTP消息格式

• 兩類消息：請求消息、響應消息，由ASCII碼寫，人類直接可讀，
• 請求消息：
  • method類型：
    • HTTP 1.0： GET、POST、HEAD（請Server不要將所請求的對象放入響應消息中，一般做測試用）
    • HTTP 1.1：GET、POST、HEAD、PUT（把消息體裏的文件上傳到URL字段所指定的路徑） 、DELETE（刪除URL字段所指定的文件）
• 響應消息：
  • HTTP響應狀態代碼（位於響應消息的第一行）
    • 100-199 用於指定客戶端應相應的某些動作（提示信息）
    • 200-299 用於表示請求成功 eg：200 OK
    • 300-399 用於已經移動的文件並且常被包含在定位頭信息中指定新的地址信息 （重定向）eg：301 Move Permanently
    • 400-499 用於指出客戶端的錯誤 eg：400 Bad Request（請求出現語法錯誤）、404 Not Found
    • 500-599 用於指出服務器段的錯誤 eg：505 HTTP Version Not Supported 服務器不支持請求中所指明的HTTP版本

2.4 Cookie技術

前面提到了 HTTP 服務器是無狀態的。 這簡化了服務器的設計，並且允許工程們去開發可以同時處理數以千計的 TCP 連接的高性能 Web 服務器。 然而一個 Web 站點通常希望能夠識別用戶，比如網上購物裏的購物車。
爲此.，HTTP 使用了 cookie技術，它允許站點對用戶進行眼蹤， 目前大多數商務 Web 站點都使用了 cookie。

• cookie技術有四個組件：
  1. 在 HTTP 響應報文中的一個 cookie 首部行
  2. 在 HTTP 請求報文中的一個 cookie 首部行
  3. 在用戶端系統中保留有一個 cookie 文件，並由用戶的瀏覽器進行管理
  4. 位於 Web 站點的一個後端數據庫
• cookie技術的場景：
  • 身份認證
  • 購物車
  • 推薦
  • web Email
• 存在隱私問題

2.5 Web 緩存（Web Cache）/代理服務器（proxy server）技術

• 功能：在不訪問服務器的前提下滿足客戶端的HTTP請求
• 爲什麼發明這項技術？——從性能上考慮
  • 縮短客戶請求的響應時間
  • 減少機構、組織的流量
  • 在大範圍內（Internet）實現有效的內容分發
• 假設瀏覽器正在請求對象 ：
  • 瀏覽器建立一個到 Web 緩存器的 TCP 連接，並向 Web 緩存器中的對象發送一個 HTTP 請求。
  • Web 緩存器進行檢查，看看本地是否存儲了該對象副本。 如果有， Web 緩存器就向客戶瀏覽器用 HTTP 響應報文返回該對象。
  • 如果 Web緩存器中沒有該對象，它就打開一個與該對象的初始服務器的TCP 連接，發送請求，獲取對象，返回給客戶端並將該對象保存在本地
• 緩存既充當客戶端也充當服務器
• 一般由ISP（Internet服務提供商）架設。 例如， 一所大學可能在它的校園網上安裝一臺緩存器，並且將所有校園網上的用戶瀏覽器配置爲指向它。
• 條件GET方法：高速緩存能減少用戶感受到的響應時間，但也引人了一個新的問題，即存放在緩存器中的對象副本可能是陳舊的。換句話說，保存在服務器中的對象自該副本緩存在客戶上以後可能已經被修改了。
  • 解決： HTTP協議有一種機制，允許緩存器證實它的對象是最新的。 這種機制就是條件 GET (conditional GET) 方法
  • 具體：①請求報文使用 GET 方法;並且②請求報文中包 含一個"If-Modified -Since : "首部行。那麼，這個 HTTP 請求報文就是一個條件GET 請求報文。
  • 若緩存中的對象是最新的 ，則服務器的響應消息中不包含對象，在響應報文中，狀態行中爲 304 Not Modified，它告訴緩存器可以使用該對象，能向請求的瀏覽器轉發該對象副本。

3.Email應用

3.1 Email應用概述

• Email應用的構成組件：
  • 郵件代理（user agent）
  • 郵件服務器（mail server）
    • 郵箱（mailbox）：管理和存儲着發送給用戶的報文。
    • 報文隊列( message queue)：存儲等待發送的Email，通常每 30 分鐘左右嘗試一次發送；如果幾天後仍不能成功，服務器就刪除該報文並以電子郵件的形式通知發送方
  • SMTP協議（Simple Mail Transfer Protocol）
    • 使用TCP進行Email的可靠傳輸
    • 端口25
    • 握手——消息傳輸——關閉
    • 採用命令/響應交互模式（HTTP採用請求/響應）
    • SMTP 一般不使用中間郵件服務器發送郵件，即使這兩個 郵件服務器位於地球的兩端也是這樣。
• 例子：
  1. 發送方 Alice 發電子郵件給接收方 Bob
  2. 當Alice 完成郵件撰寫時，她的郵件代理向其郵件服務器發送郵件，此時郵件放在郵件服務器的外出報文隊列中。
  3. 發送方Alice的郵件服務器將郵件傳輸到接收方Bob的郵件服務器，然後在這裏被分發到接收方Bob的郵箱中。
  4. 典型的異步交互
• SMTP與HTTP的比較：
  • 都用於從一臺主機向另一臺主機傳送文件。
  • 當進行文件傳送時，持續的 HTTP 和 SMTP 都使用持續連接。
  • HTTP 主要是一個拉協議 (pull protocol) , 即在方便的時候，某些人在 Web 服務器上裝載信息，用戶使用 HTTP 從該服務器拉取這些信息。 特別是 TCP 連接是由想接收文件的機器發起的。
  • SMTP 基本上是一個推協議 (push protocol) ，即發送郵件服務器把文件推向接收郵件服務器。特別是，這個 TCP 連接是由要發送該文件的機器發起的。
  • SMTP 要求每個報文(包括它們的體)使用 7 比特 ASCII 碼格式。 如果HTTP 數據則不受這種限制。
  • 對於一個既包含文本又包含圖形的文檔，HTTP 把每個對象封裝到它自己的 HTTP 響應報文中， 而 SMTP 則把所有報文對象放在一個報文之中。

3.2 Email消息格式與POP協議

• 文本消息格式標準：
  • 頭部行（header）
    • To
    • From
    • Subject
  • 空白行
  • 消息體（body）
    • 消息本身（只能是ASCII字符）
• 郵件包含多媒體等非文本格式怎麼辦？——MIME
  • MIME（Multipurpose Internet Mail Extensions）多媒體郵件擴展：通過在郵件頭部增加額外的行以聲明MIME的內容類型
  • 根據聲明的編碼方法把文件編碼成ASCII碼，收件人根據編碼方法把ASCII數據解碼
• SMTP 將郵件報文從Alice 的郵件服務器交付給 Bob 的郵件服務器，該報文就被放入了 Bob 的郵箱中。收件人Bob從郵件服務器上收郵件時採用的不是SMTP協議，而是郵件訪問協議
  • POP（POSl Office Protocol）郵局協議
    • 極爲簡單
    • 認證/授權（客戶端——服務器）和下載
    • 無狀態
  • IMAP（Intemet Mail Access Protocol ）因特網郵件訪問協議
    • 所有消息保存在一個地方：服務器
    • 允許用戶通過文件夾組織消息
    • 支持跨會話的用戶狀態
  • HTTP：163、QQ Mail等

4.DNS應用：因特網的目錄服務

4.1 DNS概述

• Internet中主機或路由器的標識（兩套方案）：
  • IP地址：數字，用戶不容易記住
  • 域名：方便用戶記憶，更好識別如www.baidu.com
  • 在網絡層中使用的是IP地址，而人使用的是域名，因此二者需要建立映射關係——DNS負責
• DNS（Domain Name System）域名解析系統
  • 多層命名服務器構成的分佈式數據庫
  • 一個使得主機能夠查詢分佈式數據庫的應用層協議。
  • DNS 服務器通常是運行 BIND (Berkeley Internet Name Domain) 軟件的 UNIX機器。 DNS 協議運行在 UDP 之上，使用 53 號端口
• 分佈式、層次數據庫：
  • 根DNS域名服務器，在因特網上有 13 個根 DNS 服務器(標號爲 A 到 M) ，它們中的大部分位於北美洲。
  • 頂級DNS域名服務器，這些服務器負責頂級域名如 com、 org、 net、 edu ，以及所有國家的頂級域名如uk、fr、ca 和 jpo。由一些組織或公司維護。
  • 權威 DNS 服務器， 組織的域名解析服務器，只要對外提供服務，就要維護。如多數大學和大公司實現和維護它們自己基本和輔助(備份)的權威 DN 服務器。
  • 本地DNS服務器，嚴格說來並不屬於該服務器的層次結構，但它對 DNS 層次結構是重要的。 每個 ISP (如一個大學、一個公司或一個居民區的 ISP) 都有一臺本地 DNS 服務器(也叫默認域名服務器) 。作爲代理和緩存
• DNS查詢示例：
  • 從請求主機到本地 DNS 服務器的查詢是遞歸的，其餘的查詢是迭代的。
  • 遞歸查詢
• DNS 緩存與更新
  • DNS 緩存原理非常簡單。 在一個請求鏈中，當某 DNS 服務器接收一個 DNS 回答（IP地址與域名的映射）時，它能將該回答中的信息緩存在本地存儲器中。 一段時間後，緩存失效
• DNS提供的其他服務：
  • 主機別名 (host aliasing) ，有着複雜主機名的主機能擁有一個或者多個別名
  • 郵件服務器別名 (mail server aliasing)
  • 負載分配 (load distribution)
• 爲什麼使用分佈式不使用集中式？
  • 單點故障 (a single point of failure) 。 如果該 DNS 服務器崩潰，整個因特網隨之癱瘓!
  • 通信容量( traffic volume) 。 單個 DNS 服務器不得不處理所有的 DNS 查詢(用於爲上億臺主機產生的所有 HTTP 請求報文和電子郵件報文服務) 。
  • 遠距離的集中式數據庫 (distant centralized database) 。 單個 DNS 服務器不可能 "鄰近"所有查詢客戶 。 如果我們將單臺 DNS 服務器放在紐約市，那麼所有來自 澳大利亞的查詢必須傳播到地球的另一邊，中間也許還要經過低速和擁塞的鏈路。 這將導致嚴重的時延。
  • 維護 (maintenance) 。 單個DNS服務器將不得不爲所有的因特網主機保留記錄。 這不僅將使這個中央數據庫非常龐大，而且它還不得不爲解決每個新添加的主機 而頻繁更新。

4.2 DNS記錄與消息格式

• RR（resource records）資源記錄：RR 提供了主機名到 IP地址的映射。 每個 DNS 回答報文包含了一條或多條資源記錄。
• 資源記錄是一個包含了下列字段的 4 元組：（Name, Value , Type , TTL）
  • TTL 是該記錄的生存時間，它決定了資源記錄應當從緩存中刪除的時間。
  • Name 和 Value 的值取決於 Type：
    • Type =A ，則 Name：主機域名， Value：IP地址
    • Type = NS ，則 Name ：域（如 edu. cn）， Value：該域權威域名解析服務器的主機域名
    • Type = CNAME ，則Name：某一真實域名的別名，Value：真實域名
    • Type = MX，Value是與Name相對應的郵件服務器
• DNS有自己的協議：DNS協議
  • 查詢/回覆性協議
  • 兩者消息格式相同

4.3 在 DNS 數據庫中插入記錄

• 假定你剛剛創建一個稱爲網絡烏托邦 (Network Utopia) 的令人興奮的新創業公司。 你必定要做的第一件事是在註冊登記機構 ( registrar )註冊域名： networkutopia. com
• 註冊登記機構 ( registrar )是一個商業實體， 它驗證該域名的唯一性，將該域名輸入 DNS 數據庫，對提供的服務收取少量費用。
• 步驟：
  1. 向域名管理機構提供你的權威域名解析服務器的名字和IP地址
  2. 域名管理機構向 com 頂級域名解析服務器中插入兩條記錄（前面講過的RR）：
     (networkutopia.com, dns1.networkutopia.com, NS) ——域名和權威域名解析服務器的主機域名
     (dns1.networkutopia.com, 212.212.212 .1, A) ——主機域名和 IP 地址
  3. 還要確保用於 Web 服務器 www. networkulopia. com 的類型 A 資源記錄和用於郵件服務器 mail. networkutopia. com 的類型 MX 資源記錄被輸入到自己的權威 DNS 服務器中。
  4. 完成所有這些步驟，人們將能夠訪問你的 Web 站點，並向你公司的僱員發送電子郵件。
• 例子：
  1. 假定在澳大利亞的Alice 要觀看www. networkutopía. com 的 Web 頁 面。
  2. 如前面所討論，她的主機將首先向其本地 DNS 服務器發送請求。
  3. 該本地服務器接着 則聯繫一個 TLD com （頂級）服務器。 (如果 TLD com 服務器的地址沒有被緩存，該本地 DNS 服務 器也將必須與根 DNS 服務器相聯繫）
  4. 該 TLD 服務器包含前面列出的類型 NS 和類型 A 資 源記錄，因爲註冊登記機構將這些資源記錄插入所有的 TLD com 服務器。 該 TLD com 服務 器向Alíce 的本地 DNS 服務器發送一個回答，該回答包含了這兩條資源記錄。
  5. 該本地 DNS 服務器則向 212. 212. 212. 1 發送一個 DNS 查詢，請求對應於 www. networkutopia. com 的類型 A 記錄。 該記錄提供了所希望的 Web 服務器的 IP 地址，如 212.212.71. 4 ，本地 DNS 服 務器將該地址回傳給Alice 的主機。
  6. Alice 的瀏覽器此時能夠向主機212.212. 71. 4 發起一個 TCP 連接，並在該連接上發送一個町rTP 請求。