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