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