計算機網路中的往返時間用圖表示

① 計算機網路-可靠傳輸-停止等待協議

全雙工通信的雙方既是發送方也是接收方。下面為了討論問題的方便，我們僅考慮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所示)。流水線傳輸就是發送方可連續發送多個分組，不必每發完一個分組就停頓下來等待對方的確認。這樣可使信道上一真有數據不間斷地在傳送。顯然，這種傳輸方式可以獲得很高的信道利用率。

② 什麼是RTT計算機網路里的東西

RTT(Round-Trip Time)：往返時延。是指數據從網路一端傳到另一端所需的時間。通常，時延由發送時延、傳播時延、排隊時延、處理時延四個部分組成。

（1）發送時延

發送時延是結點將數據分組發送到傳輸媒介所需要的時間，也就是從分組的第一個比特開始發送算起，到最後一個比特發送完畢所需要的時間。顯然，發送時延與網路介面/信道的傳輸速率成反比，與數據分組的長度成正比。

（2）傳播時延

傳播時延是電磁波在信道中傳播一定距離所需要花費的時間，傳播時延和信道的傳輸速率無關，
而是取決於傳輸媒介的長度，以及某種物理形式的信號在傳輸媒介中的傳播速度。

如電磁波在自由空間的傳播速度是光速，即3×105km/s。電磁波在網路傳輸媒體中的傳播速度比在自由空間中的傳播速度要略低一些，在銅線中的傳播速度約為2.3×105km/s
，在光纖中的傳播速度約為2.0×105km/s 。

（3）排隊時延

排隊時延是分組在所經過的網路結點的緩存隊列中排隊所經歷的時延，排隊時延的長短主要取決於網路中當時的通信量，當網路的通信流量大時，排隊時間就長，極端情況下，當網路發生擁塞導致分組丟失時，該結點的排隊時延視為無窮大。

此外，在有優先順序演算法的網路中，排隊時延還取決於數據的優先順序和結點的隊列調度演算法。

（4）處理時延

處理時延是分組在中間結點的存儲轉發過程中而進行的一些必要的處理所花費的時間，這些處理包括提取分組的首部，進行差錯校驗，為分組定址和選路等。

(2)計算機網路中的往返時間用圖表示擴展閱讀

網路端到端的時延是幾種時延的總合，其計算公式是：

總時延=傳播時延+發送時延+排隊時延+處理時延

根據網路的不同情況，有時有些時延可以忽略不計，如在區域網中，傳播時延很小可以忽略不計；當網路沒有擁塞時，分組在各個結點的排隊時延可以忽略不計。

往返時延（Round-Trip Time，RTT）也是一個重要的性能指標，它表示從發送方發送數據開始，到發送方收到來自接收方的確認，總共經歷的時延。對於復雜的網路，往返時延要包括各中間結點的處理時延和轉發數據時的發送時延。

③ 計算機網路——TCP/UDP協議

計算機網路七層模型中，傳輸層有兩個重要的協議：
（1）用戶數據報協議UDP (User Datagram Protocol)
（2）傳輸控制協議TCP (Transmission Control Protocol)

UDP 在傳送數據之前不需要先建立連接。遠地主機的運輸層在收到UDP 報文後，不需要給出任何確認。雖然UDP 不提供可靠交付，但在某些情況下UDP 卻是一種最有效的工作方式。

TCP 則提供面向連接的服務。在傳送數據之前必須先建立連接，數據傳送結束後要釋放連接。TCP 不提供廣播或多播服務。由於TCP 要提供可靠的、面向連接的運輸服務，因此不可避免地增加了許多的開銷，如確認、流量控制、計時器以及連接管理等。

UDP 的主要特點是：

首部手段很簡單，只有8 個位元組，由四個欄位組成，每個欄位的長度都是兩個位元組。

前面已經講過，每條TCP 連接有兩個端點，TCP 連接的端點叫做套接字（socket）或插口。套接字格式如下：

套接寧socket= (IP 地址：埠號』）

每一條TCP 連接唯一地被通信兩端的兩個端點（即兩個套接宇）所確定。即：
TCP 連接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}

3次握手鏈接

4次握手釋放鏈接

斷開連接請求可以由客戶端發出，也可以由伺服器端發出，在這里我們稱A端向B端請求斷開連接。

各個狀態節點解釋如下：

下面為了討論問題的萬便，我們僅考慮A發送數據而B 接收數據並發送確認。因此A 叫做發送方，而B 叫做接收方。

「停止等待」就是每發送完一個分組就停止發送，等待對方的確認。在收到確認後再發送下一個分組。

使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網路上實現可靠的通信。像上述的這種可靠傳輸協議常稱為自動重傳請求ARQ (Automatic Repeat reQuest）。意思是重傳的請求是自動進行的。接收方不需要請求發送方重傳某個出錯的分組。

滑動窗口協議比較復雜，是TCP 協議的精髓所在。這里先給出連續ARQ 協議最基本的概念，但不涉提到許多細節問題。詳細的滑動窗口協議將在後面討論。

下圖表示發送方維持的發送窗口，它的意義是：位於發送窗口內的5 個分組都可連續發送出去，而不需要等待對方的確認。這樣，信道利用率就提高了。

連續ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。

接收方一般都是採用 累積確認 的方式。這就是說，接收方不必對收到的分組逐個發送確認，而是可以在收到幾個分組後，對按序到達的最後一個分組發送確認，這樣就表示：到這個分組為止的所有分組都己正確收到了。

累積確認 的優點是容易實現，即使確認丟失也不必重傳。但缺點是不能向發送方反映出接收方己經正確收到的所有分組的信息。

例如，如果發送方發送了前5 個分組，而中間的第3 個分組丟失了。這時接收方只能對前兩個分組發出確認。發送方無法知道後面三個分組的下落，而只好把後面的三個分組都再重傳一次。這就叫做Go-back-N （回退N ），表示需要再退回來重傳己發送過的N 個分組。可見當通信線路質量不好時，連續ARQ 協議會帶來負面的影響。

TCP 的滑動窗口是以位元組為單位的。現假定A 收到了B 發來的確認報文段，其中窗口是20 （位元組），而確認號是31 （這表明B 期望收到的下一個序號是31 ，而序號30 為止的數據己經收到了）。根據這兩個數據， A 就構造出自己的發送窗口，其位置如圖所示。

發送窗口表示：在沒有收到B 的確認的情況下， A可以連續把窗口內的數據都發送出去。凡是己經發送過的數據，在未收到確認之前都必須暫時保留，以便在超時重傳時使用。

發送窗口後沿的後面部分表示己發送且己收到了確認。這些數據顯然不需要再保留了。而發送窗口前沿的前面部分表示不允許發送的，因為接收方都沒有為這部分數據保留臨時存放的緩存空間。

現在假定A 發送了序號為31 ～ 41 的數據。這時發送窗口位置並未改變，但發送窗口內靠後面有11個位元組（灰色小方框表示）表示己發送但未收到確認。而發送窗口內靠前面的9 個位元組（ 42 ～ 50 ）是允許發送但尚未發送的。】

再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 號為止的數據是已經發送過確認，並且己經交付給主機了。因此在B 可以不再保留這些數據。接收窗口內的序號（31～50）足允許接收的。B 收到了序號為32 和33 的數據，這些數據沒有按序到達，因為序號為31 的數據沒有收到（也許丟失了，也許滯留在網路中的某處）。 請注意， B 只能對按序收到的數據中的最高序號給出確認，因此B 發送的確認報文段中的確認號仍然是31 （即期望收到的序號）。

現在假定B 收到了序號為31 的數據，並把序號為31～33的數據交付給主機，然後B刪除這些數據。接著把接收窗口向前移動3個序號，同時給A 發送確認，其中窗口值仍為20，但確認號是34，這表明B 已經收到了到序號33 為止的數據。我們注意到，B還收到了序號為37, 38 和40 的數據，但這些都沒有按序到達，只能先存在接收窗口。A收到B的確認後，就可以把發送窗口向前滑動3個序號，指針P2 不動。可以看出，現在A 的可用窗口增大了，可發送的序號范圍是42～53。整個過程如下圖：

A 在繼續發送完序號42-53的數據後，指針P2向前移動和P3重合。發送窗口內的序號都已用完，但還沒有再收到確認。由於A 的發送窗口己滿，可用窗口己減小到0，因此必須停止發送。

上面已經講到， TCP 的發送方在規定的時間內沒有收到確認就要重傳已發送的報文段。這種重傳的概念是很簡單的，但重傳時間的選擇卻是TCP 最復雜的問題之一。

TCP採用了一種自適應演算法 ，它記錄一個報文段發出的時間，以及收到相應的確認的時間。這兩個時間之差就是報文段的往返時間RTT，TCP 保留了RTT的一個加權平均往返時間RTTs （這又稱為平滑的往返時間， S 表示Smoothed 。因為進行的是加權平均，因此得出的結果更加平滑）。每當第一次測量到RTT樣本時， RTTs值就取為所測量到的RTT樣本值。但以後每測量到一個新的RTT樣本，就按下式重新計算一次RTTs:

新的RTTs = (1 － α）×（舊的RTTs) ＋ α ×（新的RTT樣本）

α 越大表示新的RTTs受新的RTT樣本的影響越大。推薦的α 值為0.125，用這種方法得出的加權平均往返時間RTTs 就比測量出的RTT值更加平滑。

顯然，超時計時器設置的超時重傳時間RTO (RetransmissionTime-Out）應略大於上面得出的加權平均往返時間RTTs。RFC 2988 建議使用下式計算RTO:

RTO = RTTs + 4 × RTTd

RTTd是RTT 的偏差的加權平均值，它與RTTs和新的RTT樣本之差有關。計算公式如下：

新的RTTd= (1- β）×（舊的RTTd) + β × |RTTs－新的RTT樣本|

發現問題： 如圖所示，發送出一個報文段。設定的重傳時間到了，還沒有收到確認。於是重
傳報文段。經過了一段時間後，收到了確認報文段。現在的問題是：如何判定此確認報文段是對先發送的報文段的確認，還是對後來重傳的報文段的確認？

若收到的確認是對重傳報文段的確認，但卻被源主機當成是對原來的報文段的確認，則這樣計算出的RTTs 和超時重傳時間RTO 就會偏大。若後面再發送的報文段又是經過重傳後才收到確認報文段，則按此方法得出的超時重傳時間RTO 就越來越長。

若收到的確認是對原來的報文段的確認，但被當成是對重傳報文段的確認，則由此計算出的RTTs 和RTO 都會偏小。這就必然導致報文段過多地重傳。這樣就有可能使RTO 越來越短。

Kam 提出了一個演算法：在計算加權平均RTTs 時，只要報文段重傳了就不採用其往返時間樣本。這樣得出的加權平均RTTs 和RTO 就較准確。

新問題： 設想出現這樣的情況：報文段的時延突然增大了很多。因此在原來得出的重傳時間內，不會收到確認報文段。於是就重傳報文段。但根據Kam 演算法，不考慮重傳的報文段的往返時間樣本。這樣，超時重傳時間就無法更新。

解決方案： 對Kam 演算法進行修正，方法是z報文段每重傳一次，就把超時重傳時間RTO 增大一些。典型的做法是取新的重傳時間為2 倍的舊的重傳時間。當不再發生報文段的重傳時，才根據上面給出的公式計算超時重傳時間。

流量控制（flow control）就是讓發送方的發送速率不要太快，要讓接收方來得及接收。

利用滑動窗口機制可以很方便地在TCP 連接上實現對發送方的流量控制。

接收方的主機B 進行了三次流量控制。第一次把窗口減小到rwnd =300，第二次又減到rwnd = 100 ，最後減到rwnd = 0 ，即不允許發送方再發送數據了。這種使發送方暫停發送的狀態將持續到主機B 重新發出一個新的窗口值為止。我們還應注意到，B 向A 發送的三個報文段都設置了ACK=1，只有在ACK=1 時確認號欄位才有意義。

發生死鎖： 現在我們考慮一種情況。上圖中， B 向A 發送了零窗口的報文段後不久， B 的接收緩存又有了一些存儲空間。於是B 向A 發送了rwnd = 400 的報文段。然而這個報文段在傳送過程中丟失了。A 一直等待收到B 發送的非零窗口的通知，而B 也一直等待A 發送的數據。如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。

解決方案： TCP 為每一個連接設有一個 持續計時器（persistence timer） 。只要TCP 連接的一方收到對方的零窗口通知，就啟動持續計時器。若持續計時器設置的時間到期，就發送一個 零窗口探測報文段 （僅攜帶1 宇節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。

1 TCP連接時是三次握手，那麼兩次握手可行嗎？

在《計算機網路》中是這樣解釋的：已失效的連接請求報文段」的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網路結點長時間的滯留了，以致延誤到連接釋放以後的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認為是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用「三次握手」，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送ACK包。這樣就會白白浪費資源。而經過三次握手，客戶端和伺服器都有應有答，這樣可以確保TCP正確連接。

2 為什麼TCP連接是三次，揮手確是四次？

在TCP連接中，伺服器端的SYN和ACK向客戶端發送是一次性發送的，而在斷開連接的過程中，B端向A端發送的ACK和FIN是是分兩次發送的。因為在B端接收到A端的FIN後，B端可能還有數據要傳輸，所以先發送ACK，等B端處理完自己的事情後就可以發送FIN斷開連接了。

3 為什麼在第四次揮手後會有2個MSL的延時？

MSL是Maximum Segment Lifetime，最大報文段生存時間，2個MSL是報文段發送和接收的最長時間。假定網路不可靠，那麼第四次發送的ACK可能丟失，即B端無法收到這個ACK，如果B端收不到這個確認ACK，B端會定時向A端重復發送FIN，直到B端收到A的確認ACK。所以這個2MSL就是用來處理這個可能丟失的ACK的。

1 文件傳送協議

文件傳送協議FTP (File Transfer Protocol) [RFC 959］是網際網路上使用得最廣泛的文件傳送協議，底層採用TCP協議。

盯P 使用客戶伺服器方式。一個FTP 伺服器進程可同時為多個客戶進程提供服務。FTP的伺服器進程由兩大部分組成：一個主進程，負責接受新的請求：另外有若干個從屬進程，負責處理單個請求。

在進行文件傳輸時，客戶和伺服器之間要建立兩個並行的TCP 連接：「控制連接」（21埠）和「數據連接」（22埠）。控制連接在整個會話期間一直保持打開， FTP 客戶所發出的傳送請求，通過控制連接發送給伺服器端的控制進程，但控制連接並不用來傳送文件。實際用於傳輸文件的是「數據連接」。伺服器端的控制進程在接收到FTP 客戶發送來的文件傳輸請求後就創建「數據傳送進程」和「數據連接」，用來連接客戶端和伺服器端的數據傳送進程。

2 簡單文件傳送協議TFTP

TCP/IP 協議族中還有一個簡單文件傳送協議TFfP (Trivial File Transfer Protocol），它是一個很小且易於實現的文件傳送協議，埠號69。

TFfP 也使用客戶伺服器方式，但它使用UDP 數據報，因此TFfP 需要有自己的差錯改正措施。TFfP 只支持文件傳輸而不支持交耳。

3 TELNET

TELNET 是一個簡單的遠程終端協議，底層採用TCP協議。TELNET 也使用客戶伺服器方式。在本地系統運行TELNET 客戶進程，而在遠地主機則運行TELNET 伺服器進程，佔用埠23。

4 郵件傳輸協議

一個電子郵件系統應具如圖所示的三個主要組成構件，這就是用戶代理、郵件伺服器，以及郵件發送協議（如SMTP ）和郵件讀取協議（如POP3)， POP3 是郵局協議（Post Office Protocol）的版本3 。

SMTP 和POP3 （或IMAP ）都是在TCP 連接的上面傳送郵件，使用TCP 的目的是為了使郵件的傳送成為可靠的。

④ 網路中的RTT是什麼意思

RTT(Round-Trip Time): 往返時延。在計算機網路中它是一個重要的性能指標，表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延。 RTT(Radio Transmission Technology): 無線傳輸技術。參考CDMA2000詞條中的CDMA2000 1xRTT。 RTT(Radiation Tracking Transcer): 紅外線跟蹤系統, 輻射跟蹤換能器。 RTT(Radio Teletype (-writer)): 無線電電傳打字電報機。 RTT(Radioteletype Transmitter): 無線電電傳打字電報發射機。 RTT(Real-Time Tactics):即時戰術游戲又稱「實時戰術」游戲。它與即時戰略（RTS：Real-Time Strategy）相類似，但缺少必要的戰略要素，如資源採集、建造、發展等。一種常見的誤解是認為「只要是即時進行的戰爭游戲就是即時戰略游戲」。其實即時戰略游戲的定義是很嚴格的，即時戰略的「戰略（Strategy）」的謀定過程必須是即時的，如果只有戰斗是即時的，而採集、建造、發展等戰略元素卻以回合制進行，則該游戲不能歸為即時戰略游戲。如果該游戲完全沒有上述戰略元素，則只能歸為即時戰術（RTT：Real-Time Tactics）游戲。

⑤ 計算機網路——應用層-Web&HTTP

計算機網路系列博文——目錄

20世紀90年代初
網際網路應用

Web應用的組成

由對象組成。對象是一個文件，如HTML文件，JPEG圖像，Java程序，視頻片段等。
對象可通過一個URL地址定址。
Web頁面常由一個HTML基本文件和多個引用對象構成。

URL(Uniform Resoure Locator)：統一資源定位器 RFC1738

用以定址Web對象
由一個存放對象的伺服器主機名和對象路徑名構成。

HTTP 由客戶端程序和服務端程序實現，二者通過交換HTTP報文會話。
HTTP規范定義了HTTP客戶端和服務端之間的通信協議。

Web瀏覽器實現HTTP客戶端,請求、接收、展示Web對象
Web伺服器實現HTTP服務端,響應客戶的請求，發送對象

HTTP使用TCP作為支撐運輸層協議。

埠：80

無狀態協議 伺服器不保存關於客戶的任何信息
伺服器向客戶發送被請求的文件，而不存儲任何關於客戶的狀態信息。

往返時間（Round-Trip Time,RTT)
一個短分組從客戶到伺服器然後再返回客戶所花費的時間。

某客戶和伺服器的一次會話中，每個請求/響應對通過一個單獨的TCP連接傳輸

HTTP 1.0版本使用非持續性連接

對多個待獲得的web對象，客戶端一次只請求一個對象，待前一個對象接收完畢後再發送對下一個對象的請求。

時間分析

瀏覽器通常支持並行的TCP連接。並行TCP連接數通常為5~10個。
對多個待獲得的web對象，客戶端一次可同時建立多個TCP連接，以同時請求多個web對象。
時間分析

某客戶和伺服器的一次會話中，所有請求/響應對經同一TCP連接傳輸

HTTP 1.1版本在默認方式下採用持續連接，但也可由客戶端/伺服器配置為非持續連接。

客戶端只有收到前一個響應後才發送新的請求
可理解為同個TCP內的串列

時間分析

客戶端只要遇到一個引用對象就盡快發出請求
可理解為同個TCP內的並行
HTTP 1.1的默認選項

時間分析

TCP 三次握手
1.客戶向伺服器發送一個小TCP報文段；
2.伺服器用一個小TCP報文段做出確認和響應；
3.客戶向伺服器返回確認和一個HTTP請求報文；
4.伺服器返回相應HTML文件;

HTTP規范
RFC 1945 , RFC 2616

用ASCII文本書寫
HTTP協議有兩類消息，請求消息(request)和響應消息(response)

請求行 HTTP請求報文的第一行

方法

首部行 請求行後繼的其它行，包含一些會話信息

空行 回車換行，分隔首部行和實體體

實體體(entity body)
GET方法下實體體為空
POST方法下實體體包含表單信息

狀態行

常見狀態碼

首部行

空行

實體體
包含了所請求的對象

HTTP是無狀態協議，但cookie技術允許伺服器識別用戶
cookie在無狀態的HTTP之上建立一個用戶會話層

參見 [RFC 6265]

cookie組件

cookie技術的爭議在於它可能泄露用戶的隱私

代表原Web伺服器來響應HTTP請求的網路實體

Web緩沖器通常由ISP購買並安裝

允許緩存器證實其緩存的副本是新的。
如果緩存器有web對象最新的版本，則初始伺服器不需要向緩存器發送該web對象

在HTTP請求消息中聲明所持有版本的日期
If-modified-since: <date>

如果緩存的版本是最新的，則響應消息中不包含對象
HTTP/1.0 304 Not Modified

內容分發網路（Content Distribution Network,CDN）
基於緩存器技術，CDN公司在網際網路上安裝許多地理上分散的緩存器，使得大流量本地化。
有共享CDN(Akamai,Limelight)，專用CDN（谷歌，微軟）

⑥ 網路編程（五）TCP詳解

考慮最簡單的情況：兩台主機之間的通信。這個時候只需要一條網線把兩者連起來，規定好彼此的硬體介面，如都用 USB、電壓 10v、頻率 2.4GHz 等， 這一層就是物理層，這些規定就是物理層協議 。

我們當然不滿足於只有兩台電腦連接，因此我們可以使用交換機把多個電腦連接起來，如下圖：

這樣連接起來的網路，稱為區域網，也可以稱為乙太網（乙太網是區域網的一種）。在這個網路中，我們需要標識每個機器，這樣才可以指定要和哪個機器通信。這個標識就是硬體地址 MAC。

硬體地址隨機器的生產就被確定，永久性唯一。在區域網中，我們需要和另外的機器通信時，只需要知道他的硬體地址，交換機就會把我們的消息發送到對應的機器。

這里我們可以不管底層的網線介面如何發送，把物理層抽離，在他之上創建一個新的層次，這就是 數據鏈路層 。

我們依然不滿足於區域網的規模，需要把所有的區域網聯系起來，這個時候就需要用到路由器來連接兩個區域網：

但是如果我們還是使用硬體地址來作為通信對象的唯一標識，那麼當網路規模越來越大，需要記住所有機器的硬體地址是不現實的；

同時，一個網路對象可能會頻繁更換設備，這個時候硬體地址表維護起來更加復雜。這里使用了一個新的地址來標記一個網路對象： IP 地址 。

通過一個簡單的寄信例子來理解 IP 地址。

我住在北京市，我朋友 A 住在上海市，我要給朋友 A 寫信：

因此，這里 IP 地址就是一個網路接入地址（朋友 A 的住址），我只需要知道目標 IP 地址，路由器就可以把消息給我帶到。 在區域網中，就可以動態維護一個 MAC 地址與 IP 地址的映射關系，根據目的 IP 地址就可以尋找到機器的 MAC 地址進行發送 。

這樣我們不需管理底層如何去選擇機器，我們只需要知道 IP 地址，就可以和我們的目標進行通信。這一層就是 網路層 。網路層的核心作用就是 提供主機之間的邏輯通信 。

這樣，在網路中的所有主機，在邏輯上都連接起來了，上層只需要提供目標 IP 地址和數據，網路層就可以把消息發送到對應的主機。

一個主機有多個進程，進程之間進行不同的網路通信，如邊和朋友開黑邊和女朋友聊微信。我的手機同時和兩個不同機器進行通信。

那麼當我的手機收到數據時，如何區分是微信的數據，還是王者的數據？那麼就必須在網路層之上再添加一層： 運輸層 ：

運輸層通過 socket（套接字），將網路信息進行進一步的拆分，不同的應用進程可以獨立進行網路請求，互不幹擾。

這就是運輸層的最本質特點： 提供進程之間的邏輯通信 。這里的進程可以是主機之間，也可以是同個主機，所以在 android 中，socket 通信也是進程通信的一種方式。

現在不同的機器上的應用進程之間可以獨立通信了，那麼我們就可以在計算機網路上開發出形形式式的應用：如 web 網頁的 http，文件傳輸 ftp 等等。這一層稱為 應用層 。

應用層還可以進一步拆分出表示層、會話層，但他們的本質特點都沒有改變： 完成具體的業務需求 。和下面的四層相比，他們並不是必須的，可以歸屬到應用層中。

最後對計網分層進行小結：

這里需要注意的是，分層並不是在物理上的分層，而是邏輯上的分層。通過對底層邏輯的封裝，使得上層的開發可以直接依賴底層的功能而無需理會具體的實現，簡便了開發。

這種分層的思路，也就是責任鏈設計模式，通過層層封裝，把不同的職責獨立起來，更加方便開發、維護等等。

TCP 並不是把應用層傳輸過來的數據直接加上首部然後發送給目標，而是把數據看成一個位元組 流，給他們標上序號之後分部分發送。這就是 TCP 的 面向位元組流 特性：

面向位元組流的好處是無需一次存儲過大的數據佔用太多內存，壞處是無法知道這些位元組代表的意義，例如應用層發送一個音頻文件和一個文本文件，對於 TCP 來說就是一串位元組流，沒有意義可言，這會導致粘包以及拆包問題，後面講。

前面講到，TCP 是可靠傳輸協議，也就是，一個數據交給他，他肯定可以完整無誤地發送到目標地址，除非網路炸了。他實現的網路模型如下：

對於應用層來說，他就是一個可靠傳輸的底層支持服務；而運輸層底層採用了網路層的不可靠傳輸。雖然在網路層甚至數據鏈路層就可以使用協議來保證數據傳輸的可靠性，但這樣網路的設計會更加復雜、效率會隨之降低。把數據傳輸的可靠性保證放在運輸層，會更加合適。

可靠傳輸原理的重點總結一下有： 滑動窗口、超時重傳、累積確認、選擇確認、連續 ARQ 。

停止等待協議

要實現可靠傳輸，最簡便的方法就是：我發送一個數據包給你，然後你跟我回復收到，我繼續發送下一個數據包。傳輸模型如下：

這種「一來一去」的方法來保證傳輸可靠就是 停止等待協議 （stop-and-wait）。不知道還記不記得前面 TCP 首部有一個 ack 欄位，當他設置為 1 的時候，表示這個報文是一個確認收到報文。

然後再來考慮另一種情況：丟包。網路環境不可靠，導致每一次發送的數據包可能會丟失，如果機器 A 發送了數據包丟失了，那麼機器 B 永遠接收不到數據，機器 A 永遠在等待。

解決這個問題的方法是： 超時重傳 。當機器 A 發出一個數據包時便開始計時，時間到還沒收到確認回復，就可以認為是發生了丟包，便再次發送，也就是重傳。

但重傳會導致另一種問題：如果原先的數據包並沒有丟失，只是在網路中待的時間比較久，這個時候機器 B 會受到兩個數據包，那麼機器 B 是如何辨別這兩個數據包是屬於同一份數據還是不同的數據？

這就需要前面講過的方法： 給數據位元組進行編號 。這樣接收方就可以根據數據的位元組編號，得出這些數據是接下來的數據，還是重傳的數據。

在 TCP 首部有兩個欄位：序號和確認號，他們表示發送方數據第一個位元組的編號，和接收方期待的下一份數據的第一個位元組的編號。

停止等待協議的優點是簡單，但缺點是 信道利用率 太低。

假定AB之間有一條直通的信道來傳送分組

這里的TD是A發送分組所需要的時間（顯然TD = 分組長度 / 數據速率）再假定TA是B發送確認分組所需要的時間（A和B處理分組的時間都忽略不計）那麼A在經過TD+RTT+TA時間後才能發送下一個分組，這里的RTT是往返時間，因為只有TD是採用來傳輸有用的數據（這個數據包括了分組首部，如果可以知道傳輸更精確的數據的時間，可以計算的更精確），所有信道利用率為

為了提高傳輸效率，發送方可以不使用低效率的停止等待協議，而是採用 流水線傳輸 ：就是發送方可以 連續的發送多個分組 ，不必每發完一個分組就停下來等待對方的確認。這樣可使信道上一直有數據不間斷地在傳送。顯然這種傳輸方式可以獲得很高的信道利用率

停止等待協議已經可以滿足可靠傳輸了，但有一個致命缺點： 效率太低 。發送方發送一個數據包之後便進入等待，這個期間並沒有干任何事，浪費了資源。解決的方法是： 連續發送數據包 。

也就是下面介紹的 連續ARQ協議 和 滑動窗口協議

連續 ARQ 協議

模型如下：

和停止等待最大的不同就是，他會源源不斷地發送，接收方源源不斷收到數據之後，逐一進行確認回復。這樣便極大地提高了效率。但同樣，帶來了一些額外的問題:

發送是否可以無限發送直到把緩沖區所有數據發送完？不可以。因為需要考慮接收方緩沖區以及讀取數據的能力。如果發送太快導致接收方無法接受，那麼只是會頻繁進行重傳，浪費了網路資源。所以發送方發送數據的范圍，需要考慮到接收方緩沖區的情況。這就是 TCP 的 流量控制 。

解決方法是： 滑動窗口 。基本模型如下：

在 TCP 的首部有一個窗口大小欄位，他表示接收方的剩餘緩沖區大小，讓發送方可以調整自己的發送窗口大小。通過滑動窗口，就可以實現 TCP 的流量控制，不至於發送太快，導致太多的數據丟失。

連續 ARQ 帶來的第二個問題是：網路中充斥著和發送數據包一樣數據量的確認回復報文，因為每一個發送數據包，必須得有一個確認回復。提高網路效率的方法是： 累積確認 。

接收方不需要逐個進行回復，而是累積到一定量的數據包之後，告訴發送方，在此數據包之前的數據全都收到。例如，收到 1234，接收方只需要告訴發送方我收到 4 了，那麼發送方就知道 1234 都收到了。

第三個問題是：如何處理丟包情況。在停止等待協議中很簡單，直接一個超時重傳就解決了。但，連續 ARQ 中不太一樣。

例如：接收方收到了 123 567，六個位元組，編號為 4 的位元組丟失了。按照累積確認的思路，只能發送 3 的確認回復，567 都必須丟掉，因為發送方會進行重傳。這就是 GBN（go-back-n) 思路。

但是我們會發現，只需要重傳 4 即可，這樣不是很浪費資源，所以就有了： 選擇確認 SACK 。在 TCP 報文的選項欄位，可以設置已經收到的報文段，每一個報文段需要兩個邊界來進行確定。這樣發送方，就可以根據這個選項欄位只重傳丟失的數據了。

第四個問題是：擁塞控制的問題
也是通過窗口的大小來控制的，但是檢測網路滿不滿是個挺難的事情，所以 TCP 發送包經常被比喻成往誰管理灌水，所以擁塞控制就是在不堵塞，不丟包的情況下盡可能的發揮帶寬。

水管有粗細，網路有帶寬，即每秒鍾能發送多少數據；水管有長度，端到端有時延。理想狀態下，水管裡面的水 = 水管粗細 * 水管長度。對於網路上，通道的容量 = 帶寬 * 往返時延。

如果我們設置發送窗口，使得發送但未確認的包為通道的容量，就能撐滿整個管道。

如圖所示，假設往返時間為 8 秒，去 4 秒，回 4 秒，每秒發送一個包，已經過去了 8 秒，則 8 個包都發出去了，其中前四個已經到達接收端，但是 ACK 還沒返回，不能算發送成功，5-8 後四個包還在路上，還沒被接收，這個時候，管道正好撐滿，在發送端，已發送未確認的 8 個包，正好等於帶寬，也即每秒發送一個包，也即每秒發送一個包，乘以來回時間 8 秒。

如果在這個基礎上調大窗口，使得單位時間可以發送更多的包，那麼會出現接收端處理不過來，多出來的包會被丟棄，這個時候，我們可以增加一個緩存，但是緩存裡面的包 4 秒內肯定達不到接收端課，它的缺點會增加時延，如果時延達到一定程度就會超時重傳

TCP 擁塞控制主要來避免兩種現象，包丟失和超時重傳，一旦出現了這些現象說明發送的太快了，要慢一點。

具體的方法就是發送端慢啟動，比如倒水，剛開始倒的很慢，漸漸變快。然後設置一個閾值，當超過這個值的時候就要慢下來

慢下來還是在增長，這時候就可能水滿則溢，出現擁塞，需要降低倒水的速度，等水慢慢滲下去。

擁塞的一種表現是丟包，需要超時重傳，這個時候，採用快速重傳演算法，將當前速度變為一半。所以速度還是在比較高的值，也沒有一夜回到解放前。

到這里關於 TCP 的可靠傳輸原理就已經介紹得差不多。最後進行一個小結：

當然，這只是可靠傳輸的冰山一角，感興趣可以再深入去研究

⑦ 計算機網路有哪些常用的性能指標

計算機網路常用性能指標有：
1、速率：連接在計算機網路上的主機在數字信道上傳送數據的速率。
2、帶寬：網路通信線路傳送數據的能力。
3、吞吐量：單位時間內通過網路的數據量。
4、時延：數據從網路一端傳到另一端所需的時間。
5、時延帶寬積：傳播時延帶寬。
6、往返時間RTT：數據開始到結束所用時間。
7、利用率信道：數據通過信道時間。

(7)計算機網路中的往返時間用圖表示擴展閱讀：
計算機網路中的時延是由一下幾個不同的部分組成的：
（1）發送時延
發送時延是主機或路由器發送數據幀所需要的時間，也就是從發送數據幀的第一個比特算起，到該幀的最後一個比特發送完畢所需的時間。因此發送時延也叫做傳輸時延。發送時延的計算公式是：
發送時延=數據幀長度（bit）/發送速率（bit/s）
（2）傳播時延
傳播時延是電磁波在信道中傳播一定的距離需要花費的時間。傳播時延的計算公式是：
傳播時延=信道長度（m）/電磁波在信道上大的傳播速率（m/s）
電磁波在自由空間的傳播速率是光速。即3.0*10^5km/s。
發送時延發生在機器內部的發送器中，與傳輸信道的長度沒有任何關系。傳播時延發生在機器外部的傳輸信道媒體上，而與信道的發送速率無關。信號傳送的距離越遠，傳播時延就越大
（3）處理時延
主機或路由器在收到分組時需要花費一定時間進行處理，例如分析分組的首部，從分組中提取數據部分、進行差錯檢驗或查找合適的路由等，這就產生了處理時延。
（4）排隊時延
分組在進行網路傳輸時，要經過許多路由器。但分組在進入路由器後要先在輸入隊列中排隊等待，在路由器確定了轉發介面後，還要在輸出隊列中排隊等待轉發。這就產生了排隊時延。排隊時延的長短取決於網路當時的通信量。當網路的通信量很大時會發生隊列溢出，使分組丟失，這相當於排隊時延無窮大。
這樣數據在網路中經歷的總時延就是以上四種時延之和：總時延=發送時延+傳播時延+處理時延+排隊時延。
一般來說，小時延的網路要優於大時延的網路。

⑧ 什麼是數據的排隊時延，往返時延

排隊時延：有時可用排隊時延表示處理時延，而處理時延是數據在交換結點為存儲轉發而進行的一些的必要的的處理所花費的時間。
往返時延：在計算機網路中它也是一個重要的性能指標，它表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認），總共經歷的時延。

⑨ 怎麼計算網址的rtt

計算網址的rtt的方法是：

1、首先，先採樣RTT，記下最近好幾次的RTT值。

2、然後做平滑計算SRTT（ Smoothed RTT），公式為：（其中的 α 取值在0.8 到 0.9之間，這個演算法英文叫Exponential weighted moving average，中文叫：加權移動平均）SRTT = ( α * SRTT ) + ((1- α) * RTT)。

3、開始計算rtt。公式如下：rtt= min [ UBOUND,max [ LBOUND, (β * SRTT) ]]。

其中：UBOUND是最大的timeout時間，上限值、LBOUND是最小的timeout時間，下限值、β 值一般在1.3到2.0之間。

RTT往返時間是：

RTT(Round-Trip Time)往返時間在計算機網路中它是一個重要的性能指標。表示從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據後便立即發送確認，不包含數據傳輸時間）總共經歷的時間。

RTT由三個部分決定：鏈路的傳播時間、末端系統的處理時間、路由器的緩存中的排隊和處理時間。其中前兩個部分的值作為一個TCP連接相對固定。

路由器的緩存中的排隊和處理時間會隨著整個網路擁塞程度的變化而變化。所以RTT的變化在一定程度上反映了網路擁塞程度的變化。簡單來說就是發送方從發送數據開始，到收到來自接受方的確認信息所經歷的時間。

⑩ 計算機網路中的往返時間怎麼解釋

1.時延
時延(delay 或 latency)是指數據從網路一端傳到另一端所需的時間。通常，時延由發送時延、傳播時延、排隊時延、處理時延四個部分組成。
（1）發送時延
發送時延是結點將數據分組發送到傳輸媒介所需要的時間，也就是從分組的第一個比特開始發送算起，到最後一個比特發送完畢所需要的時間。顯然，發送時延與網路介面/信道的傳輸速率成反比，與數據分組的長度成正比。

（2）傳播時延
傳播時延是電磁波在信道中傳播一定距離所需要花費的時間，傳播時延和信道的傳輸速率無關， 而是取決於傳輸媒介的長度，以及某種物理形式的信號在傳輸媒介中的傳播速度。如電磁波在自由空間的傳播速度是光速，即3×105km/s。電磁波在網路傳輸媒體中的傳播速度比在自由空間中的傳播速度要略低一些，在銅線中的傳播速度約為2.3×105km/s ，在光纖中的傳播速度約為2.0×105km/s 。傳播時延的計算公式是：

（3）排隊時延
排隊時延是分組在所經過的網路結點的緩存隊列中排隊所經歷的時延，排隊時延的長短主要取決於網路中當時的通信量，當網路的通信流量大時，排隊時間就長，極端情況下，當網路發生擁塞導致分組丟失時，該結點的排隊時延視為無窮大。此外，在有優先順序演算法的網路中，排隊時延還取決於數據的優先順序和結點的隊列調度演算法。
（4）處理時延
處理時延是分組在中間結點的存儲轉發過程中而進行的一些必要的處理所花費的時間，這些處理包括提取分組的首部，進行差錯校驗，為分組定址和選路等。
綜上所述，網路端到端的時延是幾種時延的總合，其計算公式是：
總時延=傳播時延+發送時延+排隊時延+處理時延
根據網路的不同情況，有時有些時延可以忽略不計，如在區域網中，傳播時延很小可以忽略不計；當網路沒有擁塞時，分組在各個結點的排隊時延可以忽略不計。
2.往返時延
往返時延（Round-Trip Time，RTT）也是一個重要的性能指標，它表示從發送方發送數據開始，到發送方收到來自接收方的確認，總共經歷的時延。對於復雜的網路，往返時延要包括各中間結點的處理時延和轉發數據時的發送時延。
3.時延變化/時延抖動
時延抖動(jitter)指不同分組穿越網路的延遲的變化。當傳輸多媒體信息時，如音視頻應用，更需要關心時延的變化。因為應用層信息的解碼和無失真展示要求數據的時延變化在某個范圍內，這時會引入時延抖動參數來描述網路性能。