TCP review --TCP/IP協議

TCP    

    將保持首部和數據的校驗和。出錯重傳。
    將開啓回覆的定時器,超時重傳。
    IP 層非可靠,可能會重複和失序 ,設置數據包的序列值。表示字節個數,32位的無符號的字節數。
    流量控制:緩衝區,滑動窗口機制。窗口大小爲字節數。
    TCP交換8bit 字節構成的 字節流。
    確認序號: 確認已經收到的字節,但不包含確認序號所指的序號。
    TCP最多有60字節的首部。
    TCP應用: Telnet  Rlogin  FTP SMTP

TCP    連接建立:3次握手
    連接終止:4次握手 (TCP爲全雙工,保證 通信雙方都不再收、發數據)
    半關閉: 一端不再發送數據 ,但可以繼續接收數據。
    MSS一般爲 MTU減去 IP首部長度 和TCP首部長度(20+20字節)。系統允許發送的數據長度小於另一端的MSS值
    呼入連接請求隊列:TCP併發實現。服務器接受客戶的連接請求,完成三次握手,將其放入隊列中,直至隊列滿,不再接受連接請求 。應用層從隊列中取出連接請求處理。
    數據捎帶ACK ,不立刻發送確認ACK,而是等待一會,與要發送至對方的數據一起發送過去。

Nagle算法:
    一個TCP連接上最多只能有一個未被確認的未完成的小分組,在該分組確認到達之前不能發送其他的小分組。 (收到一個響應後 ,才能發送下一個分組)。收集多個小的分組一起發送出去。確認到達的越快,數據發送的越快。
    在局域網環境中,時延比較小的時候使用比較合理。
    在廣域網中時延比較大的環境中,會引起延時 。此時關閉Nagle算法比較合理。

滑動窗口協議: 接收方不必確認每一個收到的分組。
    接收方提供的窗口大小通常由接收進程控制,這將影響TCP的性能。
    許多TCP實現在窗口大小增加了兩個最大報文長度或者最大可能窗口的50%時,發送這個窗口的更新。


PUSH 標誌:
    當服務器的TCP接收到一個設置了PUSH標誌的報文段時,它需要立即將這些數據遞交給服務器進程而不能等待判斷是否還會有額外的數據到達。
       
慢啓動算法: slow start
    擁塞窗口 congestion window (cwnd)
    每收到一個ACK,擁塞窗口就增加一個報文段。(慢啓動以報文段大小爲單位進行增加)。發送方去擁塞窗口與通告窗口中的最小值作爲發送上限。
    擁塞窗口是發送方使用的流量控制。通告窗口則是接收方使用的流量控制。

窗口和通道容量:
    通道容量: capacity(bit) = bandwith(b/s)*round-trip time(s)
    窗口大小理論上應該和 通道容量大小相同

擁塞:
    當多個輸入流到達一個路由器,而路由器的輸出流小於這些輸入流的總和時會發生擁塞
    eg:從速度較高的局域網 向 速度較低的廣域網 發送數據時,連接局域網和廣域網的路由器成爲瓶頸。


緊急方式:
    URG比特被置1,並且一個16bit的緊急指針被置爲一個正的偏移量,該偏移量必須與TCP首部中的序號字段相加,以便得出緊急數據的最後一個字節。

超時和重傳: 採用確認實現可靠的運輸。
    超時重傳 ,每次重傳時增加一倍 直至64s .這個倍乘關係被稱爲“指數退避”。
    首次分組傳輸與復位信號傳輸之間的時間差約爲9分鐘。


RTT測量: 在發送一個報文段時,如果給定的定時器已經被使用,則該報文段不被計時。
    1個滴答 500ms

擁塞避免算法:
    假定: 由於分組受到損壞引起的丟失是非常少的。分組丟失就意味着在源主機和目的主機之間發生了擁塞。
    分組丟失指示: 重複確認 ,超時 。
    擁塞窗口:cwnd
    慢啓動門限:ssthresh
    當擁塞發生時,ssthresh被設置爲當前窗口大小的一半;如果是超時引起了擁塞,則cwnd被設置爲一個報文段
    慢啓動算法初始設置cwnd爲1個報文段,此後每收到一個就加1。指數增長。
    擁塞避免算法要求每收到一個確認cwnd就增加1/cwnd. 加性增長。
    ICMP差錯:源站抑制實現 慢啓動算法
    TCP不對ACK報文段進行確認,TCP只確認包含數據的ACK的報文段。

   TCP堅持定時器: 堅持定時器來週期性地向接收方查詢窗口大小。(window probe 窗口探查)

   糊塗窗口避免策略:使TCP避免通告小的窗口大小或發送小的報文段。

   TCP保活定時器
    保活功能主要是爲服務器應用程序提供的 。 服務器應用程序希望知道客戶主機是否崩潰,從而可以代表客戶使用資源 。爲了檢測半開放的連接狀態。
    如果沒有保活定時器,並且也沒有應用層的定時器,則客戶無法知道對端已經崩潰或重新啓動

                                                            參考《TCP/IP協議 卷一》

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章