2008年3月28日
#
先說說TCP收包的context（不定長包）。一般情況，發(fā)送方發(fā)送一個包，然后接收方收到一個包，這是最好處理的。第二種情況，當每次發(fā)生的包比較小時，發(fā)送數(shù)據(jù)時，TCP會啟用優(yōu)化算法，將多個小包集中起來發(fā)送，以提高傳輸效率。此時接收方的recv buffer中，可能出現(xiàn)不止一個包。第三種情況，recv buffer中每次只一個包，但接收方?jīng)]及時取包，這時recv buffer中會積累多個包。
理所當然，TCP收包要考慮所有這些情況。一般來說有三種方法。第一種，定義好通訊協(xié)議，先收包頭，然后根據(jù)包頭中的消息真實大小，接收消息剩余部分。第二種方法，通訊協(xié)議規(guī)定好每個消息的開始和結(jié)束標識符。然后每次recv得到的數(shù)據(jù)先放到一個大（比如你的最大packet的2倍）buffer中，最后再來分析這個buffer分包。第三種方法，先用recv+MSG_PEEK接收某個固定長度，然后對接收到的"包"進行分析，然后做真正的recv操作。
2008年3月24日
#
能不能接受爆發(fā)連接（并發(fā)度如何），主要是取決于accept的速度。一個TCP連接的建立，要在client和server之間，完成三次握手，然后連接會被放到完成隊列中，accept從完成隊列中取出連接并返回。任何影響accept取連接的因素，都會影響并發(fā)度。一般策略是，1 獨立處理accept，2 使用epoll處理accept，這兩種情況，并發(fā)度都是不錯的。
并發(fā)地接受了這么多連接，并不代表能完全處理。假如有很多連接同時在線，server accept成功并收到了數(shù)據(jù)，這時消息被放到消息隊列中，等待邏輯線程來處理。因為生產(chǎn)者（收數(shù)據(jù)）的速度總是大于消費者（處理數(shù)據(jù)）的速度，因此消息隊列會有考慮流控，以免系統(tǒng)資源被耗光。這樣，有些消息就可能丟失。這就是同時在線連接數(shù)的問題。
前者是高并發(fā)，后者是高負載。設(shè)計時會權(quán)衡偏向。
并發(fā)服務(wù)器有三種常見的架構(gòu)：
1. 單線程epoll（ET非阻塞I/O) +線程池，也叫半同步半異步模式。這種模型比較常見，而且因為異步層和同步層使用消息隊列傳遞消息，更容易實現(xiàn)對消息的FIFO處理。缺點就是線程的同步和上下文切換開銷比較大。
2. ConnectionPerThread+阻塞型I/O。這是最古老的服務(wù)器并發(fā)模型，不太適合現(xiàn)今的這些高并發(fā)高負載服務(wù)器，當連接數(shù)巨大的時候，創(chuàng)建銷毀線程的開銷會無法承受，并且內(nèi)核創(chuàng)建線程的速度也會成為瓶頸。這種模型的一種改進型就是領(lǐng)導者/跟隨者模式，它吸取第一種模型中，線程數(shù)量不會膨脹的優(yōu)點，使用線程池來處理連接。每當有連接到達時，都使用一個線程阻塞處理，處理完成后，線程再回到線程池中，這樣有限的線程模擬出了ConnectionPerThread。一般來說，領(lǐng)導者/跟隨者模型比第一種模型更加高效，因為它減少了線程同步和切換的開銷，它的缺點就是FIFO很難保證。
3. 流水線模型。前面兩種模式都有個缺點，它們不能花太長時間處理邏輯，因為在多CPU系統(tǒng)上，某些耗時的長請求可能會不斷占住CPU，而導致短請求得不到處理，這會使某些CPU閑置。于是這種模型提出，將請求處理的過程劃分步驟，不同的步驟考慮不同的資源處理（比如CPU, DISK I/O等），每個步驟使用單獨的線程或線程池。這樣比較耗時的操作可能集中在流水線的下級，而短請求也可以在上級得到快速處理。因為各級線程之間使用消息隊列傳遞請求，也很容易實現(xiàn)FIFO。
如何高效處理多個socket I/O的讀寫，是提高服務(wù)器性能的重點問題。unix-like下面，現(xiàn)有機制有select,poll, epoll,kqueue,/dev/poll兩大類。
Select有個缺點，它用fd_set管理所有要監(jiān)視的I/O句柄，但是fd_set是一個位數(shù)組，只能接受句柄號小于FD_SETSIZE（默認1024）的句柄，雖然進程默認句柄號都是小于1024的，但是可以通過ulimit –n來修改，尤其是連接數(shù)超過1024時必需這么做（實際可能更少），如果要將大于1024的句柄放入fd_set，就可能發(fā)生數(shù)組越界程序崩潰的場面。
Poll雖然解決了FD_SETSIZE問題，但是它和select一樣，都有性能上的瓶頸。它們都會隨著連接數(shù)的增加性能直線下降。這主要有兩個原因，其一是每次select/poll操作，kernel都會建立一個當前線程關(guān)心的事件列表，并讓線程阻塞在這個列表上，這是很耗時的操作。其二是每次select/poll返回后，線程都要掃描所有句柄來dispatch已發(fā)生的事件，這也是很耗時的。當連接數(shù)巨大時，這種消耗積累起來，就很受不了。
為了解決select/poll的性能問題，unix-like系統(tǒng)上開發(fā)出了三套新的利器epoll，kqueue，/dev/poll，其中epoll是linux的，kqueue是freebsd的，/dev/poll是Solaris上的，它們是select/poll的替代品。它們的設(shè)計就是針對select/poll的性能問題，主要避免 1。每次調(diào)用都建立事件等待列表，取而代之建立長期的事件關(guān)注列表，這個列表可通過句柄（比如epfd）來增加和刪除事件。2。調(diào)用返回之后，不再需要遍歷所有句柄進行分發(fā)，內(nèi)核會直接返回當前已發(fā)生的事件。不用說，性能在select, poll基礎(chǔ)上有了大幅提升。
要注意的是，凡是使用readiness notification（LT)或者readiness change notification（ET)機制，都應(yīng)該配合非阻塞I/O，因為這種事件通知，并不一定表示文件描述符真正就緒，如果收到通知之后去read，很有可能進入阻塞狀態(tài)，這會嚴重影響服務(wù)器的并發(fā)性能，同時對ET模式，不能漏掉任何事件的處理，并且每次都應(yīng)該讀到socket返回EWOULDBLOCK為止，不然這個socket之后會永遠保持沉默。