計算機網絡基礎（3）

DNS

域名系統是因特網的一項服務。它做爲將域名和 IP 地址相互映射的一個分佈式數據庫，
可以令人更方便的訪問互聯網。
DNS 使用 TCP 和 UDP 端口 53

任何一個鏈接在因特網上的主機或路由器，都有一個惟一的層次結構的名字，即域名。
因特網的域名系統DNS被設計成一個聯機分佈式數據庫系統，並採用CS方式。採用層次結構的命名樹做爲主機的名字。

許多應用層軟件常常直接使用域名系統 DNS，但計算機的用戶只是間接而不是直接使用域名系統

名字到 IP 地址的解析是由若干個域名服務器程序完成的。域名服務器程序在專設的結點上運行，運行該程序的機器稱爲域名服務器。

因特網的域名結構

層次樹狀結構的命名方法:

… . 三級域名 . 二級域名 . 頂級域名

域名服務器

一個服務器所負責管轄的（或有權限的）範圍叫作區.每個區設置相應的權限域名服務器，用來保存該區中的全部主機的域名到IP地址的映射.

根域名服務器是最重要的域名服務器。全部的根域名服務器都知道全部的頂級域名服務器的域名和 IP 地址。
不論是哪個本地域名服務器，若要對因特網上任何一個域名進行解析，只要本身沒法解析，就首先求助於根域名服務器. 根域名服務器並不直接把域名直接轉換成 IP 地址。在使用迭代查詢時，根域名服務器把下一步應當找的頂級域名服務器的 IP 地址告訴本地域名服務器

本地域名服務器對域名系統很是重要。
當一個主機發出 DNS 查詢請求時，這個查詢請求報文就發送給本地域名服務器。

域名解析過程

主機向本地域名服務器的查詢通常都是採用遞歸查詢。
本地域名服務器向根域名服務器的查詢一般是採用迭代查詢

---

HTTP

HTTP協議定義了瀏覽器（萬維網客戶進程）怎樣向萬維網服務器請求萬維網文檔以及服務器怎樣把文檔傳送給瀏覽器。

從層次的角度，HTTP是面向事務的應用層協議。它是萬維網上可以可靠地交換文件的重要基礎。它使用TCP鏈接進行可靠的傳送。 HTTP自己是無鏈接的。HTTP協議是無狀態的。(同一個客戶第二次訪問同一個服務器上的頁面時，服務器響應與第一次相同。)

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

(2) 用何協議實現萬維網上各類超鏈的連接？ 
在萬維網客戶程序與萬維網服務器程序之間進行交互所使用的協議，是`超文本傳送協議 HTTP `
HTTP 是一個`應用層協議`，它使用 TCP 鏈接進行`可靠`的傳送。

(3) 怎樣使各類萬維網文檔都能在因特網上的各類計算機上顯示出來，
同時使用戶清楚地知道在什麼地方存在着超鏈？ 
超文本標記語言 HTML (HyperText Markup Language)使得萬維網頁面的設計者
能夠很方便地用一個超鏈從本頁面的某處連接到因特網上的任何一個萬維網頁面，
而且可以在本身的計算機屏幕上將這些頁面顯示出來。 

(4) 怎樣使用戶可以很方便地找到所需的信息？ 
爲了在萬維網上方便地查找信息，用戶可以使用各類的搜索工具（即搜索引擎）。

每一個萬維網網點都有一個服務器進程，它不斷地監聽TCP的端口80，以便發現是否有瀏覽器向它發出鏈接創建請求。一旦監聽到鏈接創建請求，就創建TCP。這以後，瀏覽器就像萬維網服務器發出瀏覽整個頁面的請求.服務器接着就返回所請求的頁面做爲響應。最後TCP鏈接就被釋放了。

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

(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有兩類報文：
1. 請求報文 -- 從客戶向服務器發出請求報文
2. 響應報文 -- 從服務器獲得客戶的回答

HTTP請求/響應報文都是由三部分組成，報文區別就是開始行不一樣。
1 開始行
請求報文 ： 請求行（方法，url， 版本）

e.g. GET /chn/yxsz/index.htm http/1.1

響應報文： 狀態行（版本，狀態碼，短語）

e.g. HTTP/1.1 202 Accepted {接受}

2 首部行

3 實體主體

cookie 做用

HTTP是無狀態的，若是想讓HTTP服務器和客戶之間傳遞狀態信息(用cookie傳遞客戶)，就須要用cookie.

使用 Cookie 的網站服務器爲用戶產生一個惟一的識別碼。利用此識別碼，網站就可以跟蹤該用戶在該網站的活動。

狀態碼

全部狀態碼的第一個數字表明瞭響應的五種狀態之一。

1xx : 請求已經接受，須要繼續處理。
2xx : 請求已經被服務器接收、理解
    200 OK
    請求已成功，請求所但願的響應頭或數據體將隨此響應返回。
3xx : 重定向
4xx : 客戶端錯誤
    400 bad request 因爲包含語法錯誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。
    401 unauthorized 當前請求須要用戶驗證。
    403 Forbbiden 服務器已經理解請求，可是拒絕執行它。
    404 Not Found 請求失敗，請求所但願獲得的資源未被在服務器上發現。
    沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的
    405 Method Not Allowed 請求行中指定的請求方法不能被用於請求相應的資源。
    該響應必須返回一個 Allow 頭信息用以表示出當前資源可以接受的請求方法的列表。
    鑑於 PUT，DELETE 方法會對服務器上的資源進行寫操做，
    於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，
    對於此類請求均會返回 405 錯誤。
5xx : 服務器錯誤
    503 Service Unavailable
    因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。
    這個情況是臨時的，而且將在一段時間之後恢復。
    若是可以預計延遲時間，那麼響應中能夠包含一個 Retry-After 頭用以標明這個延遲時間。
    若是沒有給出這個 Retry-After 信息，那麼客戶端應當以處理 500 響應的方式處理它。

    505 HTTP Version Not Supported
    服務器不支持，或者拒絕支持在請求中使用的 HTTP 版本。

HTTP SSL

Https 是一種基於SSL的Http，全部的http數據都是在SSL協議封裝之上傳輸的，Https協議是在Http協議的基礎上，添加了SSL握手以及數據加密傳輸，也屬於應用層協議。

傳輸層安全協議TLS 及其前身安全套接層SSL是一種安全協議，目的是爲互聯網通訊，提供安全及數據完整性保障。在發送方，SSL 接收應用層的數據，對數據進行加密，而後把加了密的數據送往 TCP 套接字。在接收方，SSL 從 TCP 套接字讀取數據，解密後把數據交給應用層。

SSL/TLS 能夠達到
1. 全部信息都是加密傳播，第三方沒法竊聽
2. 具備校驗機制，一旦被篡改，通訊雙發馬上發現
3. 配備身份證書，防止身份被冒充。

SSL/TLS 協議的基本過程是這樣的：
（1） 客戶端向服務器端索要並驗證公鑰。
（2） 雙方協商生成 "對話密鑰"。
（3） 雙方採用 "對話密鑰" 進行加密通訊。

上面過程的前兩步 -- 即「握手階段」
"握手階段" 涉及四次通訊。須要注意的是，"握手階段" 的全部通訊都是明文的.

1. 客戶端發出請求（clientHello）
   客戶端（瀏覽器）先向服務器發出加密通訊的請求。
   客戶端向服務器提供
   (1) 支持的協議版本，TLS1.0？
   (2) 一個客戶端生成的隨機數，稍後用於生成「對話密鑰」
   (3) 支持的加密方法，RSA公鑰加密
   (4) 支持的壓縮方法
2. 服務器迴應（serverHello）
   (1) 確認使用的加密通訊協議版本
   (2) 一個服務器生成的隨機數，稍後用於生成「對話密鑰」
   (3) 確認使用的加密方法，好比RSA公鑰加密
   (4) 服務器證書

3. 客戶端迴應
   客戶端收到服務器迴應後，首先驗證服務器證書。若是證書不是可信機構頒佈，或者證書中的域名與實際域名不一致，或者證書已通過期，就會向訪問者顯示一個警告，有其選擇是否還要通訊。

   若是證書沒有問題，客戶端就會從證書中取出服務器的公鑰。

   then 向服務器發送下面三個信息：
   (1) 一個隨機數。用戶服務器公鑰加密，防止被竊聽。
   (2) 編碼改變通知。表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
   (3) 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的全部內容的 hash 值，用來供服務器校驗。

   --- 一共使用了3個隨機數，用來生成會話密鑰。

4. 服務器作出最後的響應
   服務器在收到客戶端的第三個隨機數pre-master key以後，計算生成本次會話所用的「會話密鑰」。 而後向客戶端最後發送下面的信息：
   （1）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
   （2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的全部內容的 hash 值，用來供客戶端校驗。

   至此，整個握手階段所有結束。接下來，客戶端與服務器進入加密通訊，就徹底是使用普通的 HTTP 協議，只不過用 "會話密鑰" 加密內容。

---

HTTP get/post區別

Http 定義了與服務器交互的不一樣方法，最基本的方法有 4 種，分別是 GET，POST，PUT，DELETE. HTTP 中的 GET，POST，PUT，DELETE 就對應着對這個資源的查 ，改 ，增 ，刪 4 個操做。GET 通常用於獲取 / 查詢 資源信息，而 POST 通常用於更新 資源信息.

語義上： get是獲取指定URL的資源，是讀操做，不管對某個資源get多少次，它的狀態是不會改變的。在這個意義上，咱們說get是安全的（not 密碼學意義/數據保護意義 上的安全）。 由於GET是安全的，因此get返回的內容能夠被瀏覽器，cache服務器緩存起來。

post是對指定資源「追加/添加」數據，因此是不安全的，每次提交的post，參與的代碼都會認爲這個操做會修改操做對象資源的狀態。

安全的是指沒有明顯的對用戶有影響的反作用 (包括修改該資源的狀態)。HTTP 方法裏的 GET 和 HEAD 都是安全的。冪等的是指一個方法不論多少次操做，結果都是同樣。PUT(把內容放到指定 URL)，DELETE(刪除某個 URL 表明的資源)，雖然都修改了資源內容，但屢次操做，結果是相同的，所以和 HEAD，GET 同樣都是冪等的。

因此根據 HTTP 協議，GET 是安全的，也是冪等的，而 POST 既不是安全的，也不是冪等的。

---

想更一進步的支持我，請掃描下方的二維碼，你懂的~!