A. 100M寬頻可以多台電腦上網嗎怎麼計時
100M的網路是可以多人塌戚頌使用的。每個人用的網路不一樣，這就要看你干什麼了團鄭單純的瀏覽和工作是可以的，如果是下載的話就應該在10人仔慎之內吧。可以下載終結者設置每個人用的網路。也可以登陸路由來看。
B. 計算機是如何計算時間的
早上6點起床，7點吃早飯，8點上班，9點開會，10點約了合作夥伴商談......假如時間不存在，我們做任何事情都是沒有意義的。我們需要用手錶、手機等顯示時間的機器告訴我們現在是幾點幾分，這時候該干什麼？同樣的，計算機也要看時間，才能持續不斷的運轉下去。計算機是通過看晶振，來確定時間的。
晶振在電腦中的作用晶振的作用是為系統提供基本的時鍾信號。通常一個系統共用一個晶振，便於各部分保持同步。它就像個標尺，工作頻率不穩定會造成相關設備工作頻率不穩定。有些通訊系統的基頻和射頻使用不同的晶振，而通過電子調整頻率的方法保持同步。
晶振通常與鎖相環電路配合使用，以提供系統所需的時鍾頻率。如果不同子系統需要不同頻率的時鍾信號，可以用與同一個晶振相連的不同鎖相環來提供。
C. 計算機網路中的距離向量演算法（RIP）的基本原理
RIP協議採用距離向量演算法，在實際使用中已經較少適用。在默認情況下，RIP使用一種非常簡單的度量制度：距離就是通往目的站點所需經過的鏈路數，取值為1~15，數值16表示無窮大。RIP進程使用UDP的520埠來發送和接收RIP分組。RIP分組每隔30s以廣播的形式發送一次，為了防止出現「廣播風暴」，其後續的的分組將做隨機延時後發送。在RIP中，如果一個路由在180s內未被刷，則相應的距離就被設定成無窮大，並從路由表中刪除該表項。RIP分組分為兩種：請求分組和響應分組。
D. 計算機網路問題，概念有點混。不要復制。謝謝啊
題主的第一個問題應該是非同步傳輸和同步傳輸的區分吧？那麼我先回答第一個！
先來理解一下他們存在的必要性吧。
在網路通信過程中，通信雙方要交換數據，需要高度的協同工作。為了正確的解釋信號，接收方必須確切地知道信號應當何時接收和處理，因此定時是至關重要的。在計算機網路中，定時的因素稱為位同步。同步是要接收方按照發送方發送的每個位的起止時刻和速率來接收數據，否則會產生誤差。通常可以採用同步或非同步的傳輸方式對位進行同步處理。
1. 非同步傳輸（Asynchronous Transmission）： 非同步傳輸將比特分成小組進行傳送，小組可以是8位的1個字元或更長。發送方可以在任何時刻發送這些比特組，而接收方從不知道它們會在什麼時候到達。一個常見的例子是計算機鍵盤與主機的通信。按下一個字母鍵、數字鍵或特殊字元鍵，就發送一個8比特位的ASCII代碼。鍵盤可以在任何時刻發送代碼，這取決於用戶的輸入速度，內部的硬體必須能夠在任何時刻接收一個鍵入的字元。
非同步傳輸存在一個潛在的問題，即接收方並不知道數據會在什麼時候到達。在它檢測到數據並做出響應之前，第一個比特已經過去了。這就像有人出乎意料地從後面走上來跟你說話，而你沒來得及反應過來，漏掉了最前面的幾個詞。因此，每次非同步傳輸的信息都以一個起始位開頭，它通知接收方數據已經到達了，這就給了接收方響應、接收和緩存數據比特的時間；在傳輸結束時，一個停止位表示該次傳輸信息的終止。按照慣例，空閑（沒有傳送數據）的線路實際攜帶著一個代表二進制1的信號，非同步傳輸的開始位使信號變成0，其他的比特位使信號隨傳輸的數據信息而變化。最後，停止位使信號重新變回1，該信號一直保持到下一個開始位到達。例如在鍵盤上數字「1」，按照8比特位的擴展ASCII編碼，將發送「00110001」，同時需要在8比特位的前面加一個起始位，後面一個停止位。
非同步傳輸的實現比較容易，由於每個信息都加上了「同步」信息，因此計時的漂移不會產生大的積累，但卻產生了較多的開銷。在上面的例子，每8個比特要多傳送兩個比特，總的傳輸負載就增加25%。對於數據傳輸量很小的低速設備來說問題不大，但對於那些數據傳輸量很大的高速設備來說，25%的負載增值就相當嚴重了。因此，非同步傳輸常用於低速設備。
2. 同步傳輸（Synchronous Transmission）：同步傳輸的比特分組要大得多。它不是獨立地發送每個字元，每個字元都有自己的開始位和停止位，而是把它們組合起來一起發送。我們將這些組合稱為數據幀，或簡稱為幀。
數據幀的第一部分包含一組同步字元，它是一個獨特的比特組合，類似於前面提到的起始位，用於通知接收方一個幀已經到達，但它同時還能確保接收方的采樣速度和比特的到達速度保持一致，使收發雙方進入同步。
幀的最後一部分是一個幀結束標記。與同步字元一樣，它也是一個獨特的比特串，類似於前面提到的停止位，用於表示在下一幀開始之前沒有別的即將到達的數據了。
同步傳輸通常要比非同步傳輸快速得多。接收方不必對每個字元進行開始和停止的操作。一旦檢測到幀同步字元，它就在接下來的數據到達時接收它們。另外，同步傳輸的開銷也比較少。例如，一個典型的幀可能有500位元組（即4000比特）的數據，其中可能只包含100比特的開銷。這時，增加的比特位使傳輸的比特總數增加2.5%，這與非同步傳輸中25 %的增值要小得多。隨著數據幀中實際數據比特位的增加，開銷比特所佔的百分比將相應地減少。但是，數據比特位越長，緩存數據所需要的緩沖區也越大，這就限制了一個幀的大小。另外，幀越大，它占據傳輸媒體的連續時間也越長。在極端的情況下，這將導致其他用戶等得太久。
同步傳輸方式中發送方和接收方的時鍾是統一的、字元與字元間的傳輸是同步無間隔的。
非同步傳輸方式並不要求發送方和接收方的時鍾完全一樣，字元與字元間的傳輸是非同步的。
同步與非同步傳輸的區別
1,非同步傳輸是面向字元的傳輸，而同步傳輸是面向比特的傳輸。
2,非同步傳輸的單位是字元而同步傳輸的單位是楨。
3,非同步傳輸通過字元起止的開始和停止碼抓住再同步的機會，而同步傳輸則是以數據中抽取同步信息。
4,非同步傳輸對時序的要求較低，同步傳輸往往通過特定的時鍾線路協調時序。
5,非同步傳輸相對於同步傳輸效率較低。
-----------------------我是優雅分割線--------------------
虛電路虛電路又稱為虛連接或虛通道,虛電路交換是分組交換的兩種傳輸方式中的一種。在通信和網路中，虛電路是由分組交換通信所提供的面向連接的通信服務。在兩個節點或應用進程之間建立起一個邏輯上的連接或虛電路後，就可以在兩個節點之間依次發送每一個分組，接受端收到分組的順序必然與發送端的發送順序一致，因此接受端無須負責在收集分組後重新進行排序。虛電路協議向高層協議隱藏了將數據分割成段，包或幀的過程。
信元交換又叫ATM（非同步傳輸模式），是一種面向連接的快速分組交換技術，它是通過建立虛電路來進行數據傳輸的。
信元交換技術是一種快速分組交換技術，它結合了電路交換技術延遲小和分組交換技術靈活的優點。信元是固定長度的分組，ATM採用信元交換技術，其信元長度為53位元組。信元頭5位元組，數據48位元組。
交換技術方面，經歷了：電路交換——>報文交換——>分組交換——>信元交換的過程。
在信元中包括CRC校驗和，其生成公式為X^8+X^2+X+1，校驗和只是對信元頭進行校驗。
ATDM信元傳輸採用非同步時分復用（Asynchronous Time Division Multioles），又稱統計復用（Statistic Multiptx）。信息源隨機地產生信息，因為信元到達隊列也是隨機的。高速的業務信元來得十分頻繁、集中，低速的業務信元來得很稀疏。這些信元都按順序在隊列中排隊，然後按輸出次序復用到傳輸線上。具有同樣標志的信元在傳輸線上並不對應某個固定的時間間隙，也不是按周期出現的，信息和它在時域的位置之間沒有關系，信息只是按信頭中的標志來區分的。而在同步時分復用方式（如PCM復用方式）中，信息以它在一幀中的時間位置（時隙）來區分，一個時隙對應著一條信道，不需要另外的信息頭來表示信息的身份。
VPI欄位用於選擇一條特定的虛通路，VCI欄位在一條選定的虛通路上選擇一條特定的虛電路。當進行VP交換時，是選擇一條特定的虛通路。
若在交換過程中出現擁塞，該信息被記錄在信元的PT中。
E. 計算機網路(5)| 運輸層
從通信和處理信息的角度看，運輸層是向它上面的應用層提供通信服務的，它屬於面向通信部分的最高層，同時也是用戶功能中的最低層。當網路的邊緣部分中的兩台主機使用網路的核心部分的功能進行端到端的通信時，只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到下三層的功能。
運輸層的兩個主要協議 TCP/IP 都是互聯網的正式標准，即：
（1）用戶數據報協議UDP
（2）傳輸控制協議TCP
TCP則是面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP不提供廣播或者多播服務。由於TCP要提供可靠的面向連接的運輸服務，因此需要增加很多的開銷。
TCP/IP的運輸層用一個16位埠號來標志一個埠。埠號只有本地意義。它是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間介面。
運輸層的埠號分為以下兩類：
（1）伺服器端使用的埠號： 它主要分為系統埠號0～1023和登記埠號1024～49151。
（2）客戶端使用的埠號： 49152～65535，這類埠號僅在客戶端進程運行時才動態選擇。當伺服器收到客戶端進程的報文時，就知道客戶端進程的埠號。因而可以把數據發送給客戶進程。
用戶數據報協議相比於IP的數據報服務就是只增加了復用、分用和差錯檢測功能。UDP的主要特點是：
（1）UDP是無連接的， 發送數據之前不需要建立連接，因此減少開銷和發送數據之前的時延。
（2）UDP使用盡最大努力交付， 即不保證可靠交付，因此主機不需要維持復雜的連接狀態表。
（3）UDP是面向報文的。 發送方的UDP對應用交下來的報文，添加首部後就向下交付給IP層。不對報文做任何處理，因此當報文過長時，IP層可能需要進行分片處理。
（4）UDP沒有擁塞控制， 網路出現的擁塞不會使源主機的發送速率減低。
（5）UDP支持一對一、一對多、多對一和多對多的交互通信。
（6）UDP的首部開銷小， 只有8個位元組。
UDP有兩個欄位：數據欄位和首部欄位。先介紹首部欄位，它是由4個欄位組成的，每個欄位只有2個位元組，總共有8個位元組。各個欄位的意義如下：
（1）源埠： 源埠號。在需要對方回信時選用。不需要時可用全0。
（2）目的埠： 目的埠號。在這終點交付報文時必須使用。
（3）長度： UDP用戶數據報的長度，其最小值是8（只有首部）。
（4）檢驗和： 檢測UDP用戶數據報在傳輸中是否有錯，有錯則丟棄。
當在傳送用戶數據報時，如果接收方UDP發現收到的報文中目的埠號不正確（即不存在對應於該埠號的應用進程），就丟棄該報文，並由網際控制報文協議ICMP發送「埠不可達」差錯報文給發送方。
TCP的主要特點如下：
（1）TCP是面向連接的運輸層協議。 應用程序在使用TCP協議之前，必須先建立TCP連接。傳送數據完畢後，必須釋放TCP連接。
（2）每一條TCP連接只能有兩個端點。 每一條TCP連接只能是點對點的。
（3）TCP提供可靠交付的服務。 通過TCP連接傳送的數據，無差錯、不丟失、不重復，並且按序到達。
（4）TCP提供全雙工通信。 TCP允許通信雙方的應用進程在任何時候都能發送數據。
（5）面向位元組流。 TCP中的流指的是流入到進程或進程流出的位元組序列。雖然應用程序和TCP的交互是一次一個數據塊，但TCP把應用程序交下來的數據看成一連串的無結構的位元組流。TCP不保證發送方發送的數據塊和接收方接收的數據塊一致，但保證程序接收到的位元組流和程序發送的位元組流一致。
TCP連接的端點叫做套接字或者插口。套接字是指將埠號拼接到IP地址之後，即：
每一條TCP連接唯一的被通信兩端的兩個端點所確定。即：
如圖所示，A發送分組M1，發送完畢就暫停發送，等待B的確認,B收到了M1就向A發死你確認。A在收到了對M1的確認之後，就再發送下一個分組M2，以此類推。
如圖所示，當B接收M1時檢測出了差錯，就丟棄M1，其他什麼也不做。而A只要超過了一段時間沒有收到確認，就會認為剛才發送的分組丟失了，因而重傳前面發送過的分組，這就叫做超時重傳，而實現超時重傳則需要A為每一個已發送的分組都設置一個超時計時器。
需要注意以下三點：
（1）A在發送完一個分組後，必須暫時保留已發送的分組的副本。
（2）分組和確認分組必須編號，這樣才能明確哪一個發出的分組收到了確認。
（3）超時計時器設置的重傳時間應當比數據在分組傳輸的平均往返時間更長。
如圖所示，B所發送的對M1確認丟失了，A在設定的超時重傳時間內沒有收到確認，所以無法知道自己發送的分組是怎樣出錯的，所以會重傳M1，而當B又收到了重傳的分組M1，這時應該採取兩個行動：
（1）丟棄這個重復分組M1。
（2）向A發送確認。
還有一種情況就是在傳輸過程中沒有出現差錯，但B對分組M1的確認遲到了，而A會收到重復的確認，A收下後就會丟棄，B仍然會收到重復的M1，並且同樣要丟棄重復的M1，並且重傳確認分組。
停止等待協議的優點是簡單，缺點則是信道的利用率太低。我們用TD表示A發送分組需要的時間，TA表示B發送確認分組需要的時間，RTT為往返時間，則：
為了提高傳輸的效率，發送方可以不使用低效率的停止等待協議，而是採用流水線傳輸的方式。即不必每發完一個分組就停下來等待對方的確認，這樣就可以使信道上一直有數據在不間斷的傳送。
如圖表示的是發送方維持的發送窗口，它指的是位於發送窗口內的5個分組都可以連續發送出去而不需要等待對方的確認。同時連續ARP協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。
對於接收方採用的則是累計確認的方式，即接收方不必對收到的分組逐個發送確認。而是在收到幾個分組後，對按序到達的最後一個分組發送確認，這就表示：到這個分組為止的所有分組都已正確收到了。這種方式的優點是：容易實現，即使確認丟失也不必重傳（意思是發送方不必重傳）。但缺點是不能向發送方反映出接收方已經正確收到的所有分組信息。
TCP雖然是面向位元組流的，但傳送TCP的數據單元卻是報文段。一個TCP報文段可以分為首部和數據兩部分。
為了後面講述的方便，我們假設數據傳輸只在一個方向進行，即A發送數據，B給出確認。
TCP的滑動窗口是以位元組為單位的。如圖所示，現在假定A收到了B發來的確認報文段，其中的窗口是20位元組，而確認號是31，根據這2個數據，A就構造出自己的發送窗口。
發送窗口表示：在沒有收到B的確認的情況下，A可以連續把窗口內的數據都發送出去。凡是已經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。發送窗口後面的部分表示已發送且已經收到了確認。而發送窗口前沿的部分表示不允許發送的。
現在假定A發送了序號為31~41的數據。這時發送窗口位置並未改變但是發送窗口內靠後面有11個位元組表示已發送但是未收到確認。而發送窗口內靠前面的9個位元組時允許發送但未發送的。如圖所示：
而對於B，它的接收窗口大小是20，在接收窗口外面到30號位置的數據是接收並確認的，因此可以丟棄。在下圖中，B收到了32和33的數據，但它們不是按序到達的，因為並沒有收到31號數據。B只能對按序達收到的數據中的最高序號給出確認，因此B發送的確認報文欄位的確認號依然是31號。
現在假定B收到了序號為31的數據，並把31～33的數據交付主機，然後B刪除這些數據。接著把窗口向前移動3個序號，同時給a發送確認，其中的窗口值仍為20，但確認號變為34。表明B已經收到序號33為止的數據。
因為TCP的發送方在規定的時間內沒有收到確認就要重傳已經發送的報文段，但是重傳時間的選擇卻TCP最復雜的問題之一。為此TCP採用了一種自適應演算法，它記錄了一個報文段發出的時間以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，同時TCP保留了RTT的加權平均往返時間RTTs。而RTTD是RTT的偏差加權平均值，它與RTTs和新的RTT樣本之差有關。
超時重傳時間的演算法如下：
第一次測量時，加權平均往返時間取往返時間RTT，以後每次測量到一個新的RTT，按以下公式計算：
第一次測量時，RTT偏差的加權平均等於RTT的一半，以後的測里中，按以下公式計算：
綜上超時重傳時間RTO計算如下：
若收到的報文無差錯，只是未按序號，使用選擇確認SACK可是讓發送方發送那些未收到的數據，而不重復發送已經收到的那些數據。如果要使用選擇確認SACK，那麼在建立TCP連接時，就要在TCP首部的選項中加上「允許SACK」的選項，並且雙方必須都事先商量好。
流量控制就是指讓發送方的發送速率不要太快，要讓接收方來得及接收。而利用滑動窗口機制就可以很方便的在TCP連接上實現對發送方的流量控制。
如上圖所示，接收方B進行了三次流量控制。第一次把窗口減小到rwnd=300，第二次又減到rwnd=100，最後是rwnd=0，即不允許發送方再發送數據了。
但是我們應該考慮一種情況，就是當接收方B的存儲已滿時，會向發送方發送零窗口的報文段，接著B的存儲又有了一些空間，B再向A發送一個不為零的窗口值，但這個報文丟失了，結果就是雙方一直等待下去。所以為了解決這個問題，TCP為每一個連接設有一個持續計時器。只要TCP連接的一方收到對方的零窗口通知，就啟動持續計時器，當計時器到期後，就發送一個探測段文段，而對方就在確認這個探測段時給出了現在的窗口值。如果窗口仍然是0，那麼收到這個報文段的一方就重新設置持續計時器，反之則死鎖的僵局就可以打破了。
應用程序把數據傳送到TCP的發送緩存後，TCP在何時發送這些數據？，在TCP的實現中廣泛使用了Nagle演算法。具體演算法如下：
（1）若發送應用進程要把數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發出去，把後面到達的數據位元組都緩存起來。
（2）方發送方收到對第一個數據位元組的確認後，再把發送緩存中的所有數據組裝成一個報文發送出去，同時繼續對後續到來的數據進行緩存。
（3）只有收到對前一個報文段的確認後才繼續發送下一個報文段。
當數據到達快而網路速度慢時，這種方法可以明顯減少網路帶寬。Nagle還規定：當到達的數據達到窗口的一半或最大報文長度時就立即發送一個報文。
但還還需要考慮一個叫做糊塗綜合征的問題，具體內容是若接收方的緩存已滿，應用進程每次只從緩存中取1個位元組，然後向發送方確認，並把窗口設為1個位元組（緩存只空了1個位元組的空間），接著發送方發來1個位元組，接收方發回確認，仍然將窗口設為1，這樣進行下去，網路的利用率很低。
為了解決這個問題，可以讓接收方等待一段時間，使得或者緩存已有足夠的空間或者等到接收緩存已有一半的空閑空間。此時，接收方就發出確認報文，並向發送方通知當前窗口的大小。
擁塞 是指在某一段時間內，若對網路中某一資源的需求超過了該資源所能提供的可用部分，網路的性能就會變壞的情況。而所謂的 擁塞控制 就是防止過多的數據注入到網路當中，這樣可以使網路中的路由器或者鏈路不致過載，它是一個全局性的過程，涉及到所有的主機和路由器，而流量控制往往是指點對點通信量的控制。擁塞控制所要做的都有一個前提，就是網路能夠承受現有的網路負荷。
TCP進行擁塞控制的演算法有4種：慢開始、擁塞避免、快重傳和快恢復。下面在討論這些演算法時我們假定：
（1）數據是單方向傳送的，對方只傳送確認報文。
（2）接收方總是有足夠大的緩存空間。
發送方維持一個擁塞窗口的狀態變數，其大小取決於擁塞程度，並且動態變化。發送方讓自己的發送窗口小於擁塞窗口（如果考慮接收方的接收能力的話，發送窗口可能小於擁塞窗口）。發送方控制擁塞窗口的原則是：只要網路沒有擁塞，擁塞窗口就再增大一點，以便把更多的分組發送出去，只要出現擁塞，就減小擁塞窗口，以減少注入到網路的分組數。
下面會從「慢開始演算法」講起來討論擁塞窗口的大小如何變化的。
慢開始的演算法思路是：當主機開始發送數據時，由於並不清楚網路的負荷情況，所以如果立即把大量數據位元組注入到網路中，就有可能引起網路擁塞。因此會採用由小逐漸增大發送窗口。即在通常開始發送報文時，先將擁塞窗口cwnd的值設為一個最大報文段MSS的數值，而在每收到一個新的報文段確認後，把擁塞窗口增加至多一個MSS的數值。
如上圖所示，開始時cwnd=1，發送方發送一個M1，接收方收到M1發送確認，發送方收到一個確認後將cwnd加1，此時cwnd=2，因此發送方發送M2和M3兩個報文段，接收方收到後返回兩個確認，因此cwnd增加兩次，此時cwnd=4，接著發送方發送M4～M7四個報文段。依次類推。因此使用慢開始演算法後，每經過一個傳輸輪次，擁塞窗口就加倍。
但是為了防止擁塞窗口cwnd增加過大導致網路擁塞，需要設置一個慢開始門限ssthresh，慢開始門限用法如下：
當cwnd<ssthresh時，使用上述的慢開始演算法。
當cwnd>ssthresh時，停止使用慢開始演算法，使用擁塞避免演算法。
當cwnd=ssthresh時，既可以使用慢開始演算法，也可以使用擁塞避免演算法。
這里的擁塞避免演算法是指讓擁塞窗口緩慢的增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是像慢開始階段那樣加倍增長。
需要注意的是無論在慢開始階段還是擁塞避免階段，只要發送方判斷網路出現擁塞（根據是沒有按時收到確認），立即把慢開始門限ssthresh設為出現擁塞時的發送窗口的一半。然後發送窗口cwnd重新設為1，執行慢開始演算法。目的是迅速減少主機發送到網路分組的分組數。
快重傳演算法要求接收方每收到一個失序的報文段後就立即發送重復確認，如下圖接收了M1和M2後，又接收到一個M4，M4屬於失序報文，則發送對M2的重復確認。發送方只要連續收到三次確認重復就立即重傳對方未收到的報文段M3。
與快重傳演算法配合的還有快恢復演算法，過程如下：
（1）當發送方連續收到三個重復確認時，就把慢開始門限ssthresh減半，這是為了防止網路擁塞，接著並不執行慢開始演算法。
（2）由於上圖這種情況很可能不是因為網路擁塞引起的，因此這里不執行慢開始演算法（即不把擁塞窗口cwnd設為1，這樣速度太慢），而是把cwnd值設置為慢開始門限ssthresh減半後的數值，然後開始執行擁塞避免演算法。
TCP的運輸連接有是三個階段：連接建立、數據傳送和連接釋放。在TCP的連接過程中要解決以下三個問題：
（1）要使每一方能夠確知對方的存在。
（2）要允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳選項以及服務質量）。
（3）能夠對運輸實體資源進行分配。
TCP建立連接的過程叫做握手，握手需要在客戶和伺服器之間交換3個TCP報文段。如圖是三報文握手建立的連接過程：
A最後還要發送一次確認的原因是為了防止已經失效的連接請求報文段突然又傳送到了B，因而產生錯誤。試想一種情況：如果只有第一次和第二次握手，第二次B向A發送的確認丟失了，此時B進入了連接建立狀態，A沒有收到確認，過一段時間後會再次向B發送連接請求，B收到後又會再次建立連接，白白浪費B的資源。
A在TIME-WAIT狀態等待2MSL（MSL，最長報文段壽命），主要是因為以下兩點考慮：首先是為了保證A發送的最後一個ACK報文段能夠到達B，因為這個ACK報文段可能丟失，此時B會重傳連接釋放報文，如果A已經關閉，則無法收到這個報文。其次，當A在發送完最後一個ACK報文段後，再經過時間2MSL，就可以使本連接持續時間內產生的所有報文段都從網路中消失。這樣，下一個新連接中不會出現這種舊的連接請求報文段。
在圖中每一個方框即TCP可能具有的狀態。每個方框中的大寫英文字元串時TCP標准所使用的的TCP連接狀態名。狀態之間的箭頭表示可能發生的狀態變遷。箭頭旁邊的字表明引起這種變遷的原因，或表明發生狀態變遷後又出現什麼動作，在圖中粗實線箭頭表示對客戶進程的正常變遷，粗虛線箭頭表示對伺服器進程的正常變遷，細線箭頭表示異常變遷。
F. 計算機網路的問題，麻煩知道的呃詳細解答一下
很慚愧，我也不會。。
第一題，我的課本是謝希仁的計算機網路第六版，怎麼沒見到GBN在哪一層，你給我說一下，我們共同研究
第二題，沒告訴數據傳輸率啊，怎麼求Td呢？
第三題，這個我倒是懂，肯定是900才對。第一段數據應該是100-399，共300B，第一段確認號為400，第二段肯定是900啊，確認號就是說「900之前的都收到了」
G. 計算機網路——TCP三次握手四次揮手
用戶進程和伺服器進程需要完成一次通信都需要完成 三個階段 ： 連接建立、數據傳送、連接釋放
參考：三次握手和四次揮手
首先先明確幾個概念：
序列號seq（4B） ：用來標記數據段的順序，TCP把連接中發送的所有數據位元組都編上一個序號，第一個位元組的編號由本地隨機產生，給位元組編上序號後，就給每一個報文段指派一個序號， 序列號seq就是這個報文段中的第一個位元組的數據編號 。
確認號ack（4B） ： 期待收到對方下一個報文段的第一個數據位元組的序號 ，序列號表示報文段攜帶數據的第一個位元組的編號，而確認號指的是期望接受到下一個位元組的編號，因此擋牆報文段最後一個位元組的編號+1即是確認號。
確認ACK（1bit） ：僅當ACK=1，確認號欄位才有效。ACK=0，確認號無效。
同步SYN ： 連接建立時 用於同步序號。SYN=1表示這是一個連接請求，或連接接收報文，SYN這個標志位只有在TCP建立連接才會被置為1，握手完成後SYN標志位被置為0.當SYN=1，ACK=0表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使用SYN=1，ACK=1
終止FIN ：用來釋放一個連接。
B的TCP伺服器進程先創建傳輸控制塊TCB，准備接受客戶進程的連接請求。然後伺服器進程就處於LISTEN（收聽）狀態，等待客戶的連接請求。若有，則作出響應。
1）第一次握手：A首先向B發一個SYN (Synchronize) 標記的包，告訴B請求建立連接，一個 SYN包就是僅SYN標記設為1的TCP包(參見TCP包頭Resources)， SYN=1的報文段不能攜帶數據 ，但要 消耗掉一個序號， 此時TCP客戶進程進入SYN-SENT（同步已發送）狀態。
2）第二次握手：B收到後會發一個對SYN包的確認包(SYN/ACK)回去，表示對第一個SYN包的確認，並繼續握手操作.注意: SYN/ACK包是僅SYN 和 ACK 標記為1的包。在確認報文段中，測試TCP伺服器進程進入SYN-RCVD（同步收到）狀態；
3）第三次握手：TCP客戶進程收到B的確認後，要向B給出確認報文段，ACK報文段可以攜帶數據，不攜帶數據則不消耗序號。TCP連接已經建立，A進入ESTABLISHED（已建立連接）。
當B收到A的確認後，也進入建立連接狀態。
序列號和確認號的關系：
第一次握手序列號seq=x；
第二次握手序列號seq=y，確認號ack=x+1；
第三次握手序列號seq=x+1，確認號ack=y+1；
序列號seq是上一次的確認號，而確認號是上一次的序列號+1;這是因為SYN=1的報文段不能攜帶數據，但要消耗掉一個序號，所以下一個報文段要+1；
為了防止已經失效的連接請求報文段突然又傳到服務端，因而產生錯誤」，這種情況是：一端(client)A發出去的第一個連接請求報文並沒有丟失，而是因為某些未知的原因在某個網路節點上發生滯留，導致延遲到連接釋放以後的某個時間才到達另一端(server)B。本來這是一個早已失效的報文段，但是B收到此失效的報文之後，會誤認為是A再次發出的一個新的連接請求，於是B端就向A又發出確認報文，表示同意建立連接。如果不採用「三次握手」，那麼只要B端發出確認報文就會認為新的連接已經建立了，但是A端並沒有發出建立連接的請求，因此不會去向B端發送數據，B端沒有收到數據就會一直等待，這樣B端就會白白浪費掉很多資源。如果採用「三次握手」的話就不會出現這種情況，B端收到一個過時失效的報文段之後，向A端發出確認，此時A並沒有要求建立連接，所以就不會向B端發送確認，這個時候B端也能夠知道連接沒有建立。（知乎上對上面的解釋的評論：這個解答不是問題的本質，這個課本很多知識比較片面。問題的核心在於保證信道數據傳輸的可靠性，避免資源浪費僅僅是一個小的弱原因，不重要。）
從客戶端到服務端釋放連接的過程中，需要四次報文傳輸。
TCP四次揮手過程
1）A的應用進程先向其TCP發出連接釋放報文段（FIN=1，序號seq=u），並停止再發送數據，主動關閉TCP連接，進入FIN-WAIT-1（終止等待1）狀態，等待B的確認。
2）B收到連接釋放報文段後即發出確認報文段，（ACK=1，確認號ack=u+1，序號seq=v），B進入CLOSE-WAIT（關閉等待）狀態，此時的TCP處於半關閉狀態，A到B的連接釋放。
3）A收到B的確認後，進入FIN-WAIT-2（終止等待2）狀態，等待B發出的連接釋放報文段。
4）B沒有要向A發出的數據，B發出連接釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1），B進入LAST-ACK（最後確認）狀態，等待A的確認。
5）A收到B的連接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1），A進入TIME-WAIT（時間等待）狀態。此時TCP未釋放掉，需要經過時間等待計時器設置的時間2MSL後，A才進入CLOSED狀態。
大概就是A和B：
A：「我不和你說話了」
B：「知道了」
此時A單方面不和B說話，當B也沒有話對A說的時候
B：「我也不和你說話了」
A：「好的」
兩個人互相不說話了
TCP四次揮手總結
客戶端發送FIN後，進入終止等待狀態，伺服器收到客戶端連接釋放報文段後，就立即給客戶端發送確認，伺服器就進入CLOSE_WAIT狀態，此時TCP伺服器進程就通知高層應用進程，因而從客戶端到伺服器的連接就釋放了。此時是「半關閉狀態」，即客戶端不可以發送給伺服器，伺服器可以發送給客戶端。
此時，如果伺服器沒有數據報發送給客戶端，其應用程序就通知TCP釋放連接，然後發送給客戶端連接釋放數據報，並等待確認。客戶端發送確認後，進入TIME_WAIT狀態，但是此時TCP連接還沒有釋放，然後經過等待計時器設置的2MSL後，才進入到CLOSE狀態。
H. 計算機網路-可靠傳輸-停止等待協議
全雙工通信的雙方既是發送方也是接收方。下面為了討論問題的方便，我們僅考慮A發送數據而B接收數據並發送確認。 因此A叫做發送方，而B叫做接收方 。因為這里是討論可靠傳輸的原理，因此把傳送的數據單元都稱為分組，「停止等待」就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。
圖5-9（a）是最簡單的無差錯情況。A發送分組M1,發完就暫停發送，等待B的確認。B收到了M1就向A發送確認。A在收到了對M1的確認後，就再發送下一個分組M2。同樣，在收到B對M2的確認後，再發送M3。
圖5-9(b)是分組在傳輸過程中出現差錯的情況，B接收M時檢測出了差錯，就丟棄M1,其他什麼也不做（不通知A收到有差錯的分組）①。也可能是M1在傳輸過程中丟失了，這時B當然什麼都不知道。在這兩種情況下，B都不會發送任何信息。可靠傳輸協議是這樣設計的：A只要超過了一段時間仍然沒有收到確認，就認為剛才發送的分組丟失了，因而重傳前面發送過的分組。這就叫做 超時重傳 。要實現超時重傳，就要在每發送完一個分組時設置一個 超時計時器 。如果在超時計時器到期之前收到了對方的確認，就撤銷已設置的超時計時器。其實在圖5-9(a)中，A為每一個己發送的分組都設置了一個超時計時器。但A只要在超時計時器到期之前收到了相應的確認，就撤銷該超時計時器。
這里應注意以下三點：
第一，A在發遞完一個分組後，必須暫時保留已發送的分組的副本（在發生超時重傳時使用)。只有在收到相應的確認後才能清除暫時保留的分組副本。
第二，分組和確認分組都必須進行編號②。這樣才能明確是哪一個發送出去的分組收到了確認，而哪一個分組還沒有收到確認。
①註：在可靠傳輸的協議中，也可以在檢測出有差錯時發送「否認報文」給對方。這樣做的好處是能夠讓發送方及早如道出現了差錯。不過由於這樣處理會使協議復雜化，現在實用的可靠傳輸協議都不使用這種否認報文了。
②註：編號並不是一個非常簡單的問題。分組編號使用的位數總是有限的，同一個號碼會重復使用。例如，10位的編號范圍是0~1023。當編號增加到1023時，再增加一個號就又回到0，然後重復使用這些號碼。因此，在所發送的分組中，必須能夠區分開哪些是新發送的，哪些是重傳的。對於簡單鏈路上傳送的幀，如採用停止等待協議，只要用1位編號即可，也就是發送完0號幀，收到確認後，再發送1號幀，收到確認後，再發送0號幀。但是在運輸層，這種編號方法有時並不能保證可靠傳輸。
第三，超時計時器設置的重傳時間應當比數據在分組傳輸的平均往返時間更長一些。圖5-9(b)中的一段虛線表示如果M正確到達B同時A也正確收到確認的過程。可見重傳時間應設定為比平均往返時間更長一些。顯然，如果重傳時間設定得很長，那麼通信的效率就會很低。但如果重傳時間設定得太短，以致產生不必要的重傳，就浪費了網路資源。然而，在運輸層重傳時間的准確設定是非常復雜的，這是因為已發送出的分組到底會經過哪些網路，以及這些網路將會產生多大的時延（這取決於這些網路當時的擁塞情況），這些都是不確定因素。圖5-9中把往返時間當作固定的（這並不符合網路的實際情況），只是為了講述原理的方便，關於重傳時間應如何選擇， 選擇確認SACK 。
圖5-10(b)說明的是另一種情況，B所發送的對M1的確認丟失了。A在設定的超時重傳時間內沒有收到確認，並無法知道是自己發送的分組出鋁、丟失，或者是B發送的確認丟失了。因此A在超時計時器到期後就要重傳M1,現在應注意B的動作，假定B又收到了重傳的分組M1。這時應採取兩個行動。第一，丟棄這個重復的分組M1,不向上層交付；第二，向A發送確認，不能認為已經發送過確認就不再發送，因為A之所以重傳M1就表示A沒有收到對M,的確認。
圖5-10(b)也是一種可能出現的情況。傳輸過程中沒有出現差錯，但B對分組M1的確認遲到了。A會收到重復的確認。對重復的確認的處理很簡單：收下後就丟棄。B仍然會收到重復的M1,並且同樣要丟棄重復的M1,並重傳確認分組。
通常A最終總是可以收到對所有發出的分組的確認。如果A不斷重傳分組但總是收不到確認，就說明通信線路太差，不能進行通信。
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網路上實現可靠的通信。
這種可靠傳輸協議常稱為 自動重傳請求ARQ (Automatic Repeat reQuest)。意思是重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。
停止等待協議的優點是簡單，但缺點是信道利用率太低。我們可以用圖5-11來說明這個問題。為簡單起見，假定在A和B之間有一條直通的信道來傳送分組。
假定A發送分組需要的時間是TD。顯然，TD等於分組長度除以數據率。再假定分組正確到達B後，B處理分組的時間可以忽略不計，同時立即發回確認。假定B發送 確認分組需要時間TA 。如果A處理確認分組的時間也可以忽略不計，那麼A在經過時間(TD+RTT+TA)後就可以再發送下一個分組，這里的RTT是往返時間。因為僅僅是在時間TD內才用來傳送有用的數據（包括分組的首部），因此信道的利用率U可用下式計算： U=TD/TD +RTT+TA (5-3)
請注意，更細致的計算還可以在上式分子的時間TD內扣除傳送控制信息（如首部）所花費的時間。但在進行粗略計算時，用近似的式(5-3)就可以了。
我們知道，(5-3)式中的往返時間RTT取決於所使用的信道。例如，假定1200km的信道的往返時間RTT=20ms。分組長度是1200bit,發送速率是1Mbit/s。若忽略處理時間和TA(TA一般都遠小於TD)， TD=1200/1*10^6 ，信道的利用率U=5.66%。但若把發送速率提高到10Mbit/s,則U=5.96×10^(-4)。信道在絕大多數時間內都是空閑的。
從圖5-11還可看出，當往返時間RTT遠大於分組發送時間TD時，信道的利用率就會非常低。還應注意的是，圖5-11並沒有考慮出現差錯後的分組重傳。若出現重傳，則對傳送有用的數據信息來說，信道的利用率就還要降低。
為了提高傳輸效率，發送方可以不使用低效率的停止等待協議，而是採用流水線傳輸(如圖5-12所示)。流水線傳輸就是發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認。這樣可使信道上一真有數據不間斷地在傳送。顯然，這種傳輸方式可以獲得很高的信道利用率。
I. 運輸層知識要點——謝希仁《計算機網路》
為了在計算機網路中有條不紊地交換數據，就必須遵守一些事先約定好的規則。這些規則明確規定了所 交換數據的格式 以及有關的 同步 問題。
同步的含義：在一定條件下應當發生什麼事件，因而含有時序的意思。
網路協議：為進行網路中的數據交換而建立的規則、標准或約定。
網路協議由以下三個要素組成：
1）語法：即數據與控制信息的結構或格式
2）語義：即需要發出何種控制信息，完成何種動作以及做出何種反應
3）同步：即事件實現順序的詳細說明
一、運輸層協議的概述
1.1 進程之間的通信
1.2 運輸層的兩個主要協議
1.3 運輸層的埠
二、用戶數據報協議UDP
2.1 UDP概述
2.2 UDP的首部格式
三、傳輸控制協議TCP概述
3.1 TCP的最主要的特點
3.2 TCP的連接
四、可靠傳輸的工作原理
4.1 停止等待協議
4.2 連續ARQ協議
五、TCP報文段的首部格式
六、TCP可靠傳輸的實現
6.1 以位元組為單位的滑動窗口
6.2 超時重傳時間的選擇
6.3 選擇確認SACK
七、TCP的流量控制
7.1 利用滑動窗口實現流量控制
7.2 必須考慮傳輸效率
八、TCP的擁塞控制
8.1 擁塞控制的一般原理
8.2 幾種擁塞控制方法
8.3 隨機早期檢測RED
九、TCP的運輸連接管理
9.1 TCP的連接建立
9.2 TCP的連接釋放
9.3 TCP的有限狀態機
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
1.1 進程之間的通信
1.只有主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到了下三層的功能
2.兩個主機進行通信就是兩個主機中的應用進程互相通信。從運輸層的角度看，通信的真正端點並不是主機而是主機中的進程。（IP協議能把分組送到目的主機）
網路層時為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。
3.運輸層一個重要功能——復用、分用。 （應用進程復用、分用運輸層）
1.2 運輸層的兩個主要協議
1.UDP—User Datagram Protocol 用戶數據報協議（無連接）：DNS/RIP/DHCP/SNMP/NFS
TCP—Transmission Control Protocol 傳輸控制協議（面向連接）：SMTP/TELNET/HTTP/ FTP
1.3 運輸層的埠
問題：為了使運行不同操作系統的計算機的應用進程能夠互相通信，就必須使用統一的方法（而這種方法必須與特定操作系統無關）對TCP/IP體系的應用進程進行標識。
為什麼不用進程號來區分？（第一，不同操作系統的進程標識符不同；第二，用功能來識別，而不是進程，例如郵件服務功能，而不管具體是哪個進程）
解決方案：在運輸層使用協議埠號，即埠。軟體埠是應用層的各種協議進程與運輸實體進行層間交互的一種地址。（埠號只具有本地意義，只是為了標識本計算機應用層中各個進程在和運輸層交互時的層間介面。）
埠分為兩大類：
1）伺服器使用的埠號：熟知埠號或系統埠號（0~1023）；登記埠號（1024~49151）
2）客戶端使用的埠號：49152~65535
2.1 UDP概述
1.UDP只在IP的數據報服務至上增加了很少一點功能，就是復用、分用以及差錯檢測功能
2.特點
1）無連接
2）盡最大努力交付
3）面向報文 （不合並、不拆分、保留這些報文的邊界）
4）UDP沒有擁塞控制
5）UDP支持一對一、一對多、多對一和多對多的交互通信
6）UDP的首部開銷小，只有8位元組
應用進程本身可以在不影響應用的實時性的前提下，增加一些提高可靠性的措施，如採用前向糾錯或重傳已丟失的報文。
2.2 UDP的首部格式
1.traceroute 讓發送的UDP用戶數據報故意使用一個非法的UDP埠號，接收方丟棄報文，並由ICMP（網路控制報文協議）發送「埠不可達」差錯報文給發送方。
2.計算檢驗和。IP數據報的校驗和只檢驗IP數據報的首部，但UDP的校驗和是把首部和數據部分一起都檢驗。（12位元組的首部+真正的首部+數據來進行校驗和的計算）
Q1.為什麼計算校驗和要加12位元組的偽首部
Q2.計算校驗和的原理是什麼？
3.1 TCP的最主要的特點
1.面向連接的運輸層協議（建立連接、傳輸數據、釋放連接）
2.點對點，每一條TCP連接只能有兩個端點
3.可靠交付（無差錯、不丟失、不重復、並且按序到達）
4.全雙工通信。TCP連接的兩端都設有發送緩存和接收緩存。
5.面向位元組流。（流指的是流入到進程或從進程流出的位元組序列；面向位元組流：TCP把應用程序交下來的數據看成是一連串的無結構位元組流。 接收方的應用程序必須有能力識別接收到的位元組流，把它還原成有意義的應用層數據。 因此TCP可以根據窗口值和當前網路狀況調整發送的報文長度。劃分短一點，或者積累到足夠多再發送出去。）
3.2 TCP的連接
1.TCP把連接作為最基本的抽象。
2.每一條TCP連接有兩個端點。TCP連接的端點叫作套接字。
套接字soket = （IP地址：埠號）
每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。
TCP連接 ::= {socket1, socket2}
理想的傳輸條件有以下兩個特點：
1）傳輸信道不產生差錯
2）不管發送方以多快的速度發送數據，接收方總是來得及處理收到的數據
實際的網路並不具備，因此：
1）出現差錯時，讓發送方重傳
2）接收方來不及處理時，及時告訴發送方適當降低發送數據的速度
4.1 停止等待協議
1.「停止等待」就是沒發送完一個分組就停止發送，等待對方的確認，在收到確認後再發送下一個分組。
2.超時重傳。在每發完一個分組就設置一個超時計時器，如果在超時計時器之前收到對方的確認，就撤銷已設置的超時計時器。如果未收到，就認為剛才的分組丟失，並重傳。
3.三種情況：A發送的分組出錯、丟失；B發送的確認丟失；B發送的確認遲到
確認丟失：B丟棄重復的分組，向A重傳確認
確認遲到：A丟棄重復的確認，B丟棄重復分組，並向A重傳確認
4.常稱為自動重傳請求ARQ，重傳時自動進行的（超時即重傳）
5.缺點：信道利用率太低
U=Td/(Td+RTT+Ta)
為了提高傳輸效率，發送方不使用停止等待協議，而是採用流水線傳輸。流水線傳輸就是發送發可連續發送多個分組，不必等每發完一個分組就停頓下來等待對方的確認。（連續ARQ協議和滑動窗口協議）
4.2 連續ARQ協議
1.位於發送窗口內的分組都可連續發送出去，而不需要等待對方的確認。
2.累積確認：接收方不必對收到的分組逐個發送確認，而是在收到幾個分組後，對按序到達的最後一個分組發送確認。
3.缺點：Go-back-N （發送前5個分組，第3個分組丟失，後面三個要重傳）
1.源埠和目的埠
2.序號。 每個位元組都按順序編號。
3.確認號。 期望收到對方下一個報文段的第一個數據位元組的序號。
若確認號=N，則表明：到序號N-1為止的所有數據都已正確收到。
4.數據偏移。 指出TCP報文段的數據起始處距離TCP報文段的起始處有多遠（也即TCP報文段首部長度）。由於首部中還有長度不確定的選項欄位，因此數據偏移欄位是必要的。
5.窗口。窗口欄位明確指出了現在允許對方發送的數據量。窗口值是經常在動態變化著。
6.1 以位元組為單位的滑動窗口
1.發送緩存用來暫存：
1）發送應用程序傳送給發送方TCP准備發送的數據；
2）TCP已發送但未收到確認德爾數據
2.接收緩存用來存放：
1）按序到達的、但尚未被接收應收程序讀取的數據；
2）未按序到達的數據
3.注意三點：
1）A的發送窗口是根據B的接收窗口設置的，但是在同一時刻，由於網路傳輸的滯後，A的發送窗口並不總是B的接收窗口一樣大
2）TCP通常對不按序到達的數據是先臨時存放在接收窗口中，等到位元組流中所缺少的位元組收到後，再按序交付上層的應用進程
3）TCP接收方有累計確認功能（不能過分推遲發送確認，否則會導致發送方不必要的重傳）
6.2 超時重傳時間的選擇
1.超時重傳時間設置太短，會引起很多不必要的重傳；如果設置太長，使網路的空閑時間增大，降低傳輸效率。
2.新的RTTs = (1-a)x(舊的RTTs) + ax（新的RTT樣本），其中RTT樣本的時間為：記錄一個報文段發出的時間，以及收到相應的確認時間，時間差就是報文段的往返時間RTT。
3.RTO = RTTs + 4 x RTTd，其中RTO為超時重傳時間，RTTd是RTT的偏差的加權平均值。
新的RTTd = (1-b) x （舊的RTTd）+ b x |RTTs - 新的RTT樣本|
4.一個問題：發送一個報文段，設定的重傳時間到了，還沒有收到確認。於是重傳報文段。經過一段時間，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？
1）解決方法1，在計算加權平均值RTTs時，只要報文段重傳了，就不採用其往返時間樣本。
引入的問題：報文段的時延突然增大的情況
2）解決方法2，報文段每重傳一次，就把超時重傳時間RTO增大一些（一般是2倍）。當不在發生報文段的重傳時，再根據加權平均計算。
6.3 選擇確認SACK
SACK文檔並沒有指明發送發應當怎樣響應SACK。因此大多數的實現還是重傳所有未被確認的數據塊。
7.1 利用滑動窗口實現流量控制
1.流量控制：就是讓發送方的發送速率不要太快，要讓接收方來得及接收。
2.利用滑動窗口機制可很方便地在TCP連接上實現對發送方的流量控制。發送方的發送窗口不能超過接收方給出的接收窗口的數值。
3.死鎖情況：B向A發送了零窗口的報文段後不久，B又有了一些緩存空間，因此B向A發送rwnd = 400.然而該報文段在傳送過程中丟失。A一直等待B發送的非零窗口的通知，B也一直等待A發送的數據。（ 窗口通知不超時重傳？為什麼？ ）
解決方法：TCP為每個連接設有一個持續計時器。只要一方收到對方的零窗口通知，就啟動計時器。計時器到期後，發送一個零窗口探測報文段，而對方就在確認這個探測報文段時給出了現在的窗口值。若仍為零，收到報文段的一方重新設置持續計時器。
7.2 必須考慮傳輸效率
1.應用程序把數據傳送到TCP的發送緩存後，剩下的發送任務就由TCP來控制了。
2.三種不同的機制來控制TCP報文段的發送時機：
1）TCP維持一個變數，它等於最大報文段長度MSS，只要緩存中的存放的數據達到MSS，就組裝成一個TCP報文段發送出去
2）由發送方的應用進程指明要求發送報文段，即TCP支持推送操作
3）發送方設置一個定時器
3.問題一、若用戶只發送一個位元組，則非常浪費帶寬。
解決方法：若發送應用程序把要發送的數據逐個位元組地送到TCP的發送緩存，則發送方就把第一個數據位元組先發送出去，把後面到達的數據位元組都緩存起來。當發送方收到對第一個數據字元的確認後，再把發送緩存中的所有數據組裝成一個報文段發送出去。（採用收到確認就發送+並開始緩存的方式；同時當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時，就立即發送一個報文段。）
4.問題二、糊塗窗口綜合症。接收緩存已滿，應用程序一次只讀取一個位元組，然後向發送方發送確認。
解決方法：讓接收方等待一段時間，使得接收緩存已有足夠空間容納一個最長的報文段，或者等到接收緩存已有一半空閑的空間。則接收方就發出確認報文。
8.1 擁塞控制的一般原理
1.擁塞的定義：對資源的需求 > 可用資源。 在計算機網路中的鏈路帶寬、交換結點中的緩存和處理機等，都是網路中的資源。
2.擁塞解決不能靠解決某一個部分的問題。因為這會將瓶頸轉移到其他地方。問題的實質往往是整個系統的各個部分不匹配。只有所有部分都平衡了，問題才會得到解決。
3.擁塞控制與流量控制的比較。
1）擁塞控制：防止過多的數據注入到網路中，這樣可以使網路中的路由器或鏈路不致過載。
擁塞控制有個前提：網路能夠承受現有的網路負荷
擁塞控制是一個全局性過程。（發送擁塞時，不知道在某處、什麼原因造成的）
2）流量控制：點對點通信量的控制，是個端到端的問題
流量控制：抑制發送端發送數據的速率，以便使接收端來得及接收。
4.尋找擁塞控制的方案無非就是使不等式 「對資源的需求 > 可用資源 」不再成立的條件。但是必須考慮該措施帶來的其他影響。
5.計算機網路是個復雜的系統。從控制理論的角度來看擁塞控制，可以分為開環控制和閉環控制兩種方法。
1）開環控制：設計網路時事先將有關發生擁塞的因素考慮周到，力求網路在工作時不產生擁塞。但一旦系統運行起來，就不再中途改正。
2）閉環控制：基於反饋環路。
步驟一、監測網路系統以便檢測到擁塞在何時、何處發生；
步驟二、把擁塞發生的信息傳送到可採取行動的地方
步驟三、調整網路系統的運行以解決出現的問題
8.2 幾種擁塞控制方法（只考慮網路擁塞程度，即假設接收方總是有足夠大的緩存空間）
1.慢開始和擁塞避免
1）發送方維持一個擁塞窗口。
擁塞窗口的大小取決於網路的擁塞程度，並且動態地在變化。
控制擁塞窗口的原則是：只要網路沒有出現擁塞，擁塞窗口增大；如果網路出現擁塞，則減小。
2）慢開始的思路：由小到大逐漸增大擁塞窗口數值。每收到一個對新的報文段的確認，把擁塞窗口增加至多一個MSS的數值。（沒經過一個傳輸輪次，擁塞窗口cwnd就加倍）
輪次：把擁塞窗口所允許發送的報文段都連續發送出去，並收到了對已發送的最後一位元組的確認。
慢開始的「慢」並不是指cwnd的增長速率慢，而是指TCP開始發送報文段時先設置cwnd=1（一個MSS數值）。
3）慢開始門限ssthresh
為防止擁塞窗口增長過大，引入一個慢開始門限ssthresh。
當cwnd < ssthresh時，使用上述的慢開始演算法
當cwnd > ssthresh時，停止使用慢開始演算法而改用擁塞避免演算法
4）擁塞避免演算法
思路：讓擁塞窗口cwnd緩慢增大，即沒經過一個往返時間RTT就把發送方的擁塞窗口cwnd增加1，而不是加倍。
5）慢開始門限的設置
只要發送方判斷網路出現擁塞（沒有按時收到確認），就把慢開始門限ssthresh設置為出現擁塞時發送方窗口值的一半，然後把擁塞窗口cwnd重置為1，執行慢開始演算法。
6）乘法減小和加法增大
乘法減小：網路出現擁塞時，把慢開始門限ssthresh減半（當前的ssthresh的一半），並執行慢開始演算法。
加法增大：執行擁塞避免方法
2.快重傳和快恢復
1）快重傳（盡快重傳未被確認的報文段）
首先，要求接收方每收到一個失序的報文段後就立即發出重復確認。（如接收方收到了M1和M2後都分別發出了確認，但接收方沒有收到M3但接著收到了M4。此時接收方立即發送對M2的重復確認。）
其次，發送方只要一連收到三個重復確認，就應當立即重傳對方尚未收到的報文段M3.
2）快恢復
要點一、當發送方連續收到三個重復確認，就執行「乘法減小」演算法，把慢開始門限ssthresh減半。
要點二、由於發送方認為網路很可能沒有發生擁塞（因為收到了連續的重復確認），把cwnd設置為慢開始門限ssthresh減半後的值，然後開始執行擁塞避免演算法
慢開始演算法只在TCP連接建立時和網路出現超時才使用。
3.發送方的窗口
發送方窗口的上限值 = Min [rwnd, cwnd]
8.3 隨機早期檢測RED（IP層影響TCP層的擁塞控制）
1.網路層的分組丟棄策略
網路層的策略對TCP擁塞控制影響最大的就是路由器的分組丟棄策略。
如果路由器隊列已滿，則後續到達的分組將都被丟棄。這就叫做尾部丟棄策略。
2.全局同步
由於TCP復用IP，若發生路由器中的尾部丟棄，就可能會同時影響到很多條TCP連接，結果就使許多TCP連接在同一時間突然都進入到慢開始狀態。全局同步使得全網的通信量突然下降了很多，網路恢復正常後，其通信量又突然增大很多。
3.隨機早期檢測RED
使路由器的隊列維持兩個參數，即隊列長度最小門限THmin和最大門限THmax。當每一個分組到達時，RED就先計算平均隊列長度Lav。RED演算法是：
1）若平均隊列長度小於最小門限THmin，則把新到達的分組放入隊列進行排隊
2）若平均隊列長度超過最大門限THmax，則把新到達的分組丟棄
3）若平均隊列長度在最小門限THmin和最大門限THmax之間，則按照某一概率p將新到達的分組丟棄。
隨機體現在3），在檢測到網路擁塞的早期徵兆時（即路由器的平均隊列長度超過一定的門限值時），就先以概率p隨機丟棄個別的分組，讓擁塞控制只在個別的TCP連接上進行，因而避免發生全局性的擁塞控制。
4.平均隊列長度Lav和分組丟棄概率p
Lav = (1-d) x (舊的Lav) +d x (當前的隊列長度樣本)
p = ptemp / (1- count x ptemp)
ptemp = pmax x (Lav - THmin) / (THmax - THmin)
TCP時面向連接的協議。
運輸連接就有三個階段：連接建立、數據傳送和連接釋放
運輸連接的管理：使運輸連接的建立和釋放都能正常地進行。
在TCP連接建立過程中要解決以下三個問題：
1）要使每一方能夠確知對方的存在
2）要允許雙方協商一些參數（如最大窗口值、是否使用窗口擴大選項和時間戳等等）
3）能夠對運輸實體資源（如緩存大小、連接表中的項目等）進行分配
9.1 TCP的連接建立
1.TCP規定，SYN=1報文段不能攜帶數據，但消耗一個序號
2.TCP規定，ACK=1報文段可以攜帶數據，如果不攜帶數據則不消耗序號
3.為什麼A還要發送一次確認？為了防止已失效的連接請求報文突然又傳送到B，因而產生錯誤。
「已失效的連接請求報文段」
A發出第一個連接請求報文段，在網路中滯留超時，又發出了第二個連接請求。但B收到第一個延遲的失效的連接請求報文段後，就誤認為是A又發出了一次新的連接請求。於是就向A發出確認報文段，同意建立連接。假定不採用三次握手，那麼只要B發出確認，新的連接就建立。此時A不會理睬B的確認，也不會發數據，但B一直等A發送數據，B的許多資源就浪費了。
採用三次握手，A不會向B發送確認，因此B就知道A並沒有要求建立確認。
9.2 TCP的連接釋放
1.TCP規定，FIN報文段基石不攜帶數據，也消耗一個序號
2.第二次握手後，TCP通知高層應用程序，因而從A到B這個方向的連接就釋放，TCP連接處於半關閉狀態
3.為什麼A在TIME-WAIT狀態必須等待2MSL的時間
1）為了保證A發送的最後一個ACK報文段能夠到達B。因為ACK可能丟失，此時B可能會超時重傳，然後A重傳確認，並重新啟動2MSL計時器
2）防止「已失效的連接請求報文段」出現在本連接中。可以使本連接持續時間內所產生的所有報文段都從網路中消失。
9.3 TCP的有限狀態機