網(wǎng)絡的基礎知識

一， HTTP

HTTP協(xié)議（HyperText Transfer Protocol，超文本傳輸協(xié)議）是因特網(wǎng)上應用最為廣泛的一種網(wǎng)絡傳輸協(xié)議，所有的WWW文件都必須遵守這個標準。

HTTP是一個基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML 文件, 圖片文件, 查詢結(jié)果等）。

超文本傳輸協(xié)議

  • 請求/響應報文
  • 連接建立流程
  • HTTP的特點
1，報文
請求報文
響應報文

Q：HTTP的請求方式都有哪些？

序號 方法 描述
1 GET 請求指定的頁面信息，并返回實體主體。
2 HEAD 類似于 GET 請求，只不過返回的響應中沒有具體的內(nèi)容，用于獲取報頭
3 POST 向指定資源提交數(shù)據(jù)進行處理請求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。
4 PUT 從客戶端向服務器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。
5 DELETE 請求服務器刪除指定的頁面。
6 CONNECT HTTP/1.1 協(xié)議中預留給能夠?qū)⑦B接改為管道方式的代理服務器。
7 OPTIONS 允許客戶端查看服務器的性能。
8 TRACE 回顯服務器收到的請求，主要用于測試或診斷。
9 PATCH 是對 PUT 方法的補充，用來對已知資源進行局部更新 。

Q: GET 和 POST 方式的區(qū)別

從使用方式來看

  • GET請求參數(shù)以？分割拼接到URL后面， POST請求參數(shù)在BODY里面

  • GET參數(shù)長度限制2048個字符，POST一般沒有該限制

  • GET請求不安全，POST請求比較安全

從語義角度來看

GET ： 獲取資源

  • 安全的
  • 冪等的
  • 可緩存的

POST ： 處理資源

  • 非安全的
  • 非冪等的
  • 不可緩存的

安全性
不應該引起Server端的任何狀態(tài)變化。

冪等性
同一個請求方法執(zhí)行多次和執(zhí)行一次的效果完全相同。

可緩存性
請求是否可以被緩存。

Q: 狀態(tài)碼有哪些？

分類 分類描述
1** 信息，服務器收到請求，需要請求者繼續(xù)執(zhí)行操作
2** 成功，操作被成功接收并處理
3** 重定向，需要進一步的操作以完成請求
4** 客戶端錯誤，請求包含語法錯誤或無法完成請求
5** 服務器錯誤，服務器在處理請求的過程中發(fā)生了錯誤

Q：鏈接簡歷流程是怎么樣的？

三次握手和四次揮手
2，HTTP的特點
  • 無連接
    HTTP的持久連接
  • 無狀態(tài)
    Cookie/Session

http作為補償，給到了持久連接的方案

持久連接和非持久連接

Q:那么持久連接需要哪些頭部字段呢？

  • Connection: keep-alive
  • time: 20
  • max: 10

Q:怎樣判斷一個請求是否結(jié)束呢？

  • Content-length: 1024
  • chunked: null

Q:Charles抓包原理是怎樣的？

A：利用了中間人攻擊的特點

中間人攻擊

二， HTTPS與網(wǎng)絡安全

Q:HTTPS和HTTP有怎樣的區(qū)別？

A： HTTPS = HTTP + SSL/TLS

Q:HTTPS連接建立的流程是怎樣的？

HTTPS監(jiān)理流程
HTTPS監(jiān)理流程

  • 在使用HTTPS是需要保證服務端配置正確了對應的安全證書

  • 客戶端發(fā)送請求到服務端

  • 服務端返回公鑰和證書到客戶端

  • 客戶端接收后會驗證證書的安全性,如果通過則會隨機生成一個隨機數(shù),用公鑰對其加密,發(fā)送到服務端

  • 服務端接受到這個加密后的隨機數(shù)后會用私鑰對其解密得到真正的隨機數(shù),隨后用這個隨機數(shù)當做私鑰對需要發(fā)送的數(shù)據(jù)進行對稱加密

  • 客戶端在接收到加密后的數(shù)據(jù)使用私鑰(即生成的隨機值)對數(shù)據(jù)進行解密并且解析數(shù)據(jù)呈現(xiàn)結(jié)果給客戶

  • SSL加密建立

會話秘鑰 = random S + random C + 預主秘鑰

Q: HTTPS都使用了哪些加密方式，為什么？

  • 連接簡歷過程使用非對稱加密，非對稱加密非常耗時
  • 后續(xù)通信過程使用對稱加密
非對稱加密

1公鑰私鑰的使用原則
①每一個公鑰都對應一個私鑰。
②密鑰對中，讓大家都知道的是公鑰，不告訴大家，只有自己知道的，是私鑰。 ③如果用其中一個密鑰加密數(shù)據(jù)，則只有對應的那個密鑰才可以解密。
④如果用其中一個密鑰可以進行解密數(shù)據(jù)，則該數(shù)據(jù)必然是對應的那個密鑰進行的加密。

非對稱密鑰密碼的主要應用就是公鑰加密和公鑰認證。
2公鑰加密、解密
加密的目的，是不希望第三者看到當前兩個通訊用戶的通訊內(nèi)容。

2.1加密
A（客戶）想給B（服務器）發(fā)送一段文字，但是不想讓別人看到，因此想使用非對稱加密方法來加密這段文字，當然，B需要有一對公鑰和私鑰：
① B將他的公鑰發(fā)送給A
② A用B給他的公鑰加密這段文字，然后傳給B
③ B用他的私鑰解密A發(fā)過來的消息，這里要強調(diào)的是，只要B的私鑰不泄露，這封信就是安全的，即使落在別人手里，也無法解密。
通過這幾步，B就能成功收到A發(fā)送的信息，同時又達到了保密的目的。

2.2解密
如果B想給A回信息，就簡單的多了：
① B將要回復的信息通過自己的私鑰加密，然后傳送給A
② A用B之前給他的公鑰解出這份信息。

非對稱加密

參考鏈接： https://www.cnblogs.com/mujian/p/7665958.html

對稱加密
對稱加密

三， TCP和UDP

傳輸協(xié)議層

  • TCP 傳輸控制協(xié)議
  • UDP 用戶數(shù)據(jù)協(xié)議
UDP (用戶數(shù)據(jù)協(xié)議)

特點

  • 無連接
  • 盡最大努力交付
  • 面向報文 （即不合并，也不拆分）

面向報文
面向報文的傳輸方式是應用層交給UDP多長的報文，UDP就照樣發(fā)送，即一次發(fā)送一個報文。因此，應用程序必須選擇合適大小的報文。若報文太長，則IP層需要分片，降低效率。若太短，會是IP太小。UDP對應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。這也就是說，應用層交給UDP多長的報文，UDP就照樣發(fā)送，即一次發(fā)送一個報文。

功能

  • 復用
  • 分用
  • 差錯監(jiān)測

復用/分用

復用
分用

差錯監(jiān)測

差錯監(jiān)測
TCP (傳輸控制協(xié)議)

特點

  • 面向連接
  • 可靠傳輸
  • 面向字節(jié)流
  • 流量控制
  • 擁塞控制

面向連接

數(shù)據(jù)傳輸開始之前，需要建立連接 - 三次握手
數(shù)據(jù)傳輸結(jié)束之后，需要釋放連接 - 四次揮手

可靠傳輸

  • 無差錯 (超時重傳)
  • 不丟失 (確認丟失)
  • 不重復
  • 按序到達(確認遲到)

面向字節(jié)流

面向字節(jié)流

流量控制

使用<滑動窗口協(xié)議>

發(fā)送窗口


發(fā)送窗口

接收窗口


接收窗口

擁塞控制

  • 慢開始、擁塞避免
  • 快恢復、快重傳
擁塞控制

DNS 解析

Q: DNS解析的過程是怎么樣的？

域名到IP地址的映射， DNS解析請求采用UDP數(shù)據(jù)報，明文

DNS解析過程

DNS解析查詢方式

  • 遞歸查詢
  • 迭代查詢
遞歸查詢 - “我去給你問一下”
遞歸查詢
迭代查詢 - “我告訴你誰可能知道”
迭代查詢

Q: DNS解析存在哪些常見的問題？

  • DNS劫持問題
  • DNS解析轉(zhuǎn)發(fā)問題
DNS劫持
DNS劫持
Q: DNS劫持和HTTP的關系是怎么樣的？

A： 沒有關系，DNS解析發(fā)生在HTTP建立連接之前，DNS解析請求使用UDP數(shù)據(jù)報，端口號53

Q: 怎么解決DNS劫持？
  • httpDNS
  • 長連接

httpDNS

將DNS協(xié)議向DNS服務器的53端口轉(zhuǎn)成80端口

長連接

長連接
DNS解析轉(zhuǎn)發(fā)

Client -- www.aixue.com --> xx移動DNS -- 節(jié)省資源 --> xx電信DNS -- www.aixue.com --> 權威DNS {默認1.1.1.1 xx移動 2.2.2.2 xx電信 3.3.3.3}

四， Session 和 Cookie

Session和Cookie是對HTTP協(xié)議無狀態(tài)特點的補償

Cookie

Cookie 主要用來紀錄用戶狀態(tài)，區(qū)分用戶，狀態(tài)保存在客戶端


Cookie

客戶端發(fā)送的cookie在http請求報文的Cookie首部字段中
服務端設置http響應報文的Set-Cookie首部字段

Q: 怎么樣修改Cookie
  • 新cookie覆蓋舊cookie
  • 覆蓋規(guī)則： name, path, domain 等需要與原cookie保持一致
Q: 怎么樣刪除Cookie
  • 新Cookie覆蓋舊cookie
  • 覆蓋規(guī)則： name, path, domain 等需要與原cookie保持一致
  • 設置Cookie的expires = pastTime?；蛘適axAge = 0
Q: 怎么樣保證Cookie的安全？
  • 對Cookie進行加密處理
  • 只在https上攜帶Cookie
  • 設置Cookie為httpOnly, 防止跨站腳本攻擊
Session

Session 也是用來紀錄用戶狀態(tài)，區(qū)分用戶，狀態(tài)保存在服務器端

Q: Session和Cookie的關系？

A：Session需要依賴于Cookie機制

Session工作流
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容