TCP是一種流協議（stream protocol）。這就意味著資料是以位元組流的形式傳遞給接收者的，沒有固有的"報文"或"報文邊界"的概念。從這方面來說，讀取TCP資料就像從串列埠讀取資料一樣--無法預先得知在一次指定的讀呼叫中會返回多少位元組。

為了說明這一點，我們假設在主機A和主機B的應用程式之間有一條TCP連線，主機A上的應用程式向主機B傳送一條報文。進一步假設主機A有兩條報文要傳送，並兩次呼叫send來發送，每條報文呼叫一次。很自然就會想到從主機A向主機B傳送的兩條報文是作為兩個獨立實體，在各自的分組中傳送的，如圖2-25所示。

圖2-25　傳送兩條報文的錯誤模型

圖2-26　封裝兩條報文可能採用的4種方式

現在，我們從主機B應用程式的角度來看這種情形。總的來說，主機B應用程式任意一次呼叫recv時，都不會對TCP傳送給它的資料量做任何假設。比如，當主機B應用程式讀取第一條報文時，可能會出現下列4種結果。

實際上，可能的結果不止4種，但我們忽略了出錯和EOF之類的結果。我們還假設應用程式讀取了所有可讀的資料。

（1）沒有資料可讀，應用程式阻塞，或者recv返回一條指示說明沒有資料可讀。到底會發生什麼情況取決於套接字是否標識為阻塞，以及主機B的作業系統為系統呼叫recv指定了什麼樣的語義。

（2）應用程式獲取了報文M1中的部分而不是全部資料。比如，傳送端TCP像圖2-26D那樣對資料進行分組就會發生這種情況。

（3）應用程式獲取了報文M1中所有的資料，除此之外沒有任何其他內容。如果像圖2-26A那樣對資料分組就會發生這種情況。

（4）應用程式獲取了報文M1的所有資料，以及報文M2的部分或全部資料。如果像圖2-26B或圖2-26C那樣對資料進行分組就會發生這種情況。

注意，這裡還有一個定時問題。如果主機B的應用程式在主機A傳送了第二條報文之後一段時間內都沒有讀取第一條報文，那麼這兩條報文都會成為可讀的。這就和圖2-26B所示情況相同了。這些描述說明，通常，在任意指定時刻，可讀的資料量都是不確定的。

需要再次說明的是，TCP是一個流協議（stream protocol），儘管資料是以IP分組的形式傳輸的，但分組中的資料量與send呼叫中傳送給TCP多少資料並沒有直接關係。而且，接收程式也沒有什麼可靠的方法可以判斷資料是如何分組的，因為在兩次recv呼叫之間可能會有多個分組到來。

即使接收端應用程式的響應非常及時，也可能會發生這種情況。例如，一個分組丟失了（參見技巧12，在當今的因特網中，這是非常常見的情況），而且後繼分組都安全到達，TCP會將後繼分組中的資料儲存起來，直到重傳第一個分組並正確收到為止。此時，所有資料對應用程式都是可用的。

TCP會記錄它傳送了多少位元組，以及確認的位元組，但它不會記錄這些位元組是如何分組的。實際上，有些實現在重傳丟失分組的時候傳送的資料可能比原來的多一些或少一些。這就足以支撐下面再次重複說明的內容了。

對TCP應用程式來說，就沒有"分組"這種概念。如果應用程式的設計與TCP對資料的分組方式有所關聯，就應該考慮重新設計這個應用程式了。

既然任意一次指定的讀操作中返回的資料量都是不可預測的，就必須在應用程式中做好應對這種情況的準備。通常這不是什麼問題。比如說，我們可能在用fgets這樣標準的I/O庫程式讀取資料。在這種情況下，fgets會將位元組流劃分成行。圖3-6顯示了一個這樣的例子。在其他情況下的確需要關注報文邊界問題，而這些情況下邊界都是由應用程式級維護的。

最簡單的情況就是定長報文。在這種情況下，只需要讀取報文中固定數量的位元組就可以了。根據前面的討論，讀操作返回的位元組數可能小於sizeof(msg)（圖2-26D），所以只進行

recv(s, msg, sizeof(msg), 0); 

int readn(SOCKET fd, char *buf, size_t len)
{
     int cnt = len;
     int recvlen;
     recvlen = recv(fd, buf, cnt, 0)
     if(recvlen < 0)
     {

        /* EINTR: function was interrupted by a signal that was caught, before any data was available */
            if(errno == EINTR)
                  continue;
             return -1;
      }
      /* EOF */
      if(recvlen == 0)
         return len - cnt;
     
      buf += recvlen;
      cnt -=  recvlen;
   }
   return len;
}     

TCP是流協議，不區分流邊界，如果不分幀，那麼可能會發生你send了無數次，但是對方只接收一次的情況

client 傳送位元組流時，TCP會保證server 按順序接收到全部的位元組流，其他諸如資料包的大小等，TCP協議對我們來說是透明的，我們可以全部不考慮。

    通俗點說，我們傳送資料只需要呼叫send函式，我們只需要關注send函式的返回值，從而知道了傳送了多少個位元組，在服務端，我們呼叫recv函式，我們只需要關注recv函式的返回值，從而知道接收了多少個位元組，其他情況通通不管。

   在TCP通訊過程中，我們不需要關心（也沒法關心，但可以設定）資料包的大小，個數，我們只需要在客戶端建立一個緩衝區不斷髮送，在服務端建立一個緩衝區不斷接收就夠了，當然，我們還可以定義一個包頭，來實現諸如傳送檔案這樣更強大的功能。

這就是TCP通訊的本質，不會應平臺的不同而改變。