1.3. tcp成塊資料流
1.4. 參考資料
前一章我們介紹了 tcp 連線的建立與釋放，現在來介紹使用 tcp 進行資料傳輸的有關問題。
一些有關 tcp 通訊量的研究如[caceres et al. 1991]發現，如果按照分組數量計算，約有一半的 tcp 報文段包含成塊資料（如 ftp 、電子郵件和 usenet新聞），另一半則包含互動資料 （如 telnet 和 rlogin ）。如果按位元組計算，則成塊資料與互動資料的比例約為 90% 和 10%。這是 因為成塊資料的報文段基本上都是滿長度（ full-sized ）的（通常為 512 位元組的使用者資料），而互動資料則小得多（上述研究表明 telnet 和 rlogin 分組中通常約 90% 左右的使用者資料小於 10 個位元組）。
什麼是糊塗視窗綜合症（silly window syndrome）
當傳送端應用程序產生資料很慢、或接收端應用程序處理接收緩衝區資料很慢，或二者兼而有之；就會使應用程序間傳送的報文段很小，特別是有效載荷很小。極端情況下，有效載荷可能只有1個位元組；而傳輸開銷有40位元組(20位元組的ip頭+20位元組的tcp頭) 這種現象就叫糊塗視窗綜合症。
造成糊塗視窗症候群的原因
通常tcp在接收到資料時並不立即傳送ack，相反，它推遲傳送，以便將ack與需要沿該方向傳送的資料一起傳送（有時稱這種現象為資料捎帶ack），這樣做的目的是儘量減少發往網路的報文，以提高傳輸的效率，節省網路資源。通過設定 tcp_quickack 來關閉經受時延的確認。tcp_quickack 選項是需要在每次呼叫recv後重新設定的。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-zm4jtsep-1611729036814)(./img/經受時延的ack.png)]
rfc896 [nagle 1984]中所建議的 nagle 演算法，預設是開啟的
該演算法要求乙個 tcp 連線上最多只能有乙個未被確認的未完成的小分組，在該分組的確認到達之前不能傳送其他的小分組。相反， tcp 收集這些少量的分組，並在確認到來時以乙個分組的方式發出去。該演算法的優越之處在於它是自適應的：確認到達得越快，資料也就傳送得越快。而在希望減少微小分組數目的低速廣域網上，則會傳送更少的分組.
插口api使用者可以使用 tcp_nodelay 選項來關閉nagle演算法。 host requirements rfc 宣告 tcp 必須實現 nagle 演算法，但必須為應用提供一種方法來關閉該演算法在某個連線上執行。
這個演算法比nagle演算法更激進一些，乾脆直接計算出乙個值，當傳送方的滑動視窗大小小於這個值的時候，不進行資料報的傳送。這樣這個演算法就能有效直接杜絕小包的出現了。當然可能會導致資料有一定的延遲性了。設定該選項後，核心會盡力把小資料報拼接成乙個大的資料報（乙個mtu）再傳送出去，當然若一定時間後（一般為200ms，該值尚待確認），核心仍然沒有組合成乙個mtu時也必須傳送現有的資料
然而，tcp_cork的實現可能並不像你想象的那麼完美，cork並不會將連線完全塞住。核心其實並不知道應用層到底什麼時候會傳送第二批資料用於和第一批資料拼接以達到mtu的大小，因此核心會給出乙個時間限制，在該時間內沒有拼接成乙個大包（努力接近mtu）的話，核心就會無條件傳送。也就是說若應用層程式傳送小包資料的間隔不夠短時，tcp_cork就沒有一點作用，反而失去了資料的實時性（每個小包資料都會延時一定時間再傳送）。
nagle演算法和cork演算法非常類似，但是它們的著眼點不一樣，nagle演算法主要避免網路因為太多的小包（協議頭的比例非常之大）而擁塞，而cork演算法則是為了提高網路的利用率，使得總體上協議頭占用的比例盡可能的小。如此看來這二者在避免傳送小包上是一致的，在使用者控制的層面上，nagle演算法完全不受使用者socket的控制，你只能簡單的設定tcp_nodelay而禁用它，cork演算法同樣也是通過設定或者清除tcp_cork使能或者禁用之，然而nagle演算法關心的是網路擁塞問題，只要所有的ack回來則發包，而cork演算法卻可以關心內容，在前後資料報傳送間隔很短的前提下（很重要，否則核心會幫你將分散的包發出），即使你是分散傳送多個小資料報，你也可以通過使能cork演算法將這些內容拼接在乙個包內，如果此時用nagle演算法的話，則可能做不到這一點。
下圖用視覺化的方法顯示了我們在前一節觀察到的滑動視窗協議
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-0fv5cdrc-1611729036816)(./img/tcp滑動視窗的視覺化表示.png)]
在這個圖中，我們將位元組從 1 至11 進行標號。接收方通告的視窗稱為提出的視窗（ offered window ），它覆蓋了從第4位元組到第9位元組的區域，表明接收方已經確認了包括第 3 位元組在內的資料，且通告視窗大小為6。我們知道視窗大小是與確認序號相對應的。傳送方計算它的可用視窗，該視窗表明多少資料可以立即被傳送。
當接收方確認資料後，這個滑動視窗不時地向右移動。視窗兩個邊沿的相對運動增加或減少了視窗的大小。
因為視窗的左邊沿受另一端傳送的確認序號的控制，因此不可能向左邊移動。如果接收到乙個指示視窗左邊沿向 左移動的 ack ，則它被認為是乙個重複 ack ， 並被丟棄。
如果左邊沿到達右邊沿，則稱其為乙個零視窗，此時傳送方不能夠傳送任何資料
傳送方不必傳送乙個全視窗大小的資料。
來自接收方的乙個報文段確認資料並把視窗向右邊滑動。這是因為視窗的大小是相對 於確認序號的。
接收方在傳送乙個 ack 前不必等待視窗被填滿
傳送方使用 該標誌通知接收方將所收到的資料全部提交給接收程序。這裡的資料報括與 push 一起傳送的資料以及接收方 tcp 已經為接收程序收到的其他資料。
在最初的 tcp 規範中，一般假定程式設計介面允許傳送程序告訴它的 tcp 何時設定 push 標誌。通過允許客戶應用程式通知其 tcp 設定 push 標誌，客戶程序通知 tcp 在向伺服器傳送乙個報文段時不要因等待額外資料而使已提交資料在快取中滯留。類似地，當伺服器的 tcp 接收到乙個設定了 push 標誌的報文段時，它需要立即將這些資料遞交給伺服器程序而不能等待判斷是否還會有額外的資料到達。
目前大多數的 api 沒有向應用程式提供通知其 tcp 設定 push 標誌的方法。的確， 許多實現程式認為 push 標誌已經過時，乙個好的 tcp 實現能夠自行決定何時設定這個標誌。如果待傳送資料將清空傳送快取，則大多數的源於伯克利的實現能夠自動設定 push 標誌。 這意味著我們能夠觀察到每個應用程式寫的資料均被設定了 push 標誌，因為資料在寫的時候就立即被傳送。
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-knh4drhu-1611729036820)(./img/自動設定push標誌.png)]
tcp視窗大小(bits) = 每秒吞吐量(bits/s) * 時延rtt(秒), 一般稱之為頻寬時延乘積,這個值依賴於網路速度和兩端的 rtt，可以有很大的變動
比如在乙個穩定的區域網，通過通吐量和時間(一般相對穩定)，就可以計算出tcp需要設定的windos視窗。
tcp互動資料流
tcp成塊資料流
TCP 學習筆記3 TCP的互動資料流
所謂互動資料流就是指通過互動產生的一些資料量很小的分組，比如客戶端輸出乙個命令，伺服器會對客戶端傳送乙個ack以及該命令的回顯，客戶端再傳送乙個對回顯命令的確認，如果這樣的分組很多，那麼會降低傳效率。是指tcp在接受到資料時通常不會立即傳送ack，而是會等待一段時間，以便於將ack與需要沿該方向傳送...
網路程式設計學習筆記3 TCP基礎
在網路通訊中，套接字一定是成對出現的，一端的傳送緩衝區對應對端的接收緩衝區，使用的是同乙個檔案描述符。埠號 在網路中的一台主機上，唯一標識乙個程序 socket 乙個檔案描述符指向乙個套接字，該套接字內部由核心借助兩個緩衝區實現 對於udp來說，來標識 對於tcp來說，來標識，畢竟對於tcp來說，每...
TCP的互動資料流
在 tcp進行資料傳輸時 可以分為成塊資料流和互動資料流兩種 且處理的 演算法不同.每乙個互動按鍵都會產生乙個分組,也就是說,每次從客戶傳到伺服器的是乙個位元組的按鍵 而不是每次一行 報文段2可以和報文段3進行合併 按鍵確認和按鍵回顯一起傳送 按鍵確認和按鍵回顯兩個報文段合併在一起傳送，這種技術叫做...