可靠資料傳輸：傳輸資料位元不會損壞、丟失，有序傳送接收
可靠傳輸協議的發展
rdt1.0:
rdt1.0是基於理想情況下的協議，假設所有通道都是可靠的，沒有位元位的翻轉，沒有資料報的丟失與超時，所以rdt1.0的傳輸功能就是 傳送方傳送資料，接收方接受資料。
rdt2.0:
在有位元差錯的情況下 進行可靠資料傳輸
採用自動重傳請求協議：差錯檢測、接收方反饋（肯定確認ack，否定確認nak）、重傳。
也被成為停等協議：當傳送方處於等待ack或nak時，不能從上層獲得更多資料
rdt2.1:
考慮ack或nak受損
傳送方對資料分組編號，接收方只要檢查序號。
rdt2.2:
不使用nak，採用ack，0 ack，1來表示接受的狀態
rdt3.0:位元交替協議（分組序號在0和1之間交替）
解決具有位元差錯和丟包的問題
解決傳送方接收不到響應：資料分組或接收方對該分組的ack丟失
傳送方選擇乙個時間值判定發生丟包，進行重傳
協議執行中應用到技術：檢驗和（檢驗差錯），序號（分組標記），定時器（解決資料丟失），肯定和否定分組
rdt3.0由於以停等方式執行，在rtt時間段內，網路處於空閒狀態，而rtt時間段比較長，使得利用率十分的低。解決辦法是：允許傳送方傳送多個分組不用等待確認 叫做流水線
進而引出了：回退n步、選擇重傳（增加序號範圍，增加快取，解決流水線的差錯恢復）
回退n步：
1、n指的是傳送未確認和可用於傳送的序號數量
2、gbn傳送方響應的三種型別：
上層的呼叫：
要檢查傳送視窗是否已滿（是否有n個已傳送但未被確認的分組），未滿則傳送，滿了就
等會，或者快取。
收到乙個ack：
採用累計確認
超時事件：
回退n步 名字的**。出現丟失和時延長的分組，超過定時器的時限，則重傳所有已發
送但還未被確認過的分組，使用乙個定時器
3、接收是按序號順序接收，不按序就重發
選擇重傳：
由於gbn容易引起大量重傳，降低效率。由此產生sr
sr通過讓傳送方僅重傳那些它懷疑在接收方出錯（丟失或受損）的分組，避免不必要的重傳。sr接收方確認乙個正確接收的分組不管其是否按序，失序將被快取。超時傳送方重傳
。重傳後再將快取交付。
可靠資料傳輸原理
概述 可靠資料傳輸原理 tcp的可靠資料傳輸 tcp可靠資料傳輸的滑動視窗既不是純粹的gbn，也不是純粹的sr，在這兩個協議之外又引入了新的東西。資料傳輸發生錯誤怎麼辦？傳送方的有限狀態機 圓圈代表當前所處的狀態，帶箭頭的線代表狀態的轉換，橫線上方指示引起狀態變遷的事件，橫線下方指示狀態轉換中採取的...
可靠資料傳輸原理（下）
上篇筆記中，我們主要討論了可靠資料傳輸協議的作用，以及如何從零開始一步一步構建乙個可靠的資料傳輸協議，在最後，我們構建出了 rdt 3.0 協議，它可以很好的在現實世界的底層通道上面工作。但問題是它是乙個停等協議，傳送端必須確認接收端已經接收到了正確的分組資料後才能傳送下乙個分組資料，這在現實生活中...
HTTPS資料傳輸流程
1.客戶端向伺服器端發起https請求，連線到伺服器端的443埠上 2.伺服器端有乙個秘鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的，伺服器端儲存著私鑰，將公鑰傳送給客戶端 3.客戶端收到伺服器端的公鑰之後，對公鑰進行檢查，驗證其合法性，如果發現公鑰有問題，那麼https傳輸無法繼續 如果合格，那...