跳轉到內容

CCNA 認證/應用層

來自華夏公益教科書

應用層

[編輯 | 編輯原始碼]

應用層是七層 OSI 模型的第七層。它直接與應用程式程序互動併為其執行常見的應用程式服務;它還向表示層發出請求。

常見的應用層服務提供相關應用程式程序之間的語義轉換。注意:通用應用程式服務的示例包括虛擬檔案、虛擬終端、作業傳輸和操作協議。

四層和五層 TCP/IP 模型的應用層對應於七層 OSI 模型中的應用層、表示層和會話層。

動態主機配置協議

[編輯 | 編輯原始碼]

DHCP 是一種由聯網主機(客戶端)使用的協議,用於從 DHCP 伺服器獲取 IP 地址和其他引數,例如預設閘道器、子網掩碼和 DNS 伺服器的 IP 地址。它有助於訪問網路,因為否則必須為客戶端手動設定這些設定才能參與網路。

DHCP 伺服器確保所有 IP 地址都是唯一的,例如,在第一個客戶端的分配有效(其租約尚未過期)時,不會將任何 IP 地址分配給第二個客戶端。因此,IP 地址池管理由伺服器完成,而不是由人類網路管理員完成。

DHCP 在功能上已成為舊的 BOOTP 協議的繼任者,BOOTP 協議的租約無限期授予,不支援選項。由於 DHCP 的向後相容性,很少有網路繼續使用純 BOOTP。

IP 地址分配

[編輯 | 編輯原始碼]

根據實現方式,DHCP 伺服器有三種分配 IP 地址的方法

  • 手動分配,其中 DHCP 伺服器根據一個表執行分配,該表包含伺服器管理員手動填寫的 MAC 地址 - IP 地址對。只有請求的客戶端的 MAC 地址列在這個表中,才能根據表獲取 IP 地址。
  • 自動分配,其中 DHCP 伺服器永久分配管理員提供的範圍內的一個空閒 IP 地址給請求的客戶端。
  • 動態分配,這是唯一提供 IP 地址動態重用的方法。網路管理員將一組 IP 地址分配給 DHCP,並且 LAN 上的每臺客戶端計算機都將其 TCP/IP 軟體配置為在該客戶端計算機的網路介面卡啟動時從 DHCP 伺服器請求一個 IP 地址。請求和授予過程使用一個租約概念,並具有可控的時間段。這極大地簡化了客戶端計算機側的網路安裝過程。

這個決定通常對客戶端來說是不可見的。

某些 DHCP 伺服器實現可以更新與客戶端主機關聯的 DNS 名稱以反映新的 IP 地址。它們使用與 RFC 2136 建立的 DNS 更新協議。

配置 IOS DHCP 伺服器

[編輯 | 編輯原始碼]
  • 設定 DHCP 資料庫代理

使用 IP DHCP database 命令,配置一個 DHCP 資料庫儲存。或者,使用 no IP DHCP conflict logging 命令停用 DHCP 衝突日誌記錄。

  • 設定排除的 IP 地址

使用 ip dhcp excluded-address 命令配置 DHCP 池地址範圍內但不應分配給客戶端的任何 IP 地址。

  • 配置地址池

首先,使用 IP DHCP pool name 命令建立一個 DHCP 池。接下來,在 DHCP 池模式下,使用 network 命令將網路範圍新增到 DHCP 池。

  • 配置預設 DNS 伺服器

使用 dns-server 命令設定預設 DNS 伺服器的 IP 地址。

  • 配置預設路由

使用 default-router 命令設定 DHCP 客戶端的預設路由。

  • 啟用 DHCP 伺服器

使用 service DHCP 命令啟用 DHCP 伺服器。

DHCP 和防火牆

[編輯 | 編輯原始碼]

防火牆通常必須顯式允許 DHCP 流量。DHCP 客戶端-伺服器協議規範描述了幾個情況下,資料包必須具有以下源地址0x00000000或目的地址為0xffffffff. 防欺騙策略規則和嚴格的包含性防火牆通常會阻止此類資料包。多宿主 DHCP 伺服器需要特殊考慮,並且會使配置更加複雜。

為了允許 DHCP,網路管理員需要允許幾種型別的資料包透過伺服器端防火牆。所有 DHCP 資料包都以 UDP 資料報形式傳輸;所有客戶端傳送的資料包都具有源埠 68 和目的埠 67;所有伺服器傳送的資料包都具有源埠 67 和目的埠 68。例如,伺服器端防火牆應允許以下型別的資料包

  • 來自 0.0.0.0 或 dhcp-pool 到 dhcp-ip 的傳入資料包
  • 來自任何地址到 255.255.255.255 的傳入資料包
  • 來自 dhcp-ip 到 dhcp-pool 或 255.255.255.255 的傳出資料包

其中 dhcp-ip 表示 DHCP 伺服器主機上配置的任何地址,而 dhcp-pool 代表 DHCP 伺服器分配給客戶端的地址池

Cisco IOS 擴充套件 ACL 中的示例

[編輯 | 編輯原始碼]

以下條目在啟用了 DHCP 服務的 Cisco 3560 交換機上有效。ACL 應用於路由介面 10.32.73.129,在輸入時。子網是 10.32.73.128/26。

10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps
20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps
30 permit udp any eq bootpc host 255.255.255.255 eq bootps

技術細節

[編輯 | 編輯原始碼]
典型 DHCP 會話的模式

DHCP 使用與 BOOTP 相同的兩個 IANA 分配埠:67/udp 用於伺服器端,68/udp 用於客戶端。

DHCP 操作分為四個基本階段。這些階段是 IP 租約請求、IP 租約提供、IP 租約選擇和 IP 租約確認。

DHCP 發現

[edit | edit source]

客戶端在本地物理子網上廣播以查詢可用的伺服器。網路管理員可以配置本地路由器將 DHCP 資料包轉發到不同子網上的 DHCP 伺服器。這種客戶端實現建立了一個 UDP 資料包,其廣播目標為 255.255.255.255 或子網廣播地址。

客戶端還可以請求其最後已知的 IP 地址(在下面的示例中為 192.168.1.100)。如果客戶端仍然在該 IP 地址有效的網路中,伺服器可能會授予該請求。否則,它取決於伺服器是否被設定為權威伺服器。權威伺服器將拒絕該請求,導致客戶端立即請求新的 IP 地址。非權威伺服器會簡單地忽略該請求,導致客戶端根據實現的時間超時而放棄該請求並請求新的 IP 地址。

DHCPDISCOVER
UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67
OPHTYPEHLENHOPS
0x010x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR
0x00000000
YIADDR
0x00000000
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x00053C04
0x8D590000
0x00000000
0x00000000
192 個位元組的 0。BOOTP 遺留
DHCP 選項 53:DHCP 發現
DHCP 選項 50:請求 192.168.1.100

DHCP 提供

[edit | edit source]

當 DHCP 伺服器從客戶端收到 IP 租約請求時,它會擴充套件 IP 租約提供。這是透過為客戶端保留一個 IP 地址,並將 DHCPOFFER 訊息透過網路傳送到客戶端來完成的。此訊息包含客戶端的 MAC 地址,後面是伺服器提供的 IP 地址、子網掩碼、租約期限和提供服務的 DHCP 伺服器的 IP 地址。

伺服器根據 CHADDR 欄位中指定的客戶端硬體地址來確定配置。在這裡,伺服器 192.168.1.1 在 YIADDR 欄位中指定 IP 地址。

DHCPOFFER
UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68
OPHTYPEHLENHOPS
0x020x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR
0x00000000
YIADDR
0xC0A80164
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x00053C04
0x8D590000
0x00000000
0x00000000
192 個位元組的 0。BOOTP 遺留
DHCP 選項 53:DHCP 提供
DHCP 選項 1:255.255.255.0 子網掩碼
DHCP 選項 3:192.168.1.1 路由器
DHCP 選項 51:1 天 IP 租約時間
DHCP 選項 54:192.168.1.1 DHCP 伺服器

DHCP 請求

[edit | edit source]

客戶端從收到的 DHCP“提供”資料包中選擇一個配置,並在本地子網上廣播它。同樣,此客戶端請求伺服器指定的 192.168.1.100 地址。如果客戶端收到多個提供,它會指定它接受提供服務的伺服器。

DHCPREQUEST
UDP Src=0.0.0.0 sPort=68 Dest=255.255.255.255 dPort=67
OPHTYPEHLENHOPS
0x010x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR
0x00000000
YIADDR
0x00000000
SIADDR
0x00000000
GIADDR
0x00000000
CHADDR
0x00053C04
0x8D590000
0x00000000
0x00000000
192 個位元組的 0。BOOTP 遺留
DHCP 選項 53:DHCP 請求
DHCP 選項 50:請求 192.168.1.100
DHCP 選項 54:192.168.1.1 DHCP 伺服器。

DHCP 確認

[edit | edit source]

當 DHCP 伺服器從客戶端收到 DHCPREQUEST 訊息時,它會啟動配置過程的最後階段。此確認階段包括將 DHCPACK 資料包傳送到客戶端。此資料包包括租約期限和客戶端可能請求的任何其他配置資訊。此時,TCP/IP 配置過程已完成。

伺服器確認該請求並將確認傳送到客戶端。整個系統期望客戶端使用提供的選項配置其網路介面。

DHCPACK
UDP Src=192.168.1.1 sPort=67 Dest=255.255.255.255 dPort=68
OPHTYPEHLENHOPS
0x020x010x060x00
XID
0x3903F326
SECSFLAGS
0x00000x0000
CIADDR(客戶端 IP 地址)
0x00000000
YIADDR(您的 IP 地址)
0xC0A80164
SIADDR(伺服器 IP 地址)
0x00000000
GIADDR(中繼 IP 地址)
0x00000000
CHADDR(客戶端硬體地址)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 個位元組的 0。BOOTP 遺留
DHCP 選項 53:DHCP ACK
DHCP 選項 1:255.255.255.0 子網掩碼
DHCP 選項 3:192.168.1.1 路由器
DHCP 選項 51:1 天 IP 租約時間
DHCP 選項 54:192.168.1.1 DHCP 伺服器

DHCP 選擇

[edit | edit source]

當客戶端 PC 收到 IP 租約提供時,它必須告訴所有其他 DHCP 伺服器它已接受提供。為此,客戶端廣播包含提供服務的伺服器的 IP 地址的 DHCPREQUEST 訊息。當其他 DHCP 伺服器收到此訊息時,它們會撤回可能已提供給客戶端的任何提供。然後,它們將為客戶端保留的地址返回到它們可以提供給另一臺計算機的有效地址池。任何數量的 DHCP 伺服器都可以響應 IP 租約請求,但客戶端只能為每個網路介面卡接受一個提供。

DHCP 資訊

[edit | edit source]

客戶端向 DHCP 伺服器傳送請求:要麼請求伺服器在原始 DHCPACK 中傳送的更多資訊;要麼重複特定應用程式的資料 - 例如,瀏覽器使用 DHCP Inform 透過 WPAD 獲取 Web 代理設定。此類查詢不會導致 DHCP 伺服器重新整理其資料庫中的 IP 過期時間。

DHCP 釋放

[edit | edit source]

客戶端向 DHCP 伺服器傳送請求以釋放 DHCP,並且客戶端取消配置其 IP 地址。由於客戶端通常不知道使用者何時可能將它們從網路上拔下,因此該協議沒有將傳送 DHCP Release 定義為強制性的。

電子郵件

[edit | edit source]

電子郵件由兩種型別的協議組成:伺服器到伺服器和客戶端到伺服器。

伺服器到伺服器

[edit | edit source]

簡單郵件傳輸協議 (SMTP) 是網際網路上電子郵件傳輸的事實上的標準。正式的 SMTP 在 RFC 821 (STD 10) 中定義,並由 RFC 1123 (STD 3) 第 5 章進行修訂。今天使用的協議也稱為 ESMTP,並在 RFC 2821 中定義。

SMTP 是一個相對簡單的基於文字的協議,其中指定了訊息的一個或多個收件人(並且在大多數情況下驗證了收件人的存在),然後傳輸訊息文字。使用 telnet 程式(見下文)很容易測試 SMTP 伺服器。

SMTP 使用 TCP 埠 25。要確定給定域名對應的 SMTP 伺服器,通常使用 MX(郵件交換)DNS 記錄,如果 MX 不存在,則回退到簡單的 A 記錄(並非所有 MTA(郵件傳輸代理)都支援回退)。一些當前的郵件傳輸代理也會使用 SRV 記錄,這是一種更通用的 MX 形式,但這些記錄並未被廣泛採用。

客戶端到伺服器

[edit | edit source]

SMTP 是一個“推送”協議,不允許使用者按需從遠端伺服器“拉取”訊息。為此,郵件客戶端必須使用 POP3 或 IMAP。另一個 SMTP 伺服器可以使用 ETRN 觸發 SMTP 中的傳遞。

POP3 使協議的早期版本(非正式地稱為 POP1)和 POP2 過時。在當代使用中,在電子郵件協議的上下文中,不太精確的術語 POP 幾乎總是指 POP3

POP3 的設計及其程式支援具有間歇連線(例如撥號連線)的終端使用者,允許這些使用者在連線時檢索電子郵件,然後在無需保持連線的情況下檢視和操作檢索到的訊息。儘管大多數客戶端都有一個將郵件留在伺服器上的選項,但使用 POP3 的電子郵件客戶端通常會連線、檢索所有訊息、將它們儲存在使用者的 PC 上作為新訊息、從伺服器中刪除它們,然後斷開連線。相比之下,更新、功能更強大的網際網路郵件訪問協議 (IMAP) 支援連線斷開連線兩種操作模式。使用 IMAP 的電子郵件客戶端通常將訊息留在伺服器上,直到使用者顯式刪除它們。這和 IMAP 操作的其他方面允許多個客戶端訪問同一個郵箱。大多數電子郵件客戶端支援 POP3 或 IMAP 來檢索訊息;但是,較少的網際網路服務提供商 (ISP) 支援 IMAP。POP3 和 IMAP4 之間的根本區別在於,POP3 提供對郵件存放區的訪問;郵件存在於伺服器上,直到被客戶端收集。即使客戶端將一些或所有郵件留在伺服器上,客戶端的訊息儲存也被認為是權威的。相比之下,IMAP4 提供對郵件儲存區的訪問;客戶端可以儲存訊息的本地副本,但這些副本被認為是臨時快取;伺服器的儲存區是權威的。

網路

[edit | edit source]

超文字傳輸協議 (HTTP) 是一種用於在全球資訊網上傳輸或傳送資訊的方法。它的最初目的是提供一種釋出和檢索 HTML 頁面。

HTTP 的開發由 W3C 和 IETF 協調,最終釋出了一系列 RFC,最著名的是 RFC 2616 (1999),該 RFC 定義了 HTTP/1.1,這是當今普遍使用的 HTTP 版本。

HTTP 是客戶端和伺服器之間的請求/響應協議。源客戶端(例如 Web 瀏覽器、蜘蛛或其他終端使用者工具)被稱為使用者代理。儲存或建立資源(如 HTML 檔案和影像)的目標伺服器被稱為源伺服器。在使用者代理和源伺服器之間可能存在多箇中間伺服器,例如代理、閘道器和隧道。

HTTP 客戶端透過建立與遠端主機上的特定埠(預設情況下為埠 80;參見維基百科的埠號列表)的傳輸控制協議 (TCP) 連線來發起請求。監聽該埠的 HTTP 伺服器等待客戶端傳送請求訊息。

伺服器收到請求後,會發回狀態行,例如“HTTP/1.1 200 OK”,以及自己的訊息,其主體可能是請求的檔案、錯誤訊息或其他一些資訊。

透過 HTTP 訪問的資源使用 URI 來標識(更具體地說是使用http或 https URI 方案。

請求訊息

[edit | edit source]

請求訊息由以下部分組成

  • 請求行,例如GET /images/logo.gif HTTP/1.1,它請求logo.gif檔案,它位於/images目錄下。
  • 頭,例如Accept-Language: en
  • 空行
  • 可選的訊息主體

請求行和頭都必須以 CRLF(即回車後跟換行符)結尾。空行必須僅包含 CRLF,不包含任何其他空格。

在 HTTP/1.1 協議中,除 Host 之外的所有頭都是可選的。

請求方法

[edit | edit source]

HTTP 定義了八種方法(有時稱為“動詞”),它們指示要對已標識的資源執行的所需操作。

HEAD
請求與 GET 請求對應的相同響應,但沒有響應主體。這對於檢索響應頭中寫入的元資訊很有用,無需傳輸整個內容。
GET
請求指定資源的表示。到目前為止,這是 Web 上最常用的方法。不應用於會導致副作用的操作(將其用於 Web 應用程式中的操作是一種常見的誤用)。請參閱下面的“安全方法”。
POST
提交資料以處理(例如,來自 HTML 表單)到標識的資源。資料包含在請求的主體中。這可能會導致建立新資源或更新現有資源或兩者兼而有之。
PUT
上傳指定資源的表示。
DELETE
刪除指定資源。
TRACE
回顯收到的請求,以便客戶端可以檢視中間伺服器在請求中新增或更改的內容。
OPTIONS
返回伺服器支援的 HTTP 方法。這可用於檢查 Web 伺服器的功能。
CONNECT
用於與可以更改為 SSL 隧道代理的代理一起使用。

HTTP 伺服器應該至少實現 GET 和 HEAD 方法,並且只要有可能,還應該實現 OPTIONS 方法。

參考資料

[edit | edit source]
[edit | edit source]
華夏公益教科書