tcp 的資料流
tcp的資料流大致可以分為兩類，互動資料流與成塊的資料流。互動資料流就是傳送控制命令的資料流，比如relogin，telnet，ftp命令等等；成塊資料流是用來傳送資料的包，網路上大部分的tcp包都是這種包。
很明顯，tcp在傳輸這兩種型別的包時的效率是不一樣的，因此為了提高tcp的傳輸效率，應該對這兩種型別的包採用不同的演算法。
總之，tcp的傳輸原則是儘量減少小分組傳輸的數量。
tcp的互動式資料流
ø經受時延的確認技術
tcp的互動式資料流通常使用「經過時延的確認」技術。通常server在接收到從client傳送過來的資料時，並不馬上傳送ack，而是等一小段時間，看看本機是否有資料要反饋給client，如果有，就將資料報含在此ack包中，以前傳送給client。一般情況下這個時延為200ms。需要注意的時這個 200ms的定時器時相對於核心的時鐘滴答的，也就是jeffs的。加入乙個資料分組到達後，此定時器已經pass了100ms，那麼再過100ms ack才會被傳送，如果在這100ms內有資料要反饋，則在100ms後ack會和資料一起傳送。
ønagle演算法分析。
nagle演算法主要用來預防小分組的產生。在廣域網上，大量tcp小分組極有可能造成網路的擁塞。
nagle時針對每乙個tcp連線的。它要求乙個tcp連線上最多只能有乙個未被確認的小分組。在改分組的確認到達之前不能傳送其他小分組。tcp會蒐集這些小的分組，然後在之前小分組的確認到達後將剛才蒐集的小分組合併傳送出去。
有時候我們必須要關閉nagle演算法，特別是在一些對時延要求較高的互動式操作環境中，所有的小分組必須盡快傳送出去。
我們可以通過程式設計取消nagle演算法，利用tcp_nodelay選項來關閉nagle演算法。
tcp成塊資料流
和tcp成塊資料流相關的東西有很多，比如流量控制，緊急資料傳輸，資料視窗大小調整等等。
ø正常資料流
tcp通常不會對每個到達的資料分段進行確認操作，通常乙個ack報文可以確認多個成塊資料段報文，通常情況下是兩個成塊資料報文段需要乙個ack報文確認。通常是由下面的原有造成的：當收到乙個報文後，此tcp連線被標識未乙個未完成的時延確認，當再次收到乙個資料報文後，此連線有兩個未確認的報文段，tcp馬上傳送乙個ack，當第三個資料報文到達後，第四個報文到達前，通常此tcp連線已經經過了200ms延時，因此乙個ack被傳送，這樣的迴圈周而復始，從而出現了乙個ack 確認兩個資料報文的情況。當然，ack的產生很大程度上和其接收資料報文段的時間緊密相關，也就是和client段傳送資料的頻率相關，和網路擁塞程度相關，和client與server兩端的處理能力相關，總是是乙個多因素決定的結果。
øtcp的滑動視窗協議
tcp使用滑動視窗協議來進行流量控制。特別需要注意的是，滑動視窗是乙個抽象的概念，它是針對每乙個tcp連線的，而且是有方向的，乙個tcp連線應該有兩個滑動視窗，每個資料傳輸方向上有乙個，而不是針對連線的每一端的。
視窗左邊沿向右邊滑動叫做視窗合攏，表示傳送方傳送了資料或者接收到了確認；視窗右邊沿向右邊滑動叫做視窗的張開，表示資料已經被使用者空間程序接收並且釋放了快取；視窗左邊沿向左移動則表明此ack是重複ack，應該丟棄；視窗右邊沿向左移動叫做視窗收縮，一般不會有人這樣做。
當左邊沿和右邊沿重合的時候表明視窗大小是0，此時傳送方不應該在傳送資料了，因為接收方的接收緩衝區已滿，使用者程序還沒以接收。當使用者程序接收完成後，接收方應該傳送乙個ack，表明此時的接收視窗已經恢復，此ack的序號同前乙個win為0的ack相同。
同樣，在實現中，傳送方不必傳送乙個全視窗的資料，但是它當然可以這樣做。ack總是將視窗向右邊滑動，視窗的大小可以減小，接收方在傳送ack之前不必等待視窗被填滿（即變為0），很多實現是收到兩個資料報文段後立刻傳送ack。
øtcp視窗大小的調整
tcp視窗的大小通常由接收端來確認，也就是在tcp建立連線的第二個syn+ack報文的win欄位來確認。
當然，程式可以隨時改變這個視窗（快取）的大小。預設的視窗大小是4096位元組，但是對於檔案傳輸來說這並不是乙個理想的數字，如果程式的主要目的是傳輸檔案，那麼最好將這個快取設定到最大，但是這樣可能會造成傳送端連續傳送多個資料報文段後，接收方才反饋乙個ack的情況，當然，這也沒有什麼不可以的，只要不超時，就不算錯。
øtcp的push包
push是tcp報頭中的乙個標誌位，傳送方在傳送資料的時候可以設定這個標誌位。該標誌通知接收方將接收到的資料全部提交給接收程序。這裡所說的資料報括與此push包一起傳輸的資料以及之前就為該程序傳輸過來的資料。
當server端收到這些資料後，它需要立刻將這些資料提交給應用層程序，而不再等待是否還有額外的資料到達。
那麼應該合適設定push標誌呢？實際上現在的tcp協議棧基本上都可以自行處理這個問題，而不是交給應用層處理。如果待傳送的資料會清空傳送快取，那麼棧就會自動為此包設定push標誌，源於bsd的棧一般都會這麼做，而且，bsd tcp stack也從來不會將收到的資料推遲提交給應用程式，因此，在bsd tcp stack中，push位是被忽略的，因為根本就沒有用。
øtcp的慢啟動（擁塞視窗）
tcp在區域網環境中的效率是很高的，但是到了廣域網的環境中情況就不同了，在傳送方和接收方之間可能存在多個router以及一些速率比較慢的鏈路，而且一些中繼路由器必須快取分組，還可能分片，所以在廣域網的環境中，tcp的效率可能出現問題。
為了解決這個問題，現在的tcp棧都支援「慢啟動」演算法，即擁塞視窗控制演算法。該演算法通過觀察到新分組進入網路的速率與另一端返回ack的速率相同而工作。其實，擁塞視窗是傳送方使用的一種流量控制演算法。
慢啟動為tcp的傳送方增加了乙個擁塞視窗，當連線建立時，擁塞視窗被初始化為乙個報文段大小，每收到乙個ack，擁塞視窗就會增加乙個報文段，傳送方取擁塞視窗與通過視窗的最小值作為傳送的上限。
øtcp成塊資料吞吐量
tcp視窗大小，視窗流量控制，慢啟動對tcp的成塊資料傳輸綜合作用，可能對tcp的資料傳輸有意想不到的影響。
rtt（round-trip time） ：往返時間。是指乙個報文段從發出去到收到此報文段的ack所經歷的時間。通常乙個報文段的rtt與傳播時延和傳送時延兩個因素相關。
在傳送的過程中有可能發生這樣的情況，即tcp兩端的傳輸「管道」被填滿，即整個管道上都有資料在跑，此時不管擁塞視窗和通告視窗是多少，管道上都不能在容納更多的資料了。此時每當接收方從網路上移去乙個報文段，傳送方就傳送乙個，但是管道上的ack總是固定的，這種情況就是連線的理想穩定狀態。
一般情況下頻寬*時延就是一條線路的容量，因此吧rtt減小可以增加一條線路的容量，注意rtt加大的意思時傳輸時間減小！
當資料由乙個大的管道向乙個小的管道傳輸時，就有可能發生擁塞，例如，當若干輸入流到達乙個路由器，而此路由器的輸出頻寬小於這些輸入流的頻寬總和時，就會發生擁塞。這種情況普遍見於區域網與廣域網的介面處。如果傳送方處於區域網，而且不使用慢啟動，使用區域網的頻寬盡快的傳送報文，那麼返回的ack之間的間隔與最慢的廣域網鏈路一致。而且，由於路由器**包速度慢，所以路由器就有可能主動丟失分組包。
øtcp的緊急方式
tcp提供了一種「緊急方式」的資料傳輸方式，tcp的一端可以告訴另一端有些具有某種方式的緊急資料被放在了普通的資料流中，接收方可以自行選擇處理。緊急方式客廳通過設定tcp的urg標識位與緊急指標的偏移量來設定。這個緊急指標指向緊急資料的最後乙個位元組（也有可能是最後乙個位元組的下乙個位元組）。
現在有許多實現將緊急方式叫做「帶外資料」，其實這是不正確的。
目前緊急指標被用來禁止停止ftp的資料傳輸。不過總的來說，用的不多。
對於資料傳輸來說，如果用緊急資料來傳輸大量資料，這種方法顯然是不可取的，再建立乙個tcp連線不是更簡單有效嗎？
重讀TCP 協議
拖延症晚期患者，終於在週末的尾巴開始寫這篇本來上週就應該總結出來的文章了 大部分介紹 tcp 協議的開頭都是，tcp 協議是一種面向連線的 可靠的 基於位元組流的傳輸層協議。講真的就是這麼單純的記住這個概念，在實踐中並沒有什麼具體用處，畢竟工作和考試不一樣 為了更深刻的理解這個協議，讓我們先拆解下概...
TCP IP協議 TCP協議
今天算是對了tcp協議有個膚淺的理解了 儘管tcp和udp都是一樣的網路層ip，但是tcp卻和udp實現著不一樣的服務，tcp是乙個面向連線的，可靠地位元組流服務！面向連線是指 兩個使用tcp的程式要建立乙個tcp連線才能交換資料。tcp以以下方式提供可靠性 1 應用程式被分為tcp認為合適傳送的資...
TCP協議 UDP協議
tcp是面向連線的傳輸層的協議，它在程序互動時，會建立乙個鏈結，然後在傳輸資料之後會取消連線，tcp的鏈結是虛連線。每一條tcp連線只能有兩個端點，只能是點對點的資料鏈結，不能進行廣播。tcp提供可靠的按時交付的 無差錯的 不重複的 按序到達的服務 可靠有序 不丟不重 tcp提供全雙工通訊 傳送快取...