詳細講解計算機網絡——應用層

應用層協議

在傳輸層之上,便是應用層。傳輸層的 UDP 報文和 TCP 報文段的數據部分就是應用層交付的數據。

在這裡插入圖片描述

應用層直接為用戶提供服務,應用層有很多協議,每一個協議對應著計算機上的一個服務。

不同類型的網絡應用有不同的通信規則,因此應用層協議是多種多樣的,比如DNS、FTP、Telnet、SMTP、HTTP、RIP、NFS等協議都是用於解決其各自的一類問題。

在這裡插入圖片描述

應用層協議(application-layer protocol)定義瞭運行在不同端系統上的應用程序如何相互傳遞報文。

應用層協議定義瞭:

在這裡插入圖片描述

一、DNS

1、DNS 是什麼

DNS 全名叫 Domain Name Server,中文俗稱“域名服務器”

在 Internet 上域名與 IP 地址之間是一一對應的,域名雖然便於人們記憶,但機器之間隻能互相認識IP地址,它們之間的轉換工作稱為域名解析,域名解析需要由專門的域名解析服務器來完成,DNS 就是進行域名解析的服務器,將域名(機器名) 轉換為 IP地址。

DNS 是一個分佈式數據庫,提供瞭主機名和 IP 地址之間相互轉換的服務。

這裡的分佈式數據庫是指,每個站點隻保留它自己的那部分數據。

如果整個因特網都使用一個域名服務器,負荷太大, 所以 DNS 設計成一個分佈式的數據庫,即使單個主機出故障也不會妨礙整個 DNS 系統。

另外 DNS 使得大多數域名都能在本地解析,僅少量解析需要在因特網上通信,因此 DNS 效率很高。

域名和 IP 是一對一關系嗎?

  • 實際上域名和 IP 是多對多關系。
  • 一個 IP 可以被多個域名指向(購買的虛擬主機)
  • 一個域名下也可以有多個 IP(負載均衡)

2、域名結構

  • 域名指的是用點符號分割的計算機名字。
  • IP地址對應著網絡上的各個機器,但由於IP地址沒有具體字面含義,難以記憶,有時IP地址還會經常更換。
  • 引入域名來標識某臺機器。域名是全球唯一的,每次申請域名,都會在域名服務器上查詢是否存在。
  • 所有域名都是以“ . ”開始的。

在這裡插入圖片描述

域名結構是樹狀結構,樹的最頂端代表根域名

  • 下一層是 .com、.cn 等頂級域名。
  • 再下層就是二級、三級、四級域名。

在這裡插入圖片描述

  • 頂級域名代表服務器或網站的性質常見有com(商用)、cn(中國)、net(提供信息)、edu(教育)、gov(政府)等等。

  在這裡插入圖片描述

  • 二級域名:每個人都可以申請的,可以在頂級域名下申請,比如 www.esyc.com中esyc就是一個二級域名。在二級域名下你就可以註冊其他域名瞭。
  • 三級域名:www.mail.esyc.com中mail就是三級域名。在www.esyc.com這個域名註冊這個三級域名的時候無需在征得com域名的同意。即一個域創建子域的時候不需要征求上級同意。

當然域名可以3級可以4級可以5級等等,級別是沒有限制的,隻需要滿足,一個域名的各個組成部分不超過63個字符長,總長不超過255個字符長。

3、域名服務器

在這裡插入圖片描述

● 根域名服務器:最高層次的域名服務器,根域名服務器知道所有頂級域名服務器的域名和IP地址。任何一個本地域名服務器要對互聯網上的任何域名進行解析,隻要自己無法解析,就會首先求助於根域名服務器。

● 頂級域名服務器:管理在該頂級域名服務器下註冊的所有二級域名。當收到DNS查詢請求時,就給出相應的回答(可能是最後的結果,也可能是下一步需要去找的域名服務器的IP地址)。

● 權限域名服務器(權威域名服務器):負責一個區的域名服務器。當一個權威域名服務器不能給出最終的查詢結果時,就會告訴發出請求方,下一步應該去找哪一個權威域名服務器。

● 本地域名服務器(遞歸服務器):主機發出 DNS 查詢請求時,該請求首先會發給本地域名服務器。

理論上講,任何標準域名的解析都需要經過層級式的域名解析。

即首先要通過第一層的根域名服務器的指引,才能去下面的頂級域名服務器尋找。

但是實際應用,提供接入服務的服務商的緩存域名服務器上可能已經有瞭域名與 IP 映射的緩存。

4、DNS 解析流程

● 在瀏覽器中輸入 www.qq.com 域名,瀏覽器先檢查自身緩存中有沒有被解析過的這個域名對應的 IP 地址,如果有,就調用這個 IP 映射,完成域名解析。

● 如果瀏覽器緩存中未命中,操作系統會檢查本地的 hosts 文件是否有該域名和 IP 的映射,如果有,就調用這個IP地址映射,完成域名解析。

● 如果 hosts 裡也沒有這個域名的映射,則向本地域名服務器(LDNS)發送請求,看是否有這個域名的映射關系,如果有,直接返回,完成域名解析。(LDNS 一般在城市的某個角落,距離你不會很遠,一般都會緩存域名解析結果,大約 80% 的域名解析到這裡就完成瞭)

● 如果 LDNS 仍然未命中,LDNS 就向根服務器發送查詢請求,根服務器裡面記錄的都是各個頂級域所在的服務器 IP,根服務器會根據域名後綴返回對應的頂級域名服務器位置。當向根請求 www.qq.com 的時候,根服務器就會返回 .com 服務器的位置信息。

● LDNS 拿到 .com 的權威服務器地址以後,就會詢問 .com 的權威服務器,知不知道 www.qq.com 的位置。這個時候 .com 權威服務器查找並返回 www.qq.com 服務器的地址。LDNS 繼續向 www.qq.com 的權威服務器去查詢這個地址,由 www.qq.com 的服務器給出瞭 IP 地址:202.173.11.10

● LDNS 服務器得到瞭 www.qq.com 對應的 IP 地址後以 DNS 應答包的方式傳遞給客戶機,並把域名和對應的 IP 地址在本地緩存下來。

● 客戶機根據 IP 地址建立連接,並在客戶端緩存域名/IP映射。

在這裡插入圖片描述

簡單來說,其實隻有四步:

在這裡插入圖片描述

5、DNS 服務器查詢方式

在這裡插入圖片描述

(1)迭代查詢

DNS 服務器會向客戶機提供其他能夠解析查詢請求的 DNS 服務器地址。

  • 當客戶機發送查詢請求時,DNS 服務器並不直接回復查詢結果,而是告訴客戶機另一臺 DNS 服務器地址,
  • 客戶機再向這臺 DNS 服務器提交請求,依次循環直到返回查詢的結果為止。
  • 迭代查詢返回的是最佳的查詢點或者主機地址。本地域名服務器向根域名服務器的查詢通常是采用迭代查詢。

在這裡插入圖片描述

(2)遞歸查詢

DNS 服務器必須使用一個準確的查詢結果回復客戶機。

  • 如果DNS 服務器本地沒有存儲查詢目標的 DNS 信息,那麼該服務器會去詢問其他服務器(即代替客戶機去查詢,而不是讓客戶機自己進行下一步查詢),並將返回的查詢結果提交給客戶機。
  • 因此,遞歸查詢返回的查詢結果或者是所要查詢的IP地址,或者是報錯(表示無法查詢到所需的 IP 地址)。主機向本地域名服務器的查詢一般都是采用遞歸查詢。

在這裡插入圖片描述

6、DNS 緩存機制

DNS 緩存不僅產生於操作系統,瀏覽器、應用程序以及 ISP(網絡服務提供商)都會對 DNS 進行緩存。

一條域名的 DNS 記錄會在本地有兩種緩存:瀏覽器緩存和操作系統緩存。

  • 在瀏覽器中訪問的時候,會優先訪問瀏覽器緩存,如果未命中再訪問OS緩存,
  • 最後再訪問 DNS 服務器(一般是ISP提供),然後 DNS 服務器會遞歸式的查找域名記錄並返回結果。

DNS 記錄會有一個 TTL 值(Time To Live,存活時間),單位是秒,代表這條記錄最長有效期是多少。

瀏覽器 DNS 緩存的時間跟 DNS 服務器返回的 TTL 值無關。

應用程序的 DNS 緩存是由應用程序控制的,比如 Java 網絡應用程序的 DNS 緩存是由 JVM 的緩存策略控制的。

OS 緩存會參考 DNS 服務器響應的 TTL 值,但是不完全等於 TTL 值。

● 瀏覽器 DNS 緩存:瀏覽器在獲取網站域名的實際 IP 地址後會對其 IP 進行緩存,減少網絡請求的損耗。每種瀏覽器都有一個固定的 DNS 緩存時間,其中 Chrome 的過期時間是 1 分鐘,在這個期限內不會重新請求 DNS。Chrome 瀏覽器看本身的 DNS 緩存時間比較方便,在地址欄輸入:chrome://net-internals/#dns,就能看到看瀏覽器的緩存。

● Java DNS 緩存:Java 網絡應用程序的 DNS 緩存是由 JVM 的緩存策略控制的,可以直接設置緩存過期時間:java.security.Security.setProperty(“networkaddress.cache.ttl”, 10);

● ISP DNS 緩存:一般 ISP 服務器上緩存時間(15 min)比 OS 緩存時間長,就算刷新瞭本機操作系統的緩存,ISP 上仍然保留。

● Windows DNS 緩存:Windows 訪問 DNS 後會把記錄保存一段短暫的時間,可通過 ipconfig /displaydns 查看 windows 的 DNS 緩存、通過 ipconfig /flushdns 來清除緩存。

● IOS DNS 緩存:按照官方文檔說法,IOS 設備上每 24 小時刷新一次 DNS 緩存。

7、DNS 使用 UDP 還是 TCP

DNS 占用 53 號端口,同時使用 TCP 和 UDP 協議。

DNS 在進行區域傳輸的時候使用 TCP 協議,其它時候則使用 UDP 協議;

DNS 有兩種類型的 DNS 服務器:主 DNS 服務器和輔助 DNS 服務器

  • 在一個區中主 DNS 服務器從自己本機的數據文件中讀取該區的 DNS 數據信息而輔助 DNS 服務器則從區的主 DNS 服務器中讀取該區的 DNS 數據信息。
  • 當一個輔助 DNS 服務器啟動時,它需要與主 DNS 服務器通信,並加載數據信息,即區域傳輸(zone transfer)。

區域傳送(主、輔 DNS 服務器通信)時使用 TCP

輔 DNS 服務器會定時(一般時3小時)向主域名服務器進行查詢以便瞭解數據是否有變動。

如有變動,則會執行一次區域傳送,進行數據同步。

區域傳送將使用 TCP而不是 UDP,因為數據同步傳送的數據量比較大。

TCP是一種可靠的連接,保證瞭數據的準確性。

域名解析時使用 UDP

客戶端向 DNS 服務器查詢域名,一般返回的內容都不超過 512 字節,用 UDP 傳輸即可。不用經過 TCP 三次握手,這樣 DNS 服務器負載更低,響應更快。雖然從理論上說,客戶端也可以指定向 DNS 服務器查詢的時候使用 TCP,但事實上,很多 DNS 服務器進行配置的時候,僅支持 UDP 查詢包。

二、萬維網

1、萬維網概述

  • 萬維網 WWW (World Wide Web) 並非某種特殊的計算機網絡。
  • 萬維網是一個大規模的、聯機式的信息儲藏所。
  • 萬維網用鏈接的方法能非常方便地從互聯網上的一個站點訪問另一個站點,從而主動地按需獲取豐富的信息。

這種訪問方式稱為“鏈接”。

在這裡插入圖片描述

通俗的來說萬維網的使用就是我們通過遊覽器進行網絡的通信,得到的是網頁及其其他的數據。

(1)超媒體與超文本

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

(2)萬維網的工作方式

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

(3)萬維網必須解決的問題

1)怎樣標志分佈在整個互聯網上的萬維網文檔?

使用統一資源定位符 URL (Uniform Resource Locator) 來標志萬維網上的各種文檔。使每一個文檔在整個互聯網的范圍內具有唯一的標識符 URL。

2)用何協議實現萬維網上各種超鏈的鏈接?

在萬維網客戶程序與萬維網服務器程序之間進行交互所使用的協議,是超文本傳送協議 HTTP (HyperText Transfer Protocol)。HTTP 是一個應用層協議,它使用 TCP 連接進行可靠的傳送。

3)怎樣使各種萬維網文檔都能在互聯網上的各種計算機上顯示出來,同時使用戶清楚地知道在什麼地方存在著超鏈?

超文本標記語言 HTML (HyperText Markup Language) 使得萬維網頁面的設計者可以很方便地用一個超鏈從本頁面的某處鏈接到互聯網上的任何一個萬維網頁面,並且能夠在自己的計算機屏幕上將這些頁面顯示出來。

4)怎樣使用戶能夠很方便地找到所需的信息?

為瞭在萬維網上方便地查找信息,用戶可使用各種的搜索工具(即搜索引擎)。

2、超文本傳送協議 HTTP

(1)HTTP 的操作過程

為瞭使超文本的鏈接能夠高效率地完成,需要用 HTTP 協議來傳送一切必須的信息。

從層次的角度看,HTTP 是面向事務的(transaction-oriented)應用層協議,它是萬維網上能夠可靠地交換文件(包括文本、聲音、圖像等各種多媒體文件)的重要基礎。

在這裡插入圖片描述

(2)請求一個萬維網文檔所需的時間

在這裡插入圖片描述

每次的數據傳輸度需要進行建立連接與釋放連接的過程,為瞭提高傳輸的效率,提出瞭以下幾種方案:

不釋放連接、流水操作、代理服務器。

1)不釋放連接

  • HTTP/1.0 協議每次傳完一個萬維網文檔後會釋放連接,故每請求一個文檔需要2×RTT的開銷。
  • 萬維網服務器在發送響應後仍然在一段時間內保持這條連接,使同一個客戶(瀏覽器)和該服務器可以繼續在這條連接上傳送後續的 HTTP 請求報文和響應報文。
  • 這並不局限於傳送同一個頁面上鏈接的文檔,而是隻要這些文檔都在同一個服務器上就行。
  • 目前一些流行的瀏覽器(例如,IE 6.0)的默認設置就是使用 HTTP/1.1。

2)流水與非流水

  • 非流水線方式:客戶在收到前一個響應後才能發出下一個請求。這使得客戶每訪問一次對象都隻需要一個 RTT 時間。但服務器在發送完一個對象後,其 TCP 連接就處於空閑狀態,浪費瞭服務器資源。
  • 流水線方式:客戶在收到 HTTP 的響應報文之前就能夠接著發送新的請求報文。一個接一個的請求報文到達服務器後,服務器就可連續發回響應報文。使用流水線方式時,客戶訪問所有對象隻需要花費一個 RTT時間,使 TCP 連接中的空閑時間減少,提高瞭下載文檔效率。

3)代理服務器

  • 代理服務器 (proxy server) 又稱為萬維網高速緩存 (Web cache),它代表瀏覽器發出 HTTP 請求。
  • 萬維網高速緩存把最近的一些請求和響應暫存在本地磁盤中。
  • 當與暫時存放的請求相同的新請求到達時,萬維網高速緩存就把暫存的響應發送出去,而不需要按 URL 的地址再去互聯網訪問該資源。
  • 代理服務器既是一個服務器,有時也是一個客戶。

3、萬維網的文檔

(1)超文本標記語言 HTML

HTML

(HyperText Markup Language) 中的 Markup 的意思就是“設置標記”。

在這裡插入圖片描述

當瀏覽器從服務器讀取 HTML 文檔後,就按照 HTML 文檔中的各種標簽,根據瀏覽器所使用的顯示器尺寸和分辨率大小,重新排版並恢復出所讀取的頁面。

兩種不同的鏈接:

在這裡插入圖片描述

HTML還規定瞭鏈接的設置方法。每個鏈接都有一個起點和終點。

XML
  • XML (Extensible Markup Language)是可擴展標記語言,它和HTML很相似。
  • 但XML的設計宗旨是傳輸數據,而不是顯示數據(HTML是為瞭在瀏覽器上顯示數據)。
  • XML 不是要替換 HTML,而是對 HTML 的補充。
XHTML
  • XHTML (Extensible HTML) 是可擴展超文本標記語言,它與 HTML 4.01 幾乎是相同的。
  • 但 XHTML 是更嚴格的 HTML 版本,也是一個 W3C 標準(2000年1月),是作為一種 XML 應用被重新定義的 HTML,並將逐漸取代 HTML。
  • 新的瀏覽器都支持 XHTML。
CSS
  • CSS (Cascading Style Sheets) 是層疊樣式表,它是一種樣式表語言,用於為 HTML 文檔定義佈局。
  • CSS 與 HTML 的區別就是:HTML 用於結構化內容,而 CSS 則用於格式化結構化的內容。

(2)動態萬維網文檔

靜態文檔是指該文檔創作完畢後就存放在萬維網服務器中,在被用戶瀏覽的過程中,內容不會改變。

動態文檔是指文檔的內容是在瀏覽器訪問萬維網服務器時才由應用程序動態創建。

動態文檔和靜態文檔之間的主要差別體現在服務器一端。

這主要是文檔內容的生成方法不同。而從瀏覽器的角度看,這兩種文檔並沒有區別。

在這裡插入圖片描述

CGI (Common Gateway Interface) 是一種標準,它定義瞭動態文檔應如何創建,輸入數據應如何提供給應用程序,以及輸出結果應如何使用。萬維網服務器與 CGI 的通信遵循 CGI 標準。

在這裡插入圖片描述

(3)活動萬維網文檔

瀏覽器屏幕的連續刷新

在這裡插入圖片描述

每當瀏覽器請求一個活動文檔時,服務器就返回一段程序副本在瀏覽器端運行。

活動文檔程序可與用戶直接交互,並可連續地改變屏幕顯示。

由於活動文檔技術不需要服務器的連續更新傳送,對網絡帶寬的要求也不會太高。

在這裡插入圖片描述

三、HTTP 與 HTTPs 協議

  • HTTP 是用於從萬維網(WWW)服務器傳輸超文本到本地瀏覽器的傳送協議,是基於 TCP/IP 協議之上的應用層協議。
  • HTTP 定義瞭客戶端如何從服務器請求 Web 頁面,以及服務器如何把 Web 頁面傳送給客戶端。
  • HTTP 采用瞭請求 / 響應模型,客戶端向服務器發送一個請求報文,服務器以一個狀態行作為響應。

1、HTTP 特點

(1)簡單快速:

客戶向服務器請求服務時,隻需傳送請求方法和路徑。

請求方法常用的有 GET、HEAD、POST。

每種方法規定瞭客戶與服務器聯系的類型不同。

由於 HTTP 協議簡單,使得 HTTP 服務器的程序規模小,因而通信速度很快。

(2)靈活:

HTTP 允許傳輸任意類型的數據對象。 正在傳輸的類型由 Content-Type 加以標記。

(3)無連接:

無連接的含義是限制每次連接隻處理一個請求。

服務器處理完客戶的請求,並收到客戶的應答後立即斷開連接。

采用這種方式可以節省傳輸時間。

HTTP使用TCP協議作為它的支撐運輸協。

HTTP客戶首先發起一個與服務器的TCP連接,一旦建立連接,該瀏覽器和服務器就可以通過套接字接口訪問TCP。

(4)無狀態保存:

HTTP 協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。

  • 缺少狀態意味著如果後續處理需要前面的信息,則它必須重傳,這樣可能導致每次連接傳送的數據量增大(缺點)。
  • 另一方面,在服務器不需要先前信息時它的應答就較快,可以更快地處理大量事務(優點)。

補充:對於無狀態保存,如果用戶登錄一傢購物網站,希望即使用戶跳轉到該站的其他頁面也能繼續保持登錄狀態。HTTP/1.1 雖然是無狀態協議,但為瞭實現保存狀態的功能,引入瞭 Cookie 技術。

對於無連接,早期的 HTTP 是請求響應之後直接斷開,但現在的 HTTP/1.1 不直接斷開,而是等幾秒鐘,如果用戶在這幾秒鐘之內有新的請求,那麼還是通過之前的連接通道來收發消息,如果過瞭這幾秒鐘用戶沒有發送新的請求,那麼就會斷開連接,這樣可以提高效率,減少短時間內建立連接的次數,因為建立連接也是耗時的。

(5)支持 B/S 及 C/S 模式。

2、HTTP 各版本比較

在這裡插入圖片描述

3、HTTP 的請求與響應報文

(1)HTTP 請求(Request)

客戶端發送一個 HTTP 請求到服務器的請求消息包括:請求行(request line)、請求頭部(header)、空行和請求數據四個部分。

在這裡插入圖片描述

HTTP 請求行

在這裡插入圖片描述

HTTP 請求頭

請求頭信息為 “名:值” 對,之間用冒號分隔。

請求頭參數包括:

在這裡插入圖片描述 在這裡插入圖片描述 在這裡插入圖片描述

空行

HTTP 請求頭的最後會有一個空行,表示請求頭部結束,接下來為請求數據,空行一定要有。

請求數據

請求數據不一定有,比如 get 請求就沒有請求數據。

(2)HTTP 響應(Response)

服務器接收並處理客戶端發過來的請求後會返回一個 HTTP 的響應消息,響應包括:狀態行、響應頭部、空行和響應正文四個部分。

在這裡插入圖片描述

狀態行:

包括協議版本、狀態碼和狀態碼描述。協議版本和請求報文一致,狀態碼是一個 3 位數字。

在這裡插入圖片描述

比較常見的狀態碼有:

  • 200 表示響應成功;
  • 302 表示跳轉,跳轉地址通過響應頭中的 Location 屬性指定;
  • 400 表示客戶端請求有語法錯誤,不能被服務器識別;
  • 403 表示服務器接收到請求,但拒絕提供服務(認證失敗);
響應頭部

這裡是引用

4、HTTP 請求響應步驟

(1)客戶端連接到 Web 服務器

用戶確定要訪問網頁的URL,並將其輸入到瀏覽器的地址欄中,瀏覽器向DNS服務器發出請求,獲取Web服務器域名所對應的IP地址。

HTTP 客戶端通常就是瀏覽器,與 Web 服務器的 HTTP 端口(默認為 80)建立一個 TCP 套接字連接,比如http://www.abc.com;

(2)發送 HTTP 請求

通過 TCP 套接字,客戶端向 Web 服務器發送一個請求傳輸網頁的 HTTP 請求報文。

一個請求報文由請求行、請求頭部、空行和請求數據 4 部分組成;

(3)服務器接受請求並返回 HTTP 響應

Web 服務器解析請求,定位請求資源並將資源復本寫到 TCP 套接字,由客戶端讀取。

一個響應由 狀態行、響應頭部、空行和響應數據 4 部分組成;

(4)釋放 TCP 連接

若 connection 模式為 close,則服務器主動關閉 TCP 連接,客戶端被動關閉連接,TCP 連接釋放;

若 connection 模式為 keepalive,則該連接會保持一段時間,在該時間內可以繼續接收請求;

(5)客戶端瀏覽器解析 HTML 內容

客戶端瀏覽器首先解析狀態行,查看表明請求是否成功的狀態代碼。

然後解析每一個響應頭,響應頭告知以下為若幹字節的 HTML 文檔和文檔的字符集。

客戶端瀏覽器讀取響應數據 HTML,根據 HTML 的語法對其進行格式化,並在瀏覽器窗口中顯示;

在這裡插入圖片描述

5、HTTPS 協議

HTTPS(Secure Hypertext Transfer Protocol)安全超文本傳輸協議,使用安全套接字層(SSL)進行信息交換

即 HTTPS 是使用瞭 TLS/SSL 加密的 HTTP 協議,基於非對稱加密算法和對稱加密算法的協作使用。

TLS/SSL 指加密的規范,介於 TCP 和 HTTP 之間的安全協議,不影響原有的 TCP 和 HTTP 協議。

在這裡插入圖片描述 在這裡插入圖片描述

(1)TLS/SSL協議的三個特性

TLS/SSL 協議就是客戶端和服務器之間實現安全交換信息的協議。

在這裡插入圖片描述

TLS/SSL 的功能實現主要依賴於三類基本算法:散列函數 Hash、非對稱加密和對稱加密。

  • 先利用非對稱加密實現身份認證和密鑰協商
  • 再通過對稱加密算法用協商好的密鑰對數據加密
  • 最後基於散列函數驗證信息的完整性

在這裡插入圖片描述

(2)SSL 握手過程

● ClientHello:客戶端請求建立 SSL 連接,向服務器提供以下信息:

1)支持的 SSL 協議版本,比如 TLS1.0;

2)客戶端生成的隨機數,用於後續對稱加密階段生成對話密鑰;

3)支持的加密方法,比如RSA公鑰加密。

● SeverHello:服務器對客戶端的請求發出回應,包括以下信息:

1)確認使用的 SSL 協議版本,如果服務器與客戶端支持的版本不一致,服務器關閉通信;

2)服務器生成的隨機數,用於後續對稱加密階段生成對話密鑰;

3)確認使用的加密方法,比如 RSA 公鑰加密;

4)服務器證書。(如果服務器也需要確認客戶端的身份,就會再包含一項信息,即要求客戶端提供客戶端證書,比如金融機構隻允許認證客戶連入自己的網絡)

● 客戶端收到服務器回應後,驗證服務器證書的合法性,如果證書非可信機構頒佈、證書已過期等,會提出警告,選擇是否還要繼續通信。如果證書沒有問題,客戶端就從證書中取出服務器的公鑰。然後向服務器發送三個信息:

1)用公鑰加密的隨機數(pre-master key);

2)編碼改變通知,表示隨後的信息將用雙方商量好的加密方法和密鑰發送;

3)客戶端握手結束通知,這一項同時也是前面發送的所有內容的 hash 值,用於供服務器校驗。

● 服務器的最後回應,服務器收到客戶端的 pre-master key 之後,計算生成本次會話所用的會話密鑰,然後向客戶端發送以下信息:

1)編碼改變通知,表示隨後的信息將用雙方商量好的加密方法和密鑰發送;

2)服務器握手結束通知,這一項同時也是前面發送的所有內容的 hash 值,用於供客戶端校驗。

握手階段結束,客戶端和服務器進入加密通信階段,就是使用 HTTP 協議,隻不過通信內容都用上面商定的會話密鑰進行瞭加密。

在這裡插入圖片描述

(3)非對稱加密和對稱加密

1)非對稱加密:用於在 SSL 握手過程中加密生成的密碼。一對多通信,分為公鑰和私鑰,公鑰加密的信息隻有私鑰能解開(甚至公鑰都不能解密出自己加密的信息),因此掌握公鑰的不同客戶端之間不能互相解密信息。常見非對稱加密算法有 RSA、ECC、DH 等。

2)對稱加密:用於加密真正要傳輸的數據。一對一通信,使用相同的密鑰對信息進行加密和解密,隻有掌握密鑰才能獲取信息,能夠防止信息竊聽。常見的對稱加密算法有 AES-CBC、DES、3DES、AES-GCM 等。不同節點采用的對稱密鑰不同,從而保證瞭信息隻能由通信雙方獲取。

3)Hash 算法:用於驗證數據的完整性。哈希函數特性是單向不可逆,對輸入非常敏感,輸出長度固定,對原始數據的任何修改都會改變散列函數的結果,在這裡用於防止信息篡改並驗證數據的完整性。常見的算法有 MD5、SHA1、SHA256(Secure Hash Algorithm,安全哈希算法)。散列函數不能脫離加密進行信息防篡改,因為明文傳輸時中間人可以修改信息後重新計算信息摘要,因此需要對傳輸的信息及信息摘要進行加密。

6、HTTP 和 HTTPs 區別

在這裡插入圖片描述

HTTPS 優點:

在這裡插入圖片描述

HTTPS 缺點:

在這裡插入圖片描述

7、Web 緩存

Web緩存(Web cache)也叫代理服務器(proxy server)。

在這裡插入圖片描述

(1)WEB緩存的作用

在這裡插入圖片描述

(2)工作過程

1) 瀏覽器和代理服務器建立TCP連接,並將HTTP請求發送到代理服務器

2)代理服務器見檢查本地已存儲對象復本。如果存儲對象在其中,代理服務器向瀏覽器發送HTTP響應報文返回該對象

3)如果代理服務器中沒有該請求對象,代理服務器和源服務器建立TCP連接,然後代理服務器向源服務器發送一個目標對象的HTTP請求。源服務器接到請求後,將請求對象通過HTTP響應發送給代理服務器

4)代理服務器收到請求的對象時,在本地建立該對象的副本,然後通HTTP響應將對象發送給瀏覽器。

8、Web 頁面請求過程

(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 轉發表中安裝默認網關。

(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 地址,發回給主機。

(3)DNS 解析域名

①: 知道瞭網關路由器的 MAC 地址之後,就可以繼續 DNS 的解析過程瞭。

②: 網關路由器接收到包含 DNS 查詢報文的以太網幀後,抽取出 IP 數據報,並根據轉發表決定該 IP 數據報應該轉發的路由器。

③:因為路由器具有內部網關協議(RIP、OSPF)和外部網關協議(BGP)這兩種路由選擇協議,因此路由表中已經配置瞭網關路由器到達 DNS 服務器的路由表項。

④: 到達 DNS 服務器之後,DNS 服務器抽取出 DNS 查詢報文,並在 DNS 數據庫中查找待解析的域名。

⑤: 找到 DNS 記錄之後,發送 DNS 回答報文,將該回答報文放入 UDP 報文段中,然後放入 IP 數據報中,通過路由器反向轉發回網關路由器,並經過以太網交換機到達主機。

(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 頁面。

四、遠程終端協議 TELNET

TELNET 是一個簡單的遠程終端協議,也是互聯網的正式標準。

用戶用 TELNET 就可在其所在地通過 TCP 連接註冊(即登錄)到遠地的另一個主機上(使用主機名或 IP 地址)。

TELNET 能將用戶的擊鍵傳到遠地主機,同時也能將遠地主機的輸出通過 TCP 連接返回到用戶屏幕。

這種服務是透明的,因為用戶感覺到好像鍵盤和顯示器是直接連在遠地主機上。

客戶/服務器方式

現在由於 PC 的功能越來越強,用戶已較少使用 TELNET 瞭。TELNET 也使用客戶/服務器方式。

在本地系統運行 TELNET 客戶進程,而在遠地主機則運行 TELNET 服務器進程。

和 FTP 的情況相似,服務器中的主進程等待新的請求,並產生從屬進程來處理每一個連接。

TELNET 使用網絡虛擬終端 NVT 格式 。

在這裡插入圖片描述

網絡虛擬終端 NVT 格式

客戶軟件把用戶的擊鍵和命令轉換成 NVT 格式,並送交服務器。

服務器軟件把收到的數據和命令,從 NVT 格式轉換成遠地系統所需的格式。

向用戶返數據時,服務器把遠地系統的格式轉換為 NVT 格式,本地客戶再從 NVT 格式轉換到本地系統所需的格式。

五、FTP

文件傳輸協議(FileTransfer Protocol,FTP)屬於 TCP/IP 協議族的應用層協議,其傳輸層使用的是 TCP,基於客戶機/服務器模式工作,為數據傳輸提供瞭可靠保證。

在這裡插入圖片描述

FTP的工作過程

其實就是客戶機程序根據用戶需要發送命令,服務器程序響應命令的過程。

需要建立兩種類型的連接:控制連接和數據連接。

  • 控制連接傳送客戶機程序發出的命令和服務器返回的響應信息
  • 而數據連接則負責傳輸文件的內容。

在這裡插入圖片描述

流程

(1)啟動FTP服務器:

由於FTP采用瞭客戶機/服務器工作模式,因此在創建FTP會話之前,首先必須啟動FTP服務器,並使其處於等待客戶機程序的FTP請求狀態。

(2)啟動FTP客戶機程序並建立控制連接:

啟動FTP客戶機程序,並向FTP服務器的21端口(控制連接端口)發出主動連接的請求,以期獲得FTP服務器的相應權限。服務器響應請求後便在用戶協議解釋器和服務器協議解釋器之間建立瞭一條TCP連接。

(3)建立數據連接並進行文件傳輸:

用戶通過客戶機程序輸入FTP命令,服務器接收命令。如果命令正確且需要進行文件傳輸,服務器使用TCP20端口在雙方之間建立另一條TCP連接,即數據連接,並通過該連接進行文件傳輸。當本次命令的文件傳輸完畢,關閉該數據連接。

(4)關閉FTP:

用戶執行完其所需的FTP命令後,發出退出FTP命令,控制連接關閉,本次FTP服務結束。

常見的命令下:

在這裡插入圖片描述

六、電子郵件傳輸協議

一個電子郵件系統由三部分組成:

用戶代理、郵件服務器以及郵件協議。

在這裡插入圖片描述

需要發送者郵件代理、發送者郵件服務器、接收者郵件服務器,接收者代理4個程序的參與。

● 郵件服務代理(郵件服務器)MTA:郵件服務代理通常是計算機系統中的一個進程,負責把郵件從源端傳輸到目的端。

● 用戶代理:用戶代理就是我們平時見到的Gmail,QQ郵箱之類的,其中有查看郵件等功能。

● 郵件傳輸過程:用戶編寫郵件後會存放在郵件服務器,發送時根據目的郵箱地址從DNS查找對方的郵件服務器地址並發送,目的郵件服務器將郵件存儲 。

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

電子郵件格式:

在這裡插入圖片描述

1、SMTP(Simple Mail Transfer Protocol)

簡單郵件傳輸協議SMTP(下層協議TCP,端口25):一般用於發送郵件即由用戶代理發送到郵件服務器,或郵件服務器到達目的郵件服務器。 SMTP 是建立在傳輸層協議 TCP 上的可靠高效的郵件傳輸協議,采用請求/應答方式來實現。整個工作過程包括連接建立、郵件傳送和連接釋放3個階段。

(1)連接建立:SMTP是基於客戶機/服務器模式工作的,郵件服務器在TCP的25端口守候客戶機的請求。當需要發送郵件時,發送主機的SMTP客戶機向連接主機的SMTP服務器的TCP端口25發出建立連接請求,得到服務器確認後連接建立。此後,SMTP客戶機再次向SMTP服務器發送HELO命令,並附上發送方主機名以確認SMTP服務器是否已經準備好接收郵件。如果SMTP服務器應答“250 XXXX”表示已準備好接收郵件。(2)郵件傳送:SMTP客戶機得到SMTP服務器的肯定回答後,隨即可利用MAIL命令告訴SMTP服務器新的郵件發送操作已經開始。如果SMTP服務器已經準備好接收郵件,則以250應答代碼應答。其後SMTP客戶機可以用RCPT命令發送郵件接收者的目的地址,以便SMTP服務器把郵件內容最終傳送到收件人的郵箱中。如果命令被接收,則返回250應答碼。然後SMTP客戶機可利用DATA命令告訴SMTP服務器下面將要發送郵件內容。如果命令被接收,則SMTP服務器以354應答碼應答,並認定以下的各行都是郵件內容。發送完畢後,再發送

2、POP3

郵局協議版本3POP3協議(下層協議TCP,端口110)用於由郵件服務器接收郵件到用戶代理端。

(1)隻要用戶從服務器上讀取瞭郵件,就把該郵件刪除,但是目前改進的 POP3 已經全面支持下載而不刪除原郵件。

(2)無論你在客戶端做瞭任何操作(如移動、標記),都不會反映到服務器上,也就是隻能單方面地從服務器“讀取”。POP3協議所用的是110端口。

3、IMAP

交互郵件訪問協議IMAP協議(下層協議TCP,端口143)用於由郵件服務器接收郵件到用戶代理端。

IMAP 協議中客戶端和服務器上的郵件保持同步,如果不手動刪除郵件,那麼服務器上的郵件也不會被自動刪除。

IMAP 這種做法可以讓用戶隨時隨地去訪問服務器上的郵件。

同時它與 POP3 的本質區別在於,在客戶端的操作(包括刪除)都會反映到服務器上,是一個雙向的通信。

七、Socket

TCP下的socket

處於應用層和運輸層之間,給出瞭一個接口,可以使用TCP協議進行通信。

在這裡插入圖片描述

TCP 下 socket 流程:

在這裡插入圖片描述

到此這篇關於詳細講解計算機網絡——應用層的文章就介紹到這瞭,更多相關計算機網絡應用層內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: