ios恢復預備份 和 tcp的數據格式
1 server 12.12.12.1
router 12.12.12.2
2 show flash del flash:c1841-advipservicesk9-mz.124-15.T1.bin
3 copy tftp flash
12.12.12.1
c1841-advipservicesk9-mz.124-15.T1.bin
1 show flash
2 copy flash tftp
c1841-advipservicesk9-mz.124-15.T1.bin
1.1.1.2
tcp的數據格式
ATCP數據報格式（轉）--看明白了受益匪淺
2010-10-15 17:53:41| 分類：網絡技術 | 標籤：報文 tcp|字號大中小訂閱
一、TCP報文格式
傳輸控制協議（TCP）向上與用戶應用程序進程接口，向下與網絡層協議IP接口。用戶應用程序採用首先調用TCP（或UDP），然後將應用程序數據遞交給TCP這一方式，在IP網絡上傳送數據。TCP將這些數據打包分段並調用IP模塊向目的主機傳送每個數據段。接收方的TCP將段中的數據放入接收緩衝器，然後將段重裝爲應用程序數據，再將這些數據發送到目的的應用程序進程。
儘管TCP和UDP都使用相同的網絡層（IP），TCP卻嚮應用層提供與UDP完全不同的服務。
TCP提供一種面向連接的、可靠的字節流服務。
源端口號（16位），標識主機上發起傳送的應用程序；目的端口（16位）標識主機上傳送要到達的應用程序。源端和目的端的端口號，用於尋找發端和收端應用進程。這兩個值加上I P首部中的源端I P地址和目的端I P地址唯一確定一個T C P連接。一個I P地址和一個端口號有時也稱爲一個插口（socket），插口對（socket pair）(包含客戶I P地址、客戶端口號、服務器 I P地址和服務器端口號的四元組 )可唯一確定互聯網絡中每個T C P連接的雙方。IP+TCP端口唯一確定一個TCP連接。
TCP協議通過使用"端口"來標識源端和目標端的應用進程。端口號可以使用0到65535之間的任何數字。在收到服務請求時，操作系統動態地爲客戶端的應用程序分配端口號。在服務器端，每種服務在"衆所周知的端口"（Well-Know Port）爲用戶提供服務。
●序號字段：佔32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節。
●確認號字段：佔32比特。只有ACK標誌爲1時，確認號字段纔有效。它包含目標端所期望收到源端的下一個數據字節。
●頭部長度字段：佔4比特。給出頭部佔32比特的數目。沒有任何選項字段的TCP頭部長度爲20字節；最多可以有60字節的TCP頭部。
預留：由跟在數據偏移字段後的6位構成，預留位通常爲0.
●標誌位字段（U、A、P、R、S、F）：佔6比特。各比特的含義如下：
◆緊急比特URG——當URG＝1時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送(相當於高優先級的數據)。 |
◆確認比特ACK——只有當ACK＝1時確認號字段纔有效。當ACK＝0時，確認號無效。 ◆PUSH比特PSH——當PSH＝1時，表示數據包中的數據必須迅速傳播到應用層處理。 |
◆復位比特RST(Reset) —— 當RST＝1時，表明TCP連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立運輸連接。 |
◆同步比特SYN——同步比特SYN置爲1，就表示這是一個連接請求或連接接受報文。 |
◆終止比特FIN(FINal)——用來釋放一個連接。當FIN＝1時，表明此報文段的發送端的數據已發送完畢，並要求釋放運輸連接。 |
●窗口大小字段：佔16比特。此字段用來進行流量控制。單位爲字節數，這個值是本機期望一次接收的字節數。
●TCP校驗和字段：佔16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。
●緊急指針字段：佔16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。
●選項、填充字段：佔32比特。可能包括"窗口擴大因子"、"時間戳"等選項。
TCP首部的主要選項：
最大報文段長度MSS(Maximum Segment Size)是TCP報文段中的數據字段的最大長度。MSS告訴對方TCP：“我的緩存所能接收的報文段的數據字段的最大長度是MSS個字節。”
窗口擴大因子，用於長肥管道。
時間戳，可用於測量往返時延RTT。
TCP的數據編號與確認
TCP協議是面向字節的。TCP將所要傳送的報文看成是字節組成的數據流，並使每一個字節對應於一個序號。
在連接建立時，雙方要商定初始序號。TCP每次發送的報文段的首部中的序號字段數值表示該報文段中的數據部分的第一個字節的序號。
TCP的確認是對接收到的數據的最高序號表示確認。接收端返回的確認號是已收到的數據的最高序號加1。因此確認號表示接收端期望下次收到的數據中的第一個數據字節的序號。
爲提高效率，TCP可以累積確認，即在接收多個報文段後，一次確認。
一、TCP的流量控制
TCP採用大小可變的滑動窗口進行流量控制。窗口大小的單位是字節。
TCP報文段首部的窗口字段寫入的數值就是當前給對方設置的發送窗口數值的上限。
發送窗口在連接建立時由雙方商定。但在通信的過程中，接收端可根據自己的資源情況，隨時動態地調整對方的發送窗口上限值(可增大或減小)。
發送端要發送900字節長的數據，劃分爲9個100字節長的報文段，而發送窗口確定爲500字節。
發送端只要收到了對方的確認，發送窗口就可前移。
發送TCP要維護一個指針。每發送一個報文段，指針就向前移動一個報文段的距離。
發送端已發送400字節的數據，但只收到對前200字節數據的確認，同時窗口大小不變。
現在發送端還可發送300字節。
發送端收到對方對前400字節數據的確認，但對方通知發送端必須把窗口減小到400字節。
現在發送端最多還可發送400字節的數據。
利用可變窗口大小進行流量控制雙方確定的窗口值是400
二、慢啓動和擁塞避免
發送端的主機在確定發送報文段的速率時，既要根據接收端的接收能力，又要從全局考慮不要使網絡發生擁塞。
因此，每一個TCP連接需要有以下兩個狀態變量：
接收端窗口rwnd(receiver window) 又稱爲通知窗口(advertised window)。
擁塞窗口cwnd(congestion window)。
接收端窗口rwnd和擁塞窗口cwnd
接收窗口rwnd 這是接收端根據其目前的接收緩存大小所許諾的最新的窗口值，是來自接收端的流量控制。接收端將此窗口值放在TCP報文的首部中的窗口字段，傳送給發送端。
擁塞窗口cwnd(congestion window) 是發送端根據自己估計的網絡擁塞程度而設置的窗口值，是來自發送端的流量控制。
發送窗口的上限值
發送端的發送窗口的上限值應當取爲接收端窗口rwnd和擁塞窗口cwnd這兩個變量中較小的一個，即應按以下公式確定：
發送窗口的上限值＝Min[rwnd,cwnd]
當 rwnd < cwnd 時，是接收端的接收能力限制發送窗口的最大值。
當 cwnd < rwnd 時，則是網絡的擁塞限制發送窗口的最大值。
慢啓動算法的原理
在剛開始發送時，可先將擁塞窗口cwnd設置爲一個最大報文段MSS的數值。
在每收到一個對新的報文段的確認後，將擁塞窗口增加至2倍MSS的數值。
用這樣的方法逐步增大發送端的擁塞窗口cwnd，可以使分組注入到網絡的速率更加合理。
慢啓動和擁塞避免算法的實現舉例
當TCP連接進行初始化時，將擁塞窗口置爲1。圖中的窗口單位不使用字節而使用報文段。
慢啓動門限的初始值設置爲 16 個報文段，即ssthresh = 16。
發送端的發送窗口不能超過擁塞窗口cwnd和接收端窗口rwnd中的最小值。我們假定接收端窗口足夠大，因此現在發送窗口的數值等於擁塞窗口的數值。
在執行慢啓動算法時，擁塞窗口cwnd 的初始值爲1，發送第一個報文段M0。
發送端收到ACK1（確認M0，期望收到M1）後，將cwnd從1增大到2，於是發送端可以接着發送M1和M2兩個報文段。
接收端發回ACK2和ACK3。發送端每收到一個對新報文段的確認ACK，就把發送端的擁塞窗口加倍。現在發送端的cwnd從2增大到4，並可發送M4—M6共 4個報文段。
發送端每收到一個對新報文段的確認ACK，就把發送端的擁塞窗口加倍，因此擁塞窗口cwnd隨着傳輸次數按指數規律增長。
當擁塞窗口cwnd增長到慢開始門限值ssthresh時（即當cwnd = 16時），就改爲執行擁塞避免算法，擁塞窗口按線性規律增長。
假定擁塞窗口的數值增長到24時，網絡出現超時（表明網絡擁塞了）。
更新後的ssthresh值變爲12（即發送窗口數值24的一半），擁塞窗口再重新設置爲1，並執行慢啓動算法。
當cwnd = 12時改爲執行擁塞避免算法，擁塞窗口按按線性規律增長，每經過一個往返時延就增加一個MSS的大小。
乘法減小(multiplicative decrease)
“乘法減小“是指不論在慢啓動階段還是擁塞避免階段，只要出現一次超時（即出現一次網絡擁塞），就把慢啓動門限值 ssthresh 設置爲當前的擁塞窗口值乘以0.5。
當網絡頻繁出現擁塞時，ssthresh值就下降得很快，以大大減少注入到網絡中的分組數。
加法增大(additive increase)
“加法增大”是指執行擁塞避免算法後，當收到對所有報文段的確認就將擁塞窗口cwnd增加一個MSS大小，使擁塞窗口緩慢增大，以防止網絡過早出現擁塞。
進入擁塞避免算法後，擁塞窗口的增大速度由指數增長變爲線性增長。
TCP中默認報文段丟失是由於網絡擁塞造成超時而引起的。
“擁塞避免”並非指完全能夠避免了擁塞。利用以上的措施要完全避免網絡擁塞還是不可能的。
“擁塞避免”是說在擁塞避免階段把擁塞窗口控制爲按線性規律增長，使網絡比較不容易出現擁塞。
三、TCP的重傳機制
重傳機制是TCP中最重要和最複雜的問題之一。
TCP每發送一個報文段，就對這個報文段設置一次計時器。只要計時器設置的重傳時間到但還沒有收到確認，就要重傳這一報文段。
由於TCP的下層是一個互連網環境，IP數據報所選擇的路由變化很大。因而傳輸層的往返時延的方差也很大。
往返時延的自適應算法
記錄每一個報文段發出的時間，以及收到相應的確認報文段的時間。這兩個時間之差就是報文段的往返時延。
將各個報文段的往返時延樣本加權平均，就得出報文段的平均往返時延RTT。
每測量到一個新的往返時延樣本，就按下式重新計算一次平均往返時延RTT：
平均往返時延RTT =a*(舊的RTT)+(1-a)*(新的往返時延樣本)
在上式中，0=<a<1。
參數a的選擇
若a很接近於1，表示新算出的平均往返時延RTT和原來的值相比變化不大，而新的往返時延樣本的影響不大(RTT值更新較慢)。
若選擇a接近於零，則表示加權計算的平均往返時延RTT受新的往返時延樣本的影響較大(RTT值更新較快)。
典型的a值爲7/8。
超時重傳時間RTO(Retransmission Time-Out)
計時器的RTO應略大於上面得出的RTT，
即：RTO ＝ b * RTT
這裏b是個大於1的係數。
若取b很接近於1，發送端可及時地重傳丟失的報文段，因此效率得到提高。
但若報文段並未丟失而僅僅是增加了一點時延，那麼過早地重傳反而會加重網絡的負擔。
因此TCP原先的標準推薦將b值取爲2。
往返時間測量的複雜性
TCP報文段1沒有收到確認。重傳（即報文段2）後，收到了確認報文段ACK。
如何判定此確認報文段是對原來的報文段1的確認，還是對重傳的報文段2的確認？
Karn算法
在計算平均往返時延RTT時，TCP不採用重傳報文段的往返時延樣本。
由於避免了二義性的存在，這樣得出的平均往返時延RTT和重傳時間就較準確。
當網絡時延增大時，TCP忽略了重傳對往返時延的影響，會造成反覆重傳。
修正的Karn算法
報文段每重傳一次，就將重傳時間增大一些：
新的重傳時間＝r*(舊的重傳時間)
係數r的典型值是2 。
當不再發生報文段的重傳時，才根據報文段的往返時延更新平均往返時延RTT和重傳時間的數值。
實踐證明，這種策略較爲合理。
四、TCP的傳輸連接管理
TCP是面向連接的協議，提供透明、可靠的數據流傳輸。
傳輸連接有三個階段，即：連接建立、數據傳送和連接釋放。傳輸連接的管理就是使傳輸連接的建立和釋放都能正常地進行。
在TCP的連接建立過程中要解決以下三個問題：
要使每一方能夠確知對方的存在。
要允許雙方協商一些參數（如最大報文段長度，最大窗口大小，服務質量等）。
能夠對傳輸實體資源（如緩存大小，連接表中的項目等）進行分配。
客戶服務器方式
TCP 的連接和建立都是採用客戶服務器方式。
主動發起連接建立的應用進程叫做客戶(client)。
被動等待連接建立的應用進程叫做服務器(server)。
用三次握手建立TCP連接
TCP連接建立
A的TCP向B發出連接請求報文段，其首部中置同步比特SYN =1，並選擇序號x，表明傳送數據時的第一個數據字節的序號是x。
B的TCP收到連接請求報文段後，如同意，則發回確認。B在確認報文段中應置SYN=1，其確認號應爲x＋1，同時也爲自己選擇序號y。
A收到此報文段後，向B給出確認，其確認號應爲 y＋1。
A的TCP通知上層應用進程，連接已經建立。
當運行服務器進程的主機B的TCP收到主機A的確認後，也通知其上層應用進程，連接已經建立。
TCP連接的釋放
在數據傳輸結束後，通信的雙方都可以發出釋放連接的請求。TCP連接釋放採用文雅釋放過程。
TCP連接的釋放是兩個方向分別釋放連接，每個方向上連接的釋放，只終止本方向的數據傳輸。
當一個方向的連接釋放後，TCP的連接就稱爲“半連接”或“半關閉”。當兩個方向的連接都已釋放，TCP連接才完全釋放。
TCP連接釋放的過程
TCP的正常的連接建立和關閉
TCP 有限狀態機。
粗實線表示客戶的正常路徑；
粗虛線表示服務器的正常路徑；細線表示不常見的事件