通信
計算機間的通信基礎
得知通信機器的IP位址後，需要先進行一次ARP（廣播）通信，确定對方的MAC位址（網卡位址）後才能使用ICMP協定來傳輸資料
- 廣播是在同一個網段内傳播的
- 網卡位址為FFFF,FFFF,FFFF（主機ID全1）即為廣播狀态
- 在與其他計算機進行通信前，會先判斷目标主機與自己是否處于同一網段，如果不處于同一網段，則将由路由器進行轉發
資料通信模拟
1）區域網路：pc1——————集線器/交換機——————pc2
- 可用網線（數字信号）進行通信
- 網線不可超過100米
2）廣域網：pc1——————數據機——————數據機——————pc2
- 網線（數字信号）傳輸範圍短，可以使用電話線或光纖（模拟信号）進行傳輸資料，利用數據機轉換為對應的數字信号
連接配接方式
1）處于同一網段（連接配接的裝置處于同一廣播域）：
- 網線直連
- 所用為交叉線（同種機器互聯方式）
- 兩台機器互聯
- 同軸電纜
- 半雙工通信（同網線間不能同時發送資料）
- 易沖突，不安全，容易癱瘓
- 內建器
- 半雙工通信
- 易沖突，不安全
- 網橋
- MAC位址表，可記錄機器的MAC位址（兩台機器互通時）
- 交換機
-
MAC位址表
當交換機的MAC位址表達到存儲上限時，若再收到資料包，會向除源端口外的所有端口發送資料包（泛洪）
- 全雙工通信
-
2）路由器：可以讓不同網段的主機進行傳輸資料，會隔絕廣播域
- 若兩台不同網段的主機要想進行資料傳輸，需要利用
網關
- 發送資料的主機發現與接收資料的主機網段不相同時，發送端會根據配置的網關，進行廣播，擷取路由器網關的MAC位址，再将資料傳輸給路由器
- 路由器沒有直連到目标主機上，會
下一跳
網絡分層
Ⅰ、實體層
資料格式：比特流
Ⅱ、資料鍊路層
簡介
①資料格式：幀
②傳輸協定：CSMA/CD、PPP
1）鍊路：從一個節點到另一節點的一段線路上，中間
無其他交換節點
。傳輸資料時，需要用對應的通信協定控制資料的傳輸
- 廣播信道（主機間通信穿過集線器等）：
CSMA/CD協定
- 使用CSMA/CD協定的網絡稱為
以太網
以太網幀
Ethernet V2标準
- 為確定能檢測到正在發送的幀是否産生了沖突，要求以太網幀至少為
64位元組
- 目前的交換機已使用全雙工通信，不再使用CSMA/CD協定，但仍使用
以太網幀傳輸資料
以太網
- 使用CSMA/CD協定的網絡稱為
- 點對點信道（2個路由器間組成的信道）：
PPP協定
幀
資料鍊路層的3個基本：封裝成幀、透明傳輸、差錯檢驗
①封裝成幀：
幀首部 + 幀的資料部分 + 幀尾部
== 幀長
- 幀首部：首部+幀開始符
- 幀的資料部分：IP資料包（上一層）、規定MTU（每種協定規定的所能傳輸的幀的最大資料長度，以太網為1500位元組）
- 幀尾部：FCS+幀結束符
②透明傳輸：當資料内出現了SOH（幀開始符）、EOT（幀結束符）、ESC，需要進行轉義（填充ESC位元組）
③差錯檢驗：根據資料部分和首部計算出一個FCS值，每次接收資料前檢驗其值是否與發送前的一樣，若不一樣則丢棄
1）Ethernet V2幀：
以太網幀：
首部 + 資料 + FCS（4位元組）
- 首部由
目标MAC位址
源MAC位址
傳輸協定類型
- 以太網幀至少64位元組，是以資料長度至少為：64-6-6-2-4位元組（
46
- 當資料部分（
網絡層首部+資料部分
- 在
鍊路層
-
無幀開始符和結束符
2）PPP協定：
首部 + 資料 + 尾部
- 首部包含
幀開始符
Address字段
Control字段
PPP内部協定
- 尾部包含
FCS
幀結束符
- 當資料内出現7E（幀開始與結束符）、7D時，需要進行轉義（将7E替換為7D5E，将7D替換為7D5D）
網卡
- 屬于實體層和資料鍊路層
- 每接收一個幀時，會先進行差錯校驗，若差錯校驗失敗，則丢棄資料包
- 抓包抓到的幀無FCS部分，因為抓到的為通過了校驗的幀
- MAC位址即為網卡的實體位址
Ⅲ、網絡層
簡介
①資料格式：包
②傳輸協定：IP、ARP、ICMP
- 網絡層資料包（IP資料包、Packet）由
首部
資料部分
資料：多數時候是由傳輸層傳遞下來的資料段
首部：固定部分（
20位元組
）+ 可變部分，最多
60位元組
①固定部分：
-
版本
-
首部長度
×4
才是首部的長度
0b0101：20（最小長度）、0b1111：60（最大長度）
-
區分服務
-
總長度
首部
資料長度
- 由于下一層的幀的資料部分長度不能超過1500位元組，是以（總長度）過大的IP資料包，需要分為
片
- 每一片都獨立擁有自己的網絡層首部
- 由于下一層的幀的資料部分長度不能超過1500位元組，是以（總長度）過大的IP資料包，需要分為
-
辨別
- 當資料包過大而進行分片時，同一個資料包下的所有片的辨別都是一樣的
-
标志
- 第1位：保留
- 第2位：
1
- 第3位：
1
-
片偏移
- 片偏移
×8
/8
- 每一片的長度一定為8的整數倍
- 片偏移
-
生存時間
TTL-1
- 利用ping指令可推測出傳遞資料間經曆的路由器個數
-
協定
- ICMP（1（十進制））、IGMP（2）、IP（4）、TCP（6）、EGP（8）、IGP（9）、UDP（17）、IPv6（41）、ESP（50）、OSPF（89）
-
首部檢驗和
-
源IP位址
-
目标IP位址
②可選部分：
-
可選字段
-
填充
IP
- 網絡間的通信協定
- IP位址組成部分：
網絡号（網絡ID）
主機号
子網路遮罩
常與IP位址一同使用，由若幹個0和1組成，子網路遮罩的唯一作用就是為了區分IP位址的網絡号和主機号，1的個數為
子網路遮罩的長度
，也是
IP位址的網絡号位數
，0則代表為
IP位址的主機号位數
網段
- 子網路遮罩與IP位址按位與
&
互相通信
網關
- 同一網段的計算機網絡ID相同
- 同一網段的連接配接個數為：
主機ID數-2
網關與路由器
- 連接配接不同網絡位址的裝置，路由器為代表之一，當兩台處于不同網段間的裝置要進行通信時，發送端會将資料發送給與其網關配置相同的裝置（路由器），再由該裝置将資料轉發出去
- 若有多個網段的裝置需要跳轉，可使用
預設網關
0.0.0.0
IP位址分類
- 根據子網路遮罩可劃分為ABCDE類
- 根據使用區域劃分為公網IP和私網IP
- 根據其狀态可分為靜态IP和動态IP
0000 0000（一）0000 0000（二）0000 0000（三）0000 0000（四）
（一）劃分
1）A類：預設子網路遮罩是：
255.0.0.0
（
/8
）
- 網絡ID必須以
0開頭
①網絡ID：0不能用，127作為保留網段（127.0.0.1為本地環回位址，即本機位址），是以可用于配置設定主機的範圍：1~126
②主機ID：（個數）256* 256 * 256 -2
2）B類：預設子網路遮罩為：
255.255.0.0
（
/16
）
- 網絡ID必須以
10開頭
①網絡ID：可用于配置設定主機的範圍（一）：128~191 （二）：0~255
②主機ID：（個數）256 * 256 -2
3）C類：預設子網路遮罩：
255.255.255.0
（
/24
）
- 網絡ID必須以
110開頭
①網絡ID：可用于配置設定主機的範圍（一）：192~223 （二、三）：0~255
②主機ID：（個數）256 -2
4）D類：以1110開頭，多點傳播位址，無子網路遮罩，（一）取值範圍為：224~239
5）E類：以1111開頭，保留今後使用，（一）取值範圍為：240~255
- 隻有A、B、C類位址才能配置設定給主機
- 主機ID全為0，代表為主機所在的網段
- 主機ID全為1，表示主機所在網段的全部主機（廣播），會為所有處于同一網段的主機發送資料
- IP處于哪類位址，與子網路遮罩（
/xx
網絡ID所屬的類的子網路遮罩+對主機ID的子網劃分
（二）子網路遮罩劃分
- 為節約IP位址的浪費，可将主機ID劃分為子網路遮罩（用二進制形式了解）
1）等長子網劃分：子網路遮罩相同
将192.168.1.0 /24劃分出兩個子網段：192.168.1.0 /25和192.168.1.128 /25
此為C類網段（192.168.1.0），在此網段的基礎上将最後8bit的第一位劃分為子網路遮罩部分，此刻的子網路遮罩就有25bit（全0為網段，全1為廣播），為255.255.255.128
（二進制位）0為一類網段，可配置設定的IP位址為1~126（126台），
（二進制位）1為另一類網段，可配置設定的IP位址為129~254（126台）
2）變長子網劃分：劃分為不等長的子網，子網路遮罩不相同
3）超網：将連續的網段合并成一個更大的網段
- 必須是連續的網段
- 子網路遮罩往左移後（合并後），最終合成的網段必須處于同一網段
ARP
- 位址解析協定，将IP位址解析為MAC位址（通過IP位址擷取MAC位址）
- 每台主機都會有自己的ARP緩存清單，記錄IP位址和MAC位址之間的對應關系
- 兩台主機間要進行通信，必須知道對方的MAC位址
- 全球唯一性
- 相同MAC位址存在時，不會傳輸資料
- 由48位二進制（12位十六進制，二進制的
1111
F
- RARP：逆位址解析協定
- 使用與ARP相同的報頭結構
- 作用與ARP相反，是将MAC位址轉換為IP位址
- 已被BOOTP（DHCP前身）、DHCP取代
ICMP
- 網際網路控制消息協定
- 通常用于傳回錯誤資訊（如TTL值過期、目的不可達等）
- ICMP的錯誤資訊總是包含了源資料的資訊并傳回給發送者
Ⅳ、傳輸層
簡介
①資料格式：段
②傳輸協定：TCP、UDP
③處于傳輸層的資料段一般在傳輸層就劃分好，不會再傳輸給網絡層進行劃分
- 原因：若在網絡層劃分資料，若在傳輸過程中丢包，則接收方将資料段合并起來時，并不能合并為一個完整的資料段，此時便不會發送ACK（确認号），發送方在超過一段時間後還未收到響應，則會重新将整個傳輸層資料（可靠傳輸僅在傳輸層存在）重新發送給網絡層，讓網絡層進行劃分，極大影響了重發的性能
UDP
無連接配接，不可靠傳輸，首部占用空間小，傳輸速率快，資源消耗小，應用層協定
DNS
- 組成部分：
僞首部
首部
資料部分
- 首部包含
源端口
目的端口
長度
檢驗和
- 長度：
首部長度
資料長度
傳輸層資料長度=網絡層總長度-網絡層首部長度-傳輸層首部長度
- 長度：
- 僞首部僅在進行校驗和時起作用，
不會傳輸給網絡層
- 僞首部包含
源IP位址
目的IP位址
17
UDP長度
- 首部包含
- 端口：端口占2位元組，是以端口号取值範圍為
0~65535
TCP
結構
面向連接配接，可靠傳輸，首部占用空間大，傳輸速率慢，資源消耗大，應用層協定
HTTP
、
HTTPS
、
FTP
、
SMTP
、
DNS
- 組成部分：
僞首部
首部
資料部分
1）首部
-
源端口
目的端口
-
序号
seq
建立連接配接後
傳給對方
第一個位元組
-
确認号
ack
建立連接配接後
傳過來
第一個位元組
-
資料偏移
-
保留
-
URG
-
ACK
-
PSH
-
RST
-
SYN
-
FIN
-
視窗
-
檢驗和
僞首部
首部長度
資料部分
不會傳輸給網絡層
-
緊急指針
-
選項
-
填充
四大特性
可靠傳輸
- 停止等待ARQ協定：發送後一個資料後，等待響應，逾時後會自動重傳
- 在超過一段時間或發送一定次數後還未成功擷取響應ack（确認号），則會發送RST（reset封包）斷開連接配接
- 連續ARQ協定+滑動視窗協定：同時向用戶端發送多個資料（根據用戶端的接收視窗決定），等待響應，根據
确認号
SACK
- TCP資料包用
發送視窗
确認号
确認号
接收視窗
- SACK（位于首部可選字段中）會在響應時，告訴對方哪些資料包丢失，哪些資料包已收到（SACK資訊）
King=5
Length
Left Edge
Right Edge
- 左邊界和右邊界合起來（左閉右開）就是已成功接收到的資料包
- 一對邊界占用
8
4組
- SACK（位于首部可選字段中）會在響應時，告訴對方哪些資料包丢失，哪些資料包已收到（SACK資訊）
- 滑動視窗：即發送資料和接收資料後，視窗向後移動，繼續以原視窗大小發送資料
- TCP資料包用
流量控制
- 如果接收方的緩沖區滿了，發送方還在發送資料，則接收方會将收到的資料包丢棄，造成網絡資源的浪費，是以使用流量控制（讓發送方發送資料速率不要太快，使接收方來得及接收處理）
- 通過 發送的資料包的首部所給的視窗字段資訊 來控制發送方的發送速率（即發送視窗大小不能超過接收視窗大小）
- 當發送方接收到的視窗大小資訊為0時，發送方會停止發送資料（可能是接收方的緩存區大小已滿）
- 為防止 接收方已從視窗大小資訊為0 轉為 能接收資訊的狀态，但做出響應時接收方未能收到響應，是以，發送方在接收到接收方視窗大小資訊為0後，會開啟一個計時器，在一定時間後，自動詢問接收方的視窗大小資訊，若依舊為0時重置計時器
擁塞控制
- 當過多的資料注入到網絡中，鍊路吞吐量（鍊路允許資料通過的最大量）不足資料通過時，鍊路就會發生擁塞，并自動丢棄過載的資料包
- 擁塞控制是一個
全局性過程
-
MSS
資料部分
1460位元組
cwnd
rwnd
swnd
- 發送視窗的大小由 擁塞視窗及接收視窗間的
最小的
- 發送視窗的大小由 擁塞視窗及接收視窗間的
- 擁塞控制方法：
-
慢開始
-
擁塞避免
ssthresh
加法增大
乘法減小
慢開始
-
快速重傳
3次
确認号
4次
-
快速恢複
快重傳
新的ssthresh門檻值處
加法增大
快恢複
-
建立連接配接
序号與确認号
- 序号、确認号：
相對值
第一次握手
第二次握手
①用戶端：
第一次握手
--> TCP資料部分占
0位元組
（建立連接配接，不發送資料）
- SYN=
1
-
seq為0（用戶端表面未發送任何資料，但會告訴伺服器自身真實的序号）
ack為0（确認号字段未生效）
②伺服器：
第二次握手
--> TCP資料部分占
0位元組
（響應連接配接，不發送資料）
- SYN=
1
1
-
seq為0（伺服器表面未發送任何資料，但會告訴用戶端自身真實的序号）
ack為1（伺服器希望下一次能收到來自用戶端的1資料）
③用戶端：
第三次握手
--> TCP資料部分占
0位元組
（響應連接配接，不發送資料）
- SYN= （連接配接正式建立），ACK=
1
-
seq為1（用戶端發送給伺服器它希望收到的1資料）
ack為1（伺服器暫未做出響應，依然希望收到1資料）
④用戶端：
發送HTTP協定
--> TCP資料部分占
k位元組
（用戶端發送請求資料）
- SYN=0，ACK=1
-
seq為1（伺服器暫未做出響應，用戶端發送給伺服器它希望收到1資料）
ack為1（伺服器暫未做出響應，依然希望收到1資料）
⑤伺服器：
響應資料
--> TCP資料部分占
b1位元組
（伺服器響應，連續發包）
- SYN=0，ACK=1
-
seq為1（伺服器第1次響應，發送給用戶端b1個位元組中的第一個）
ack為k+1（伺服器已收到用戶端請求資料所發送的k個位元組，希望收到第k+1個位元組）
⑥伺服器：
響應資料
--> TCP資料部分占
b2位元組
（伺服器響應，連續發包）
- SYN=0，ACK=1
-
seq為b1+1（伺服器第2次響應，發送給用戶端b2個位元組中的第一個）
ack為k+1（用戶端暫未做出響應，伺服器已收到用戶端請求資料所發送的k個位元組，希望收到第k+1個位元組）
⑦伺服器：
響應資料
--> TCP資料部分占
b3位元組
（伺服器響應，連續發包）
- SYN=0，ACK=1
-
seq為b1+b2+1（伺服器第3次響應，發送給用戶端b3個位元組中的第一個）
ack為k+1（用戶端暫未做出響應，伺服器已收到用戶端請求資料所發送的k個位元組，希望收到第k+1個位元組）
⑧伺服器：
響應資料
--> TCP資料部分占
b4位元組
（伺服器響應，連續發包）
- SYN=0，ACK=1
-
seq為b1+b2+b3+1（伺服器第4次響應，發送給用戶端b4個位元組中的第一個）
ack為k+1（用戶端暫未做出響應，伺服器已收到用戶端請求資料所發送的k個位元組，希望收到第k+1個位元組）
⑨用戶端：
收到資料，做出響應
--> TCP資料部分為
0位元組
（用戶端接收資料，響應伺服器，并申請下一個資料）
- SYN=0，ACK=1
-
seq為k+1（用戶端發送給伺服器它希望收到的k+1資料（其實隻是響應，并沒有真正發送資料））
ack為b1+b2+b3+b4+1（用戶端共收到伺服器4次響應所發送的所有資料，希望收到下一個資料）
⑩伺服器：
響應資料
--> TCP資料部分占
xx位元組
（伺服器響應，連續發包）
- SYN=0，ACK=1
-
seq為b1+b2+b3+b4+1（伺服器發送給用戶端它希望收到的下一個資料）
ack為k+1（伺服器并沒有真正收到用戶端發送的k+1的資料，希望用戶端發送k+1的資料）
三次握手連接配接狀态
-
CLOSED
-
LISTEN
-
SYN-SENT
-
SYN-RCVD
-
ESTABLISHED
四次揮手連接配接狀态
-
ESTABLISHED
-
FIN-WAIT-1
-
CLOSE-WAIT
-
FIN-WAIT-2
-
LAST-ACK
-
TIME-WAIT
- 2MSL：MSL指的是資料包發送到另一方所用的時間，超出此時間後，資料包會失效。2MSL是因為資料包發送後響應，2MSL内必定會接收到資料包或資料包已丢失
-
CLOSING
總結
細節分析
①前兩次握手：
- SYN都為1（建立連接配接，發送請求）
- 資料部分長度為0（隻發送建立連接配接請求，無發送資料）
- TCP頭部一般為
32位元組
- 可選部分：MSS（資料部分的大小）、是否支援SACK（重傳記錄）、Window Scale（視窗縮放系數）等資訊
②三次握手原因：
- 防止server伺服器端一直等待發送資源，造成浪費
由于用戶端發送請求時，可能有網絡延遲，在發送後的某個時間點到達，用戶端會因為沒收到響應，再發一個請求，此請求先到達，在資料傳輸完畢後斷開連接配接，此刻伺服器端收到了晚到達的請求，會與用戶端建立連接配接（隻有兩次握手就建立了連接配接），但用戶端無發送資料，伺服器端一直等待用戶端發送資料，是以造成資源的浪費。
③多次握手失敗處理：
- 若此刻伺服器端的狀态為SYN-RCVD（等待第三次握手狀态），若短時間内無收到用戶端發送的ACK确認報，會重新第二次握手
- 若多次第二次握手後仍沒有收到用戶端發送的ACK确認報，則伺服器端會發送RST包，強制斷開連接配接
④四次揮手原因：
由于TCP是全雙工模式，是以前2揮手隻是表明用戶端已經沒有資料要發送給伺服器，關閉了将資料傳輸給伺服器的通道，但伺服器向用戶端傳輸資料的通道并未關閉，是以又需要2次揮手，關閉伺服器向用戶端發送資料的通道
⑤用戶端發送ACK确認報後需要等待一段時間後再關閉連接配接的原因：
- 若用戶端發送的ACK确認報丢失，伺服器會一直等待，甚至多次發送FIN封包，浪費資源
- 若用戶端發送ACK确認報後立即關閉連接配接，有可能因為ACK确認報丢失，用戶端等待一段時間後重發FIN确認報，此刻剛好有新的用戶端程式被分到了一樣的端口号，該程式接收到伺服器發送的FIN封包後，就會執行斷開連接配接的操作
⑥出現3次揮手的原因：
- 用戶端向伺服器發送釋放連接配接請求，伺服器在收到FIN封包後，也想關閉連接配接，于是原本應發送的ACK确認報被該為發送FIN封包，從FIN-WAIT-1直接進入TIME-WAIT狀态（少了第2次揮手）
⑦短連接配接與長連接配接：
- 短連接配接：發送一次資料後即關閉連接配接
- 長連接配接：一直發送資料，保持連接配接不斷開
Ⅴ、應用層
簡介
①資料格式：封包、使用者資料
②傳輸協定：FTP、HTTP、SMTP、DNS、DHCP等
1）域名：域名要進過DNS伺服器解析為對應的IP位址才能由路由器轉發接收
- 路由器使用IP位址而不使用域名的原因：IP位址固定隻占
4位元組
- 域名
從右往左
依次是：頂級域名（TDL）、二級域名、三級域名 . . .
①頂級域名：
-
通用頂級域名（gTLD）：
com（公司）、net（網絡機構）、org（組織機構）、edu（教育機構）、gov（政府部門）、int（國際組織）等
-
國家及地區頂級域名（ccTLD）：
cn（中國）、jp（日本）、uk（英國）
-
新通用頂級域名（New gTLD）：
vip、xyz、top、club、shop等
-
DNS
DNS說明
- 第一次解析完成之後會有緩存，即再次通路域名時不會進行DNS解析
- 可基于UDP協定，也可基于TCP協定，伺服器占用53端口
- 所有的DNS伺服器記錄了
DNS根域名伺服器
下一級DNS伺服器
用戶端會先通路最近的一台DNS伺服器（即用戶端自己配置的DNS伺服器），若本機的DNS伺服器無目标域名對應的IP位址的緩存，會請求DNS根域名伺服器，根域名伺服器會将他的下一級IP位址傳回給用戶端，用戶端通過該IP去請求對應的DNS伺服器，直到找到有目标域名的DNS伺服器為止
CDN
- 内容分發網絡
- 利用最靠近用戶端的伺服器，快速将一些靜态資源發送給用戶端
- 若最靠近用戶端的CDN伺服器（
CDN邊緣節點
父層節點
源站
備份
在使用了CDN後，用戶端先将要通路的域名發送給
DNS伺服器
，DNS伺服器若發現該域名含有CDN站點，會将域名直接發送給
CDN DNS伺服器
，通過CDN DNS伺服器将IP發送給用戶端。用戶端收到IP後，會去通路
CDN全局負載均衡系統
，CDN全局負載均衡系統會将IP發送給
CDN區域負載均衡系統
進行分析，最後傳回目标IP給CDN全局負載均衡系統，CDN全局負載均衡系統再返還給用戶端目标IP，用戶端通過目标IP通路
CDN緩存伺服器
DHCP
動态主機配置協定，用于動态給主機配置設定IP位址
- DHCP協定基于UDP協定，用戶端是68端口，伺服器是67端口
- DHCP伺服器會從IP位址池中，挑選一個IP位址
出租
- 家用路由器即可充當DHCP伺服器
- 借助DHCP中繼代理實作跨網段配置設定IP位址
- 在用戶端申請的IP位址快過期時，會自動向DHCP伺服器發送REQUEST資訊申請續約
配置設定IP位址
DISCOVER
：用戶端發送廣播包給伺服器（源IP
0.0.0.0
，目标IP
255.255.255.255
，目标MAC
FF:FF:FF:FF:FF:FF
）
OFFER
：伺服器（可以多個伺服器）傳回用戶端可以租用的IP位址，包含租用期限、子網路遮罩、網關、DNS資訊等
REQUEST
：用戶端選擇好IP位址（OFFER）後，發送廣播包進行回應
ACKNOWLEDGE
：被選中的伺服器發送ACK确認報給用戶端
HTTP
- 超文本傳輸協定（設計的原目的是為了接收HTML頁面），由
URI
URL
ABNF（标準）
格式
- 對HTTP的标準規範
HTTP-message=start-line
*(header-field CRLF)
CRLF
[message-body]
- （行）start-line：
request-line
status-line
request-line：method SP request-target SP HTTP-version CRLF
- HTTP-version：HTTP-name / DIGIT.DIGIT
- HTTP-name：%48.54.54.50（HTTP）
status-line：HTTP-version SP status-code SP reason-phrase CRLF
- status-code：3DIGIT
- reason-phrase：*(HTAB或SP或VCHAR或obs-text)
- （頭）header-field：field-name : OWS field-value OWS
field-name：token（鍵）
field-value：*(field-content或obs-fold)
OWS：*(SP/HTAB)
- （體）message-body：*OCTET
-
*
-
()
-
[]
-
CRLF
-
SP
-
DIGIT
-
HTAB
-
OCTET
-
;
表單檔案上傳
（頭）
Content-Type:multipart/form-data;boundary=xxx
（體）mutipart-body：
1*encapsulation
close-delimiter
encapsulation：delimiter body-part CRLFclose-delimiter：-- boundary – CRLF（結束符）
- delimiter：-- boundary CRLF（分隔符）
- body-part（值）
格式（非标準）
（一）請求封包
請求行：
方法
+
空格
+
URL
+
空格
+
版本
+
CR（回車）
+
LF（換行）
請求頭：
首部字段名
+
:
+
空格
+
值
+
CR
+
LF
. . .（可有多個）
CR
+
LF
請求體（
get
方法無請求體）
（二）響應封包
響應行：
版本
+
空格
+
狀态碼
+
空格
+
短語
+
CR
+
LF
響應頭：
首部字段名
+
:
+
空格
+
值
+
CR
+
LF
. . .（可有多個）
CR
+
LF
響應體
請求方法
GET
：常用于讀取的操作，請求參數直接跟在URL後面（但URL長度是有限制的）
POST
：常用于添加、删除、修改等操作，請求參數可以跟在URL後面，也可以存放在請求體中（基本無大小限制）
HEAD
：請求得到與GET相同的響應，但無響應體（常用于下載下傳檔案前先确定檔案大小）
OPTIONS
：擷取目标資源所支援的通信選項（比如伺服器支援的請求方法）
PUT
：用于對已存在資源進行整體覆寫
PATCH
：用于對資源進行部分修改（資源不存在時會建立新的資源）
DELETE
：用于删除指定的資源
TRACE
：請求伺服器回顯其收到的請求資訊（常用于HTTP請求的測試診斷）
CONNECT
：可以開啟一個用戶端與所請求資源間的雙向溝通的通道，可以用來建立隧道（可以用來通路采用了SSL（HTTPS）協定的站點）
頭部字段
請求頭字段
：有關要擷取資源或用戶端本身資訊的消息頭
響應頭字段
：有關響應的補充資訊，如伺服器本身（版本、名稱等）的消息頭
實體頭字段
：有關實體主體的更多資訊，如主體長度（Content-Length）或其MIME類型
通用頭字段
：同時适用于請求和響應資訊，但與消息主體無關的消息頭
-
,
q=xx
（一）請求頭字段
User-Agent
：浏覽器的身份辨別字元串（附有系統資訊等）
User-Agent : Mozilla/5.0 (X11; Linux x86; rv: 12.0) Gecko/20100101 Firefox/21.0
Host
：伺服器域名、端口号
Host : localhost : 80
Date
：發送消息的日期時間
Date : Tue , 15 Nov 1994 08 : 12 : 31 GMT
Referer
：表示轉到此頁面的前一個網頁（由哪個網頁轉到此網頁的，可用來做資源的通路限制，比如從其他網址過來的不能通路，由特定網址過來才能通路）
Referer : https 😕/ www . baidu . com（上一個網址是百度）
Content-Type
：表達請求體的資料類型（告訴伺服器要如何處理請求）
Content-Type : multipart / form-data（上傳檔案表單類型）
Content-Length
：請求體的長度（位元組為機關）
Content-Length : 348
Accept
：能夠接受的響應内容類型（Content-Types）
Accept : text / plain
Accept-Charset
：能夠接受的字元集
Acceot-Charset : utf-8
Accept-Encoding
：能夠接受的編碼方式清單
Accept-Encoding : gzip , deflate
Accept-Language
：能夠接受的響應内容的自然語言清單
Accept-Language : en-US
Range
：僅請求某個實體的一部分，位元組偏移從0開始（可用于多線程下載下傳等）
Range : bytes=500-999（擷取第500位元組到第999位元組）
Origin
：表明發起跨域資源共享請求的來源（常與響應頭Access-Control-Allow-Origin使用，用來判斷該來源是否可以通路資源）
Origin : https 😕/ www . baidu . com（表明是從該連接配接轉過來的，請求跨域資源共享）
Cookie
：之前由伺服器通過Set-Cookie發送的Cookie
Cookie : $Version=1 ; Skin=new ;
Connection
：浏覽器想要優先使用的連接配接類型
Connection : keep-alive（表示長連接配接）
Cache-Control
：用來指定在這次請求/響應中所有緩存機制都必須遵守的規則
Cache-Control : no-cache
（二）響應頭字段
Date
：發送該消息的日期時間
Date : Tue , 15 Nov 1994 08 : 12 : 31 GMT
Last-Modified
：所請求的對象的最後修改日期
Last-Modified : Tue , 15 Nov 1994 12 : 45 : 26 GMT
Server
：伺服器名字
Server : Apache / 2.4.1 (Unix)
Expires
：指定一個時間，超過該時間則認為該響應已過期
Expires : Thu , 01 Dec 1994 16 : 00 : 00 GMT
Content-Type
：表達響應體的資料類型（告訴浏覽器如何處理響應）
Content-Type : text / html ; charset=utf-8（解析并展示html頁面）
Content-Encoding
：内容所使用的編碼類型
Content-Encoding : gzip
Content-Length
：響應體的長度（位元組為機關）
Content-Length : 348
Content-Disposition
：可以讓用戶端下載下傳檔案并使用指定的檔案類型和檔案名
Content-Disposition : attachment ; filename =" fname.txt "（該響應内容為可下載下傳檔案，且檔案類型為txt，檔案名為fname）
Accept-Ranges
：伺服器支援哪些種類的部分内容範圍（常與請求頭Range一同使用）
Accept-Ranges : bytes
Content-Range
：該資訊屬于完整的資訊中的哪一部分
Content-Range : bytes 2101-47021/47022
Access-Control-Allow-Origin
：指定哪些網站可以跨域參與到資源共享過程中（常與請求頭Origin一同使用，判斷該跨域請求是否可以通過）
Access-Control-Allow-Origin : *（表明所有的網站過來的都可以擷取資源）
Set-Cookie
：傳回一個Cookie讓用戶端儲存
Set-Cookie : UserID=JohnDoe ; Max-Age=3600 ; Version=1
Location
：用來指明請求重定向的新位址或在建立了某個新資源時使用
Location : http 😕/ www . w3 . org（在用戶端收到伺服器發送的 302 響應碼後，會重新發送一次請求，通路該 Location 位址）
Connection
：對用戶端所使用的連接配接類型
Connection : close（短連接配接）
Cache-Control
：向從伺服器到包括用戶端在内的所有緩存機制告知，他們是否可以緩存該對象，機關為秒
Cache-Control : max-age = 3600
狀态碼
-
資訊響應：100~199
成功響應：200~299
重定向：300~399
用戶端錯誤：400~499
伺服器錯誤：500~599
- 背景開發程式員可設定傳回給用戶端的狀态碼（如Java中調用
Response.setStatus()
①
100 Continue
：請求的初始部分已被伺服器收到，且伺服器沒有拒絕，用戶端應該繼續發送剩餘的請求，如果請求已完成，忽略該響應
常作為用戶端發送請求體前的請求，若伺服器拒絕該請求（常見于沒有包含伺服器所需的請求頭等），就可以起到節約資源的作用（因為沒有發送請求體）
②
200 OK
：請求成功标志
③
302 Found
：請求的資源被暫時移動到了由Location頭部指定的URL上
請求的資源路徑已移動，伺服器傳回302後，用戶端會根據頭部Location找到它所指定的URL的位址，發送新的請求通路該URL（請求重定向）
④
304 Not Modified
：表明用戶端所申請的資源伺服器并未進行修改，可直接使用用戶端自身所緩存的内容
按+Ctrl
可強制重新整理緩存F5
⑤
400 Bad Request
：文法無效，伺服器無法了解該請求
常見于請求格式錯誤，或請求内不包含伺服器所需内容，開發人員主動抛出
⑥
401 Unauthorized
：缺乏目标資源要求的身份驗證憑證
常見于一些一來就需要登入才能通路的情況
⑦
403 Forbidden
：伺服器有能力處理該請求，但拒絕授權通路
⑧
404 Not Found
：伺服器無法找到所請求的資源
⑨
405 Methed Not Allowed
：伺服器
禁止
了使用目前HTTP方法的請求
⑩
406 Not Acceptable
：伺服器無法提供與Accept-Charset以及Accept-Language指定的值相比對的響應
即用戶端所能接受的字元集或編碼方式，伺服器無法提供
⑪
408 Request Timeout
：伺服器想将沒有在使用的連接配接關閉
若設定了長連接配接的話，會一直保持着連接配接，但一些伺服器會在一些空閑連接配接上發送此資訊，即使用戶端沒有發送任何請求斷開連接配接
⑫
500 Internal Server Error
：所請求的伺服器遇到意外并阻止其執行請求
⑬
501 Not Implemented
：請求的方法
不被伺服器支援
，是以無法處理請求
- ⑭
502 Bad Gateway
⑮
503 Service Unavailable
：伺服器尚未處于可以接受請求的狀态
常見于伺服器停機維護或已超載
跨域
浏覽器有個
同源政策
，規定了在預設情況下，
AJAX
（CORS，跨域資源共享）請求隻能發送給同源的URL
- 同源指的是3個相同：
協定
域名（IP）
端口
- 跨域請求：
$()
- img、script、link、iframe、video、audio等标簽不受同源政策的限制
- CORS的實作需要
用戶端
伺服器
- 用戶端一般都支援
- 伺服器需要傳回對應的響應頭（如
Access-Control-Allow-Origin
- 浏覽器有可能是已經擷取到了資源的，但沒有Access-Control-Allow-Origin的響應頭，是以沒有權限顯示
Cookie與Session
- Cookie：會在用戶端（浏覽器）存儲一些資料，并存儲到本地硬碟上，伺服器通過Set-Cookie傳回Cookie交給用戶端去存儲
- 發送請求時的路徑接受了Cookie，其所有的
子路徑
- 當沒有設定Cookie的過期時間時，預設在浏覽器關閉時就會失效
- 發送請求時的路徑接受了Cookie，其所有的
- Session：可以在伺服器内臨時存儲一些資料，用
JSESSIONID
- Session預設的有效時間為30分鐘
- 調用
request.getSession().invalidate()
基于Java代碼分析Cookie與Session的關系：
- 當用戶端在沒有Cookie資訊的情況下發送請求
- 伺服器收到請求後調用
request.getSession()
Set-Cookie :JSESSIONID = 唯一ID值
- 用戶端收到該響應頭後，立即建立一個Cookie對象
- 在之後該
路徑
子路徑
Cookie:JSESSIONID = 唯一ID值
- 用戶端收到請求後依舊調用
request.getSession()
- 當用戶端删除Cookie時，又回到了無Cookie的狀态，此刻若向伺服器發送請求，則會重新建立一個Session對象
緩存
- 緩存對象一般是：GET請求、靜态資源（HTML、CSS、JS、圖檔等）
- Ctrl+F5可重置重新整理緩存（重新發送請求）
-
Pragma：作用類似于Cache-Control（已淘汰）
Expires：緩存的過期時間（GMT格式）（已淘汰）
Cache-Control：設定緩存政策
- no-storage：不緩存資料到本地
- public：允許使用者、代理伺服器等緩存資料到本地
- private：隻允許使用者緩存資料到本地
- max-age：緩存有效的時間，機關秒
-
no-cache：每次需要發送請求（無響應體）給伺服器詢問緩存是否有發生變化，再決定如何使用緩存
伺服器有可能傳回304 Not Modified（目标檔案未發生變化）
- 優先級：Pragma > Cache-Control > Expires
響應頭：
- Last-Modified：資源最後一次修改的時間
- ETag：資源的唯一辨別（根據檔案内容計算出來的摘要值）
優先級：ETag > Last-Modified
請求頭：
- If-None-Match
- 若上次的響應頭中含有ETag，則會将ETag的值作為請求頭的值
- 當伺服器發現資源的最新摘要值與If-None-Match的值不比對，則會傳回最新的資源（200 OK）
- 當發現值相同時，則說明資源未發生變化，是以不會傳回具體的資源（304 Not Modified）
- If-Modified-Since
- 若上次的響應頭中未含有ETag，但有Last-Modified，則會将Last-Modified的值作為請求頭的值
- 若伺服器發現資源的最後一次修改時間晚于If-Modified-Since，則會傳回最新的資源部（200 OK）
- 當發現時間相同或早于時，則說明資源未發送變化，是以不會傳回具體的資源（304 Not Modified）
Last-Modified與ETag對比：
- Last-Modified隻能精确到秒，是以若有資源能在1秒内被修改，則用戶端将無法擷取到最新的資源
- 若有些資源被修改後，又改了回來，此時修改時間發生了變化，但内容并未發生變化，會導緻相同的資源卻重複發送，沒有使用緩存機制
- ETag隻以資源内容為判斷标準，若資源未發生修改，則會使用緩存
緩存流程：
- 請求–>無本地緩存–>請求伺服器–>擷取到資源（根據Cache-Control是否為no-storage：是（不緩存到本地）否（緩存到本地））
- 請求–>有本地緩存–>
- Cache-Control不為no-cach–>緩存未過期–>使用本地緩存
- Cache-Control為no-cach
- 響應頭無ETag–>響應頭無Last-Modified–>請求伺服器–>擷取到資源–>決定是否緩存到本地
- 響應頭為ETag–>請求頭If-None-Match–>判斷資料是否有被修改（有（200 OK）無（304 Not Modified））
HTTPS
- 超文本傳輸安全協定
- 又稱HTTP over TLS、HTTP over SSL、HTTP Secure
- 預設端口為443（HTTP為80）
- 若通路HTTP的網址有HTTPS，一般會重定向到HTTPS處
- HTTPS成本較高
SSL/TLS
- HTTPS是在HTTP的基礎上使用了SSL/TLS來加密封包，防止竊聽
- TLS：傳輸層安全性協定，前身即為SSL（安全套接層）
- 位于應用層和傳輸層之間
HTTPS通信過程
- TCP的3次握手
- TLS的連接配接
- HTTP請求和響應
連接配接的目的是為了使用加密算法生産密鑰，使用ECDHE算法實作步驟：
TLS連接配接十大步驟：
- 省略ACK确認報
- （用戶端–>伺服器）
Client Hello
- TLS版本号
- 用戶端支援的加密元件（Cipher Suite）清單
- 加密元件是指所使用的加密算法及密鑰長度等
- 一個随機數（Client Random）
- （伺服器–>用戶端）
Server Hello
- TLS版本号
- 選擇的加密元件
- 從接收到的用戶端加密元件清單中挑選出來的
- 一個随機數（Server Random）
- （伺服器–>用戶端）
Certificate
- 伺服器的證書（已受CA簽名）
- （伺服器–>用戶端）
Server Key Exchange
- 一個參數（Server Params，用以實作ECDHE算法）
- ECDHE是一種密鑰交換算法
- 為防止僞造，Server Params會經過伺服器私鑰簽名
- 一個參數（Server Params，用以實作ECDHE算法）
- （伺服器–>用戶端）
Server Hello Done
- 通知用戶端，協商部分結束
前五步用戶端與伺服器間主要共享了：Client Random、Server Random、Server Params，用戶端也拿到了伺服器的公鑰證書，會先檢驗證書的有效性，之後：
- （用戶端–>伺服器）
Client Key Exchange
- 一個參數（Client Params，用以實作ECDHE算法的另一個參數）
此時，用戶端與伺服器都擁有了ECDHE算法所需要的兩個參數，用戶端與伺服器會用這兩個參數，計算出一個新的随機密鑰串：Pre-master secret，然後結合之前的兩個随機數，生成一個主密鑰，最後使用主密鑰衍生出其他密鑰、用戶端發送用的會話密鑰、伺服器發送用的會話密鑰（對稱密鑰）
- （用戶端–>伺服器）
Change Cipher Spec
- 告知伺服器之後的所有通信将采用計算出來的會話密鑰進行加密
- （用戶端–>伺服器）
Finished
- 将連接配接至今全部封包的整體校驗值（摘要，即哈希值），加密後發送給伺服器
- 此次握手協商是否成功，将以伺服器能否正确解密該封包作為判定标準
- （伺服器–>用戶端）
Change Cipher Spec
- 告知用戶端之後的所有通信将采用計算出來的會話密鑰進行加密
- （伺服器–>用戶端）
Finished
- 将連接配接至今全部封包的整體校驗值（摘要，即哈希值），加密後發送給用戶端
- 此次握手協商是否成功，将以用戶端能否正确解密該封包作為判定标準
HTTP/2
簡介
HTTP缺點：
- 同一連接配接，隻能對應一個請求
- 針對同一個域名，大多數浏覽器隻允許同時存在6個并發連接配接
- 隻允許用戶端主動發起請求
- 一個請求隻能對應一個響應
- 同一個會話中的多次請求，頭資訊會被重複傳輸
- 一般會給每個傳輸增加500~800位元組的開銷
- 使用Cookie會增加更多的開銷
為此，SPDY現世：
- SPDY，基于TCP的
應用層協定
- SPDY即為HTTP/2前身
- SPDY非取代HTTP，僅僅是修改了HTTP請求和響應的傳輸方式
- 僅增加了一個SDPY層，現有的代碼無需做任何變化，僅需更新一下用戶端與伺服器
HTTP/2特性
資料流
：邏輯概念，代表已建立的連接配接内的
雙向位元組流
，可以承載一條或多條消息
- 改進後的HTTP/2的所有通信都在一個TCP連接配接上完成，此連接配接可以承接任意數量的雙向資料流
消息
：與HTTP請求和響應消息對應，由一系列幀組成
幀
：在HTTP/2
應用層通信
的最小機關，每個幀都包含
幀頭
（會辨別出目前幀所屬的資料流）
- 是以來自不同資料流的幀可以交錯發送，最後再根據每個幀頭的資料流辨別符重新組裝好
-
二進制格式
- 采用二進制格式（二進制幀）傳輸資料，取代了HTTP/1的文本格式
- 在協定的解析和優化擴充方面帶來了更多的優勢
-
多路複用
- 用戶端和伺服器可以将HTTP消息分解為互不依賴的幀，然後可以交錯發送，最後在接收方那邊将幀重新組合起來
- 并行交錯發送多個請求，請求間互不影響
- 并行交錯發送多個響應，響應間互不影響
- 僅使用一個連接配接并行發送多個請求和響應，取代了HTTP/1的最多6個連接配接的情況
- 用戶端和伺服器可以将HTTP消息分解為互不依賴的幀，然後可以交錯發送，最後在接收方那邊将幀重新組合起來
-
優先級
- 優先給父資料流配置設定資源
- 同級資料流間按照權重比配置設定資源
- 按資源所占比例決定權重比，資源所占比例越大，權重比越高
-
頭部壓縮
- HTTP/2使用HPACK壓縮請求頭和響應頭資訊
- 存在一個靜态表，記錄上一次所發送的請求頭和資料頭，并對頭資訊進行編号。當下一次發送請求時，發現所要發的頭資訊已存在于靜态表中，就會隻發送重複的頭資訊的編号，以此來實作頭部壓縮
- HTTP/2使用HPACK壓縮請求頭和響應頭資訊
-
伺服器推送
- 伺服器會對用戶端的一個請求發送多個響應
- 除了對最初請求的響應外，伺服器還會向用戶端額外推送後續可能所需的資源，而無需用戶端請求
- 伺服器會對用戶端的一個請求發送多個響應
HTTP/3
簡介
HTTP/2缺點：
-
對頭阻塞
- HTTP/2以TCP協定作為底層，發送資料時雖然可以
多路複用
可靠傳輸
- HTTP/2以TCP協定作為底層，發送資料時雖然可以
-
握手延遲
- HTTP/2使用TCP協定作為底層，是以需要3次握手，若使用了TCP+TLS，則需要不斷進行互動，即建立連接配接時間長
是以，基于UDP的QUIC協定現世：
- 棄用了TCP協定，改用基于UDP的QUIC協定
- 意為快速UDP網絡連接配接
- HTT-over-QUIC即為HTTP/3前身
HTTP/3特性
- UDP無對頭阻塞問題，盡管發
- 握手
0 RRT
- RRT：即往返的時間
- 使用
QUIC
-
連接配接遷移
- TCP基于四大要素（源IP、源端口、目标IP、目标端口）建立連接配接，而QUIC雖然也基于四大要素，但不以四大要素作為連接配接辨別
- QUIC會使用一組
Connection ID
- 取代了HTTP/2的：一旦IP或端口發生變化，就會斷開連接配接的情況
弊端：
- CPU負載高（很多裝置未針對
UDP協定
WebSocket
HTTP請求特點：通信隻能由用戶端發起，為實作推送效果，使用的是
輪詢
技術
- 輪詢：浏覽器每隔一段時間向伺服器發送HTTP請求，伺服器傳回最新的資料給用戶端
WebSocket：
- 基于
TCP
全雙工通信
應用層
- 全雙工通信：伺服器、用戶端都能主動發送資訊給對方
- TCP原本支援全雙工通信，HTTP本身設計的“
請求-應答模式
- 在
建立連接配接
主動
- WebSocket和HTTP屬于
平級
- WebSocket使用80（
ws://
wss://
- 因為WebSocket需要事先建立連接配接（應用層方面），使得WebSocket也成為了一種有狀态的協定（會一直保持着連接配接狀态），是以之後的通信會省略部分狀态資訊
建立連接配接：WebSocket需要
借助
HTTP協定來建立連接配接（握手）
- 由用戶端（浏覽器）主動發起握手請求
頭資訊包含：
-
Upgrade: websocket
-
Connection: upgrade
-
Sec-WebSocket-Version
-
Sec-WebScoket-Key
-
伺服器收到Key後，會：
①：在Key受加上一個
固定
的GUID值
②：将①結果進行SHA-1
摘要計算
③：将②的結果進行Hex to Base64編碼（十六進制）
④：将③的結果作為
Sex-WebSocket-Accept
- 可以盡量避免普通的HTTP請求被認為WebSocket協定更新請求
-
WebService
- 一種跨程式設計語言和跨作業系統平台的遠端調用技術
标準
- 可以用普通的Web API取代
- 即要求若調用WebService服務，需要按照标準調用SOAP來擷取資料
SOAP：簡單對象通路協定
- 大多數為
HTTP+XM
- WebService使用該協定來封裝傳遞資料
- WSDL：WebService描述語言
- 使用一個XML文檔，描述了WevService接口的資訊
RESTful
- 譯為“表現層狀态轉移”
- 是一種網際網路軟體架構
設計風格
- 符合REST架構的Web服務，稱為RESTful Web服務
标準：
- URL中使用名詞（建議複數形式），不使用動詞
- 使用HTTP的方法表示動作
GET：查詢 POST：建立 PUT：更新 DELETE：删除 /users 查詢所有使用者 建立一個新使用者 更新所有使用者資訊 删除所有使用者 /users/6 查詢id為6的使用者 405（Method Not Allowed） 更新id為6的使用者資訊 删除id為6的使用者 - 一個資源連接配接到其他資源，使用子資源方式
GET /users/6/cars/88
POST /users/8/cars
- API版本化
baidu.com/v1/users
baidu.com/v2/users/66
- 傳回JSON格式的資料
- 發生錯誤時，不要傳回200狀态碼
HTTPDNS
- 基于HTTP協定向DNS伺服器（HTTP伺服器）發送域名解析請求
- 替代了基于DNS協定向營運商Local DNS發起解析請求的傳統方式
- 可以避免Local DNS造成的域名劫持和跨網通路等問題
- 常用于移動網際網路中
FTP
- 檔案傳輸協定，基于TCP的應用層協定
- URL格式：ftp://[user[:password]@]host[:port]/url-path
連接配接模式：需要用戶端與伺服器間建立
控制連接配接
和
資料連接配接
- 控制連接配接（指令端口）：用于傳輸狀态資訊（指令、cmd等）
- 資料連接配接（資料端口）：用于傳輸檔案和目錄資訊（data）
- 主動：
- 用戶端打開一個随機的
指令端口
大于
N
）
同時連接配接到伺服器的
指令端口21
- 用戶端開啟監聽資料的
資料端口N+1
Port
指令端口21
- 告訴伺服器此刻正在監聽資料的
資料端口N+1
- 伺服器的
指令端口21
- 告訴伺服器此刻正在監聽資料的
- 伺服器開啟
資料端口20
資料端口N+1
- 用戶端打開一個随機的
- 被動：
- 用戶端打開一個随機的
指令端口N
指令端口21
- 用戶端通過
指令端口N
PASV
指令端口21
資料端口P
- 用戶端
資料端口N+1
資料端口P
- 用戶端打開一個随機的
SMTP、POP、IMAP
簡介
發郵件使用協定：SMTP
- 簡單郵件傳輸協定
- 基于TCP
- 伺服器預設使用25端口，SSL/TLS下使用465端口
收郵件使用協定：POP
- 郵局協定
- 基于TCP，現使用POP3
- 伺服器預設使用110端口，SSL/TLS下使用995端口
收郵件使用協定：IMAP
- 網際網路資訊通路協定
- 基于TCP，現使用IMAP4
- 伺服器預設使用143端口，SSL/TLS使用993端口
POP與IMAP
POP特點：
- 用戶端連接配接伺服器時，會下載下傳伺服器内所有的郵件
- 可以設定下載下傳完成時，立即删除還是等待一段時間後再删除伺服器内的郵件
- 用戶端的操作（如删除郵件等）不會跟伺服器同步
- 每個用戶端都是獨立的，都有其自己的電子郵件副本
IMAP特點：
- 用戶端連接配接伺服器時，擷取的是伺服器上郵件的基本資訊，不會下載下傳郵件
- 在打開郵件時，才會開始下載下傳郵件
- 用戶端的操作會跟伺服器同步
- 所有的用戶端看到的始終是相同的一份郵件
IPv6
- 網際協定第6版
- 主要是為了解決IPv4位址枯竭問題，同時對IPv4進行了一些改進
- 使用比例增長緩慢，原因是需要裝置、作業系統核心更新以便支援IPv6
- 采用128位位址，每16bit一組，共8組，每組以
:
分隔開
如：
xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x
-
每組前面連續的0可以省略
如：
xxxx:0xxx:0000:0000:0000:0000:0xxx:0x0x
xxxx:xxx:0:0:0:0:xxx:x0x
- 可用
::
表示一組0或多組連續的0，但隻能出現一次，否則會造成歧義
如：
xxxx:0xxx:0000:0000:0000:0000:0xxx:0x0x
xxxx:0xxx::xxx:x0x
-
::1
首部格式：固定40位元組
-
version
-
Traffic Class
- 若路由器發生擁塞，則優先級低的資料包會先被丢棄
-
Payload Length
- 最大值為65535位元組
- 包括了擴充頭部、上一層（傳輸層）資料的長度
-
Hop Limit
-
Source Address
-
Destination Address
-
Flow Label
- 指明資料包屬于哪個流
- 用資料包源位址、目的位址、流标簽共同辨別一個流
-
Next Header
- 若有拓展頭部，則指明下一個拓展頭部的類型（編号）
網絡安全
代理伺服器
簡介
- 代替用戶端發送請求，代替伺服器發送響應，本身不産生内容
正向代理：
- 代理的對象是用戶端
- 為用戶端選擇伺服器
- 能隐藏用戶端的身份
- 能通過代理伺服器繞過防火牆
- 代理伺服器能限制某些裝置對Internet的通路（比如某些路由器隻允許代理伺服器通路，而代理伺服器就可以充當間接通路路由器的媒介）
- 資料過濾（與控制Internet通路權限類似）
反向代理：
- 代理的對象是伺服器
- 為伺服器選擇用戶端
- 能隐藏伺服器身份
- 安全防護
- 負載均衡（通過代理伺服器的負載均衡算法将請求分發到多個伺服器上）
頭部字段
Via
：追加（所有）經過的每一台代理伺服器的主機名或域名
X-Forwarded-For
：追加（所有）請求方的（公網）IP位址
- 如代理1将請求發送給代理2，此時的X-Forwarded-For為将請求發送給代理1的主機
X-Real-IP
：用戶端的真實（公網）IP位址
常見網絡安全問題
截獲：竊聽通信内容（被動攻擊）
中斷：中斷網絡通信（主動攻擊）
篡改：修改通信内容（主動攻擊）
僞造：僞造通信内容（主動攻擊）
ARP欺騙
- 網絡層
- 讓攻擊者擷取區域網路上的資料包甚至可以篡改資料包
- 讓網絡上特定電腦之間無法正常通信
- 讓送至特定IP位址的資料被錯誤送到攻擊者所篡改的地方
步驟：
- 假設C是攻擊者，A是接收方，B是發送方
- C隻要收到過A、B發送的ARP請求，就能擁有A、B的IP、MAC位址，也就能進行欺騙活動
- C在B接收到A的ARP響應包後，将一個ARP響應給B，響應包内的源IP為A的IP位址，源MAC被修改為C的MAC位址，此時B中的ARP表内原本A的MAC位址會被替換為C的MAC位址，B會根據目标IP的MAC位址（也就是現在的C）發送資料
防護：
- 靜态ARP
- 監聽ARP的不正常舉動
DoS、DDoS
- DoS：拒絕服務攻擊，使目标電腦的網絡或系統資源耗盡，使服務暫時中斷或停止，導緻使用者無法正常通路
- DDoS：使用網絡上多個被攻陷的電腦作為“僵屍”（殭屍電腦）,向特定的目标發動DoS攻擊
DoS攻擊分為2大類：
- 帶寬消耗型：UDP洪水攻擊、ICMP洪水攻擊
- 資源消耗型：SYN洪水攻擊、LAND攻擊
防禦：
- 防火牆：
- 防火牆可設定規則，比如隻允許或拒絕特定的通信協定、端口或IP位址，當攻擊從少數不正常的IP位址發出時，可以簡單的使用拒絕規則阻止一切從攻擊源IP發出的通信
- 複雜攻擊難以使用，例如當80端口受到攻擊時，不可能拒絕端口所有的通信，因為此規則也會阻止合法的流量進入）
- 防火牆可能處于較後端，可能惡意流量在路由器端就已經将網絡擁塞了
- 交換機：
- 大多數交換機具有一定的速度限制和通路控制能力
- 路由器：
- 和交換機類似
- 黑洞引導：
- 将受攻擊的計算機的通信全部發送至一個“黑洞”（空接口或是不存在的計算機位址）或有能力處理洪水的網絡裝置商處，以免網絡狀态受到較大影響
- 流量清洗：
- 将流量送至DDoS防護清洗中心，将正常流量與惡意流量區分開來，正常的流量将會被送回用戶端
SYN洪水攻擊
- 傳輸層
- 攻擊者發送一系列SYN請求到目标（第一次請求），并讓目标接收不到ACK（第三次握手）而進行等待，消耗資源
方式：
- 跳過發送最後的ACK資訊
- 第一次發送SYN時修改了源IP位址，讓目标送SYN-ACK到僞造的IP位址處
LAND攻擊
- 傳輸層
- 區域網路拒絕服務攻擊
- 通過持續發送
相同的源IP位址和目标IP位址
- 有些系統存在缺陷，允許裝置接收并響應來自網絡、卻宣稱來自于裝置自身的資料包，導緻循環應答
防護：
- 大多數防火牆都能攔截類似的資料包
- 路由器進行配置，屏蔽所有源位址和目标位址相同的資料包
DNS劫持
- 應用層
- 又稱為域名劫持，攻擊者篡改了某個域名的解析結果，将該域名的IP變為指定的IP，使得原本的網址被劫持到了另一個假冒的網址處
防護：
- 使用更靠譜的DNS伺服器
HTTP劫持
- 對HTTP資料包進行攔截處理後，插入一些指定的JS代碼，比如通路某些正常的網站時，會莫名其妙彈出些彈窗廣告
加密與解密
簡介
encrypt：加密
decrypt：解密
plaintext：明文
ciphertext：密文
- HTTP協定預設采取明文傳輸，即資料包被攔截後，很容易就能得到資料包内的資料
- 應當對資料進行加密後，再進行傳輸
- 常見的加密有：
-
不可逆：
單向散列函數：MDS、SHA等
-
可逆：
對稱加密：DES、3DES、AES等
非對稱加密：RSA等
-
其他：
混合密碼系統、數字簽名、證書
-
單向散列函數
- 又稱為消息摘要函數、哈希函數
- 散列值，又稱為消息摘要、指紋
- 根據消息内容計算出
唯一
- 散列值長度與消息長度
無關
固定長度
- 特點：
- 計算速度快
- 消息不同，散列值不同
- 單向性，即無法根據散列值計算出消息
常見的單向散列函數：
- MD4、MD5：産生128bit的散列值（已不安全）
- SHA-1：産生160bit的散列值（已不安全）
- SHA-2：SHA-256、SHA-384、SHA-512，散列值分别是256bit、384bit、512bit
- SHA-3：全新标準
常用場景：
- 校驗資料是否已被更改
- 将資料進行單向散列函數計算出一個唯一的散列值，再與現有的資料進行對比，若發現散列值不一樣，則說明資料已被篡改（因為相同資料的散列值相同）
- 密碼加密
- 将資料進行單向散列函數計算出一個散列值，即使資料被攔截擷取到，竊聽者也無法通過散列值逆推得出密碼
對稱加密
- 又稱對稱密碼
- 加密、解密時使用的是同一個密鑰
- 常見的對稱加密算法：DES、3DES、AES
- 将明文加密為暗文并發送給對方，并告知對方暗文的密鑰
- 存在密鑰被竊聽的風險
- 解決辦法：私下共享密鑰、密鑰配置設定中心、
非對稱加密
- 解決辦法：私下共享密鑰、密鑰配置設定中心、
DES
- DES是一種将64bit明文加密為64bit密文的對稱加密算法，密鑰長度為56bit（實質上為64bit，但每隔7bit會設定一個用于錯誤檢驗的bit）
- 由于DES每次隻能加密64bit的資料，是以當資料較大時，就要對DES加密進行疊代
- 已能在短時間内被破解
3DES
- 将DES重複3次所得到的密碼算法，又稱為3重DES、DES-EDE3
- 即用
3把不同
加密-->解密-->加密
- 處理速度不高，且安全問題逐漸暴露
AES
- 取代DES、3DES稱為新标準的算法，又稱為Rijndael加密法
- 密鑰長度有128、192、256bit三種
非對稱加密
- 又稱為公鑰密碼
- 密鑰分為加密密鑰、解密密鑰
- 加密密鑰一般是公開的，又稱公鑰
- 解密密鑰是由接受者自己保管，不會公開，又稱私鑰
- 公鑰和私鑰是一一對應的，不能單獨生成
-
公鑰加密的密文，必須使用與該公鑰對應的私鑰才能解密（常用于加密）
私鑰加密的密文，需要使用與該私鑰對應的公鑰解密（常用于數字簽名）
- 接收方将自身的公鑰發送給發送方，發送方用公鑰将資料加密後發送給接收方，接收方就可以用自身獨有的私鑰進行解密
- 非對稱加密解密速度比對稱加密慢
- 存在公鑰被篡改的風險
- 解決辦法：
證書
- 解決辦法：
RSA
- 目前使用最廣泛的非對稱加密算法
混合密碼
- 會話密鑰：指本次通信所随機生成的臨時密鑰
- 用
非對稱加密
密鑰
步驟：
- 随機生成的
會話密鑰
暗文
- 用接收者發送的
公鑰
會話密鑰
- 将加密後的會話密鑰和暗文一起發送給
接收者
- 接收者先用私鑰解密會話密鑰，再用會話密鑰解密暗文
缺點：
- 公鑰存在被篡改的風險
- 解決方法：
證書
- 解決方法：
證書
- 接收者在發送給發送者公鑰時，有可能被竊聽者攔截，竊聽者僞造出自己的公鑰發送給發送方，發送方用竊聽者的公鑰加密内容後發送給接收方，竊聽者攔截後用自身的私鑰解密，擷取資料
- 證書，又稱公鑰證書，内含接收方的個人資訊和公鑰
- 由認證機構（CA）用自身的公鑰施加數字簽名
步驟：
- 接收方将自身的
公鑰
- 認證機構用自身的
私鑰
公鑰
數字簽名
- 發送方在收到接收方的證書後，會先擷取認證機構的公鑰，再用認證機構的
公鑰
證書擷取步驟：
- 接收方将公鑰發送給認證機構注冊證書
- 認證機構生成對應證書并儲存到倉庫中
- 發送方去倉庫下載下傳對應證書做校驗
- 現各大CA的公鑰，預設已内置在浏覽器和作業系統中
- 可以用OpenSSL建構一套屬于自己的CA，稱為“自簽名證書”
數字簽名
- 生成簽名：消息發送者用自身的私鑰進行簽名
- 驗證簽名：資訊接收者用消息發送者的公鑰進行簽名校驗
- 數字簽名的作用：確定内容沒有被篡改，對消息發送方的肯定
-
既然為加密，則不希望别人知道我的資訊，隻有我能解密
公鑰加密，私鑰解密
-
既然為簽名，則不希望别人冒充我發消息，隻有我能簽名
私鑰簽名，公鑰驗簽
步驟：
- 發送方将資訊和自身公鑰發送給接收方
- 發送方用自身的私鑰對資訊進行簽名，然後發送簽名給接收方
- 接收方在收到簽名後用發送方的公鑰對其進行解密，确認與其收到的資訊是否一緻，若資訊一緻則說明資訊可信
缺點：
-
私鑰加密解密速度慢
解決方法：使用單向散列函數
- 發送方使用單向散列函數将資訊生成為對應的唯一散列值，對其進行簽名後發送給接收方
- 接收方使用單向散列函數對資訊進行計算，得出其散列值
- 接收方用發送方的公鑰進行解密，得出其散列值，判斷兩個散列值是否相同
概念剖析
零碎知識點
1）網絡、網際網路與網際網路：
- 網絡（
Network
- 網際網路（
internet
- 網際網路（
Internet
2）網絡分類：
- 區域網路（
LAN
- 以太網（
Ethernet
- 無線區域網路（
WLAN
- 以太網（
- 城域網（
MAN
- 廣域網（
WAN
3）ISP、伺服器機房：
- ISP：指網絡服務提供商，如移動等
- 伺服器機房：主機通過各種ISP連接配接到對應ISP的伺服器内
4）上網方式：
- 電話線入戶：ADSL電話撥号上網
- 非對稱數位用戶線路，提供上、下行不對稱的傳輸寬帶（上傳或下載下傳的速度不一樣）
-
①電腦連接配接路由器的區域網路（LAN）接口
②路由器的廣域網（WAN）接口連接配接貓（數據機，用于數字信号和模拟信号間的轉換）
③貓的電話接口連接配接（外網）電話線
- 光纖入戶：
- ①電腦連接配接路由器的區域網路（LAN）接口
- ②路由器的廣域網（WAN）接口連接配接光貓（數據機，用于數字信号和光信号間的轉換）
- ③光貓的PON接口連接配接入戶光纖
- 無線路由器：
- 路由器内置交換機，該交換機的一個端口連接配接無線AP，是以連接配接無線網的裝置處于同一網段
5）公網IP、私網IP：
- IP位址可分為公網IP和私網IP
- 資料傳輸間需要使用NAT技術進行轉換
- 公網IP：
- Internet上的路由器隻能下一跳到公網的路由器，不能到達私網的路由器
- 私網IP：
- 區域網路使用，在不同區域網路内可以重複
- 由保留的公網網段劃分出來：
- A類：
10.0.0.0/8
- B類：
172.16.0.0/16
172.31.0.0/16
- C類：
192.168.0.0/24
192.168.255.0/24
- A類：
6）NAT：
- 由于私網IP在不同區域網路内可以重複，是以在進行資料傳輸時，需要将私網IP轉換為公網IP（確定資料傳輸目的地無誤）
- 可由路由器完成
- 節約公網IP資源，隐藏内部真實IP
- NAT分類：
- 靜态轉換：手動配置NAT映射表，一對一轉換
- 動态轉換：定義外部位址池，動态随機轉換，一對一轉換
- PAT：多對一轉換，采用端口多路複用（一個公網IP可以同時被使用），利用端口号區分
7）模拟信号與數字信号：
- 模拟信号：連續的信号，适合長距離傳輸，抗幹擾能力差，受幹擾難複原
- 數字信号：離散的信号（變化差異大），不适合長距離傳輸，抗幹擾能力強，受幹擾也可修複
8）信道：資訊傳輸的通道，一條傳輸媒體（如網線）上可具有多條信道
- 單工通信：隻能一個方向上傳輸資料，不能改變信号的傳輸方向，如無線電廣播
- 半雙工通信：信号可雙向傳輸，但隻能交替進行，如對講機
- 全雙工通信：信号可同時雙向傳輸，如手機
9）tcpdump：Linux上的抓包工具
vpn
- 虛拟私人網絡
- 可以在公共網絡上建立專用網絡，進行加密通訊
- 用戶端到VPN伺服器間的資料傳輸過程中會進行資料加密，而VPN伺服器到伺服器間的資料傳輸過程不會進行資料加密
- VPN加密是在原有的協定上進行的資料加密
- 需要安裝額外的VPN用戶端軟體
- 可以提高上網的安全性
- 隐藏上網者的身份
- 在資料發送開始就進行了加密
- 突破網站的地域限制
- 一些網站會對不同地區的使用者展示不同内容
- 突破網絡封鎖（比如防火牆的限制）
與代理的差別：
- VPN需要安裝特定的VPN用戶端軟體，代理不需要
- VPN預設會對資料進行加密，代理不會
- VPN比較貴
實作原理：隧道協定（工作在傳輸層、資料鍊路層）
- PPTP（點對點隧道協定）、L2TP（第二層隧道協定）、IPsec（網際網路安全協定）、SSL VPN
網絡爬蟲
- 網絡蜘蛛，模拟人類行為進行浏覽頁面，并儲存資料的過程
- 搜尋引擎也使用了爬蟲
- robots.txt：存于網站根目錄下，用于告訴哪些可以爬，哪些不能（隻是個規範）
-
User-agent:*
Disallow
User-agent:*
Allow:/
-
User-agent:name_spider
Allow:
-
User-agent:*
Disallow:/
-
User-agent:*
Disallow:/xxx/
-
User-agent:*
Disallow:/*.php$
-
無線網絡
- 手機等裝置上會有傳輸信号所用的天線，通過天線将信号發送到最近的基站，基站間可能通過天線、光纖等傳遞信号，最後通過天線傳遞給對方
- 路由器上也有類似天線的（無線AP）無線接入點
即時通信
- 簡稱IM，常用XMPP、MQTT、自定義協定等
XMPP：
- 可拓展消息與存在協定，前身時Jabber
- 基于TCP，預設端口5222、5269
- 特點：
- 使用XML格式進傳輸，體積較大
- 比較成熟的IM協定，開發者接入友善
MQTT：
- 消息隊列遙測傳輸
- 基于TCP，預設端口為1883、883（帶SSL/TLS）
- 特點：
- 開銷很小，降低網絡流量，資訊冗雜遠小于XMPP
- 非專門的IM協定，很多功能需要自己實作
- 被認為是最适合物聯網（loT）的網絡協定
流媒體
- 又稱流式媒體
- 指将一連串多媒體資料壓縮後，分段發送資料，實作即時傳輸的一種技術
- 使用該技術将不必使用前先下載下傳整個媒體檔案
- 常見協定：
- RTP：實時傳輸協定，基于UDP
- RTCP：實時傳輸控制協定，基于UDP，使用RTP的下一個端口
- RTSP：實時流協定，基于TCP、UDP的554端口
- RTMP：實時消息傳輸協定，預設基于TCP的1935端口
- HLS：基于HTTP的流媒體網絡傳輸協定
指令
ping的用法
ping /?
：檢視ping的用法
ping ip位址 -l 資料包大小
：給指定ip發送指定大小的資料包
ping ip位址 -f
：不允許網絡層分片
ping ip位址 -i TTL
：設定TTL的值
tracert ip位址
、
pathping ip位址
：跟蹤資料包經過的路由器
DNS常用指令
ipconfig/displaydns
：檢視DNS緩存記錄
ipconfig/flushdns
：清空DNS緩存記錄
nslookup 域名
：可檢視域名對應的IP位址
MAC位址常用指令
arp -a （主機IP）
：檢視ARP緩存
arp -d （主機IP）
：删除ARP緩存
arp -s 主機IP MAC位址
：增加一條緩存（靜态緩存，時間較久）
DHCP常用指令
ipconfig/all
：檢視DHCP相關的詳細詳細，如租約過期時間、DHCP伺服器位址
ipconfig/release
：釋放租約
ipconfig/renew
：重新申請IP位址、申請續約（延長租期）
OpenSSL常用指令
- 需要安裝有OpenSSL
openssl genrsa -out 私鑰檔案名.key
：生成私鑰
openssl rsa -in 私鑰檔案名.key -pubout -out 公鑰檔案名.pem
：生成公鑰
常用指令
netstat -an
：檢視被占用的端口
netstat -anb
：檢視被占用的端口、占用端口的程式
（需要配置）
telnet localhost 端口号
：檢視是否可以通路主機的某個端口
（Xshell中使用）
telnet localhost 8080
：直接面向HTTP封包與伺服器互動
![碩博連讀，985院校在夾縫中求生，衆多強者中面試Python成功上岸前言一、Python入門二、資料庫三、爬蟲四、資料分析五、web開發（前/後端）[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)