1.TCP:傳輸控制協議---< >

1.TCP:傳輸控制協議

1.1引言

IP和UDP協議,沒有實現差錯糾正;對於以太網和基於其上的其餘協議,協議都提供了必定次數的重試,若是仍是不成功則放棄. 通訊媒介可能會丟失或則改變傳遞的消息,出現了通訊的問題.這個課題的最重要的理論研究者是勞德.香農,在1948年給出[S48]

通訊差錯問題的解決:

• 使用差錯校驗碼(添加一些冗餘的比特,即便比特丟失丟失,真實的信息也能夠被恢復出來)
• 自動重複請求(Automatic Repeat Request,ARQ),包含了TCP協議

1.1.1 ARQ和重傳

處理分組丟失(比特差錯)的方法是重發分組直到他被正確的接受.判斷方法?

1. 接收方是否已經收到分組
2. 接收方接收到的分組是否與執以前發送方的同樣

ACK(acknowledge)

• 發送方發送一個分組,而後等待一個ACK.當接收方接收到這個分組時,它發送對應的ACK,整個過程就這樣繼續.

ACK出現的問題:

1. 對一個請求ACK應該等待多久?
2. 若是ACK丟失了怎麼辦?
3. 若是分組被接受到了,可是裏面有錯怎麼辦?

ACK出現的問解決:

• 問題1:後面討論
• 問題2:再次發送原分組
• 問題3:通常使用校驗和與CRC,當接收方接受到一個含有差錯的分組,它不發送ACK.最後,發送方重發完整分組到無差錯的分組.

接收方接收到重複分組的解決辦法

使用序列號,發送方爲每一個分組分配序列號,由分組自身攜帶着.接收方使用這個序列號碼來判斷是否已經見過這個分組,若是見過則丟棄.

1.1.2 分組窗口和滑動窗口

• 存在於發送方和接收方,窗口結構便於記錄在發送方和接收方數據的流動
• 發送方窗口:記錄哪些分組能夠釋放,哪些分組能夠被釋放,哪些分組正在正在等待ACK,以及哪些分組不能被髮送.
• 接收方窗口:記錄着哪些分組已經被接受和確認,哪些分組是下一步指望的(和已經分配多少內存來他們),以及哪分組即便被接受也將會由於內存限制而被丟棄.
• window size(窗口大小):分組窗口中的分組數量(window)
• window(分組窗口):發送方注入但尚未完成確認的分組集合

1.1.3 變量窗口:流量控制和擁塞控制

流量控制(flow control):處理當接收方相對發送方太慢產生的問題,在接收方跟不上的時候會強迫發送方慢下來.

flow control的操做方法

1. rate_based(速率)流量控制:給發送方指定某個速率,同時確保數據永遠不能超過這個速率.這種類型的流量控制最適合流應用程序,可被用於廣播和組播發現.
2. window-based(基於窗口)流量控制,是使用滑動窗口時最流行的方法.窗口大小不是固定的,是隨時間而變更的.必須使用window advertisement或則簡單地稱爲window update(窗口更新)---讓接收方能夠通知發送方使用多大的窗口

流量控制原理

修改發送方的窗口大小:分組沒有收到任何一個ACK以前,發送方注入W個分組到網絡,若是發送方和接收方足夠快,網絡沒有丟失一個分組以及有無窮的空間的話,這就意味着通訊正比於(SW/R)b/s,這裏W是窗口大小,S是分組大小(比特單位計算),R是往返時間.當來自接收方的窗口夾帶着發送方的值W時,那麼發送方的所有速率就被限制而不能超越接收方.這種方法能夠很好的保護接收方.可是對於中間的網絡呢?在接收方和發送方可能會有有限內存的路由器,他們與低速網絡鏈路抗爭着,這種狀況出現了,發送方的速率可能超過某個路由器的能力,從而致使丟包.這種狀況由 congestion control(擁塞控制)的流量控制形式來處理.

congestion control(擁塞控制)

擁塞控制涉及發送方以及減速以不低於壓垮其與接收方之間的網絡.使用一個窗口通告來告訴發送方爲接收方減速.

1.1.4 設置重傳超時

重傳超時應該是多大?

round-trip-time estimation(往返時間估計),這是一個統計過程.總的來講,選擇一組RTT樣本的平均值做爲真實的RTT是最有可能的.這個RTT值是動態的.

1.2 TCP的引入

1.2.1 TCP服務模型

TCP提供了一種connection-oriented(面向鏈接),可靠的字節流服務.

• 面向鏈接:TCP的兩個應用程序之間必須在他們可交換數據以前,經過聯繫來創建一個TCP鏈接.例如,打電話,等待另一方接聽電話並說"喂",而後再說"找誰?".這正是TCP鏈接的兩個端點在相互通訊.
• 字節流服務:抽象概念給應用程序使用,一端給TCP字節流,一樣的字節流會出現另一端.每一個端點獨立選擇本身的讀和寫大小.TCP不會解讀字節流裏的字節內容,他不知道正在交換的數據字節是否是二進制數據,ASCII字符,EBCDIC字符或做其餘東西.對於這個字節流的解讀取決於鏈接中的每一個端點的應用程序.

1.2.2 TCP中的可靠性

可靠性:

• 提供了一個字節流接口,TCP必須把一個發送應用程序的字節流轉換成一組IP能夠攜帶的分組,稱爲組包(packetization).分組包含序列號,在TCP中表明瞭每一個分組第一個字節在整個數據流中的字節偏移,而非分組號.這容許分組在傳送中是可變的大小的,而且容許他們組合,稱爲從新組包(repacketization).應用程序數據被打散成TCP認爲最佳大小的快來發送,每一個報文段大小與分片的單個IP數據報大小不一樣.TCP傳給IP的塊稱爲報文段(segment)
• TCP維持了強制的校驗和:校驗和涉及他的頭部,任何相關程序數據和IP頭部的全部字段.這是一個端到端的僞頭部,用於檢測傳送中引入的比特差錯.
• 重傳計時器:當TCP發送一組報文段時,他一般設置一個重傳計時器,等待對方的確認接收.當ACK到達時再更新超時.若是一個ACK沒有及時接收到,這個報文段就會被重傳.
• ACK:當TCP接收到鏈接的另外一端的數據時,他會發送一個確認.
• TCP給應用程序提供了雙工服務:數據能夠同時往兩個方向流動,兩個方向相互獨立.所以,鏈接的每一個端點必須對每一個方向的維持數據流的一個序列號.
• 使用序列號:一個TCP接收端可丟棄重複的報文段和記錄以及雜亂無序的報文段

1.3 TCP頭部和封裝

每一個TCP頭部包含了源和目的的端口號碼.這兩個值與IP頭部中的源和目的地IP地址一塊兒,惟一性地標識了每一個鏈接.在TCP術語中,一個IP地址和一個端口的組合被稱爲一個端點(endpoint)或則套接字(socket).每一個TCP鏈接都有一對套接字或端點(四元組,由客戶機IP地址,客戶機端口號,服務器IP地址以及服務器端口組成惟一標識)

• 序列號(Sequence Number)字段標識了TCP發送端到TCP接收端的數據流的一個字節,該字節表明着包含該序列號的報文段的第一個字節.範圍0-2^32-1,每一個被交換的字節都已經被編號,確認號字段(ACK號/ACK字段)包含的值是該確認號的發送方期待的接受的下一個序列號.即最後被成功接收的數據字節的序列號加1.在ack字段被啓用有效.

SYN字段:創建新鏈接時,從客戶機發送服務器的第一個報文段的SYN位字段被啓用.這樣的報文段稱爲SYN報文段.序列號包含了本次鏈接的這個方向上要使用的第一個序列號.常常是一個隨機數(Initial Sequence Number,ISN)

• CWR（Congestion Window Reduce）---擁塞窗口減少標識(發送下降它的發送速率),收到了設置ECE標識的包,減少發送窗口大小來下降發送的速率
• ECE(ECN Echo)---ECN回顯(發送方接收到了一個更早的擁塞通知),三次握手的時候代表TCP端是具有ECN功能的,在數據傳輸的時候標識收到的TCP包的IP頭部ECN被設置成11,即網絡擁堵
• URG(Urgent)---緊急(緊急指針字段有效--不多使用),標識報文段發送的數據是否包含緊急數據,URG=1標識有緊急數據,這時的緊急指針字段纔有效果
• ACK---確認(確認字段有效--鏈接創建之後通常是啓用狀態),ACK=1時,確認的字段纔有效,TCP規定,創建鏈接後ACK必須是1
• PSH(PUSH)---推送(接收方應儘快給應用程序傳送這個數據---沒被可靠地實現或用到),PSH=1表示,應該立馬把數據推送給應用程序,而不是緩存起來
• RST---重置鏈接(鏈接取消,常常是錯誤),RST=1表示TCP出現了嚴重錯誤(主機崩了),必須釋放鏈接,從新創建鏈接
• SYN---用於初始化一個鏈接的同步序列號,SYN=1,ACK=0表示這是一個創建鏈接的報文段,當SYN=1,ACK=1表示雙方贊成創建鏈接.SYN=1,只能表示這是一個創建鏈接或則贊成創建鏈接的報文.只有在前兩次握手中SYN纔是1
• FIN---標記數據是否發送完成.若是FIN=1,表示數據發送完成,能夠釋放鏈接
• TCP校驗和字段覆蓋了TCP的頭部和數據以及頭部中的一些字段.
• 緊急指針(Urgent Pointer)字段只有在URG爲字段被設置時纔有效.這個指針是一個必需要加到報文段的序列號字段上的正偏移,以產生緊急數據的最後一個字節的序列號.TCP的緊急機制是發送方給另一端提供特殊標識數據的方法,

2.TCP 鏈接管理

3.TCP 超時與重傳

4.TCP 數據流與窗口管理

5.TCP 擁塞控制

6.TCP 保活機制