多線程模型適用于處理短連接，且連接的打開關(guān)閉非常頻繁的情形，但不適合處理長連接。多線程模型默認情況下，（在Linux）每個線程會開8M的?？臻g，再TCP長連接的情況下，2000/分鐘的請求，幾乎可以假定有上萬甚至十幾萬的并發(fā)連接，假定有10000個連接，開這么多個線程需要10000*8M=80G的內(nèi)存空間！即使調(diào)整每個線程的棧空間，也很難滿足更多的需求。甚至攻擊者可以利用這一點發(fā)動DDoS，只要一個連接連上服務器什么也不做，就能吃掉服務器幾M的內(nèi)存，這不同于多進程模型，線程間內(nèi)存無法共享，因為所有線程處在同一個地址空間中。內(nèi)存是多線程模型的軟肋。在UNIX平臺下多進程模型擅長處理并發(fā)長連接，但卻不適用于連接頻繁產(chǎn)生和關(guān)閉的情形。Windows平臺忽略此項。 同樣的連接需要的內(nèi)存數(shù)量并不比多線程模型少，但是得益于操作系統(tǒng)虛擬內(nèi)存的Copy on Write機制，fork產(chǎn)生的進程和父進程共享了很大一部分物理內(nèi)存。但是多進程模型在執(zhí)行效率上太低，接受一個連接需要幾百個時鐘周期，產(chǎn)生一個進程 可能消耗幾萬個CPU時鐘周期，兩者的開銷不成比例。而且由于每個進程的地址空間是獨立的，如果需要進行進程間通信的話，只能使用IPC進行進程間通 信，而不能直接對內(nèi)存進行訪問。在CPU能力不足的情況下同樣容易遭受DDos，攻擊者只需要連上服務器，然后立刻關(guān)閉連接，服務端則需要打開一個進程再關(guān)閉。同時需要保持很多的長連接，而且連接的開關(guān)很頻繁，最高效的模型是非阻塞、異步IO模型。而且不要用select/poll，這兩個API的有著O(N)的時間復雜度。在Linux用epoll，BSD用kqueue，Windows用IOCP，或者用libevent封裝的統(tǒng)一接口（對于不同平臺libevent實現(xiàn)時采用各個平臺特有的API），這些平臺特有的API時間復雜度為O(1)。
然而在非阻塞，異步I/O模型下的編程是非常痛苦的。由于I/O操作不再阻塞，報文的解析需要小心翼翼，并且需要親自管理維護每個鏈接的狀態(tài)。并且為了充分利用CPU，還應結(jié)合線程池，避免在輪詢線程中處理業(yè)務邏輯。
但這種模型的效率是極高的。以知名的http服務器nginx為例，可以輕松應付上千萬的空連接+少量活動鏈接，每個連接連接僅需要幾K的內(nèi)核緩沖區(qū)，想要應付更多的空連接，只需簡單的增加內(nèi)存（數(shù)據(jù)來源為淘寶一位工程師的一次技術(shù)講座，并未實測）。這使得DDoS攻擊者的成本大大增加，這種模型攻擊者只能將服務器的帶寬全部占用，才能達到目的，而兩方的投入是不成比例的。