應用場景選擇
如果需要可靠傳輸,首選 TCP
如果需要傳輸的數據包很大,也首選 TCP
絕大部分的場景,都可以優先考慮 TCP
UDP 相比于 TCP,最大的優點在于傳輸效率
有些情況,既需要可靠性又需要性能,這個時候時候就需要 KCP
TCP 是高可靠低效率,UDP 是無可靠高效率,KCP 是低可靠較高效率
如何使用 UDP 來實現可靠傳輸?
TCP 咋做我們就咋做
IP 協議主要完成的工作是兩方面
1.地址管理,使用一套地址體系,來描述互聯網上每個設備所處的位置
2.路由選擇
先認識一下 IP 協議報頭
上述拆包過程都是 IP(系統內核)自動完成的(IP 的拆包并不是因為達到 64 KB,而是在數據鏈路層還有限制)
包拆了之后,未來如何組包?
六度空間理論
世界上任何兩個人想認識一下,只需要六層朋友介紹(設想是每個人執行力都是一定的)
在計算機中,每個路由器都是“執行力最強的朋友”
所以想要通過網絡訪問到世界任何一個角落,最多經歷 32 / 64 次就足夠了
windous 有一個命令 tracert 這個命令就可以看到當前網絡通信的路徑是怎樣的
IP 協議如何管理的地址?
IP 地址本質上就是一個 32 整數,為了方便,就會把 IP 表示成 點分十進制 的方式,通過 3 個點分成 4 個部分,每個部分 1 個字節,每個部分的取值都是 0 - 255
IP 地址存在,目的就是為了能夠區分網絡上不同的設備,希望每個網絡設備都有唯一的一個 IP 地址
如何解決 IP地址不夠用?
1.動態分配 IP 地址
2.NAT地址
先把 IP 分成兩大類
1.私網 IP / 局域網 IP
IP 地址是以 10.*,172.16-172.31.*,192.168.*
這三類地址都是 私網 IP
2.公網IP / 廣域網 IP
要求公網上的設備,對應的公網 IP,都必須是唯一的
但是私網上 / 局域網上的設備,使用私網 IP,只要保證局域網內部的 IP 不重復即可,不同的局域網之間的 IP 允許重復
由于上述設定,就有一個重要的限制:
1.公網設備訪問公網設備,沒有任何問題,直接訪問即可
2.局域網設備訪問局域網設備(同一個局域網),也沒有問題
3.局域網設備訪問局域網設備(不同局域網),不允許訪問
4.局域網設備訪問公網設備,就需要對局域網設備的 IP 進行地址轉換
5.公網設備訪問局域網設備,不允許主動訪問
3.IPV6?
增加了 IP 地址個數
IPV4 使用了 4 個字節表示 IP 地址
IPV6 使用了 16 個字節 表示 IP 地址
IPV6 和 IPV4 不兼容
把一個 IP 地址,分成兩個部分,網絡號 + 主機號
我們的機器都是在一個局域網中的,網絡號都是相同的,主機號是不同的
一個局域網中,網絡號 和 主機號 都相同,是無法上網的
如果局域網中的設備,網絡號 和 路由器的網絡號不相同,無法上網
路由器 有一個功能 DHCP 自動把局域網這里的設備的 IP 分配好
1111 1111 1111 1111 1111 1111 0000 0000
左側全都是 1, 右側全是 0,不會出現 1 0 混著,位置為 1的撲粉都是“網絡號”,為 0 的部分就全都是主機號
家用寬帶來說的話,一般默認前三個字節是網絡號,主機號的范圍就表示局域網中可以有多少個設備,一個字節能表示 256
時間往前推移 20 到 30 年左右,當年的網段劃分方式不太一樣
在之前的網段劃分方式,沒有子網掩碼,直接通過設定 IP 的前綴來起到設置網段的效果
比較死板,尤其是 A B 類浪費了 很多 IP 地址
一些特殊的 IP地址
127.0.0.1? ? 127.*? 環回 IP
如果某個 IP 的主機號為全 0,表示 “這個網段”? 它不能分配給某個主機
如果某個 IP 的主機號全是 1,表示“廣播地址” ,表示二進制全是 1
192.168.0.255 這才是正確的
廣播一對多,這樣的傳輸,而且這里的多,指的是所有人
單播:一對一
組播:一對多(整體的一部分)
廣播:一對多(整體的所有)
往廣播地址上發消息,局域網中所有的設備都能收到,必須要發 UDP 的消息,TCP 不支持廣播
廣播的一個典型的應用場景:手機投屏 / 電腦投屏
點擊投屏,手機就會在局域網中廣播一個查詢數據包,看哪些設備有回應,根據回應,就知道 IP
為哪個的設備是能夠支持投屏的
接下來選擇對應的設備,就可以把數據和這個設備進行通信了
IP 協議 地址管理
路由選擇
網絡結構太復雜,每個路由器都無法掌握全局的信息,只能掌握一部分局部信息,此時路由器規劃出來的路線,只能是一個“較優解”
路由器轉發數據包的過程就是類似的過程
數據報中包含了“目的 IP” 字段,就是要問路的目標,每個路由器都對于網絡環境(和他相鄰的設備情況)有一定了解的,此時,就可以根據它的了解告訴我們下一步往哪個方向走
路由器內部有一個數據結構,路由表
路由表? ?目的 IP 的網段? ? ? 對應的網絡接口(從路由器的哪個口出)
拿著目的 IP 去路由表匹配,很可能此時查詢結果在路由表不存在
數據鏈路層
以太網(橫跨數據鏈路層 和 物理層)
以太網
數據幀格式
數據鏈路層,引入了另外一套地址體系,稱為“mac地址” / 物理地址
mac 地址 和 IP 地址 是獨立的兩套地址體系
IP 地址 側重于 全局的轉發,從起點到終點,這整個轉發過程,通過 IP 地址 負責完成(查詢路由表,通過 IP 地址)
MAC 地址,側重于 局部的轉發,兩個相鄰設備之間的轉發
一般開發很少用到 mac 地址,而 IP 地址會用的很多
mac 地址通常按照 16 禁止的方式表示字節之間通常使用 - 或者 :分割
mac 地址表示的范圍比 IPV4 地址大很多,當前 mac 地址都是和主機 一對一綁定的
IP 地址很多時候都是動態分配的
mac 地址就是靜態分配的,網卡出廠時,mac 地址就寫死了
由于 mac 地址有這樣的特性,有些程序,就會使用 mac 地址來作為機器的身份標識
域名解析系統 DNS
使用 IP 地址來描述網絡設備的位置? ?域名 一串可讀性更好的單詞 把域名自動的轉換成對應的 IP 地址
上古時期,映入了一個 hosts 文件
這里的內容就是行文本,包含很多行,每一行都有 IP 和 域名,每次訪問某個域名就會進行查詢,獲取到對應的 IP
hosts 文件目前仍然是有效的
搭建域名服務器的時候還會對于域名進行分級管理,一級域名,二級域名,三級域名。。。。這樣就可以控制每個服務器管理的數據都不多
這時谷歌搞的一套 DNS 鏡像服務器
HTTP 協議
HTTP 也是基于 TCP 來實現的
“超文本傳輸協議”
文本 => 字符串 超文本 不僅僅是字符串,還可以攜帶一些圖片,特殊的格式
HTTP 協議最主要的應用場景,就是網站,瀏覽器 和 服務器之間,傳輸數據,客戶端 和 服務器之間的數據傳輸,也很可能是 HTTP
HTTP 協議交互過程
HTTP 報文格式
抓包工具 抓包工具本質上是一個 “代理程序”,能夠獲取到網絡上傳輸的數據,并顯示出來
代理分成兩種
正向代理(客戶端代言人)
反向代理(服務器代言人)
如果之前fidder 安裝配置沒問題的話,會抓到很多數據包
打開一個網站,瀏覽器和服務器之間進行的 HTTP 交互不是只有一次,通常有很多次,第一次交互拿到這個頁面的 html,html 還會依賴其他的 css 和 js,圖片等,html 被瀏覽器加載之后,又會觸發一些其他的 http 請求,獲取到 css,js等,當執行js 的時候,js 代碼里可能又要觸發很多的http請求,獲取到一些數據
藍色的表示返回的是一個 html,往往是一個網站的入口請求,選中請求并雙擊,能看到明細
右上角請求明細
右下角響應明細
http請求的原始數據
當前響應數據被壓縮了,網絡傳輸中,帶寬是一個比較貴的硬件資源,為了節省帶寬,就可以把相應數據進行壓縮
HTTP 請求,包含四個部分
1.首行
2.請求頭
3.空行
請求頭最下面會有一個空行,這個空行就可以表示結束標記
4.正文(body)
http 的載荷部分
有的 http 有 body 有的沒有
HTTP 響應的基本格式,分成 4 個部分
1.首行
2.響應頭 鍵值對
3.空行
4.響應正文
相應的載荷是 html
URL
描述一個網絡上的資源位置
唯一資源定位符
uri 是唯一資源標識符
查詢字符串,是客戶端給服務器傳遞信息的重要途徑,這里的組織方式是按照鍵值對的方式來組織的
關于 URL encode
query string 里是自定義的鍵值對
在 URL 中,本身有些特殊符號具有特定的含義
如果 url 的 query string 中也包含同樣的符號,咋辦?
如果直接寫進去,可能就會使服務器 / 瀏覽器 解析失敗,靠譜的方法就是對上述符號進行 “轉義”
對于漢字,也是要進行轉義的
漢字的 utf8 / gbk 等編碼值其中可能某個字節就恰好和某可符號的 ascil 碼一致
這里的 urlencode 編碼十分重要
實際開發中,當要構造一個 url,尤其是 url 的 query string 中要包含中文的時候,務必要進行編碼