文章目錄
- 1 網路應用模型
- 1.1 概述
- 1.2 網路應用模型
- 1.2.1 客戶/服務器模型(Client/Server)
- 1.2.2 P2P模型(Peer-to-Peer)
- 2 域名系統DNS
- 2.1 域名
- 2.2 域名服務器
- 2.3 域名決議程序
- 3 檔案傳送協議FTP
- 4 動態主機配置協議DHCP
- 5 電子郵件協議
- 5.1 簡單郵件傳送協議SMTP
- 5.2 郵局協議POP3
- 5.3 網際報文存取協議IMAP
- 6 萬維網和HTTP協議
- 6.1 萬維網概述
- 6.2 超文本傳輸協議HTTP
- 6.2.1 特點
- 6.2.2 HTTP的報文結構
- 7 常用埠
- 8 Web 頁面請求程序
- 8.1 DHCP 配置主機資訊
- 8.2 ARP 決議 MAC 地址
- 8.3 DNS 決議域名
- 8.4 HTTP 請求頁面
- 參考
1 網路應用模型
1.1 概述

1.2 網路應用模型
1.2.1 客戶/服務器模型(Client/Server)

1.2.2 P2P模型(Peer-to-Peer)
在P2P模型中,各計算機沒有固定的客戶和服務器劃分,相反,任意一一對計算機一稱為對等方(Peer), 直接相互通信,

2 域名系統DNS
DNS 是一個分布式資料庫,提供了主機名和 IP 地址之間相互轉換的服務,這里的分布式資料庫是指,每個站點只保留它自己的那部分資料,
2.1 域名
因特網采用層次樹狀結構的命名方法,采用這種命名方法,任何一個連接到因特網的主機或路由器,都有一個唯一的層次結構名稱,即域名(Domain Name),
域名具有層次結構,從上到下依次為:根域名、頂級域名、二級域名,

DNS 可以使用 UDP 或者 TCP 進行傳輸,使用的埠號都為 53,大多數情況下 DNS 使用 UDP 進行傳輸,這就要求域名決議器和域名服務器都必須自己處理超時和重傳從而保證可靠性,在兩種情況下會使用 TCP 進行傳輸:
- 如果回傳的回應超過的 512 位元組(UDP 最大只支持 512 位元組的資料),
- 區域傳送(區域傳送是主域名服務器向輔助域名服務器傳送變化的那部分資料),
2.2 域名服務器
因特網的域名系統被設計成一個聯機分布式的資料庫系統,并采用客戶/服務器模型,DNS服務器有很多臺,根據層次結構分為三層,根域名服務器、頂級域名服務器、權限域名服務器,

2.3 域名決議程序
域名決議是指把域名映射成為IP地址或把IP地址映射成域名的程序,前者稱為正向決議,后者稱為反向決議,
- 當客戶端需要域名決議時,通過本機的DNS客戶端構造一個
DNS請求報文,以UDP資料報方式發往本地域名服務器, - 域名決議有兩種方式:遞回查詢和遞回與迭代相結合的查詢,

3 檔案傳送協議FTP
檔案傳輸協議( File Transfer Protocol, FTP)是因特網上使用得最廣泛的檔案傳輸協議,
- 提供不同種類主機系統(硬、軟體體系等都可以不同)之間的檔案傳輸能力,
- 以用戶權限管理的方式提供用戶對遠程FTP服務器上的檔案管理能力,
- 以匿名FTP的方式提供
公用檔案共享的能力,
FTP 使用 TCP 進行連接,它需要兩個并行連接來傳送一個檔案:
- 控制連接:服務器打開埠號 21 等待客戶端的連接,客戶端主動建立連接后,使用這個連接將客戶端的命令傳送給服務器,并傳回服務器的應答,
- 資料連接:用來傳送一個檔案資料,埠號為20,
根據資料連接是否是服務器端主動建立,FTP 有主動和被動兩種模式:
-
主動模式:服務器端主動建立資料連接,其中服務器端的埠號為 20,客戶端的埠號隨機,但是必須大于 1024,因為 0~1023 是熟知埠號,
-
被動模式:客戶端主動建立資料連接,其中客戶端的埠號由客戶端自己指定,服務器端的埠號隨機,

主動模式要求客戶端開放埠號給服務器端,需要去配置客戶端的防火墻,被動模式只需要服務器端開放埠號即可,無需客戶端配置防火墻,但是被動模式會導致服務器端的安全性減弱,因為開放了過多的埠號,
4 動態主機配置協議DHCP
DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的連網方式,用戶不再需要手動配置 IP 地址等資訊,
DHCP 配置的內容不僅是 IP 地址,還包括子網掩碼、網關 IP 地址,
DHCP 作業程序如下:
- 客戶端發送 Discover 報文,該報文的目的地址為 255.255.255.255:67,源地址為 0.0.0.0:68,被放入 UDP 中,該報文被廣播到同一個子網的所有主機上,如果客戶端和 DHCP 服務器不在同一個子網,就需要使用中繼代理,
- DHCP 服務器收到 Discover 報文之后,發送 Offer 報文給客戶端,該報文包含了客戶端所需要的資訊,因為客戶端可能收到多個 DHCP 服務器提供的資訊,因此客戶端需要進行選擇,
- 如果客戶端選擇了某個 DHCP 服務器提供的資訊,那么就發送 Request 報文給該 DHCP 服務器,
- DHCP 服務器發送 Ack 報文,表示客戶端此時可以使用提供給它的資訊,
5 電子郵件協議
電子郵件是一種異步通信方式,通信時不需要雙方同時在場,電子郵件把郵件發送到收件人使用的郵件服務器,并放在其中的收件人郵箱中,收件人可以隨時上網到自己使用的郵件服務器進行讀取,
一個電子郵件系統由三部分組成:用戶代理、郵件服務器以及郵件協議,

郵件協議包含發送協議和讀取協議,發送協議常用 SMTP,讀取協議常用 POP3 和 IMAP,

5.1 簡單郵件傳送協議SMTP

由于SMTP 只能發送 ASCII 碼,而互聯網郵件擴充 MIME 可以發送二進制檔案,MIME 并沒有改動或者取代 SMTP,而是增加郵件主體的結構,定義了非 ASCII 碼的編碼規則,

5.2 郵局協議POP3
POP3 的特點是只要用戶從服務器上讀取了郵件,就把該郵件洗掉,但最新版本的 POP3 可以不洗掉郵件,
5.3 網際報文存取協議IMAP
因特網報文存取協議(IMAP)比POP復雜得多,IMAP為用戶提供了創建檔案夾、在不同檔案夾之間移動郵件及在遠程檔案夾中查詢郵件的命令,為此IMAP服務器維護了會話用戶的狀態資訊,
IMAP的另一特性是允許用戶代理只獲取報文的某些部分,例如可以只讀取一個報文的首部,或一個多部分MIME報文的一部分,
IMAP 協議中客戶端和服務器上的郵件保持同步,如果不手動洗掉郵件,那么服務器上的郵件也不會被洗掉,IMAP 這種做法可以讓用戶隨時隨地去訪問服務器上的郵件,
6 萬維網和HTTP協議
6.1 萬維網概述
萬維網(World Wide Web, WWW)是一個資料空間,在這個空間中: 一個有用的事物就被稱為“資源”,并由一個全域“統一資源定位符”(URL)標識,這些資源通過超文本傳輸協議(HTTP)傳送給使用者,通過單擊鏈接來獲取資源,

6.2 超文本傳輸協議HTTP
HTTP定義了瀏覽器(萬維網客戶行程)怎樣向萬維網服務器請求萬維網檔案,以及服務器怎樣把檔案傳送給瀏覽器,
從層次的角度看,HTTP是面向事務的(Transaction-oriented) 應用層協議,它規定了在瀏覽器和服務器之間的請求和回應的格式與規則,是萬維網上能夠可靠地交換檔案(包括文本、聲音、影像等各種多媒體檔案)的重要基礎,

6.2.1 特點

非持久連接與持久連接都是在TCP建立連接第三次握手時發生,
對于非持久連接,每個網頁元素物件(如JPEG圖形、Flash 等)的傳輸都需要單獨建立一個TCP連接,如圖所示(第三次握手的報文段中捎帶了客戶對萬維網檔案的請求),也就是說,請求一個萬維網檔案所需的時間是該檔案的傳輸時間(與檔案大小成正比)加上兩倍往返時間RTT(一個RTT用于TCP連接,另一個RTT用于請求和接收檔案),
持久連接,是指萬維網服務器在發送回應后仍然保持這條連接,使同一個客戶和服務器可以繼續在這條連接上傳送后續的HTTP請求與回應報文,
持久連接又分為非流水線和流水線兩種方式,
對于非流水線方式,客戶在收到前一個回應后才能發出下一個請求;
HTTP/1.1 的默認方式是使用流水線的持久連接,這種情況下,客戶每遇到一個物件參考就立即發出一個請求,因而客戶可以逐個地連續發出對各個參考物件的請求,如果所有的請求和回應都是連續發送的,那么所有參考的物件共計經歷1個RTT延遲,而不是像非流水線方式那樣,每個參考都必須有1個RTT延遲,

6.2.2 HTTP的報文結構
HTTP是面向文本的(Text-Oriented), 因此報文中的每個欄位都是一一些ASCII碼串,并且每個欄位的長度都是不確定的,有兩類HTTP報文:
- 請求報文——從客戶向服務器發送的請求報文
- 回應報文——從服務器到客戶的回答

例如:

7 常用埠
| 應用 | 應用層協議 | 埠號 | 傳輸層協議 | 備注 |
|---|---|---|---|---|
| 域名決議 | DNS | 53 | UDP/TCP | 長度超過 512 位元組時使用 TCP |
| 動態主機配置協議 | DHCP | 67/68 | UDP | |
| 簡單網路管理協議 | SNMP | 161/162 | UDP | |
| 檔案傳送協議 | FTP | 20/21 | TCP | 控制連接 21,資料連接 20 |
| 遠程終端協議 | TELNET | 23 | TCP | |
| 超文本傳送協議 | HTTP | 80 | TCP | |
| 簡單郵件傳送協議 | SMTP | 25 | TCP | |
| 郵件讀取協議 | POP3 | 110 | TCP | |
| 網際報文存取協議 | IMAP | 143 | TCP |
8 Web 頁面請求程序
8.1 DHCP 配置主機資訊
-
假設主機最開始沒有 IP 地址以及其它資訊,那么就需要先使用 DHCP 來獲取,
-
主機生成一個 DHCP 請求報文,并將這個報文放入具有目的埠 67 和源埠 68 的 UDP 報文段中,
-
該報文段則被放入在一個具有廣播 IP 目的地址(255.255.255.255) 和源 IP 地址(0.0.0.0)的 IP 資料報中,
-
該資料報則被放置在 MAC 幀中,該幀具有目的地址 FF:FF:FF:FF:FF:FF,將廣播到與交換機連接的所有設備,
-
連接在交換機的 DHCP 服務器收到廣播幀之后,不斷地向上分解得到 IP 資料報、UDP 報文段、DHCP 請求報文,之后生成 DHCP ACK 報文,該報文包含以下資訊:IP 地址、DNS 服務器的 IP 地址、默認網關路由器的 IP 地址和子網掩碼,該報文被放入 UDP 報文段中,UDP 報文段有被放入 IP 資料報中,最后放入 MAC 幀中,
-
該幀的目的地址是請求主機的 MAC 地址,因為交換機具有自學習能力,之前主機發送了廣播幀之后就記錄了 MAC 地址到其轉發介面的交換表項,因此現在交換機就可以直接知道應該向哪個介面發送該幀,
-
主機收到該幀后,不斷分解得到 DHCP 報文,之后就配置它的 IP 地址、子網掩碼和 DNS 服務器的 IP 地址,并在其 IP 轉發表中安裝默認網關,
8.2 ARP 決議 MAC 地址
-
主機通過瀏覽器生成一個 TCP 套接字,套接字向 HTTP 服務器發送 HTTP 請求,為了生成該套接字,主機需要知道網站的域名對應的 IP 地址,
-
主機生成一個 DNS 查詢報文,該報文具有 53 號埠,因為 DNS 服務器的埠號是 53,
-
該 DNS 查詢報文被放入目的地址為 DNS 服務器 IP 地址的 IP 資料報中,
-
該 IP 資料報被放入一個以太網幀中,該幀將發送到網關路由器,
-
DHCP 程序只知道網關路由器的 IP 地址,為了獲取網關路由器的 MAC 地址,需要使用 ARP 協議,
-
主機生成一個包含目的地址為網關路由器 IP 地址的 ARP 查詢報文,將該 ARP 查詢報文放入一個具有廣播目的地址(FF:FF:FF:FF:FF:FF)的以太網幀中,并向交換機發送該以太網幀,交換機將該幀轉發給所有的連接設備,包括網關路由器,
-
網關路由器接收到該幀后,不斷向上分解得到 ARP 報文,發現其中的 IP 地址與其介面的 IP 地址匹配,因此就發送一個 ARP 回答報文,包含了它的 MAC 地址,發回給主機,
8.3 DNS 決議域名
-
知道了網關路由器的 MAC 地址之后,就可以繼續 DNS 的決議程序了,
-
網關路由器接收到包含 DNS 查詢報文的以太網幀后,抽取出 IP 資料報,并根據轉發表決定該 IP 資料報應該轉發的路由器,
-
因為路由器具有內部網關協議(RIP、OSPF)和外部網關協議(BGP)這兩種路由選擇協議,因此路由表中已經配置了網關路由器到達 DNS 服務器的路由表項,
-
到達 DNS 服務器之后,DNS 服務器抽取出 DNS 查詢報文,并在 DNS 資料庫中查找待決議的域名,
-
找到 DNS 記錄之后,發送 DNS 回答報文,將該回答報文放入 UDP 報文段中,然后放入 IP 資料報中,通過路由器反向轉發回網關路由器,并經過以太網交換機到達主機,
8.4 HTTP 請求頁面
-
有了 HTTP 服務器的 IP 地址之后,主機就能夠生成 TCP 套接字,該套接字將用于向 Web 服務器發送 HTTP GET 報文,
-
在生成 TCP 套接字之前,必須先與 HTTP 服務器進行三次握手來建立連接,生成一個具有目的埠 80 的 TCP SYN 報文段,并向 HTTP 服務器發送該報文段,
-
HTTP 服務器收到該報文段之后,生成 TCP SYN ACK 報文段,發回給主機,
-
連接建立之后,瀏覽器生成 HTTP GET 報文,并交付給 HTTP 服務器,
-
HTTP 服務器從 TCP 套接字讀取 HTTP GET 報文,生成一個 HTTP 回應報文,將 Web 頁面內容放入報文主體中,發回給主機,
-
瀏覽器收到 HTTP 回應報文后,抽取出 Web 頁面內容,之后進行渲染,顯示 Web 頁面,
參考
計算機網路
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/224023.html
標籤:python
上一篇:藍橋杯大賽
