計算機網絡（謝希仁版）--應用層

 

應用層：

　1. 域名系統（DNS）:

　　1. 概述：

　　　許多應用層軟件常常直接使用域名系統 DNS (Domain Name System)，但計算機的用戶只是間接而不是直接使用域名系統。
　　　因特網採用層次結構的命名樹做爲主機的名字，並使用分佈式的域名系統 DNS。
　　　名字到 IP 地址的解析是由若干個域名服務器程序完成的。域名服務器程序在專設的結點上運行，運行該程序的機器稱爲域名服務器。

　　2.  因特網的域名結構：
　　　因特網採用了層次樹狀結構的命名方法。
　　　任何一個鏈接在因特網上的主機或路由器，都有一個惟一的層次結構的名字，即域名。
　　　域名的結構由標號序列組成，各標號之間用點隔開：
　　　

　　　域名不區分大小寫，頂級域名由ICANN管理

　　3. 域名服務器：

　　　一個服務器所負責管轄的（或有權限的）範圍叫作區(zone)。
　　　各單位根據具體狀況來劃分本身管轄範圍的區。但在一個區中的全部節點必須是可以連通的。
　　　每個區設置相應的權限域名服務器，用來保存該區中的全部主機的域名到IP地址的映射。
　　　DNS 服務器的管轄範圍不是以「域」爲單位，而是以「區」爲單位。

　　　　

 

　　　域名服務器有如下四種類型：根域名服務器、頂級域名服務器、權限域名服務器、本地域名服務器

　　4. 根域名服務器：

　　　根域名服務器是最重要的域名服務器。全部的根域名服務器都知道全部的頂級域名服務器的域名和 IP 地址。
　　　不論是哪個本地域名服務器，若要對因特網上任何一個域名進行解析，只要本身沒法解析，就首先求助於根域名服務器。
　　　在因特網上共有13 個不一樣 IP 地址的根域名服務器，它們的名字是用一個英文字母命名，從a 一直到 m（前13 個字母）。

　　　到 2006 年末全世界已經安裝了一百多個根域名服務器機器，分佈在世界各地。
　　　這樣作的目的是爲了方便用戶，使世界上大部分 DNS 域名服務器都能就近找到一個根域名服務器。

　　　根域名服務器並不直接把域名直接轉換成 IP 地址。
  　　 在使用迭代查詢時，根域名服務器把下一步應當找的頂級域名服務器的 IP 地址告訴本地域名服務器。

　　5. 頂級域名服務器：

　　　這些域名服務器負責管理在該頂級域名服務器註冊的全部二級域名。
　　　當收到 DNS 查詢請求時，就給出相應的回答（多是最後的結果，也多是下一步應當找的域名服務器的 IP 地址）。

　　6. 權限域名服務器：

　　　這就是前面已經講過的負責一個區的域名服務器。
　　　當一個權限域名服務器還不能給出最後的查詢回答時，就會告訴發出查詢請求的 DNS 客戶，下一步應當找哪個權限域名服務器。

　　7. 本地域名服務器：

　　　當一個主機發出 DNS 查詢請求時，這個查詢請求報文就發送給本地域名服務器。
　　　每個因特網服務提供者 ISP，或一個大學，甚至一個大學裏的系，均可以擁有一個本地域名服務器，
　　　這種域名服務器有時也稱爲默認域名服務器。 就是PC機上默認DNS。

　　8. 提升域名服務器的可靠性：

　　　DNS 域名服務器都把數據複製到幾個域名服務器來保存，其中的一個是主域名服務器，其餘的是輔助域名服務器。
　　　當主域名服務器出故障時，輔助域名服務器能夠保證 DNS 的查詢工做不會中斷。
　　　主域名服務器按期把數據複製到輔助域名服務器中，而更改數據只能在主域名服務器中進行。這樣就保證了數據的一致性。

　　9. 域名的解析過程：

　　　主機向本地域名服務器的查詢通常都是採用遞歸查詢。若是主機所詢問的本地域名服務器不知道被查詢域名的 IP 地址，那麼本地域名服務器就以 DNS 客戶的身份，向其餘根域名服務器繼續發出查詢請求報文。
　　　本地域名服務器向根域名服務器的查詢一般是採用迭代查詢。當根域名服務器收到本地域名服務器的迭代查詢請求報文時，要麼給出所要查詢的 IP 地址，要麼告訴本地域名服務器：「你下一步應當向哪個域名服務器進行查詢」。而後讓本地域名服務器進行後續的查詢。

　　10. 名字的高速緩存：

　　　每一個域名服務器都維護一個高速緩存，存放最近用過的名字以及從何處得到名字映射信息的記錄。
　　　可大大減輕根域名服務器的負荷，使因特網上的 DNS 查詢請求和回答報文的數量大爲減小。
　　　爲保持高速緩存中的內容正確，域名服務器應爲每項內容設置計時器，並處理超過合理時間的項（例如，每一個項目只存放兩天）。
　　　當權限域名服務器回答一個查詢請求時，在響應中都指明綁定有效存在的時間值。增長此時間值可減小網絡開銷，而減小此時間值可提升域名轉換的準確性。
　　　不但在本地域名服務器中須要高速緩存，在主機中也須要，就是Linux中的host文件。

　　11. 補充：

　　　DNS 請求報文是 UDP報文。

 

　2. 文件傳送協議（FTP）:

　　1. 概述：

　　　FTP 提供交互式的訪問，容許客戶指明文件的類型與格式，並容許文件具備存取權限。
　　　FTP 屏蔽了各計算機系統（主要是文件系統）的細節，於是適合於在異構網絡中任意計算機之間傳送文件。
　　2. 特色：

　　　文件傳送協議 FTP 只提供文件傳送的一些基本的服務，它使用 TCP 可靠的運輸服務。
　　　FTP 的主要功能是減小或消除在不一樣操做系統下處理文件的不兼容性。
　　　FTP 使用客戶服務器方式。一個 FTP 服務器進程可同時爲多個客戶進程提供服務。FTP 的服務器進程由兩大部分組成：一個主進程，負責接受新的請求；另外有若干個從屬進程，負責處理單個請求。

　　3. 主進程的工做步驟以下：

　　　打開熟知端口（端口號爲 21），使客戶進程可以鏈接上。
　　　等待客戶進程發出鏈接請求。
　　　啓動從屬進程來處理客戶進程發來的請求。從屬進程對客戶進程的請求處理完畢後即終止，但從屬進程在運行期間根據須要還可能建立其餘一些子進程。
　　　回到等待狀態，繼續接受其餘客戶進程發來的請求。主進程與從屬進程的處理是併發地進行。

　　4. 兩個鏈接：

　　　控制鏈接在整個會話期間一直保持打開，FTP 客戶發出的傳送請求經過控制鏈接發送給服務器端的控制進程，但控制鏈接不用來傳送文件。
　　　實際用於傳輸文件的是「數據鏈接」。服務器端的控制進程在接收到 FTP 客戶發送來的文件傳輸請求後就建立「數據傳送進程」和「數據鏈接」，用來鏈接客戶端和服務器端的數據傳送進程。
　　　數據傳送進程實際完成文件的傳送，在傳送完畢後關閉「數據傳送鏈接」並結束運行。

　　　

　　5. 兩個不一樣的端口號：

　　　當客戶進程向服務器進程發出創建鏈接請求時，要尋找鏈接服務器進程的熟知端口(21)，同時還要告訴服務器進程本身的另外一個端口號碼，用於創建數據傳送鏈接。
　　　接着，服務器進程用本身傳送數據的熟知端口(20)與客戶進程所提供的端口號碼創建數據傳送鏈接。
　　　因爲 FTP 使用了兩個不一樣的端口號，因此數據鏈接與控制鏈接不會發生混亂。

　　6. 文件共享協議：

　　　FTP 和 TFTP 都屬於文件共享協議的一大類：複製整個文件。

　　　NFS （網絡文件系統）則屬於文件共享協議的另外一大類：聯機訪問。

　　　NFS 容許應用進程打開一個遠地文件，並能在該文件的某一個特定的位置上開始讀寫數據。
　　　NFS 可以使用戶只複製一個大文件中的一個很小的片斷，而不須要複製整個大文件。（FTP、TFTP則須要複製整個大文件）
　　　對於上述例子，計算機 A 的 NFS 客戶軟件，把要添加的數據和在文件後面寫數據的請求一塊兒發送到遠地的計算機 B 的 NFS 服務器。NFS 服務器更新文件後返回應答信息。在網絡上傳送的只是少許的修改數據。

　　7. 簡單文件傳送協議 TFTP：

　　　1. 概述：

　　　TFTP 是一個很小且易於實現的文件傳送協議。
　　　TFTP 使用客戶服務器方式和使用 UDP 數據報，所以 TFTP 須要有本身的差錯改正措施。
　　　TFTP 只支持文件傳輸而不支持交互。
　　　TFTP 沒有一個龐大的命令集，沒有列目錄的功能，也不能對用戶進行身份鑑別。

　　　2. 特色：

　　　(1) 每次傳送的數據 PDU 中有 512 字節的數據，但最後一次可不足 512 字節。
    　  (2) 數據 PDU 也稱爲文件塊(block)，每一個塊按序編號，從 1 開始。
    　  (3) 支持 ASCII 碼或二進制傳送。
         (4) 可對文件進行讀或寫。
         (5) 使用很簡單的首部。

　　　3. 工做流程（像中止等待協議）：

　　　發送完一個文件塊後就等待對方的確認，確認時應指明所確認的塊編號。
　　　發完數據後在規定時間內收不到確認就要重發數據 PDU。
　　　發送確認 PDU 的一方若在規定時間內收不到下一個文件塊，也要重發確認 PDU。這樣就可保證文件的傳送不致因某一個數據報的丟失而告失敗。

　　　在一開始工做時。TFTP 客戶進程發送一個讀請求 PDU 或寫請求 PDU 給 TFTP 服務器進程，其熟知端口號碼爲 69。
　　　TFTP 服務器進程要選擇一個新的端口和 TFTP 客戶進程進行通訊。
　　　若文件長度剛好爲 512 字節的整數倍，則在文件傳送完畢後，還必須在最後發送一個只含首部而無數據的數據 PDU。
　　　若文件長度不是 512 字節的整數倍，則最後傳送數據 PDU 的數據字段必定不滿512字節，這正好可做爲文件結束的標誌。

 

　3. 遠程終端協議(TELNET)：

　　1. TELNET 能將用戶的擊鍵傳到遠地主機，同時也能將遠地主機的輸出經過 TCP 鏈接返回到用戶屏幕。這種服務是透明的，由於用戶感受到好像鍵盤和顯示器是直接連在遠地主機上。
　　2. 工做流程：

　　　客戶軟件把用戶的擊鍵和命令轉換成 NVT （網路虛擬終端）格式，並送交服務器。
　　　服務器軟件把收到的數據和命令，從 NVT 格式轉換成遠地系統所需的格式。
　　　向用戶返回數據時，服務器把遠地系統的格式轉換爲 NVT 格式，本地客戶再從 NVT 格式轉換到本地系統所需的格式。

 

　4. 萬維網（WWW）:

　　1. 概述：萬維網用連接的方法能很是方便地從因特網上的一個站點訪問另外一個站點，從而主動地按需獲取豐富的信息。

　　

　　2. 超媒體與超文本：

　　　萬維網是分佈式超媒體(hypermedia)系統，它是超文本(hypertext)系統的擴充。
　　　一個超文本由多個信息源連接成。利用一個連接可以使用戶找到另外一個文檔。這些文檔能夠位於世界上任何一個接在因特網上的超文本系統中。超文本是萬維網的基礎。
　　　超媒體與超文本的區別是文檔內容不一樣。超文本文檔僅包含文本信息，而超媒體文檔還包含其餘表示方式的信息，如圖形、圖像、聲音、動畫，甚至活動視頻圖像。

　　3. 工做方式：

　　　萬維網以客戶-服務器方式工做。
　　　瀏覽器就是在用戶計算機上的萬維網客戶程序。萬維網文檔所駐留的計算機則運行服務器程序，所以這個計算機也稱爲萬維網服務器。
　　　客戶程序向服務器程序發出請求，服務器程序向客戶程序送回客戶所要的萬維網文檔。
　　　在一個客戶程序主窗口上顯示出的萬維網文檔稱爲頁面(page)。

　　4. 怎樣標誌分佈在整個因特網上的萬維網文檔？

　　　使用統一資源定位符 URL (Uniform Resource Locator)來標誌萬維網上的各類文檔。
　　　使每個文檔在整個因特網的範圍內具備惟一的標識符 URL。

　　　URL的通常形式：

　　　　

　　　　在 URL 中的字符對大寫或小寫沒有要求。

　　　　http協議的默認端口號爲80，能夠不寫。

　　5. 用何協議實現萬維網上各類超鏈的連接？

　　　爲了使超文本的連接可以高效率地完成，須要用 HTTP 協議來傳送一切必須的信息。
　　　從層次的角度看，HTTP 是面向事務的(transaction-oriented)應用層協議。

　　　萬維網的工做過程：

　　　　

　　　用戶點擊鼠標後所發生的事件：

　　　　(1) 瀏覽器分析超鏈指向頁面的 URL。
　　　　(2) 瀏覽器向 DNS 請求解析 www.tsinghua.edu.cn 的 IP 地址。
　　　　(3) 域名系統 DNS 解析出清華大學服務器的 IP 地址。
　　　　(4) 瀏覽器與服務器創建 TCP 鏈接
　　　　(5) 瀏覽器發出取文件命令：
      　　　　GET /chn/yxsz/index.htm。
　　　　(6) 服務器給出響應，把文件 index.htm 發給瀏覽器。
　　　　(7) TCP 鏈接釋放。
　　　　(8) 瀏覽器顯示「清華大學院系設置」文件 index.htm 中的全部文本。

　　　HTTP的主要特色：

　　　　HTTP 是面向事務的客戶服務器協議。
　　　　HTTP 1.0 協議是無狀態的(stateless)。
　　　　HTTP 協議自己也是無鏈接的，雖然它使用了面向鏈接的 TCP 向上提供的服務。　

　　　請求一個萬維網文檔所需的時間（使用HTTP/1.0協議）：

　　　　

　　　　缺點是沒請求一個文檔，就要兩倍RTT時間。

　　　持續鏈接（解決上述問題）：

　　　　HTTP/1.1 協議使用持續鏈接。
　　　　萬維網服務器在發送響應後仍然在一段時間內保持這條鏈接，使同一個客戶（瀏覽器）和該服務器能夠繼續在這條鏈接上傳送後續的 HTTP 請求報文和響應報文。
　　　　這並不侷限於傳送同一個頁面上連接的文檔，而是只要這些文檔都在同一個服務器上就行。

　　　持續鏈接的兩種工做方式：
　　　　非流水線方式：客戶在收到前一個響應後才能發出下一個請求。這比非持續鏈接的兩倍 RTT 的開銷節省了創建 TCP 鏈接所需的一個 RTT 時間。但服務器在發送完一個對象後，其 TCP 鏈接就處於空閒狀態，浪費了服務器資源。
　　　　流水線方式：客戶在收到 HTTP 的響應報文以前就可以接着發送新的請求報文。一個接一個的請求報文到達服務器後，服務器就可連續發回響應報文。使用流水線方式時，客戶訪問全部的對象只需花費一個 RTT時間，使 TCP 鏈接中的空閒時間減小，提升了下載文檔效率。

　　　代理服務器：

　　　　代理服務器(proxy server)又稱爲萬維網高速緩存(Web cache)，它表明瀏覽器發出 HTTP 請求。
　　　　萬維網高速緩存把最近的一些請求和響應暫存在本地磁盤中。
　　　　當與暫時存放的請求相同的新請求到達時，萬維網高速緩存就把暫存的響應發送出去，而不須要按 URL 的地址再去因特網訪問該資源。

　　　HTTP 的報文結構：

　　　　HTTP 有兩類報文：
　　　　　請求報文——從客戶向服務器發送請求報文。
　　　　　響應報文——從服務器到客戶的回答。
　　　　　因爲 HTTP 是面向正文的(text-oriented)，所以在報文中的每個字段都是一些 ASCII 碼串，於是每一個字段的長度都是不肯定的。

　　　　請求報文結構：

　　　　　

　　　　　報文由三個部分組成，即開始行、首部行（用來講明瀏覽器、服務器或報文主體的一些信息）和實體主體。
　　　　　HTTP 請求報文的一些方法：

　　　　　　

　　　　　版本就是HTTP的版本。

　　　　響應報文結構：

　　　　　

　　　　　報文由三個部分組成，即狀態行、首部行（用來講明瀏覽器、服務器或報文主體的一些信息）和實體主體。

　　　　　狀態碼都是三位數字：

　　　　　　1xx 表示通知信息的，如請求收到了或正在進行處理。
　　　　　　2xx 表示成功，如接受或知道了。（202Accepted）
　　　　　　3xx 表示重定向，表示要完成請求還必須採起進一步的行動。
　　　　　　4xx 表示客戶的差錯，如請求中有錯誤的語法或不能完成。（404 Not Found）
　　　　　　5xx 表示服務器的差錯，如服務器失效沒法完成請求。

　　　　　短語：解釋狀態碼的簡單短語

　　在服務器上存放用戶的信息：

　　　萬維網站點使用 Cookie 來跟蹤用戶。
　　　Cookie 表示在 HTTP 服務器和客戶之間傳遞的狀態信息。
　　　使用 Cookie 的網站服務器爲用戶產生一個惟一的識別碼。利用此識別碼，網站就可以跟蹤該用戶在該網站的活動。  　

 

　5. 電子郵件：

　　1. 其中的一些協議：

　　　發送郵件的協議：SMTP
　　　讀取郵件的協議：POP3 和 IMAP
　　　MIME 在其郵件首部中說明了郵件的數據類型(如文本、聲音、圖像、視像等)，使用 MIME 可在郵件中同時傳送多種類型的數據。

　　2. 電子郵件的最主要的組成構件：

　　　

　　　用戶代理（UA）：用戶代理 UA 就是用戶與電子郵件系統的接口，是電子郵件客戶端軟件。用戶代理的功能：撰寫、顯示、處理和通訊。
　　　郵件服務器：發送和接收郵件，同時還要向發信人報告郵件傳送的狀況（已交付、被拒絕、丟失等）。郵件服務器按照客戶-服務器方式工做。郵件服務器須要使用發送和讀取兩個不一樣的協議。

　　3. 發送和接收電子郵件的幾個重要步驟：
　　　（1） 發件人調用 PC 中的用戶代理撰寫和編輯要發送的郵件。
　　　（2）發件人的用戶代理把郵件用 SMTP 協議發給發送方郵件服務器，
　　　（3）SMTP 服務器把郵件臨時存放在郵件緩存隊列中，等待發送。
　　　（4）發送方郵件服務器的 SMTP 客戶與接收方郵件服務器的 SMTP 服務器創建 TCP 鏈接，而後就把郵件緩存隊列中的郵件依次發送出去。

　　　（5）運行在接收方郵件服務器中的SMTP服務器進程收到郵件後，把郵件放入收件人的用戶郵箱中，等待收件人進行讀取。
　　　（6）收件人在打算收信時，就運行 PC 機中的用戶代理，使用 POP3（或 IMAP）協議讀取發送給本身的郵件。
　　　 請注意，POP3 服務器和 POP3 客戶之間的通訊是由 POP3 客戶發起的。

 　　4. 簡單郵件傳送協議 SMTP：

　　　SMTP 規定了 14 條命令和 21 種應答信息。每條命令用 4 個字母組成，而每一種應答信息通常只有一行信息，由一個 3 位數字的代碼開始，後面附上（也可不附上）很簡單的文字說明。  
　　　SMTP 通訊的三個階段：

　　　　1. 鏈接創建：TCP 鏈接是在發送主機的 SMTP 客戶和接收主機的 SMTP 服務器之間創建的。SMTP不使用中間的郵件服務器。   
　　　　2. 郵件傳送
　　　　3. 鏈接釋放：郵件發送完畢後，SMTP 應釋放 TCP 鏈接。
　　　注意：

　　　　SMTP 原本只能傳送 ASCII 碼，不能傳送二進制數據，後來有了 MIME 能夠傳送二進制數據，但在傳送非 ASCII 碼的長報文時，在網絡上的效率是不高的。

　　　　此外，SMTP 傳送的郵件是明文的，不利於保密。

　　5. 郵件讀取協議POP3 和 IMAP：

　　　郵局協議 POP 是一個很是簡單、但功能有限的郵件讀取協議，如今使用的是它的第三個版本 POP3。
　　　注意： POP3協議，只要用戶從 POP 服務器讀取了郵件，POP 服務器就把該郵件刪除。

　　　用戶在本身的 PC 機上就能夠操縱 ISP 的郵件服務器的郵箱，就像在本地操縱同樣。
　　　所以 IMAP 是一個聯機協議。當用戶 PC 機上的 IMAP 客戶程序打開 IMAP 服務器的郵箱時，用戶就可看到郵件的首部。若用戶須要打開某個郵件，則該郵件才傳到用戶的計算機上。
　　　IMAP最大的好處就是用戶能夠在不一樣的地方使用不一樣的計算機隨時上網閱讀和處理本身的郵件。
　　　IMAP 還容許收件人只讀取郵件中的某一個部分。例如，收到了一個帶有視像附件（此文件可能很大）的郵件。爲了節省時間，能夠先下載郵件的正文部分，待之後有時間再讀取或下載這個很長的附件。
　　　IMAP 的缺點是若是用戶沒有將郵件複製到本身的 PC 上，則郵件一直是存放在 IMAP 服務器上。所以用戶須要常常與 IMAP 服務器創建鏈接。  

　　6. 基於萬維網的電子郵件（經過瀏覽器發送電子郵件）：

　　　電子郵件從 A 發送到網易郵件服務器是使用 HTTP 協議。
　　　兩個郵件服務器之間的傳送使用 SMTP。
　　　郵件重新浪郵件服務器傳送到 B 是使用 HTTP 協議。
　　　

　　7. 通用因特網郵件擴充 MIME：

　　　SMTP 的缺點：

　　　　SMTP 不能傳送可執行文件或其餘的二進制對象。
　　　　SMTP 限於傳送 7 位的 ASCII 碼。許多其餘非英語國家的文字（如中文、俄文，甚至帶重音符號的法文或德文）就沒法傳送。
　　　　SMTP 服務器會拒絕超過必定長度的郵件。

　　　MIME 的特色：

　　　　MIME 並無改動 SMTP 或取代它。
　　　　MIME 的意圖是繼續使用目前的[RFC 822]格式，但增長了郵件主體的結構，並定義了傳送非 ASCII 碼的編碼規則。  

　　　MIME 和 SMTP 的關係：

　　　　

　　　MIME 主要包括三個部分：

　　　　5 個新的郵件首部字段，它們可包含在[RFC 822]首部中。這些字段提供了有關郵件主體的信息。　　
　　　　定義了許多郵件內容的格式，對多媒體電子郵件的表示方法進行了標準化。　　
　　　　定義了傳送編碼，可對任何內容格式進行轉換，而不會被郵件系統改變。

　　　MIME 增長 5 個新的郵件首部：

　　　　MIME-Version: 標誌 MIME 的版本。如今的版本號是 1.0。若無此行，則爲英文文本。
　　　　Content-Description: 這是可讀字符串，說明此郵件是什麼。和郵件的主題差很少。
　　　　Content-Id: 郵件的惟一標識符。
　　　　Content-Transfer-Encoding: 在傳送時郵件的主體是如何編碼的。
　　　　Content-Type: 說明郵件的性質。

　　　內容傳送編碼：

　　　　最簡單的編碼就是 7 位 ASCII 碼，而每行不能超過 1000 個字符。MIME 對這種由 ASCII 碼構成的郵件主體不進行任何轉換。
　　　　另外一種編碼稱爲 quoted-printable，這種編碼方法適用於當所傳送的數據中只有少許的非 ASCII 碼。
　　　　對於任意的二進制文件，可用 base64 編碼。

　　　內容類型：

　　　　MIME着標準規定 Content-Type 說明必須含有兩個標識符，即內容類型(type)和子類型(subtype)，中間用「/」分開。
　　　　MIME 標準定義了 7 個基本內容類型和 15 種子類型。

 

　6. 動態主機配置協議 DHCP：

　　1. 工做方式：

　　　須要 IP 地址的主機在啓動時就向 DHCP 服務器廣播發送發現報文（DHCPDISCOVER），這時該主機就成爲 DHCP 客戶。
　　　本地網絡上全部主機都能收到此廣播報文，但只有 DHCP 服務器纔回答此廣播報文。
　　　DHCP 服務器先在其數據庫中查找該計算機的配置信息。若找到，則返回找到的信息。若找不到，則從服務器的 IP 地址池(address pool)中取一個地址分配給該計算機。DHCP 服務器的回答報文叫作提供報文

（DHCPOFFER）。

　　2. DHCP 中繼代理：

　　　並非每一個網絡上都有 DHCP 服務器，這樣會使 DHCP 服務器的數量太多。如今是每個網絡至少有一個 DHCP 中繼代理，它配置了 DHCP 服務器的 IP 地址信息。
　　　當 DHCP 中繼代理收到主機發送的發現報文後，就以單播方式向 DHCP 服務器轉發此報文，並等待其回答。收到 DHCP 服務器回答的提供報文後，DHCP 中繼代理再將此提供報文發回給主機。

　　　

　　3. 租用期：

　　　DHCP 服務器分配給 DHCP 客戶的 IP 地址的臨時的，所以 DHCP 客戶只能在一段有限的時間內使用這個分配到的 IP 地址。DHCP 協議稱這段時間爲租用期。
　　　租用期的數值應由 DHCP 服務器本身決定。
　　　DHCP 客戶也可在本身發送的報文中（例如，發現報文）提出對租用期的要求。

　　4. 注意：

　　　DHCP 報文是 UDP 報文。