[本文轉載來源為：http://www.tongyi.net/article/20020424/200204243275.shtml]
在前一篇文章裡，我們討論了以下問題︰如何採用sendfile()系統函數降低從磁片到網路的數據傳輸負載。接下來我們繼續討論涉及網路連接控制的另一問題，同時希望透過對這一問題的討論能有助於在實際環境下把sendfile()的功能最大化，這就是如何設定TCP/IP選項來控制套接字的行為。
TCP/IP數據傳輸
TCP/IP網路的數據傳輸通常建立在數據塊的基礎之上。從程式員的觀點來看，發送數據意味著發出（或者提交）一系列“發送數據塊”的請求。在系統級，發送單個數據塊可以透過調用系統函數write() 或者sendfile() 來完成。在網路級可以看到更多的數據塊，通常把它們叫做幀，幀再被包裝上一定位元組長度的報頭然後透過線路在網路上傳輸。幀及其報頭內部的訊息是由若干協議層定義的，從OSI參考模型的物理層到應用層都可能會牽扯到。
因為在網路連接中是由程式員來選擇最適當的應用協議，所以網路包的長度和順序都在程式員的控制之下。同樣的，程式員還必須選擇這個協議在軟體中得以實現的模式。TCP/IP協議自身已經有了多種可互操作的實現，所以在雙方通信時，每一方都有它自身的低級行為，這也是程式員所應該知道的情況。
通常情況下，程式員不必關心作業系統和網路協議棧發送和接收網路數據的方法。系統內置算法定義了低級的數據組織和傳輸模式；然而，影響這些算法的行為以及對網路連接施加更大強度控制能力的方法也是有的。例如，如果某個應用協議使用了超時和重發機製，程式員就可以採取一定措施設定或者獲取超時參數。他或她還可能需要增加發送和接收緩沖區的大小來保證網路上的訊息流動不會中斷。改變TCP/IP協議棧行為的一般的方法是採用所謂的TCP/IP選項。下面就讓我們來看一看你該如何使用這些選項來優化數據傳輸。
TCP/IP選項
有好幾種選項都能改變TCP/IP協議棧的行為。使用這些選擇能對在同一計算機上營運的其他應用程式產生不利的影響，因此普通用戶通常是不能使用這些選項的（除了root用戶以外）。我們在這裡主要討論能改變單個連接操作（用TCP/IP的術語來說就是套接字）的選項。
ioctl風格的getsockopt()和setsockopt()系統函數都提供了控制套接字行為的模式。比方說，為了在Linux上設定TCP_NODELAY選項，你可以如下編寫代碼︰
intfd, on = 1;
…
/* 此處是創建套接字等操作，出於篇幅的考慮省略*/
…
setsockopt (fd, SOL_TCP, TCP_NODELAY, &on, sizeof (on));
儘管有許多TCP選項可供程式員操作，而我們卻最關注如何處置其中的兩個選項，它們是TCP_NODELAY 和 TCP_CORK，這兩個選項都對網路連接的行為具有重要的作用。許多UNIX系統都實現了TCP_NODELAY選項，但是，TCP_CORK則是Linux系統所獨有的而且相對較新；它首先在內核版本2.4上得以實現。此外，其他UNIX系統版本也有功能類似的選項，值得注意的是，在某種由BSD派生的系統上的TCP_NOPUSH選項其實就是TCP_CORK的一部分具體實現。
TCP_NODELAY和TCP_CORK基本上控制了包的“Nagle化”，Nagle化在這裡的含義是採用Nagle算法把較小的包組裝為更大的幀。John Nagle是Nagle算法的發明人，後者就是用他的名字來命名的，他在1984年首次用這種方法來嘗試解決福特汽車公司的網路擁塞問題（欲了解詳情請參看IETF RFC 896）。他解決的問題就是所謂的silly window syndrome ，中文稱“愚蠢視窗症候群”，具體含義是，因為普遍終端應用程式每產生一次擊鍵操作就會發送一個包，而典型情況下一個包會擁有一個位元組的數據載荷以及40個位元組長的包頭，於是產生4000%的過載，很輕易地就能令網路發生擁塞,。 Nagle化後來成了一種標準並且立即在網際網路上得以實現。它現下已經成為缺省配置了，但在我們看來，有些場合下把這一選項關掉也是合乎需要的。
現下讓我們假設某個應用程式發出了一個請求，希望發送小塊數據。我們可以選擇立即發送數據或者等待產生更多的數據然後再一次發送兩種策略。如果我們馬上發送數據，那麼交互性的以及客戶/伺服器型的應用程式將極大地受益。例如，當我們正在發送一個較短的請求並且等候較大的附應時，相關過載與傳輸的數據總量相比就會比較低，而且，如果請求立即發出那麼附應時間也會快一些。以上操作可以透過設定套接字的TCP_NODELAY選項來完成，這樣就禁用了Nagle算法。
另外一種情況則需要我們等到數據量達到最大時才透過網路一次發送全部數據，這種數據傳輸模式有益於大量數據的通信性能，典型的應用就是檔案伺服器。應用Nagle算法在這種情況下就會產生問題。但是，如果你正在發送大量數據，你可以設定TCP_CORK選項禁用Nagle化，其模式正好同TCP_NODELAY相反（TCP_CORK 和 TCP_NODELAY 是互相排斥的）。下面就讓我們仔細分析下其工作原理。
假設應用程式使用sendfile()函數來轉移大量數據。應用協議通常要求發送某些訊息來預先解釋數據，這些訊息其實就是報頭內容。典型情況下報頭很小，而且套接字上設定了TCP_NODELAY。有報頭的包將被立即傳輸，在某些情況下（取決於內部的包計數器），因為這個包成功地被對方收到後需要請求對方確認。這樣，大量數據的傳輸就會被延遲而且產生了不必要的網路流量交換。
但是，如果我們在套接字上設定了TCP_CORK（可以比喻為在管道上插入“塞子”）選項，具有報頭的包就會填補大量的數據，所有的數據都根據大小自動地透過包傳輸出去。當數據傳輸完成時，最好取消TCP_CORK 選項設定給連接“拔去塞子”以便任一部分的幀都能發送出去。這同“塞住”網路連接同等重要。
總而言之，如果你肯定能一起發送多個數據集合（例如HTTP附應的頭和正文），那麼我們建議你設定TCP_CORK選項，這樣在這些數據之間不存在延遲。能極大地有益於WWW、FTP以及檔案伺服器的性能，同時也簡化了你的工作。示例代碼如下︰
intfd, on = 1;
…
/* 此處是創建套接字等操作，出於篇幅的考慮省略*/
…
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* cork */
write (fd, …);
fprintf (fd, …);
sendfile (fd, …);
write (fd, …);
sendfile (fd, …);
…
on = 0;
setsockopt (fd, SOL_TCP, TCP_CORK, &on, sizeof (on)); /* 拔去塞子 */
不幸的是，許多常用的程式並沒有考慮到以上問題。例如，Eric Allman編寫的sendmail就沒有對其套接字設定任何選項。
Apache HTTPD是網際網路上最流行的Web伺服器，它的所有套接字就都設定了TCP_NODELAY選項，而且其性能也深受大多數用戶的滿意。這是為什麼呢？答案就在於實現的差別之上。由BSD衍生的TCP/IP協議棧（值得注意的是FreeBSD）在這種狀況下的操作就不同。當在TCP_NODELAY 模式下提交大量小數據塊傳輸時，大量訊息將按照一次write()函數調用發送一塊數據的模式發送出去。然而，因為負責請求交付確認的記數器是面向位元組而非面向包（在Linux上）的，所以引入延遲的機率就降低了很多。結果僅僅和全部數據的大小有關係。而 Linux 在第一包到達之後就要求確認，FreeBSD則在進行如此操作之前會等待好幾百個包。
在Linux系統上，TCP_NODELAY的效果同習慣於BSD TCP/IP協議棧的開發者所期望的效果有很大不同，而且在Linux上的Apache性能表現也會更差些。其他在Linux上頻繁採用TCP_NODELAY的應用程式也有同樣的問題。
相得益彰
你的數據傳輸並不需要總是準確地遵守某一選項或者其它選擇。在那種情況下，你可能想要採取更為靈活的措施來控制網路連接︰在發送一系列當作單一消息的數據之前設定TCP_CORK，而且在發送應立即發出的短消息之前設定TCP_NODELAY。
把零拷貝和sendfile() 系統函數結合起來（前文有述）可以顯著地提升系統整體效率並且降低CPU負載。我們採用這一技術為Swsoft’s Virtuozzo公司開發了基於名稱的主機托管子系統，實踐經驗表明，該技術可以在裝備350-MHz Pentium II CPU的PC上實現每秒9000個HTTP請求，這一成績在以前幾乎是不可能實現的。性能上的提升顯而易見。
2007年6月25日 星期一
2007年1月18日 星期四
[轉] TCP粘包問題
粘包問題︰
一、TCP協議簡介
TCP是一個面向連接的傳輸層協議，雖然TCP不屬于ISO製定的協議集，但由於其在商業界和工業界的成功應用，它已成為事實上的網路標準，廣泛應用于各種網路主機間的通信。 作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證訊息有序無誤的傳輸。它除了提供基本的數據傳輸功能外，還為保證可靠性採用了數據編號、校驗和計算、數據確認等一系列措施。它對傳送的每個數據位元組都進行編號，並請求接收方回傳確認訊息（ACK）。發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。數據編號使接收方能夠處理數據的失序和重複問題。數據誤碼問題透過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，並要求發送方重傳。流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網路擁塞惡性循環。TCP採用可變窗口進行流量控制，由接收方控制發送方發送的數據量。 TCP為用戶提供了高可靠性的網路傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才採用TCP，而普通數據的傳輸一般採用高效率的UDP。
二、粘包問題分析與對策
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。 出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。發送方引起的粘包是由TCP協議本身造成的，TCP為提升傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。接收方引起的粘包是由於接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據（圖1所示）。 粘包情況有兩種，一種是粘在一起的包都是完整的數據包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設用戶接收緩沖區長度為m個位元組。 不是所有的粘包現象都需要處理，若傳輸的數據為不帶架構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶架構的數據，這時就需要做分包處理。 在處理定長架構數據的粘包問題時，分包算法比較簡單；在處理不定長架構數據的粘包問題時，分包算法就比較複雜。特別是如圖3所示的粘包情況，由於一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。 為了避免粘包現象，可採取以下幾種措施。一是對于發送方引起的粘包現象，用戶可透過編程設置來避免，TCP提供了強製數據立即傳送的操作指令push，TCP軟體收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；二是對于接收方引起的粘包，則可透過優化程式設計、精簡接收進程工作量、提升接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；三是由接收方控制，將一包數據按架構字段，人為控制分多次接收，然後合併，透過這種手段來避免粘包。 以上提到的三種措施，都有其不足之處。第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網路發送效率，影附應用程式的性能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當發送頻率較高時，或由於網路突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程式的效率較低，對實時應用的場合不適合。 一種比較周全的對策是︰接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。對這種方法我們進行了實驗，證明是高效可行的。
三、編程與實現
1．實現框架 實驗網路通信程式採用TCP/IP協議的Socket API編程實現。Socket是面向客戶機/伺服器模型的。TCP實現框架如圖4所示。 2．實驗硬體環境︰ 伺服器︰Pentium 350 微機 客戶機︰Pentium 166微機 網路平台︰由10兆共享式HUB連接而成的局域網 3．實驗軟體環境︰ 作業系統︰Windows 98 編程語言︰Visual C++ 5.0 4．主要線程 編程採用多線程模式，伺服器端共有兩個線程︰發送數據線程、發送統計顯示線程。客戶端共有三個線程︰接收數據線程、接收預處理粘包線程、接收統計顯示線程。其中，發送和接收線程優先級設為THREAD_PRIORITY_TIME_CRITICAL（最高優先級），預處理線程優先級為THREAD_PRIORITY_ABOVE_NORMAL（高于普通優先級），顯示線程優先級為THREAD_PRIORITY_NORMAL（普通優先級）。 實驗發送數據的數據架構如圖5所示︰ 5．分包算法 針對三種不同的粘包現象，分包算法分別採取了相應的解決辦法。其基本思路是首先將待處理的接收數據流（長度設為m）強行轉換成預定的架構數據形式，並從中取出架構數據長度字段，即圖5中的n，而后根據n計算得到第一包數據長度。
1)若n=m，則表明數據流內容恰好是一完整架構數據，直接將其存入臨時緩沖區即可。
2)若n>m，則表明數據流內容尚不夠構成一完整架構數據，需留待與下一包數據合併后再行處理。 對分包算法具體內容及軟體實現有興趣者，可與作者聯繫。 四、實驗結果分析 實驗結果如下︰ 1．在上述實驗環境下，當發送方連續發送的若干包數據長度之和小于1500B時，常會出現粘包現象，接收方經預處理線程處理后能正確解開粘在一起的包。若程式中設置了“發送不延遲”︰（setsockopt (socket_name，IPPROTO_TCP，TCP_NODELAY，(char *) on，sizeof on) ，其中on=1），則不存在粘包現象。 2．當發送數據為每包1kB～2kB的不定長數據時，若發送間隔時間小于10ms，偶爾會出現粘包，接收方經預處理線程處理后能正確解開粘在一起的包。 3．為測定處理粘包的時間，發送方依次循環發送長度為1.5kB、1.9kB、1.2kB、1.6kB、1.0kB數據，共計1000包。為製造粘包現象，接收線程每次接收前都等待10ms，接收緩沖區設為5000B，結果接收方收到526包數據，其中長度為5000B的有175包。經預處理線程處理可得到1000包正確數據，粘包處理總時間小于1ms。 實驗結果表明，TCP粘包現象確實存在，但可透過接收方的預處理予以解決，而且處理時間非常短（實驗中1000包數據總共處理時間不到1ms），幾乎不影附應用程式的正常工作。
Trackback: http://blog.csdn.net/axes/articles/328543.aspx
一、TCP協議簡介
TCP是一個面向連接的傳輸層協議，雖然TCP不屬于ISO製定的協議集，但由於其在商業界和工業界的成功應用，它已成為事實上的網路標準，廣泛應用于各種網路主機間的通信。 作為一個面向連接的傳輸層協議，TCP的目標是為用戶提供可靠的端到端連接，保證訊息有序無誤的傳輸。它除了提供基本的數據傳輸功能外，還為保證可靠性採用了數據編號、校驗和計算、數據確認等一系列措施。它對傳送的每個數據位元組都進行編號，並請求接收方回傳確認訊息（ACK）。發送方如果在規定的時間內沒有收到數據確認，就重傳該數據。數據編號使接收方能夠處理數據的失序和重複問題。數據誤碼問題透過在每個傳輸的數據段中增加校驗和予以解決，接收方在接收到數據后檢查校驗和，若校驗和有誤，則丟棄該有誤碼的數據段，並要求發送方重傳。流量控制也是保證可靠性的一個重要措施，若無流控，可能會因接收緩沖區溢出而丟失大量數據，導致許多重傳，造成網路擁塞惡性循環。TCP採用可變窗口進行流量控制，由接收方控制發送方發送的數據量。 TCP為用戶提供了高可靠性的網路傳輸服務，但可靠性保障措施也影響了傳輸效率。因此，在實際工程應用中，只有關鍵數據的傳輸才採用TCP，而普通數據的傳輸一般採用高效率的UDP。
二、粘包問題分析與對策
TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩沖區看，后一包數據的頭緊接著前一包數據的尾。 出現粘包現象的原因是多方面的，它既可能由發送方造成，也可能由接收方造成。發送方引起的粘包是由TCP協議本身造成的，TCP為提升傳輸效率，發送方往往要收集到足夠多的數據后才發送一包數據。若連續幾次發送的數據都很少，通常TCP會根據優化算法把這些數據合成一包后一次發送出去，這樣接收方就收到了粘包數據。接收方引起的粘包是由於接收方用戶進程不及時接收數據，從而導致粘包現象。這是因為接收方先把收到的數據放在系統接收緩沖區，用戶進程從該緩沖區取數據，若下一包數據到達時前一包數據尚未被用戶進程取走，則下一包數據放到系統接收緩沖區時就接到前一包數據之后，而用戶進程根據預先設定的緩沖區大小從系統接收緩沖區取數據，這樣就一次取到了多包數據（圖1所示）。 粘包情況有兩種，一種是粘在一起的包都是完整的數據包（圖1、圖2所示），另一種情況是粘在一起的包有不完整的包（圖3所示），此處假設用戶接收緩沖區長度為m個位元組。 不是所有的粘包現象都需要處理，若傳輸的數據為不帶架構的連續流數據（如文件傳輸），則不必把粘連的包分開（簡稱分包）。但在實際工程應用中，傳輸的數據一般為帶架構的數據，這時就需要做分包處理。 在處理定長架構數據的粘包問題時，分包算法比較簡單；在處理不定長架構數據的粘包問題時，分包算法就比較複雜。特別是如圖3所示的粘包情況，由於一包數據內容被分在了兩個連續的接收包中，處理起來難度較大。實際工程應用中應盡量避免出現粘包現象。 為了避免粘包現象，可採取以下幾種措施。一是對于發送方引起的粘包現象，用戶可透過編程設置來避免，TCP提供了強製數據立即傳送的操作指令push，TCP軟體收到該操作指令后，就立即將本段數據發送出去，而不必等待發送緩沖區滿；二是對于接收方引起的粘包，則可透過優化程式設計、精簡接收進程工作量、提升接收進程優先級等措施，使其及時接收數據，從而盡量避免出現粘包現象；三是由接收方控制，將一包數據按架構字段，人為控制分多次接收，然後合併，透過這種手段來避免粘包。 以上提到的三種措施，都有其不足之處。第一種編程設置方法雖然可以避免發送方引起的粘包，但它關閉了優化算法，降低了網路發送效率，影附應用程式的性能，一般不建議使用。第二種方法只能減少出現粘包的可能性，但並不能完全避免粘包，當發送頻率較高時，或由於網路突發可能使某個時間段數據包到達接收方較快，接收方還是有可能來不及接收，從而導致粘包。第三種方法雖然避免了粘包，但應用程式的效率較低，對實時應用的場合不適合。 一種比較周全的對策是︰接收方創建一預處理線程，對接收到的數據包進行預處理，將粘連的包分開。對這種方法我們進行了實驗，證明是高效可行的。
三、編程與實現
1．實現框架 實驗網路通信程式採用TCP/IP協議的Socket API編程實現。Socket是面向客戶機/伺服器模型的。TCP實現框架如圖4所示。 2．實驗硬體環境︰ 伺服器︰Pentium 350 微機 客戶機︰Pentium 166微機 網路平台︰由10兆共享式HUB連接而成的局域網 3．實驗軟體環境︰ 作業系統︰Windows 98 編程語言︰Visual C++ 5.0 4．主要線程 編程採用多線程模式，伺服器端共有兩個線程︰發送數據線程、發送統計顯示線程。客戶端共有三個線程︰接收數據線程、接收預處理粘包線程、接收統計顯示線程。其中，發送和接收線程優先級設為THREAD_PRIORITY_TIME_CRITICAL（最高優先級），預處理線程優先級為THREAD_PRIORITY_ABOVE_NORMAL（高于普通優先級），顯示線程優先級為THREAD_PRIORITY_NORMAL（普通優先級）。 實驗發送數據的數據架構如圖5所示︰ 5．分包算法 針對三種不同的粘包現象，分包算法分別採取了相應的解決辦法。其基本思路是首先將待處理的接收數據流（長度設為m）強行轉換成預定的架構數據形式，並從中取出架構數據長度字段，即圖5中的n，而后根據n計算得到第一包數據長度。
1)若n=m，則表明數據流內容恰好是一完整架構數據，直接將其存入臨時緩沖區即可。
2)若n>m，則表明數據流內容尚不夠構成一完整架構數據，需留待與下一包數據合併后再行處理。 對分包算法具體內容及軟體實現有興趣者，可與作者聯繫。 四、實驗結果分析 實驗結果如下︰ 1．在上述實驗環境下，當發送方連續發送的若干包數據長度之和小于1500B時，常會出現粘包現象，接收方經預處理線程處理后能正確解開粘在一起的包。若程式中設置了“發送不延遲”︰（setsockopt (socket_name，IPPROTO_TCP，TCP_NODELAY，(char *) on，sizeof on) ，其中on=1），則不存在粘包現象。 2．當發送數據為每包1kB～2kB的不定長數據時，若發送間隔時間小于10ms，偶爾會出現粘包，接收方經預處理線程處理后能正確解開粘在一起的包。 3．為測定處理粘包的時間，發送方依次循環發送長度為1.5kB、1.9kB、1.2kB、1.6kB、1.0kB數據，共計1000包。為製造粘包現象，接收線程每次接收前都等待10ms，接收緩沖區設為5000B，結果接收方收到526包數據，其中長度為5000B的有175包。經預處理線程處理可得到1000包正確數據，粘包處理總時間小于1ms。 實驗結果表明，TCP粘包現象確實存在，但可透過接收方的預處理予以解決，而且處理時間非常短（實驗中1000包數據總共處理時間不到1ms），幾乎不影附應用程式的正常工作。
Trackback: http://blog.csdn.net/axes/articles/328543.aspx
訂閱：
文章 (Atom)
