【百科】TCP的傳輸效率說明與算法

2016-08-27 1704 4 編輯:深色多郎 來源:互聯網技術

應用進程把數據傳送到TCP的發送緩存后,剩下的發送任務就由TCP來控制了。可以用不同的機制來控制TCP報文段的發送時機。例如,第一種機制是TCP維持一個變量,它等于最大報文段長度MSS。只要緩存中存放的數據達到MSS字節時,就組裝成一個TCP報文段發送出去。第二種機制是由發送方的應用進程指明要求發送報文段,即TCP支持的推送(push)操作。第三種機制是發送方的一個計時器期限到了,這時就把當前已有的緩存數據裝入報文段(但長度不能超過MSS)發送出去。

但是,如何控制TCP發送報文段的時機仍然是一個較為復雜的問題。

看官請注意,這是否和深圳網站建設無關,但是這也是網絡的一種知識,學習,無止境,加油吧,孩子!

例如,一個交互式用戶使用一條TELNET連接(運輸層為TCP協議)。假設用戶只發1個字符。加上20字節的首部后,得到21字節長的TCP報文段。再加上20字節的IP首部,形成41字節長的IP數。據報。在接收方TCP立即發出確認,構成的數據報是40字節長(假定沒有數據發送)。若用戶要求遠地主機會送這一字符,則又要發回41字節長的IP數據報和40字節長的確認IP數據報。這樣。用戶僅發1個字符時線路上就需傳送總長度為162字節共4個報文段。當線路寬并不富裕時,這種傳送方法的效率的確不高。因此應適當推遲發回確認報文,并盡量使用捎帶確認的方法。

在TCP的實現中廣泛使用Nagle算法。算法如下:若發送應用進程把要發送的數據逐個字節地送到TCP的發送緩存,則發送方就把第一個數據字節先發送出去,把后面到達的數據字節都緩存起來。當發送方收到第一個數據字符的確認后,再把發送緩存中的所有數據組裝成一個報文段發送出去,同時繼續對隨后到達的數據進行緩存。只有在收到對前一個報文段的確認后才繼續發送下一個報文段。當數據到達較快而網絡速率較慢時,用這樣的方法可明顯地減少所用的網絡帶寬。Nagle算法還規定,當到達的數據已達到發送窗口大小的一半或已達到報文段的最大長度時,就立即發送一個報文段。這樣做,就可以有效地提高網絡的吞吐量。

另一個問題叫做糊涂窗口綜合征(silly window syndrome)[RFC 813],有時也會使TCP的性能變壞。設想一種情況:TCP接收方的緩存已滿,而交互式的應用今晨過一次只從接收緩存中讀取1個字節(這樣就使接收緩存空間僅騰出1個字節),然后想發送方發送確認,并把窗口設置為1個字節(但發送的數據報是40字節長)。接著,發送方又發來1個字節的數據(請注意,發送方發送的IP數據報是41字節長)。接收方發回確認,仍然將窗口設置為1個字節。這樣進行下去,是網絡的效率很低。

本站文章均為深正網站建設摘自權威資料,書籍,或網絡原創文章,如有版權糾紛或者違規問題,請即刻聯系我們刪除,我們歡迎您分享,引用和轉載,但謝絕直接搬磚和抄襲!感謝...
關注深正互聯
七星彩头尾