電腦網路（Learning Records）
背景：沒想到本專業並不開設這門課程，感覺過於逆天，之前開發的時候了解過相關知識
但是從來沒有系統地學過，就自己看了書，總結一下
參考：《TCP/IP詳解 卷1：協議》
概述
大多數網路應用程式被設計成客戶——伺服器的模式
域名系統（DNS）是一個分布資料庫，它可以提供IP地址和主機名的映射
當應用程式通過TCP傳入數據時，數據通過協議棧封裝（TCP首部，IP首部，乙太網首部和尾部）
分用：
TCP伺服器是並髮型的，UDP伺服器是重複型（非並發）
ARP
又被稱為地址解析協議，它為IP地址到對應的硬體地址之間提供動態映射
首先它會發送一份「廣播」（以太數據幀）給乙太網上的每個主機
數據幀中包含目標主機的地址，如果是目標主機，則會回答硬體地址
那麼使用ARP進行請求-回答交換的IP數據現在就可以傳送了
註明：點對點鏈路不使用ARP
ARP高速快取能有效提高ARP的效率
RARP功能與ARP相反，請求以廣播的形式發送，應答以單播的形式發送
ICMP
ICMP經常被認為是IP層的一個組成部分，它傳輸報錯的資訊和其他需要注意的資訊
ICMP報文通常被IP層或更高協議層調用
ICMP時間戳可以用於計算應答的時間
IP
提供不可靠，無連接的數據報傳送服務
不可靠指的是他不能保證IP數據成功到達目的地，只提供最好的傳輸服務
無連接指的是他不處理後續數據報的狀態資訊，每個數據報的處理是相互獨立的
同時也是不按順序處理數據報的
IP路由選擇
IP從TCP或ICMP或網路介面等接受到數據報之後，其在記憶體中有一個記憶體表
當來自網路介面時，會首先檢查是否是本機的IP地址之一或廣播地址
路由表中包含
- 目的IP地址
- 下一站路由器的IP地址，或者直接相連的網路IP地址
- 標誌 指明IP地址是網路地址還是主機地址
- 為數據報的傳輸指定一個網路介面
所有的IP路由選擇只為數據報傳輸指明下一個路由的IP地址
ping
主要是為了測試一台主機是否可達，具有時間戳
Traceroute
可以看到IP數據報從一個主機傳到另一個主機所經過的路由
用Traceroute的理由（為什麼不用（RR）IP記錄路由）
- IP留給首部的空間有限，不能存放大多數的路徑
- 並不是所有的路由器都支援記錄路由選項
- 記錄路由一般是單向的選項
主要利用的是ICMP和IP首部中的TTL欄位
TTL作為一個跳站的計數器，所經過的每個路由都將其值-1
TTL也可以防止數據無休止地流動，當TTL為0或1時，會丟棄該數據，並給信源發送一份ICMP超時資訊
Traceroute的關鍵在於包含這份ICMP報文的資訊里也有該路由的資訊
所以其工作原理是：先發送一份TTL為1的報文從而得到第一個路由的地址，然後發送TTL為2的報文，這樣持續到主機
IP選路
IP層工作流程如圖所示：
IP層進行選路只是決定把哪些路由放進路由表的規則。
IP執行選路機制，而路由守護程式一般提供選路策略
IP搜索路由表時先搜索匹配項，再搜索默認項
如果要到達不直接相連的主機或網路必須用某種方式添加到路由表中
比如：
- 在系統引導時顯式的在初始化文件中運行route命令
- 運行路由守護程式
如果既沒找到匹配項，又沒找到默認項
結果取決於該IP數據報是由主機產生還是轉發的
-
主機產生——返回報錯資訊給主機
-
轉發產生——向原始發送端發送ICMP不可達報錯資訊
-
ICMP重定向差錯
當發現IP數據報應該傳送給另一個路由時，收到數據報的路由器會向數據報的發送端發送ICMP重定向差錯
重定向操作一般用來幫助主機建立完善的路由表
剛開始路由表有一個默認表項，一旦默認路由發生差錯，默認路由器將通知其進行重定向，並允許主機對對應的路由表進行改動
需要注意的是 -
重定向報文只能由路由器生成，而不能由主機生成
-
重定向報文是為主機而不是路由器使用的
路由器發送的應該是對主機的重定向，而不是對網路的重定向
動態選路
動態選路並不改變內核在IP層的運行方式
路由器之間採用通訊協議交互，而路由守護程式運行通訊協議
僅僅是放置在路由表中的資訊改變了——當路由隨時間變化時
路由是由路由守護動態增加或刪除，而不是來源於程式文件中的route命令
具體協議有：
- RIP協議（距離向量）
- OSPF協議（直接使用IP）
- BGP協議（距離向量——TCP）
- CIDR協議
UDP：用戶數據報協議
UDP並不可靠，它把應用程式傳給IP層的數據發送出去，但是並不保證能到達目的地
廣播和多播
廣播是將數據發送到網路中的所有主機（一般指的是本地相連的網路），多播是發送到主機組
廣播和多播都僅用於UDP
使用廣播的問題主要是會增加對該數據報不感興趣的主機的負荷
子網：網路小島
IGMP
多播的基礎是一個進程的概念，而多播組中的成員是動態的
多播路由器用IGMP來記錄與該路由器相連的網路中組成成員的變化情況
使用規則：
- 當第一個進程進入一個組時，發送一個IGMP報告。如果一個主機的多個進程加入同一組，只發送一個報告
- 當進程出組時，主機不發送IGMP報告
- 多播路由器會定時發送IGMP報文來查詢是否還有任何主機有屬於多播組的進程
- 主機通過發送IGMP報告來響應IGMP查詢
使用這些報文，多播路由器對每個介面保持一個表，表上記錄至少一個包含主機的多播組
路由器只將報文轉發到還擁有屬於那個組主機的介面上
DNS域名系統
DNS主要提供IP地址與主機名之間的轉換以及電子郵件的選路資訊
名字伺服器
一般用來查詢域名資訊等
主名字伺服器——-從磁碟文件調度資訊
輔名字伺服器——-從主名字伺服器調入資訊
主，輔名字伺服器之間是獨立的
應用程式通過名字解析器將主機名轉化為IP地址，也可以將IP地址轉化為主機名
名字解析器將向名字伺服器發送查詢請求
所有的DNS查詢都有相同的報文形式，它包含查詢請求和可能的回答資源記錄，授權資源和附加資源記錄
TFTP
TFTP使用不可靠的UDP，安全性沒有保證
TFTP使用停止等待協議，數據發送方在發送下一個數據塊之前需要等待對方的接收和確認
TCP
指的是傳輸控制協議，它是一種可靠的，面向連接的位元組流服務
可靠性體現在：
- 應用數據會被分成TCP認為最合適發送的數據塊。這和UDP不同（UDP應用程式產生的數據塊長度不變）
- 超時重傳
- 需要確認
- 會保持首部和數據的檢驗和
- 數據後重新排序
- 丟棄重複
- 流量控制
每個TCP段包含源端和目的端埠號，它和IP首部中的源端IP地址和目的端IP地址唯一確定一個TCP連接
TCP為應用層提供雙工服務，說明數據能在兩個方向上獨立地進行運輸
TCP連接的建立和終止
建立一個連接需要3次握手，而終止一個連接需要4次握手
SYN：同步序列編號，它是TCP/IP建立連接時使用的握手訊號，SYN=1，ACK=0時表示這是一個連接請求報文段
若對方同意連接，則響應報文段中SYN=1，ACK=1
ACK：確認號欄位，TCP規定在連接建立後的所有傳送報文段中ACK都置為1
FIN：FIN為1時表示該報文段的發送方已經結束向對方發送數據，並要求斷開連接
ISN：初始序列號
一個TCP連接由一個四元組構成
分別是發送端的IP地址和埠號，接收端的IP地址和埠號
一個TCP的建立需要以下步驟
- 客戶端發送一個SYN報文段，並且指明想要的接收端埠和自己的ISN1
- 伺服器也發送自己的SYN報文段進行響應，並且包含自己的ISN2，同時為了確認客戶端的SYN，將ACK置為ISN1+1
所以每次發送一個報文段，ISN都會+1，這樣可以防止丟失的情況 - 同樣為了確認服務端的ISN，客戶端會將ACK置為ISN2+1
所以可以發現，TCP的這三次握手主要目的在於交換連接雙方的初始序列號ISN
終止需要4次揮手
- 連接的主動關閉者發送一個FIN段指明接收者，同時發送自己的序列號ISN1
- 被動關閉者將ACK置為ISN1+1。此時，上層的程式會被告知連接的另一端已經發出了關閉請求。
- 然後被動關閉者變為主動關閉者，並發送自己的FIN
- 為了完成連接的關閉，最後一個報文還包含一個ACK用於確認上一個FIN，防止FIN丟失
TCP的成塊數據流
TCP使用的被稱為滑動窗口協議的另一種流量控制方法
該協議允許發送方在停止並等待確認前可以連續發送多少個分組
由於發送方不必每發送一個數據就等待確認，所以這可以加速數據的傳輸
用三個術語來描述窗口左右兩邊的運動
- 窗口合攏：左邊沿向右收縮，一般發生在數據被發送和確認時
- 窗口張開：右邊向右移動，一般發生在另一端的接收進程讀取已經確認的的數據並釋放了TCP的接收快取時
- 窗口收縮：右邊沿向左移動
如圖所示：
（字丑還請見諒doge
由接收方提供的滑動窗口進程通常可以由接受進程式控制制，同時也會影響到TCP的性能
———-慢啟動
TCP支援一種叫慢啟動的演算法，它保證了新分組進入網路的速率和另一端確認的速率相同
它為發送方提供了一種窗口：擁塞窗口
在工作時，發送方取擁塞窗口和通告窗口中的最小值作為發送上限。
擁塞窗口是發送方的流量限制，通告窗口是接收方的流量限制
TCP的超時和重傳
超時重傳是TCP保證安全的一個重要的機制
原理是在發送一個數據過後就開啟一個定時器，如果在一定的時間內沒有接收到ACK報文，那麼就重新發送數據，直到發送成功為止
重傳超時時間（RTO）：RTO的設定會影響到超時傳輸協議的效率，其值的設定是一個關鍵的參數
傳輸往返時間（RTT）：固定的超時值
一般會認為RTO的取值會略大於RTT
使用低通過濾器來更新一個被平滑的RTT估計器
新的SRTT=α×（舊的SRTT）+（1-α）×（新的RTT樣本）
Karn演算法：在一個超時和重傳發生時，在重傳數據到達確認前，不能更新RTT估計器，因為不知道ACK對應哪次傳輸
有關演算法還有擁塞避免演算法，快速重傳和快速回復演算法等等
TCP的堅持定時器
如果一個確認丟失了，那麼發送方和接收方之間可能會因為持續等待而發生死鎖
為了防止死鎖的產生，所以有了堅持定時器。以周期性地向接收方查詢
TCP的保活定時器
如果TCP連接的雙方都沒有向對方發送數據，則在兩個TCP模組之間不交換任何資訊
如果一個給定的TCP連接在兩個小時都沒有任何動作，則伺服器向客戶發送一個探查報文片段
則客戶主機必須處於以下4種情況之一
- 客戶主機依然正常運行，並且從伺服器可達
- 客戶主機崩潰，並且關閉或者重新啟動
- 客戶主機崩潰並已經重新啟動
- 客戶主機正常運行，但是從伺服器不可達
第一種情況客戶主機並不會發現保活探查的發生，整個過程對TCP層是透明的
只有第2，3，4種情況時TCP會發送差錯報告
HTTP協議
包括4個請求：
- get：請求讀取URL所標誌的資訊
- post：給伺服器添加資訊
- put：在給定url下儲存文檔
- delete：刪除給定url所標誌的資源
get和post區別：
- get是從伺服器上獲取數據，post是向伺服器發送數據
- get會把參數數據隊列添加到url中，值和表單內各個欄位一一對應
- get傳輸的數據量小，不超過2KB,post傳輸的數據量大，默認不限制
- 根據HTTP規範，GET用於資訊獲取，是安全和冪等的
安全：僅用於獲取資訊而不是修改資訊
冪等：對同一URL的多個請求應返回相同的結果
在瀏覽器中輸入 //www.baidu.com/ 所執行的全過程
Baidu.com是我們想要訪問的伺服器，執行以下操作
- 客戶端瀏覽器通過DNS解析//www.baidu.com/的IP地址到220.181.27.48，通過此IP地址找到客戶端到服務端的路徑，客戶端向該IP發起一個HTTP會話，然後通過TCP封裝數據包，輸出到網路層，建立TCP連接
- 在客戶端的傳輸層，把HTTP會話請求分成報文段，添加源和目的埠，如果伺服器使用80埠監聽請求，客戶端隨機選擇一個埠，和伺服器進行交換，伺服器把相應的請求返回給客戶端的埠（伺服器處理請求）
- 客戶端的網路層主要做的就是通過路由表查詢如何到達伺服器
- 包通過鏈路層發送到路由器
狀態碼（開發常用）
200：請求成功，一般用於get和post
500：伺服器內部錯誤，無法完成請求
401：請求需要用戶身份驗證
403：伺服器拒絕請求
404：伺服器無法根據客戶端請求找到網頁資源
cookie
HTTP協議本身是無狀態的——指無法辨認用戶的身份
cookie實際上是一小段文本消息
客戶端向伺服器發起請求，如果伺服器需要記錄該用戶狀態，就需要向客戶瀏覽器發一個cookie。
而客戶端瀏覽器會把cookie保存起來。當瀏覽器再次請求時，會把cookie一起提交給伺服器，伺服器會檢查該用戶的狀態
