1. OSI與TCP/IP各層的結構與功能，都有哪些協議。 

答案：

（1）OSI模型

OSI（Open System Interconnection，開放系統互連）七層網路模型稱為開放式系統互聯參考模型 ，是一個邏輯上的定義，一個規範，它把網路從邏輯上分為了7層。每一層都有相關、相對應的物理裝置，比如路由器，交換機。OSI 七層模型是一種框架性的設計方法 ，建立七層模型的主要目的是為解決異種網路互連時所遇到的相容性問題，其最主要的功能使就是幫助不同型別的主機實現資料傳輸。它的最大優點是將服務、介面和協議這三個概念明確地區分開來，通過七個層次化的結構模型使不同的系統不同的網路之間實現可靠的通訊。

 

模型優點

建立七層模型的主要目的是為解決異種網路互連時所遇到的相容性問題。它的最大優點是將服務、介面和協議這三個概念明確地區分開來：服務說明某一層為上一層提供一些什麼功能，介面說明上一層如何使用下層的服務，而協議涉及如何實現本層的服務；這樣各層之間具有很強的獨立性，互連網路中各實體採用什麼樣的協議是沒有限制的，只要向上提供相同的服務並且不改變相鄰層的介面就可以了。網路七層的劃分也是為了使網路的不同功能模組（不同層次）分擔起不同的職責，從而帶來如下好處：

● 減輕問題的複雜程度，一旦網路發生故障，可迅速定位故障所處層次，便於查詢和糾錯； 

　　

● 在各層分別定義標準介面，使具備相同對等層的不同網路裝置能實現互操作，各層之間則相對獨立，一種高層協議可放在多種低層協議上執行； 　　

● 能有效刺激網路技術革新，因為每次更新都可以在小範圍內進行，不需對整個網路動大手術； 　　

● 便於研究和教學。

 

分層介紹

1.物理層：主要定義物理裝置標準，如網線的介面型別、光纖的介面型別、各種傳輸介質的傳輸速率等。它的主要作用是傳輸位元流（就是由1、0轉化為電流強弱來進行傳輸,到達目的地後在轉化為1、0，也就是我們常說的數模轉換與模數轉換）。這一層的資料叫做位元。 

　　

2.資料鏈路層：定義瞭如何讓格式化資料以進行傳輸，以及如何讓控制對物理介質的訪問。這一層通常還提供錯誤檢測和糾正，以確保資料的可靠傳輸。 　　

3.網路層：在位於不同地理位置的網路中的兩個主機系統之間提供連線和路徑選擇。Internet的發展使得從世界各站點訪問資訊的使用者數大大增加，而網路層正是管理這種連線的層。 　　

4.傳輸層：定義了一些傳輸資料的協議和埠號（WWW埠80等），如：TCP（傳輸控制協議，傳輸效率低，可靠性強，用於傳輸可靠性要求高，資料量大的資料），UDP（使用者資料報協議，與TCP特性恰恰相反，用於傳輸可靠性要求不高，資料量小的資料，如QQ聊天資料就是通過這種方式傳輸的）。 主要是將從下層接收的資料進行分段和傳輸，到達目的地址後再進行重組。常常把這一層資料叫做段。 　　

5.會話層：通過傳輸層（埠號：傳輸埠與接收埠）建立資料傳輸的通路。主要在你的系統之間發起會話或者接受會話請求（裝置之間需要互相認識可以是IP也可以是MAC或者是主機名） 　　

6.表示層：可確保一個系統的應用層所傳送的資訊可以被另一個系統的應用層讀取。例如，PC程式與另一臺計算機進行通訊，其中一臺計算機使用擴充套件二一十進位制交換碼（EBCDIC），而另一臺則使用美國資訊交換標準碼（ASCII）來表示相同的字元。如有必要，表示層會通過使用一種通格式來實現多種資料格式之間的轉換。 　　

7.應用層： 是最靠近使用者的OSI層。這一層為使用者的應用程式（例如電子郵件、檔案傳輸和終端模擬）提供網路服務。

 

（2）TCP/IP模型

ISO制定的OSI參考模型的過於龐大、複雜招致了許多批評。與此對照，由技術人員自己開發的TCP/IP協議棧獲得了更為廣泛的應用。如圖2-1所示，是TCP/IP參考模型和OSI參考模型的對比示意圖。

　　TCP/IP協議棧是美國國防部高階研究計劃局計算機網（Advanced Research Projects Agency Network，ARPANET）和其後繼因特網使用的參考模型。ARPANET是由美國國防部（U.S．Department of Defense，DoD）贊助的研究網路。最初，它只連線了美國境內的四所大學。隨後的幾年中，它通過租用的電話線連線了數百所大學和政府部門。最終ARPANET發展成為全球規模最大的互連網路-因特網。最初的ARPANET於1990年永久性地關閉。　　
　　TCP/IP參考模型分為四個層次：應用層、傳輸層、網路互連層和主機到網路層。如圖2-2所示。

圖2-2　 TCP/IP參考模型的層次結構

　　在TCP/IP參考模型中，去掉了OSI參考模型中的會話層和表示層（這兩層的功能被合併到應用層實現）。同時將OSI參考模型中的資料鏈路層和物理層合併為主機到網路層。下面，分別介紹各層的主要功能。
　　
　　1、主機到網路層　　
　　實際上TCP/IP參考模型沒有真正描述這一層的實現，只是要求能夠提供給其上層-網路互連層一個訪問介面，以便在其上傳遞IP分組。由於這一層次未被定義，所以其具體的實現方法將隨著網路型別的不同而不同。　　
　　2、網路互連層　　
　　網路互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網路或主機。同時，為了儘快地傳送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和傳送的順序可能不同，這就需要上層必須對分組進行排序。　　
　　網路互連層定義了分組格式和協議，即IP協議（Internet Protocol）。　　
　　網路互連層除了需要完成路由的功能外，也可以完成將不同型別的網路（異構網）互連的任務。除此之外，網路互連層還需要完成擁塞控制的功能。　　
　　3、傳輸層　　
　　在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協議。即：傳輸控制協議TCP（transmission control protocol）和使用者資料報協議UDP（user datagram protocol）。　　
　　TCP協議是一個面向連線的、可靠的協議。它將一臺主機發出的位元組流無差錯地發往網際網路上的其他主機。在傳送端，它負責把上層傳送下來的位元組流分成報文段並傳遞給下層。在接收端，它負責把收到的報文進行重組後遞交給上層。TCP協議還要處理端到端的流量控制，以避免緩慢接收的接收方沒有足夠的緩衝區接收發送方傳送的大量資料。　　
　　UDP協議是一個不可靠的、無連線協議，主要適用於不需要對報文進行排序和流量控制的場合。　　
　　4、應用層　　
　　TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。　　
　　應用層面向不同的網路應用引入了不同的應用層協議。其中，有基於TCP協議的，如檔案傳輸協議（File Transfer Protocol，FTP）、虛擬終端協議（TELNET）、超文字連結協議（Hyper Text Transfer Protocol，HTTP），也有基於UDP協議的。

 

2. TCP與UDP的區別。 

答案：

TCP和UDP是OSI模型中的運輸層中的協議。TCP提供可靠的通訊傳輸，而UDP則常被用於讓廣播和細節控制交給應用的通訊傳輸。

UDP(User Datagram Protocol)

UDP不提供複雜的控制機制，利用IP提供面向無連線的通訊服務。並且它是將應用程式發來的資料在收到的那一刻，立刻按照原樣傳送到網路上的一種機制。

即使是出現網路擁堵的情況下，UDP也無法進行流量控制等避免網路擁塞的行為。此外，傳輸途中如果出現了丟包，UDP也不負責重發。甚至當出現包的到達順序亂掉時也沒有糾正的功能。如果需要這些細節控制，那麼不得不交給由採用UDP的應用程式去處理。換句話說，UDP將部分控制轉移到應用程式去處理，自己卻只提供作為傳輸層協議的最基本功能。UDP有點類似於使用者說什麼聽什麼的機制，但是需要使用者充分考慮好上層協議型別並製作相應的應用程式。

TCP(Transmission Control Protocol)

TCP充分實現了資料傳輸時各種控制功能，可以進行丟包的重發控制，還可以對次序亂掉的分包進行順序控制。而這些在UDP中都沒有。此外，TCP作為一種面向有連線的協議，只有在確認通訊對端存在時才會傳送資料，從而可以控制通訊流量的浪費。TCP通過檢驗和、序列號、確認應答、重發控制、連線管理以及視窗控制等機制實現可靠性傳輸。

TCP與UDP如何加以區分使用？

TCP用於在傳輸層有必要實現可靠性傳輸的情況。由於它是面向有連線並具備順序控制、重發控制等機制的。所以它可以為應用提供可靠傳輸。

另一方面，UDP主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊。舉一個IP電話進行通話的例子。如果使用TCP，資料在傳送途中如果丟失會被重發，但是這樣無法流暢地傳輸通話人的聲音，會導致無法進行正常交流。而採用UDP，它不會進行重發處理。從而也就不會有聲音大幅度延遲到達的問題。即使有部分資料丟失，也只是影響某一小部分的通話。此外，在多播與廣播通訊中也使用UDP而不是UDP。RIP、DHCP等基於廣播的協議也要依賴於UDP。

TCP與UDP區別總結：

1、TCP面向連線（如打電話要先撥號建立連線）;UDP是無連線的，即傳送資料之前不需要建立連線

2、TCP提供可靠的服務。也就是說，通過TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付

3、TCP面向位元組流，實際上是TCP把資料看成一連串無結構的位元組流;UDP是面向報文的

UDP沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如IP電話，實時視訊會議等），並且UDP速度更快

4、每一條TCP連線只能是點到點的;UDP支援一對一，一對多，多對一和多對多的互動通訊

5、TCP首部開銷20位元組;UDP的首部開銷小，只有8個位元組

6、TCP的邏輯通訊通道是全雙工的可靠通道，UDP則是不可靠通道

 

 

3. TCP報文結構。 

答案：

 

 

l 源埠（Source Port）：16位的源埠欄位包含初始化通訊的埠號。源埠和IP地址的作用是標識報文的返回地址。

l 目的埠(Destination Port):16位的目的埠欄位定義傳輸的目的。這個埠指明接收方計算機上的應用程式介面。

l 序列號（Sequence Number，seq）:該欄位用來標識TCP源端裝置向目的端裝置傳送的位元組流，它表示在這個報文段中的第幾個資料位元組。序列號是一個32位的數。

l 確認號（Acknowledge Number，ack）：TCP使用32位的確認號欄位標識期望收到的下一個段的第一個位元組，並宣告此前的所有資料已經正確無誤地收到，因此，確認號應該是上次已成功收到的資料位元組序列號加1！！！！。收到確認號的源計算機會知道特定的段已經被收到。確認號的欄位只在ACK標誌被設定時才有效。

l 資料偏移（Data Offset）:這個4位欄位包括TCP頭大小。由於首部可能含有選項內容，因此TCP首部的長度是不確定的。首部長度的單位是32位元或4個八位組。首部長度實際上也指示了資料區在報文段中的起始偏移值。

l 保留（Reserved）:6位置0的欄位。為將來定義新的用途保留。、

l 控制位(Control Bits):共6位，每一位標誌可以開啟一個控制功能。

URG(Urgent Pointer Field Significant,緊急指標欄位標誌):表示TCP包的緊急指標欄位有效，用來保證TCP連線不被中斷，並且督促中間齊備儘快處理這些資料。

ACK（Acknowledgement field significant,確認欄位標誌）: 取1時表示應答欄位有效，也即TCP應答號將包含在TCP段中，為0則反之。

PSH(Push Function,推功能)：這個標誌表示Push操作。所謂Push操作就是指在資料包到達接收端以後，立即送給應用程式，而不是在緩衝區中排隊。

RST（Reset the connection,重置連線）：這個標誌表示感謝連線復位請求，用來複位那些產生錯誤的連線，也被用來拒絕錯誤和非法的資料包。

SYN（Synchronize sequence numbers,同步序列號）:表示同步序號，用來建立連線。

FIN（No more data from sender）:表示傳送端已經發送到資料末尾，資料傳送完成，傳送FIN標誌位的TCP段，連線將被斷開。

l 接受視窗（Window）:目的主機使用16位的視窗欄位告訴源主機它期望每次收到的位元組數。

l 校驗和（Checksum）:TCP頭包括16位的校驗和欄位用於錯誤檢查。源主機基於部分IP頭資訊，TCP頭和資料內容計算一個校驗和，目的主機也要進行相同的計算，如果收到的內容沒有錯誤過，兩個計算應該完全一樣，從而證明資料的有效性。

l 緊急指標（Urgent Pointer）:緊急指標欄位是一個可選的16位指標，指向段內的最後一個位元組位置，這個欄位只在URG標誌被設定時才有效。

l 選項（Option）:至少1位元組的可變長欄位，標識哪個選項（如果有的話）有效。如果沒有選項，這個位元組等於0,說明選項的結束。這個位元組等於1表示無需再有操作；等於2表示下四個位元組包括源機器的最大長度（Maximum Segment Size,MSS）.

l 填充（Padding）:這個欄位中加入額外的零，以保證TCP頭是32的整數倍。

 

4. TCP的三次握手與四次揮手過程，各個狀態名稱與含義，TIMEWAIT的作用。 

（1）TCP的三次握手——建立TCP連線

 

第一步：

客戶端TCP向服務端TCP傳送一個特殊的TCP報文段，不包含應用層資料，但在報文段首部的SYN標誌位被設為1，表示建立連線的報文段，因此被稱為SYN報文段。另外，客戶端會選擇一個初始序號client_isn，記錄在此報文段的序列號seq中。該報文段會封裝在一個IP資料報中被髮送到伺服器端。這個報文段表達的就是希望建立的資訊。

第二步：

一旦包含SYN報文段的IP資料報到達伺服器主機，伺服器從IP資料報中提取出TCP SYN報文段，為該TCP連線分配需要的快取和變數，並向客戶端傳送表示允許連線的報文段。這個允許連線的報文段也不包含任何應用層資料，但包含三個重要的資訊：首先，SYN被置為1，其次，該報文段的確認號ack被置為client_isn+1，表示下一個希望接受的序列號為client_isn+1，最後，伺服器選擇自己的初始序號server_isn，記錄在序列號seq中。這個報文表達的就是允許建立該連線，我自己的初始序號是server_isn。有時也被成為SYNACK報文段。

第三步：

在收到SYNACK報文段之後，客戶端也要給該連線分配快取和變數，客戶端向伺服器再發送一個報文段，對允許連線的報文段進行了確認，其ack被置為server_isn+1，表示下一個希望從伺服器獲得的報文段的序列號為此。並且由於連線已經建立了，SYN標誌位被置為0，並且已經可以攜帶被傳送到伺服器的應用層資料。

 

（2）TCP的四次揮手——斷開TCP連線

 

簡單過程：

當客戶A 沒有東西要傳送時就要釋放 A 這邊的連線，A會發送一個報文（沒有資料），其中 FIN 設定為1,  伺服器B收到後會給應用程式一個信，這時A那邊的連線已經關閉，即A不再發送資訊（但仍可接收資訊）。  A收到B的確認後進入等待狀態，等待B請求釋放連線， B資料傳送完成後就向A請求連線釋放，也是用FIN=1 表示， 並且用 ack = u+1(如圖）， A收到後回覆一個確認資訊，並進入 TIME_WAIT 狀態， 等待 2MSL 時間。

為什麼要等待呢？

為了這種情況： B向A傳送 FIN = 1 的釋放連線請求，但這個報文丟失了， A沒有接到不會發送確認資訊， B 超時會重傳，這時A在 WAIT_TIME 還能夠接收到這個請求，這時再回復一個確認就行了。（A收到 FIN = 1 的請求後 WAIT_TIME會重新記時）

 

深入理解： 

由於TCP連線是全雙工的，因此每個方向都必須單獨進行關閉。這原則是當一方完成它的資料傳送任務後就能傳送一個FIN來終止這個方向的連線。收到一個 FIN只意味著這一方向上沒有資料流動，一個TCP連線在收到一個FIN後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。
TCP協議的連線是全雙工連線，一個TCP連線存在雙向的讀寫通道。 
簡單說來是 “先關讀，後關寫”，一共需要四個階段。以客戶機發起關閉連線為例：
1.伺服器讀通道關閉
2.客戶機寫通道關閉
3.客戶機讀通道關閉
4.伺服器寫通道關閉
關閉行為是在發起方資料傳送完畢之後，給對方發出一個FIN（finish）資料段。直到接收到對方傳送的FIN，且對方收到了接收確認ACK之後，雙方的資料通訊完全結束，過程中每次接收都需要返回確認資料段ACK。
詳細過程：
    第一階段   客戶機發送完資料之後，向伺服器傳送一個FIN資料段，序列號為i；
    1.伺服器收到FIN(i)後，返回確認段ACK，序列號為i+1，關閉伺服器讀通道；
    2.客戶機收到ACK(i+1)後，關閉客戶機寫通道；
   （此時，客戶機仍能通過讀通道讀取伺服器的資料，伺服器仍能通過寫通道寫資料）
    第二階段 伺服器傳送完資料之後，向客戶機發送一個FIN資料段，序列號為j；
    3.客戶機收到FIN(j)後，返回確認段ACK，序列號為j+1，在TIME_WAIT後才能關閉客戶機讀通道！！！！！！！！！！；
    4.伺服器收到ACK(j+1)後，關閉伺服器寫通道。
這是標準的TCP關閉兩個階段，伺服器和客戶機都可以發起關閉，完全對稱。

從上面可以看到，主動發起關閉連線的操作的一方將達到TIME_WAIT狀態，而且這個狀態要保持Maximum Segment Lifetime的兩倍時間。為什麼要這樣做而不是直接進入CLOSED狀態？

原因有二：
一、保證TCP協議的全雙工連線能夠可靠關閉
二、保證這次連線的重複資料段從網路中消失

先說第一點，如果Client直接CLOSED了，那麼由於IP協議的不可靠性或者是其它網路原因，導致Server沒有收到Client最後回覆的ACK。那麼Server就會在超時之後繼續傳送FIN，此時由於Client已經CLOSED了，就找不到與重發的FIN對應的連線，最後Server就會收到RST而不是ACK，Server就會以為是連線錯誤把問題報告給高層。這樣的情況雖然不會造成資料丟失，但是卻導致TCP協議不符合可靠連線的要求。所以，Client不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最後正確的關閉連線。

再說第二點，如果Client直接CLOSED，然後又再向Server發起一個新連線，我們不能保證這個新連線與剛關閉的連線的埠號是不同的。也就是說有可能新連線和老連線的埠號是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連線和已經關閉的老連線埠號是一樣的，如果前一次連線的某些資料仍然滯留在網路中，這些延遲資料在建立新連線之後才到達Server，由於新連線和老連線的埠號是一樣的，又因為TCP協議判斷不同連線的依據是socket pair，於是，TCP協議就認為那個延遲的資料是屬於新連線的，這樣就和真正的新連線的資料包發生混淆了。所以TCP連線還要在TIME_WAIT狀態等待2倍MSL，這樣可以保證本次連線的所有資料都從網路中消失。

 

5. TCP擁塞控制。 

（1）擁塞控制和流量控制的區別

流量控制針對的是點對點之間的（傳送方和接收方）之間的速度匹配服務，因為接收方的應用程式讀取的速度不一定很迅速，而接收方的快取是有限的，就需要避免傳送的速度過快而導致的問題。擁塞控制是由於網路中的路由和鏈路傳輸速度限制，要避免網路的過載和進行的控制。

（2）擁塞控制的幾個指導原則

第一：一個丟失的報文段意味著擁塞，因此當報文段丟失時應該降低TCP傳送方的速率；

第二：當一個確認的報文段到達時，表示當前網路是順暢的，即可以提升傳送方的速率。

第三：ACK和丟包事件充當了隱式的訊號，指導著擁塞控制。

（3）擁塞控制演算法

擁塞控制是使用擁塞視窗來進行控制的，執行在傳送方的擁塞控制機制通過跟蹤一個額外的變數，即擁塞視窗（cwnd），它對於傳送方能夠向網路中傳送流量的速率進行了限制，對於傳送方：

LastByteSent – LastByteAcked  <=  cwnd

擁塞控制演算法主要包含了三個部分：慢啟動、擁塞避免和快速回復

 

第一、慢啟動

慢開始演算法的思路就是，不要一開始就傳送大量的資料，先探測一下網路的擁塞程度，也就是說由小到大逐漸增加擁塞視窗的大小。一般一開始為1個MSS，之後翻倍這樣來增加，呈指數增長。其中1、慢啟動過程有一個閾值ssthresh，一旦到達閾值就進入擁塞避免模式。這是第一種離開結束慢啟動的方式2、如果收到了一個丟包提示，就將cwnd設為1並且重新開始慢啟動過程，這時要把閾值ssthresh設為當前cwnd值的一半。3、如果收到了三次冗餘的ACK，就執行一次快速重傳並且進入快速恢復狀態，這是最後一種結束慢啟動的過程。

第二、擁塞避免

進入擁塞避免說明cwnd值大約是上一次遇到擁塞是的一半，這時候不能翻倍，而是將cwnd的值每次增加一個MSS。結束的過程有兩種可能：1、當出現超時時，將cwnd值設為1個MSS，並且將ssthresh閾值設為當前cwnd值的一半。2、當收到三個冗餘ACK時，將ssthresh閾值設為當前cwnd值的一半，並且將cwnd值設為當前cwnd值的一半加3，即ssthresh閾值加3，並且進入快速恢復狀態。

第三、快速恢復

快速恢復就是指進入快速恢復前的一系列操作，即將ssthresh閾值設為當前cwnd值的一半，並且將cwnd值設為當前cwnd值的一半加3，即ssthresh閾值加3，之後進入擁塞避免狀態，即每次cwnd的值加1個MSS。

見下圖：

 

 

6. TCP滑動視窗與回退N針協議。 

針對TCP流量控制：

（1）滑動視窗協議

傳送和接受方都會維護一個數據幀的序列，這個序列被稱作視窗。傳送方的視窗大小由接受方確定，目的在於控制傳送速度，以免接受方的快取不夠大，而導致溢位，同時控制流量也可以避免網路擁塞。下面圖中的4,5,6號資料幀已經被髮送出去，但是未收到關聯的ACK，7,8,9幀則是等待發送。可以看出傳送端的視窗大小為6，這是由接受端告知的（事實上必須考慮擁塞視窗cwnd，這裡暫且考慮cwnd>rwnd）。此時如果傳送端收到4號ACK，則視窗的左邊緣向右收縮，視窗的右邊緣則向右擴充套件，此時視窗就向前“滑動了”，即資料幀10也可以被髮送。

 

 

（2）

第一種：位元滑動視窗協議（停等協議）

當傳送視窗和接收視窗的大小固定為1時，滑動視窗協議退化為停等協議（stop－and－wait）。該協議規定傳送方每傳送一幀後就要停下來，等待接收方已正確接收的確認（acknowledgement）返回後才能繼續傳送下一幀。由於接收方需要判斷接收到的幀是新發的幀還是重新發送的幀，因此傳送方要為每一個幀加一個序號。由於停等協議規定只有一幀完全傳送成功後才能傳送新的幀，因而只用一位元來編號就夠了。其傳送方和接收方執行的流程圖如圖所示。

 

         

第二種：回退N幀協議

由於停等協議要為每一個幀進行確認後才繼續傳送下一幀，大大降低了通道利用率，因此又提出了後退n協議。後退n協議中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個資料幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。且傳送方在每傳送完一個數據幀時都要設定超時定時器。只要在所設定的超時時間內仍收到確認幀，就要重發相應的資料幀。如：當傳送方傳送了N個幀後，若發現該N幀的前一個幀在計時器超時後仍未返回其確認資訊，則該幀被判為出錯或丟失，此時傳送方就不得不重新發送出錯幀及其後的N幀。

 

從這裡不難看出，後退n協議一方面因連續傳送資料幀而提高了效率，但另一方面，在重傳時又必須把原來已正確傳送過的資料幀進行重傳（僅因這些資料幀之前有一個數據幀出了錯），這種做法又使傳送效率降低。由此可見，若傳輸通道的傳輸質量很差因而誤位元速率較大時，連續測協議不一定優於停止等待協議。此協議中的傳送視窗的大小為k，接收視窗仍是1。

 

第三種：選擇重傳協議

在後退n協議中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。另一種效率更高的策略是當接收方發現某幀出錯後，其後繼續送來的正確的幀雖然不能立即遞交給接收方的高層，但接收方仍可收下來，存放在一個緩衝區中，同時要求傳送方重新傳送出錯的那一幀。一旦收到重新傳來的幀後，就可以原已存於緩衝區中的其餘幀一併按正確的順序遞交高層。這種方法稱為選擇重發(SELECTICE REPEAT)，其工作過程如圖所示。顯然，選擇重發減少了浪費，但要求接收方有足夠大的緩衝區空間。

 

7. Http的報文結構。 

（1）HTTP 請求報文

　　HTTP 請求報文由請求行、請求頭部、空行 和 請求包體 4 個部分組成，如下圖所示：

 

　　下面對請求報文格式進行簡單的分析：

　　請求行：請求行由方法欄位、URL 欄位 和HTTP 協議版本欄位 3 個部分組成，他們之間使用空格隔開。常用的 HTTP 請求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT;

　　● GET：當客戶端要從伺服器中讀取某個資源時，使用GET 方法。GET 方法要求伺服器將URL 定位的資源放在響應報文的資料部分，回送給客戶端，即向伺服器請求某個資源。使用GET 方法時，請求引數和對應的值附加在 URL 後面，利用一個問號(“?”)代表URL 的結尾與請求引數的開始，傳遞引數長度受限制。例如，/index.jsp?id=100&op=bind。

　　● POST：當客戶端給伺服器提供資訊較多時可以使用POST 方法，POST 方法向伺服器提交資料，比如完成表單資料的提交，將資料提交給伺服器處理。GET 一般用於獲取/查詢資源資訊，POST 會附帶使用者資料，一般用於更新資源資訊。POST 方法將請求引數封裝在HTTP 請求資料中，以名稱/值的形式出現，可以傳輸大量資料;

　　請求頭部：請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。請求頭部通知伺服器有關於客戶端請求的資訊，典型的請求頭有：

　　● User-Agent：產生請求的瀏覽器型別;

　　● Accept：客戶端可識別的響應內容型別列表;星號 “ * ” 用於按範圍將型別分組，用 “ */* ” 指示可接受全部型別，用“ type/* ”指示可接受 type 型別的所有子型別;

　　● Accept-Language：客戶端可接受的自然語言;

　　● Accept-Encoding：客戶端可接受的編碼壓縮格式;

　　● Accept-Charset：可接受的應答的字符集;

　　● Host：請求的主機名，允許多個域名同處一個IP 地址，即虛擬主機;

　　● connection：連線方式(close 或 keepalive);

　　● Cookie：儲存於客戶端擴充套件欄位，向同一域名的服務端傳送屬於該域的cookie;

　　空行：最後一個請求頭之後是一個空行，傳送回車符和換行符，通知伺服器以下不再有請求頭;

請求包體：請求包體不在 GET 方法中使用，而是在POST 方法中使用。POST 方法適用於需要客戶填寫表單的場合。與請求包體相關的最常使用的是包體型別 Content-Type 和包體長度 Content-Length;

 

（2）HTTP 響應報文

　　HTTP 響應報文由狀態行、響應頭部、空行 和 響應包體 4 個部分組成，如下圖所示：

 

　　下面對響應報文格式進行簡單的分析：

　　狀態行：狀態行由 HTTP 協議版本欄位、狀態碼和狀態碼的描述文字 3 個部分組成，他們之間使用空格隔開;

　　● 狀態碼由三位數字組成，第一位數字表示響應的型別，常用的狀態碼有五大類如下所示：

　　1xx：表示伺服器已接收了客戶端請求，客戶端可繼續傳送請求;

　　2xx：表示伺服器已成功接收到請求並進行處理;

　　3xx：表示伺服器要求客戶端重定向;

　　4xx：表示客戶端的請求有非法內容;

　　5xx：表示伺服器未能正常處理客戶端的請求而出現意外錯誤;

　　● 狀態碼描述文字有如下取值：

　　200 OK：表示客戶端請求成功;

　　400 Bad Request：表示客戶端請求有語法錯誤，不能被伺服器所理解;

　　401 Unauthonzed：表示請求未經授權，該狀態程式碼必須與 WWW-Authenticate 報頭域一起使用;

　　403 Forbidden：表示伺服器收到請求，但是拒絕提供服務，通常會在響應正文中給出不提供服務的原因;

　　404 Not Found：請求的資源不存在，例如，輸入了錯誤的URL;

　　500 Internal Server Error：表示伺服器發生不可預期的錯誤，導致無法完成客戶端的請求;

　　503 Service Unavailable：表示伺服器當前不能夠處理客戶端的請求，在一段時間之後，伺服器可能會恢復正常;

　　響應頭部：響應頭可能包括：

　　Location：Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，為了讓客戶端重定向到這個頁面新的位置，伺服器端可以發回Location響應報頭後使用重定向語句，讓客戶端去訪問新的域名所對應的伺服器上的資源;

　　Server：Server 響應報頭域包含了伺服器用來處理請求的軟體資訊及其版本。它和 User-Agent 請求報頭域是相對應的，前者傳送伺服器端軟體的資訊，後者傳送客戶端軟體(瀏覽器)和作業系統的資訊。

　　Vary：指示不可快取的請求頭列表;

　　Connection：連線方式;

　　對於請求來說：close(告訴WEB 伺服器或者代理伺服器，在完成本次請求的響應後，斷開連線，不等待本次連線的後續請求了)。keepalive(告訴WEB伺服器或者代理伺服器，在完成本次請求的響應後，保持連線，等待本次連線的後續請求);

　　對於響應來說：close(連線已經關閉); keepalive(連線保持著，在等待本次連線的後續請求); Keep-Alive：如果瀏覽器請求保持連線，則該頭部表明希望WEB 伺服器保持連線多長時間(秒);例如：Keep-Alive：300;

　　WWW-Authenticate：WWW-Authenticate響應報頭域必須被包含在