① 計算機網路自學筆記:TCP
如果你在學習這門課程，僅僅為了理解網路工作原理，那麼只要了解TCP是可靠傳輸，數據傳輸丟失時會重傳就可以了。如果你還要參加研究生考試或者公司面試等，那麼下面內容很有可能成為考查的知識點，主要的重點是序號/確認號的編碼、超時定時器的設置、可靠傳輸和連接的管理。
1 TCP連接
TCP面向連接，在一個應用進程開始向另一個應用進程發送數據之前，這兩個進程必須先相互「握手」，即它們必須相互發送某些預備報文段，以建立連接。連接的實質是雙方都初始化與連接相關的發送/接收緩沖區，以及許多TCP狀態變數。
這種「連接」不是一條如電話網路中端到端的電路，因為它們的狀態完全保留在兩個端系統中。
TCP連接提供的是全雙工服務 ，應用層數據就可在從進程B流向進程A的同時，也從進程A流向進程B。
TCP連接也總是點對點的 ，即在單個發送方與單個接收方之間建立連接。
一個客戶機進程向伺服器進程發送數據時，客戶機進程通過套接字傳遞數據流。
客戶機操作系統中運行的 TCP軟體模塊首先將這些數據放到該連接的發送緩存里 ，然後會不時地從發送緩存里取出一塊數據發送。
TCP可從緩存中取出並放入報文段中發送的數據量受限於最大報文段長MSS，通常由最大鏈路層幀長度來決定(也就是底層的通信鏈路決定)。 例如一個鏈路層幀的最大長度1500位元組，除去數據報頭部長度20位元組，TCP報文段的頭部長度20位元組，MSS為1460位元組。
報文段被往下傳給網路層，網路層將其封裝在網路層IP數據報中。然後這些數據報被發送到網路中。
當TCP在另一端接收到一個報文段後，該報文段的數據就被放人該連接的接收緩存中。應用程序從接收緩存中讀取數據流(注意是應用程序來讀，不是操作系統推送)。
TCP連接的每一端都有各自的發送緩存和接收緩存。
因此TCP連接的組成包括:主機上的緩存、控制變數和與一個進程連接的套接字變數名，以及另一台主機上的一套緩存、控制變數和與一個進程連接的套接字。
在這兩台主機之間的路由器、交換機中，沒有為該連接分配任何緩存和控制變數。
2報文段結構
TCP報文段由首部欄位和一個數據欄位組成。數據欄位包含有應用層數據。
由於MSS限制了報文段數據欄位的最大長度。當TCP發送一個大文件時，TCP通常是將文件劃分成長度為MSS的若干塊。
TCP報文段的結構。
首部包括源埠號和目的埠號，它用於多路復用/多路分解來自或送至上層應用的數據。另外，TCP首部也包括校驗和欄位。報文段首部還包含下列欄位:
32比特的序號欄位和32比特的確認號欄位。這些欄位被TCP發送方和接收方用來實現可靠數據傳輸服務。
16比特的接收窗口欄位，該欄位用於流量控制。該欄位用於指示接收方能夠接受的位元組數量。
4比特的首部長度欄位,該欄位指示以32比特的字為單位的TCP首部長度。一般TCP首部的長度就是20位元組。
可選與變長的選項欄位,該欄位用於當發送方與接收方協商最大報文段長度，或在高速網路環境下用作窗口調節因子時使用。
標志欄位ACK比特用於指示確認欄位中的ACK值的有效性，即該報文段包括一個對已被成功接收報文段的確認。 SYN和FIN比特用於連接建立和拆除。 PSH、URG和緊急指針欄位通常沒有使用。
•序號和確認號
TCP報文段首部兩個最重要的欄位是序號欄位和確認號欄位。
TCP把數據看成一個無結構的但是有序的位元組流。TCP序號是建立在傳送的位元組流之上，而不是建立在傳送的報文段的序列之上。
一個報文段的序號是該報文段首位元組在位元組流中的編號。
例如，假設主機A上的一個進程想通過一條TCP連接向主機B上的一個進程發送一個數據流。主機A中的TCP將對數據流中的每一個位元組進行編號。假定數據流由一個包含4500位元組的文件組成(可以理解為應用程序調用send函數傳遞過來的數據長度)，MSS為1000位元組(鏈路層一次能夠傳輸的位元組數)，如果主機決定數據流的首位元組編號是7。TCP模塊將為該數據流構建5個報文段(也就是分5個IP數據報)。第一個報文段的序號被賦為7;第二個報文段的序號被賦為1007,第三個報文段的序號被賦為2007，以此類推。前面4個報文段的長度是1000，最後一個是500。
確認號要比序號難理解一些。前面講過，TCP是全雙工的，因此主機A在向主機B發送數據的同時，也可能接收來自主機B的數據。從主機B到達的每個報文段中的序號欄位包含了從B流向A的數據的起始位置。 因此主機B填充進報文段的確認號是主機B期望從主機A收到的下一報文段首位元組的序號。
假設主機B已收到了來自主機A編號為7-1006的所有位元組，同時假設它要發送一個報文段給主機A。主機B等待主機A的數據流中位元組1007及後續所有位元組。所以，主機B會在它發往主機A的報文段的確認號欄位中填上1007。
再舉一個例子，假設主機B已收到一個來自主機A的包含位元組7-1006的報文段，以及另一個包含位元組2007-3006的報文段。由於某種原因，主機A還沒有收到位元組1007-2006的報文段。
在這個例子中，主機A為了重組主機B的數據流，仍在等待位元組1007。因此，A在收到包含位元組2007-3006的報文段時，將會又一次在確認號欄位中包含1007。 因為TCP只確認數據流中至第一個丟失報文段之前的位元組數據，所以TCP被稱為是採用累積確認。
TCP的實現有兩個基本的選擇:
1接收方立即丟棄失序報文段;
2接收方保留失序的位元組，並等待缺少的位元組以填補該間隔。
一條TCP連接的雙方均可隨機地選擇初始序號。 這樣做可以減少將那些仍在網路中的來自兩台主機之間先前連接的報文段，誤認為是新建連接所產生的有效報文段的可能性。
•例子telnet
Telnet由是一個用於遠程登錄的應用層協議。它運行在TCP之上，被設計成可在任意一對主機之間工作。
假設主機A發起一個與主機B的Telnet會話。因為是主機A發起該會話，因此主機A被標記為客戶機，主機B被標記為伺服器。用戶鍵入的每個字元(在客戶機端)都會被發送至遠程主機。遠程主機收到後會復制一個相同的字元發回客戶機，並顯示在Telnet用戶的屏幕上。這種「回顯」用於確保由用戶發送的字元已經被遠程主機收到並處理。因此，在從用戶擊鍵到字元顯示在用戶屏幕上之間的這段時間內，每個字元在網路中傳輸了兩次。
現在假設用戶輸入了一個字元「C」，假設客戶機和伺服器的起始序號分別是42和79。前面講過，一個報文段的序號就是該報文段數據欄位首位元組的序號。因此，客戶機發送的第一個報文段的序號為42，伺服器發送的第一個報文段的序號為79。前面講過，確認號就是主機期待的數據的下一個位元組序號。在TCP連接建立後但沒有發送任何數據之前，客戶機等待位元組79，而伺服器等待位元組42。
如圖所示，共發了3個報文段。第一個報文段是由客戶機發往伺服器，其數據欄位里包含一位元組的字元「C」的ASCII碼，其序號欄位里是42。另外，由於客戶機還沒有接收到來自伺服器的任何數據，因此該報文段中的確認號欄位里是79。
第二個報文段是由伺服器發往客戶機。它有兩個目的:第一個目的是為伺服器所收到的數據提供確認。伺服器通過在確認號欄位中填入43，告訴客戶機它已經成功地收到位元組42及以前的所有位元組，現在正等待著位元組43的出現。第二個目的是回顯字元「C」。因此，在第二個報文段的數據欄位里填入的是字元「C」的ASCII碼，第二個報文段的序號為79，它是該TCP連接上從伺服器到客戶機的數據流的起始序號，也是伺服器要發送的第一個位元組的數據。
這里客戶機到伺服器的數據的確認被裝載在一個伺服器到客戶機的數據的報文段中，這種確認被稱為是捎帶確認.
第三個報文段是從客戶機發往伺服器的。它的唯一目的是確認已從伺服器收到的數據。
3往返時延的估計與超時
TCP如同前面所講的rdt協議一樣，採用超時/重傳機制來處理報文段的丟失問題。最重要的一個問題就是超時間隔長度的設置。顯然，超時間隔必須大於TCP連接的往返時延RTT，即從一個報文段發出到收到其確認時。否則會造成不必要的重傳。
•估計往返時延
TCP估計發送方與接收方之間的往返時延是通過採集報文段的樣本RTT來實現的，就是從某報文段被發出到對該報文段的確認被收到之間的時間長度。
也就是說TCP為一個已發送的但目前尚未被確認的報文段估計sampleRTT，從而產生一個接近每個RTT的采樣值。但是，TCP不會為重傳的報文段計算RTT。
為了估計一個典型的RTT，採取了某種對RTT取平均值的辦法。TCP據下列公式來更新
EstimatedRTT=(1-)*EstimatedRTT+*SampleRTT
即估計RTT的新值是由以前估計的RTT值與sampleRTT新值加權組合而成的。
參考值是a=0.125，因此是一個加權平均值。顯然這個加權平均對最新樣本賦予的權值
要大於對老樣本賦予的權值。因為越新的樣本能更好地反映出網路當前的擁塞情況。從統計學觀點來講，這種平均被稱為指數加權移動平均
除了估算RTT外，還需要測量RTT的變化，RTT偏差的程度，因為直接使用平均值設置計時器會有問題(太靈敏)。
DevRTT=(1-β)*DevRTT+β*|SampleRTT-EstimatedRTT|
RTT偏差也使用了指數加權移動平均。B取值0.25.
•設置和管理重傳超時間隔
假設已經得到了估計RTT值和RTT偏差值，那麼TCP超時間隔應該用什麼值呢?TCP將超時間隔設置成大於等於估計RTT值和4倍的RTT偏差值,否則將造成不必要的重傳。但是超時間隔也不應該比估計RTT值大太多，否則當報文段丟失時，TCP不能很快地重傳該報文段，從而將給上層應用帶來很大的數據傳輸時延。因此，要求將超時間隔設為估計RTT值加上一定餘量。當估計RTT值波動較大時，這個余最應該大些;當波動比較小時，這個餘量應該小些。因此使用4倍的偏差值來設置重傳時間。
TimeoutInterval=EstimatedRTT+4*DevRTT
4可信數據傳輸
網際網路的網路層服務是不可靠的。IP不保證數據報的交付，不保證數據報的按序交付，也不保證數據報中數據的完整性。
TCP在IP不可靠的盡力而為服務基礎上建立了一種可靠數據傳輸服務。
TCP提供可靠數據傳輸的方法涉及前面學過的許多原理。
TCP採用流水線協議、累計確認。
TCP推薦的定時器管理過程使用單一的重傳定時器，即使有多個已發送但還未被確認的報文段也一樣。重傳由超時和多個ACK觸發。
在TCP發送方有3種與發送和重傳有關的主要事件:從上層應用程序接收數據，定時器超時和收到確認ACK。
從上層應用程序接收數據。一旦這個事件發生，TCP就從應用程序接收數據，將數據封裝在一個報文段中，並將該報文段交給IP。注意到每一個報文段都包含一個序號，這個序號就是該報文段第一個數據位元組的位元組流編號。如果定時器還沒有計時，則當報文段被傳給IP時，TCP就啟動一個該定時器。
第二個事件是超時。TCP通過重傳引起超時的報文段來響應超時事件。然後TCP重啟定時器。
第三個事件是一個來自接收方的確認報文段(ACK)。當該事件發生時，TCP將ACK的值y與變數SendBase(發送窗口的基地址)進行比較。TCP狀態變數SendBase是最早未被確認的位元組的序號。就是指接收方已正確按序接收到數據的最後一個位元組的序號。TCP採用累積確認，所以y確認了位元組編號在y之前的所有位元組都已經收到。如果Y>SendBase,則該ACK是在確認一個或多個先前未被確認的報文段。因此發送方更新其SendBase變數，相當於發送窗口向前移動。
另外，如果當前有未被確認的報文段，TCP還要重新啟動定時器。
快速重傳
超時觸發重傳存在的另一個問題是超時周期可能相對較長。當一個報文段丟失時，這種長超時周期迫使發送方等待很長時間才重傳丟失的分組，因而增加了端到端時延。所以通常發送方可在超時事件發生之前通過觀察冗餘ACK來檢測丟包情況。
冗餘ACK就是接收方再次確認某個報文段的ACK，而發送方先前已經收到對該報文段的確認。
當TCP接收方收到一個序號比所期望的序號大的報文段時，它認為檢測到了數據流中的一個間隔，即有報文段丟失。這個間隔可能是由於在網路中報文段丟失或重新排序造成的。因為TCP使用累計確認，所以接收方不向發送方發回否定確認，而是對最後一個正確接收報文段進行重復確認(即產生一個冗餘ACK)
如果TCP發送方接收到對相同報文段的3個冗餘ACK.它就認為跟在這個已被確認過3次的報文段之後的報文段已經丟失。一旦收到3個冗餘ACK，TCP就執行快速重傳 ，
即在該報文段的定時器過期之前重傳丟失的報文段。
5流量控制
前面講過，一條TCP連接雙方的主機都為該連接設置了接收緩存。當該TCP連接收到正確、按序的位元組後，它就將數據放入接收緩存。相關聯的應用進程會從該緩存中讀取數據，但沒必要數據剛一到達就立即讀取。事實上，接收方應用也許正忙於其他任務，甚至要過很長時間後才去讀取該數據。如果應用程序讀取數據時相當緩慢，而發送方發送數據太多、太快，會很容易使這個連接的接收緩存溢出。
TCP為應用程序提供了流量控制服務以消除發送方導致接收方緩存溢出的可能性。因此，可以說 流量控制是一個速度匹配服務，即發送方的發送速率與接收方應用程序的讀速率相匹配。
前面提到過，TCP發送方也可能因為IP網路的擁塞而被限制，這種形式的發送方的控制被稱為擁塞控制(congestioncontrol)。
TCP通過讓接收方維護一個稱為接收窗口的變數來提供流量控制。接收窗口用於告訴發送方，該接收方還有多少可用的緩存空間。因為TCP是全雙工通信，在連接兩端的發送方都各自維護一個接收窗口變數。 主機把當前的空閑接收緩存大小值放入它發給對方主機的報文段接收窗口欄位中，通知對方它在該連接的緩存中還有多少可用空間。
6 TCP連接管理
客戶機中的TCP會用以下方式與伺服器建立一條TCP連接:
第一步: 客戶機端首先向伺服器發送一個SNY比特被置為1報文段。該報文段中不包含應用層數據，這個特殊報文段被稱為SYN報文段。另外，客戶機會選擇一個起始序號，並將其放置到報文段的序號欄位中。為了避免某些安全性攻擊，這里一般隨機選擇序號。
第二步: 一旦包含TCP報文段的用戶數據報到達伺服器主機，伺服器會從該數據報中提取出TCPSYN報文段，為該TCP連接分配TCP緩存和控制變數，並向客戶機TCP發送允許連接的報文段。這個允許連接的報文段還是不包含應用層數據。但是，在報文段的首部卻包含3個重要的信息。
首先，SYN比特被置為1。其次，該 TCP報文段首部的確認號欄位被置為客戶端序號+1最後，伺服器選擇自己的初始序號，並將其放置到TCP報文段首部的序號欄位中。 這個允許連接的報文段實際上表明了:「我收到了你要求建立連接的、帶有初始序號的分組。我同意建立該連接，我自己的初始序號是XX」。這個同意連接的報文段通常被稱為SYN+ACK報文段。
第三步: 在收到SYN+ACK報文段後，客戶機也要給該連接分配緩存和控制變數。客戶機主機還會向伺服器發送另外一個報文段，這個報文段對伺服器允許連接的報文段進行了確認。因為連接已經建立了，所以該ACK比特被置為1，稱為ACK報文段，可以攜帶數據。
一旦以上3步完成，客戶機和伺服器就可以相互發送含有數據的報文段了。
為了建立連接，在兩台主機之間發送了3個分組，這種連接建立過程通常被稱為 三次握手(SNY、SYN+ACK、ACK，ACK報文段可以攜帶數據) 。這個過程發生在客戶機connect()伺服器，伺服器accept()客戶連接的階段。
假設客戶機應用程序決定要關閉該連接。(注意，伺服器也能選擇關閉該連接)客戶機發送一個FIN比特被置為1的TCP報文段，並進人FINWAIT1狀態。
當處在FINWAIT1狀態時，客戶機TCP等待一個來自伺服器的帶有ACK確認信息的TCP報文段。當它收到該報文段時，客戶機TCP進入FINWAIT2狀態。
當處在FINWAIT2狀態時，客戶機等待來自伺服器的FIN比特被置為1的另一個報文段，
收到該報文段後，客戶機TCP對伺服器的報文段進行ACK確認，並進入TIME_WAIT狀態。TIME_WAIT狀態使得TCP客戶機重傳最終確認報文，以防該ACK丟失。在TIME_WAIT狀態中所消耗的時間是與具體實現有關的，一般是30秒或更多時間。
經過等待後，連接正式關閉，客戶機端所有與連接有關的資源將被釋放。 因此TCP連接的關閉需要客戶端和伺服器端互相交換連接關閉的FIN、ACK置位報文段。
② 計算機網路自頂向下方法多久看完
pyright © 1999-2020, CSDN.NET, All Rights Reserved
打開APP
不吃牛油果
關注
計算機網路自頂向下方法 【第一章 計算機網路及網際網路】 原創
2021-12-08 14:43:31
2點贊
不吃牛油果
碼齡3年
關注
目錄
1.1 什麼是網際網路
1.1.1 具體構成描述
1.1.2 服務描述
1.1.3 網路協議
1.2 網路邊緣
1.2.1 接入網
1.3 網路核心
1.3.1分組交換
1.3.2 電路交換
1.3.3 報文交換
1.4 交換網中的時延，丟包和吞吐量
1.5 協議層次及其服務模型
1.1 什麼是網際網路
我們可以用兩種方式描述網際網路
1.1.1 具體構成描述
端系統(主機)：與網際網路相連的設備
端系統通過通信鏈路和分組交換機連接到一起
通信鏈路由不同的物理媒體組成，傳播速度用bit/s來計算
分組：當一台端系統要向另一台端系統發送數據時，發送端系統將數據分段，並為每段加上頭部位元組，由此形成的信息包叫分組
分組通過網路發送到接收端系統，在那裡被裝配成初始數據
分組交換機從它的一條入通信鏈路接收到達的消息，並從它的一條出通信鏈路轉發該條消息
最著名的分組交換機：路由器和鏈路層交換機
路由器通常用作網路核心
鏈路層交換機常用在接入網
一個分組所經歷的一系列的通信鏈路和分組交換機稱為通過網路的路徑
端系統通過**網際網路服務供應商(ISP)**接入網際網路中
每個ISP本身就是一個由多台分組交換機和通信鏈路組成的網路，各ISP為端系統提供了不同類型的網路接入
端系統，分組交換機和其他網路部件都需要運行一系列的協議
網際網路最重要的協議TCP/IP
IP協議定義了路由器和端系統之間交換的分組格式
在這里插入圖片描述
1.1.2 服務描述
分布式應用程序： 應用程序涉及在多個相互交換數據的端系統，故稱他們分布式應用程序。
與網際網路相連的端系統都有一個套接字介面，該介面規定了運行在端系統上的程序請求在網際網路基礎設施向另一個端系統上特定的目的程序交付數據的方式
網際網路套接字介面是一個發送程序必須遵守的規則合集
1.1.3 網路協議
在網際網路中，任何兩個以上的遠程通訊實體的所有活動都受協議的制約
協議定義了在兩個通訊實體之間交換的報文的格式和順序，以及報文的發送或接收一條報文或其他時間所採取的動作
1.2 網路邊緣
位於網路邊緣的主機又分為兩類：客戶和伺服器
客戶通常是桌面PC，智能手機等
伺服器是更強大的機器，用於存儲和發布Web頁面，郵件等
1.2.1 接入網
接入網：是將端系統物理連接到其邊緣路由器的網路
邊緣路由器 是端系統到任何其他遠程端系統的路徑上的第一台路由器
家庭接入有兩種最流行的類型：數字用戶線(DSL)和電纜
1.3 網路核心
網路核心： 又端系統的分組交換機和鏈路構成的網狀網路
1.3.1分組交換
端系統之間彼此交換報文，報文可以執行一種控制功能，也可以包含數據
為了從源端系統向目的端系統發送一個報文，源將上報文劃分為較小的數據塊，稱為分組
分組以鏈路的最大傳輸速率的速度通過通信鏈路
多數分組交換機在鏈路的輸入端使用存儲轉發傳輸，是指在交換機開始向輸出鏈路傳輸該分組的第一個比特之前，必須接受到整個分組
每台分組交換機和多個鏈路連接，對於每條相連的鏈路，該分組交換機具有一個輸出緩存，它用於存儲路由器准備發往那條鏈路的分組
如果該鏈路正在傳輸其他分組，那麼該分組必須在輸出緩存等待，這叫排隊時延
一個到達的分組可能發現輸出緩存已經滿了的情況，此時將出現分組丟包的情況
每個端系統都有一個IP地址。當源主機向目的主機發送一個分組時，源在該分組的首部包含了目的主機的IP地址
1.3.2 電路交換
電路交換：在這個發送者可以發送信息之前，電話網路必修要先在發送者和接受者之間建立一條連接。這是條真正的連接，在發送者和接受者之間的交換機都是維持著的。
當網路把這個電路建立好之後，在這個網路中的鏈路的傳輸速率也是維持好的。所以發送者可以以穩定的速率傳輸數據給接收者
鏈路中的電路是通過頻分復用FDM和時分復用TDM來實現的
對於FDM，鏈路的頻譜由跨越鏈路創建的所有連接共享。在連接期間鏈路為每條連結專用一個頻率。
在電話網路中，這個頻寬通常是4kHz，該頻段的寬度稱為帶寬
對於TDM，時間被劃分為固定的幀，每個幀又被劃分為固定數量的時隙
電路交換和分組交換的區別：
電路交換的三個步驟：
建立連接（分配通信資源）
通話（一直佔用通信資源）
釋放連接（歸還通信資源）
1.3.3 報文交換
報文交換
一個應用發送信息的整體就是一個報文。
在數據交換過程中，要以整個信息作為一個整體，一次性轉發到下一個鄰接路由器上，路由器再把整個報文接收到，再決定這個報文怎麼轉發，從哪個介面轉發出去，直至目的主機。
在這里插入圖片描述
1.4 交換網中的時延，丟包和吞吐量
我們希望網際網路服務在任意兩個端系統之間隨心所欲的瞬間移動數據而沒有任何數據損失，但那時不可能的，
所以計算機網路要限制在端系統之間的吞吐量：每秒能夠傳送的數據量
當一個分組從一個節點到另一個節點，該分組在沿途的每個節點經受了不同的時延：節點處理時延，排隊時延，傳輸時延，傳播時延，這些時延累加就是節點總時延
節點處理時延： 檢查分組首部和決定將該分組導向何處需要的時間
排隊時延： 在隊列中，當分組在鏈路上等待傳輸時，經受排隊時延
傳輸時延： 路由器推出整個分組需要的時間
傳播時延： 將分組傳播到另一個節點需要的時間
在這里插入圖片描述
到達分組時發現隊列滿了。由於沒有地方存儲這個分組，路由器將丟棄該分組，形成丟包
一個節點的性能不止可以從時延看出來，也可以從丟包率看出來
吞吐量
吞吐量表示在單位時間內通過某個網路（或信道、介面）的數據量
吞吐量被常用於對現實世界中的網路的一種測量，以便知道實際上到底有多少數據量能夠通過網路；吞吐量受網路帶寬或額定速率的限制。
時延帶寬積
時延帶寬積 = 傳播時延 × 帶寬
若發送端連續發送數據，則在所發送的第一個bit即將到達終點時，發送端就已經發送了時延帶寬積個bit；
鏈路的時延帶寬積又稱為以bit為單位的鏈路長度。
往返時間RRT
在許多情況下，網際網路上的信息不僅僅單方向傳輸，而是雙向交互；
我們有時候很需要知道雙向交互一次所需的時間。
利用率
信道利用率： 用來表示某信道有百分之幾的時間是被利用的（有數據通過）
網路利用率： 全網路的信道利用率的加權平均；
利用率並非越高越好，當某信道的利用率增大時，該信道引起的時延也會迅速增加，如下圖所示；
在這里插入圖片描述
丟包率
丟包率即分組丟失率，是指在一定的時間范圍內，傳輸過程中丟失的分組數量與總分組數量的比率；
分組丟失的兩個主要原因：分組誤碼，結點交換機緩存隊列滿（網路擁塞）。
1.5 協議層次及其服務模型
在這里插入圖片描述
在這里插入圖片描述
文章知識點與官方知識檔案匹配
網路技能樹首頁概覽
22919 人正在系統學習中
打開CSDN APP，看更多技術內容
計算機網路自頂向下方法筆記02_A橙_的博客
《計算機網路自頂向下方法》學習筆記02:運輸層。 運輸層介於應用層與網路層之間,為應用層提供了直接的通信服務。在應用層時已經介紹了兩種運輸層協議UDP和TCP,本章主要介紹這兩個協議和運輸層的原理及實現。
繼續訪問
《計算機網路 自頂向下方法》學習整理_TiSam的博客
《計算機網路 自頂向下方法》學習整理計算機網路1、計算機網路(1)英特網(2)網路邊緣(3)網路核心(4)時延、丟包、吞吐量(5)協議層次2、應用層(1)應用層協議(2)Web和HTTP(3)SMTP(4)DNS3、運輸層(1)運輸層服務(2)無連接運輸:UDP...
繼續訪問
《計算機網路-自頂向下方法》,計算機網路自頂向下方法
自頂向下方法來自於計算機演算法的其中一種思想結晶。當然在我們所了解的演算法中還有許多種類。下面是學習啦小編跟大家分享的是計算機網路自頂向下方法，歡迎大家來閱讀學習。計算機網路自頂向下方法工具/原料遞歸網路程序方法演算法方法/步驟自頂自下主要是一種演算法的實現，在不知道結果的情況之下，使用一種方法進行演算，得到一種正確的結果，也就可以命名用自頂向下的思想進行實現了。在方程式內，對於未知的結果也就是進行一種推...
繼續訪問
計算機網路自頂向下方法(一)——計算機網路和網際網路
不要成為理想的巨人，行動的矮子 寫在前面 為了更好地學習和掌握《計算機網路》這門課程，打算把自己的學習筆記轉化為博客，以便於更好地復習，也便於大家一起學習與交流。 參考課程：中科大-鄭老師《計算機網路》 參考書籍：《計算機網路自頂向下方法》原書第七版 什麼是Internet? 網際網路是一個世界范圍的計算機網路，即它是一個互聯了遍及全世界數計算設備的網路。 具體構成及描述 計算設備 : 主機（端系統）、運行的網路應用程序 節點： 主機及其上運行的應用程序 路由器、交換機等網路交換設備 例如：手機、平.
繼續訪問
最新發布 計算機網路-自頂向下方法(筆記）
計算機網路自頂向下（第7版）
繼續訪問
計算機網路 通信網路筆記（自頂向下的方法）from top to the botton of MIT
網路利用率大並不是好事：會導致網路很堵，速度變慢。時延變長。 第一章計算吞吐量： 考慮下圖，其中有一個機構網路連接到互聯網。假設平均對象大小為900,000位，並且從機構的瀏覽器到原始伺服器的平均請求速率為每秒15個請求。還假設從接入鏈路互聯網上的路由器轉發HTTP請求到收到響應所需的時間平均為3秒。對於平均接入延遲(access delay)，即從互聯網路由器到機構路由器的延遲，可以建模為,ta是通過訪問鏈路發送對象所需的平均時間(也就是機構網路到原始伺服器網路的時間，圈起來的部分)，b是對象到達訪問鏈路
繼續訪問
《計算機網路自頂向下方法》Wireshark lab（一）
Getting Started Wireshark：A packet sniffer for observing the messages exchanged between executing protocol entities A packet sniffer captures (「sniffs」) messages being sent/received from/by your computer; it will also typically store and/or display the con
繼續訪問
熱門推薦 計算機網路（自頂向下方法）學習筆記
目錄 第一章 計算機網路和網際網路 1.1 什麼是網際網路 1.1.1 組成描述 1.1.2 服務描述 1.1.3 協議 1.2 網路的邊緣 1.2.1 接入網 1.2.2 物理媒體 1.3 網路核心 1.3.1 分組交換 1.3.2 電路交換 1.3.3 分組交換和電路交換的對比 1.3.4 網路的網路 1.4 分組交換中的時延、丟包、吞吐量 1.4.1 分組交換...
繼續訪問
計算機網路 自頂向下方法
文章目錄學習本書的目的一、第一章 計算機網路和網際網路二、使用步驟總結 學習本書的目的 主要目的並不是學習計算機網路的只是，而是學習作者的思維方式，以及自己對這種思維方式的理解。 一、第一章 計算機網路和網際網路 這一章首先描述了什麼是網際網路，以及網際網路在我們生活中的應用，讓我對網際網路很感興趣，然後就描述了網際網路中最簡單的例子，兩個端之間的數據傳輸，講解數據傳輸的時候從協議到路由器最後到通信衛星，讓我腦子里大致有個輪廓，就是兩個端傳遞需要那些設備支持。由兩個端的數據傳輸，自然將到了多端傳輸，多端傳輸一個是多端之
繼續訪問
計算機網路(自頂向下方法)-網路層
將路由器、交換機和目前大多數網路設備的功能進一步抽 象成：按照流表（由控制平面設置的控制邏輯）進行PDU。：替換目標IP地址和埠號，採用存
③ 大學的計算機網路課程該怎麼學習，記筆記 自從上了大學，我們好多課程都變成了在網上看視頻學習，尤
2級c語言比較好過，把書看懂，把題目弄清楚，再做幾套模擬題，就夠了
④ 計算機網路筆記——數據鏈路層（停等協議、GBN、SR）
流量控制：防止發送端發送和接收端接收速度不匹配造成傳輸錯誤
傳輸層和數據鏈路層均有流量控制，但是控制手法不一樣
傳輸層：端到端，接收端向發送端發送一個窗口公告。告訴發送端目前我能接收多少
數據鏈路層：點到點，接收端接收不下的就不回復確認（ack），讓發送端自己重傳
涉及協議較多分批寫
優點 ：最簡單的控制協議
缺點 ：但是性能較弱,信道利用率低
控制方法 ：
發送方：發送一個幀
接收方：接收到幀後返回改幀的ack
發送方：接收到ack後發送下一個幀
差錯控制 ：
注意 ：
滑動窗口協議是基於停止等待協議的優化版本
停止等待協議性能是因為需要等待ack之後才能發送下一個幀，在傳送的很長時間內信道一直在等待狀態
滑動窗口則利用緩沖思想，允許連續發送(未收到ack之前)多個幀，以加強信道利用
窗口 ：其實就是緩沖幀的一個容器，將處理好的幀發送到緩沖到窗口，可以發送時就可以直接發送，藉此優化性能。一個幀對應一個窗口。
GBN是滑動窗口中的一種，其中 發送窗口 > 1 , 接收窗口=1 因發送錯誤後需要退回到最後正確連續幀位置開始重發，故而得名。
控制方法 ：
發送端：在將發送窗口內的數據連續發送
接收端：收到一個之後向接收端發送累計確認的ack
發送端：收到ack後窗口後移發送後面的數據
累計確認 ：累計確認允許接收端一段時間內發送一次ack而不是每一個幀都需要發送ack。該確認方式確認代表其前面的幀都以正確接收到
eg:發送端發送了編號 0,1,2,3,4,5 的幀，等待一段時間後（超過3的超時計時器）累計收到的ack對應 0,2 幀，則證明已經成功 0,1,2 均已經成功接收， 3 傳輸錯誤。並且哪怕 4,5 兩個幀接收成功後也不會返回 4,5 的ack會一直等待從 3 開始重傳
差錯控制 ：
發送幀丟失、ack丟失、ack遲到 等處理方法基本和停等協議相同，不同的是採用累計確認恢復的方式，當前面的幀出錯之後後面幀無論是否發送成功都要重傳
優點：信道利用率高（利用窗口有增加發送端佔用，並且減少ack回復次數）
缺點：累計確認使得該方法只接收正確順序的幀，而不接受亂序的幀，錯誤重傳浪費嚴重
發送窗口大小問題
窗口理論上是越多性能越好，但是窗口不能無限大，n比特編碼最大隻能2^(n-1)個窗口，否則會造成幀無法區分（本質就是留了一個比特區分兩組幀）
SR協議可以說是GBN的plus版本，在GBN的基礎上改回每一個幀都要確認的機制，解決了累計確認只接收順序幀的弊端只需要重發錯誤幀。
其中 發送窗口 > 1 , 接收窗口 > 1 , 接收窗口 > 發送窗口 (建議接 收窗口 = 發送窗口 接收窗口少了溢出多了浪費).
控制方法 ：
發送端：將窗口內的數據連續發送
接收端：收到一個幀就將該幀緩存到窗口中並回復一個ack
接收端：接收到順序幀後將數據提交給上層並接收窗口後移（若接收到的幀不是連續的順序幀時接收窗口不移動）
發送端：接收到順序幀的ack後發送窗口後移（同理發送窗口接收到的ack不連續也不移動）
差錯控制 ：
發送幀丟失、ack丟失、ack遲到 三類處理方式仍然和停等協議相同，不同的是SR向上層提交的是多個連續幀，停等只提交一個幀（不連續的幀要等接收或重傳完成後才會提交）
發送窗口大小問題
同GBN一樣，發送窗口和接收窗口都不能無限多，且不說緩存容量問題，當兩組幀同時發送時會造成無法區分，大小上限仍然是2^(n-1)個窗口（本質就是留了一個比特寫組號）
窗口大小這里留一張截圖，方便理解
假設窗口大小都為3（圖中編號到了3是借4窗口的圖，正常應編號到2,但是不妨礙理解）
左邊是錯誤重發，第一組的0幀ack丟失了
右邊是正常收發
三種協議對比：
停等協議：單線程的傻子，簡單不易出錯，但是效率極其低下
GBN：假的多線程(接收端太坑啦)，接收端是情種，只等待自己哪一個幀，丟棄了後來的幀
SR：多線程，接收端有收藏癖，等待集齊一套召喚神龍（提交給上層這只神龍……）