網絡知識（2）【待完成】

1，Web 頁面請求過程

①網絡配置-②獲取MAC地址-③DNS域名解析-④TCP鏈接創建-⑤HTTP GET 報文發送給服務器-⑥服務器生成HTTP 響應報文-⑦瀏覽器接收數據-⑧提取渲染

1.1 DHCP 配置主機信息

　　若是已經有主機信息既不須要這一步驟【獲取網絡配置信息】

　　①DHCP 請求報文：源端口：68，目標端口：67【默認UDP數據報信息，長度超過 512 字節時使用 TCP】；源ip：0.0.0.0；目標地址：255.255.255.255【IP數據報】；放入MAC幀【數據幀】中；【廣播數據合成】

　　②將上述數據廣播到全部交換機鏈接的設備；

　　③DHCP服務器接收到廣播數據幀，生成DHCP ACK報文，包含：IP 地址、DNS 服務器的 IP 地址、默認網關路由器的 IP 地址和子網掩碼

　　④該幀的目的地址是請求主機的 MAC 地址，由於交換機具備自學習能力，以前主機發送了廣播幀以後就記錄了 MAC 地址到其轉發接口的交換表項，所以如今交換機就能夠直接知道應該向哪一個接口發送該幀。

　　⑤主機收到該幀後，不斷分解獲得 DHCP 報文。以後就配置它的 IP 地址、子網掩碼和 DNS 服務器的 IP 地址，並在其 IP 轉發表中安裝默認網關。

1.2 ARP 解析 MAC 地址【地址解析協議】

• 主機經過瀏覽器生成一個 TCP 套接字，套接字向 HTTP 服務器發送 HTTP 請求。爲了生成該套接字，主機須要知道網站的域名對應的 IP 地址。

• 主機生成一個 DNS 查詢報文，該報文具備 53 號端口，由於 DNS 服務器的端口號是 53。

• 該 DNS 查詢報文被放入目的地址爲 DNS 服務器 IP 地址的 IP 數據報中。

• 該 IP 數據報被放入一個以太網幀中，該幀將發送到網關路由器。

• DHCP 過程只知道網關路由器的 IP 地址，爲了獲取網關路由器的 MAC 地址，須要使用 ARP 協議【廣播接收MAC地址】。

• 主機生成一個包含目的地址爲網關路由器 IP 地址的 ARP 查詢報文，將該 ARP 查詢報文放入一個具備廣播目的地址（FF:FF:FF:FF:FF:FF）的以太網幀中，並向交換機發送該以太網幀，交換機將該幀轉發給全部的鏈接設備，包括網關路由器。

• 網關路由器接收到該幀後，不斷向上分解獲得 ARP 報文，發現其中的 IP 地址與其接口的 IP 地址匹配，所以就發送一個 ARP 回答報文，包含了它的 MAC 地址，發回給主機。

 

1.3 DNS 解析域名【DNS 查詢報文-DNS服務器查詢-UDP回發】

• 知道了網關路由器的 MAC 地址以後，就能夠繼續 DNS 的解析過程了。

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

• 由於路由器具備內部網關協議（RIP、OSPF）和外部網關協議（BGP）這兩種路由選擇協議，所以路由表中已經配置了網關路由器到達 DNS 服務器的路由表項。

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

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

 

2， HTTP 請求頁面

• 有了 HTTP 服務器的 IP 地址以後，主機就可以生成 TCP 套接字，該套接字將用於向 Web 服務器發送 HTTP GET 報文。

• 在生成 TCP 套接字以前，必須先與 HTTP 服務器進行三次握手來創建鏈接【TCP鏈接創建】。生成一個具備目的端口 80 的 TCP SYN 報文段，並向 HTTP 服務器發送該報文段。

• HTTP 服務器收到該報文段以後，生成 TCP SYN ACK 報文段，發回給主機。

• 鏈接創建以後，瀏覽器生成 HTTP GET 報文，並交付給 HTTP 服務器。

• HTTP 服務器從 TCP 套接字讀取 HTTP GET 報文，生成一個 HTTP 響應報文，將 Web 頁面內容放入報文主體中，發回給主機。【數據傳輸】

• 瀏覽器收到 HTTP 響應報文後，抽取出 Web 頁面內容，以後進行渲染，顯示 Web 頁面。

HTTP狀態碼

服務器返回的 響應報文 中第一行爲狀態行，包含了狀態碼以及緣由短語，用來告知客戶端請求的結果。

1XX 信息【正常】

• 100 Continue ：代表到目前爲止都很正常，客戶端能夠繼續發送請求或者忽略這個響應。

2XX 成功【成功】

• 200 OK

• 204 No Content ：請求已經成功處理，可是返回的響應報文不包含實體的主體部分。通常在只須要從客戶端往服務器發送信息，而不須要返回數據時使用。

• 206 Partial Content ：表示客戶端進行了範圍請求，響應報文包含由 Content-Range 指定範圍的實體內容。

3XX 重定向【附加操做】

• 301 Moved Permanently ：永久性重定向

• 302 Found ：臨時性重定向

• 303 See Other ：和 302 有着相同的功能，可是 303 明確要求客戶端應該採用 GET 方法獲取資源。

• 注：雖然 HTTP 協議規定 30一、302 狀態下重定向時不容許把 POST 方法改爲 GET 方法，可是大多數瀏覽器都會在 30一、302 和 303 狀態下的重定向把 POST 方法改爲 GET 方法。

• 304 Not Modified ：若是請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，若是不知足條件，則服務器會返回 304 狀態碼。

• 307 Temporary Redirect ：臨時重定向，與 302 的含義相似，可是 307 要求瀏覽器不會把重定向請求的 POST 方法改爲 GET 方法。

4XX 客戶端錯誤【沒法處理】

• 400 Bad Request ：請求報文中存在語法錯誤。

• 401 Unauthorized ：該狀態碼錶示發送的請求須要有認證信息（BASIC 認證、DIGEST 認證）。若是以前已進行過一次請求，則表示用戶認證失敗。

• 403 Forbidden ：請求被拒絕。

• 404 Not Found：沒有找到頁面。

5XX 服務器錯誤【】

• 500 Internal Server Error ：服務器正在執行請求時發生錯誤。

• 503 Service Unavailable ：服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

 

3 GET 和 POST 比較

做用

　　GET 用於獲取資源，而 POST 用於傳輸實體主體。

參數

　　GET 和 POST 的請求都能使用額外的參數，可是 GET 的參數是以查詢字符串出如今 URL 中，而 POST 的參數存儲在實體主體中。

　　不能由於 POST 參數存儲在實體主體中就認爲它的安全性更高，由於照樣能夠經過一些抓包工具（Fiddler）查看。

　　由於 URL 只支持 ASCII 碼，所以 GET 的參數中若是存在中文等字符就須要先進行編碼。例如 中文 會轉換爲 %E4%B8%AD%E6%96%87，而空格會轉換爲 %20。POST 參數支持標準字符集。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

安全

安全的 HTTP 方法不會改變服務器狀態，也就是說它只是可讀的。

GET 方法是安全的，而 POST 卻不是，由於 POST 的目的是傳送實體主體內容，這個內容多是用戶上傳的表單數據，上傳成功以後，服務器可能把這個數據存儲到數據庫中，所以狀態也就發生了改變。

安全的方法除了 GET 以外還有：HEAD、OPTIONS。

不安全的方法除了 POST 以外還有 PUT、DELETE。

冪等性

冪等的 HTTP 方法，一樣的請求被執行一次與連續執行屢次的效果是同樣的，服務器的狀態也是同樣的。換句話說就是，冪等方法不該該具備反作用（統計用途除外）。

全部的安全方法也都是冪等的。

在正確實現的條件下，GET，HEAD，PUT 和 DELETE 等方法都是冪等的，而 POST 方法不是。

GET /pageX HTTP/1.1 是冪等的，連續調用屢次，客戶端接收到的結果都是同樣的：

GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1
GET /pageX HTTP/1.1

POST /add_row HTTP/1.1 不是冪等的，若是調用屢次，就會增長多行記錄：

POST /add_row HTTP/1.1   -> Adds a 1nd row
POST /add_row HTTP/1.1   -> Adds a 2nd row
POST /add_row HTTP/1.1   -> Adds a 3rd row

DELETE /idX/delete HTTP/1.1 是冪等的，即便不一樣的請求接收到的狀態碼不同：

DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
DELETE /idX/delete HTTP/1.1   -> Returns 404

可緩存

若是要對響應進行緩存，須要知足如下條件：

• 請求報文的 HTTP 方法自己是可緩存的，包括 GET 和 HEAD，可是 PUT 和 DELETE 不可緩存，POST 在多數狀況下不可緩存的。
• 響應報文的狀態碼是可緩存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
• 響應報文的 Cache-Control 首部字段沒有指定不進行緩存。

XMLHttpRequest

爲了闡述 POST 和 GET 的另外一個區別，須要先了解 XMLHttpRequest：

XMLHttpRequest 是一個 API，它爲客戶端提供了在客戶端和服務器之間傳輸數據的功能。它提供了一個經過 URL 來獲取數據的簡單方式，而且不會使整個頁面刷新。這使得網頁只更新一部分頁面而不會打擾到用戶。XMLHttpRequest 在 AJAX 中被大量使用。

• 在使用 XMLHttpRequest 的 POST 方法時，瀏覽器會先發送 Header 再發送 Data。但並非全部瀏覽器會這麼作，例如火狐就不會。
• 而 GET 方法 Header 和 Data 會一塊兒發送。

 

4 HTTPS

 

HTTP 有如下安全性問題：

• 使用明文進行通訊，內容可能會被竊聽；
• 不驗證通訊方的身份，通訊方的身份有可能遭遇假裝；
• 沒法證實報文的完整性，報文有可能遭篡改。

HTTPS 並非新協議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通訊，再由 SSL 和 TCP 通訊，也就是說 HTTPS 使用了隧道進行通訊。

經過使用 SSL，HTTPS 具備了加密（防竊聽）、認證（防假裝）和完整性保護（防篡改）。

 

加密

1. 對稱密鑰加密

對稱密鑰加密（Symmetric-Key Encryption），加密和解密使用同一密鑰。

• 優勢：運算速度快；
• 缺點：沒法安全地將密鑰傳輸給通訊方。

 

2.非對稱密鑰加密

非對稱密鑰加密，又稱公開密鑰加密（Public-Key Encryption），加密和解密使用不一樣的密鑰。

公開密鑰全部人均可以得到，通訊發送方得到接收方的公開密鑰以後，就可使用公開密鑰進行加密，接收方收到通訊內容後使用私有密鑰解密。

非對稱密鑰除了用來加密，還能夠用來進行簽名。由於私有密鑰沒法被其餘人獲取，所以通訊發送方使用其私有密鑰進行簽名，通訊接收方使用發送方的公開密鑰對簽名進行解密，就能判斷這個簽名是否正確。

• 優勢：能夠更安全地將公開密鑰傳輸給通訊發送方；
• 缺點：運算速度慢。

 

3. HTTPS 採用的加密方式

HTTPS 採用混合的加密機制，使用非對稱密鑰加密用於傳輸對稱密鑰來保證傳輸過程的安全性，以後使用對稱密鑰加密進行通訊來保證通訊過程的效率。（下圖中的 Session Key 就是對稱密鑰）

 

認證

經過使用 證書 來對通訊方進行認證。

數字證書認證機構（CA，Certificate Authority）是客戶端與服務器雙方均可信賴的第三方機構。

服務器的運營人員向 CA 提出公開密鑰的申請，CA 在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公開密鑰證書後綁定在一塊兒。

進行 HTTPS 通訊時，服務器會把證書發送給客戶端。客戶端取得其中的公開密鑰以後，先使用數字簽名進行驗證，若是驗證經過，就能夠開始通訊了。

 

完整性保護

SSL 提供報文摘要功能來進行完整性保護。

HTTP 也提供了 MD5 報文摘要功能，但不是安全的。例如報文內容被篡改以後，同時從新計算 MD5 的值，通訊接收方是沒法意識到發生了篡改。

HTTPS 的報文摘要功能之因此安全，是由於它結合了加密和認證這兩個操做。試想一下，加密以後的報文，遭到篡改以後，也很難從新計算報文摘要，由於沒法輕易獲取明文。

HTTPS 的缺點

• 由於須要進行加密解密等過程，所以速度會更慢；
• 須要支付證書受權的高額費用。

2，p2p基本原理

 

3，網絡下載

 

4，將來網絡趨勢