高性能并發(fā)web服務(wù)器實(shí)現(xiàn)核心內(nèi)幕-文庫(kù)吧資料
2025-05-18 12:55本頁面
【正文】 O 內(nèi)存緩存 ?委托給操作系統(tǒng) – sendfile() CGI ?多進(jìn)程 ?用環(huán)境變量來傳遞請(qǐng)求的 HTTP報(bào)頭信息和服務(wù)器信息 ?用 stdin傳遞請(qǐng)求的 HTTP報(bào)體 ?用 stdout發(fā)送響應(yīng)報(bào)頭 (部分 )和報(bào)體 ?缺點(diǎn) : ? 由于使用環(huán)境變量來通信 , 擴(kuò)展性受限 ? 一個(gè)進(jìn)程的生命周期只處理一個(gè)請(qǐng)求 FastCGI ?委托給網(wǎng)絡(luò) 補(bǔ)充話題 ? IO多路復(fù)用模型中 , 為什么不能用標(biāo)準(zhǔn) IO庫(kù)的行讀取函數(shù) fgets()來讀取 HTTP的首部 . ? 因?yàn)?fgets()調(diào)用可能多于一次 read(), 是可阻塞的 ? 文本協(xié)議和二進(jìn)制協(xié)議如何取舍 ? 報(bào)文的格式只是協(xié)議的其中一項(xiàng)內(nèi)容 , 語義是另一項(xiàng)更重要的內(nèi)容 . ? 文本協(xié)議總是優(yōu)于二進(jìn)制協(xié)議 (除了少數(shù)情況 ) ? 應(yīng)該更關(guān)注的是 , 報(bào)文是定長(zhǎng)報(bào)文還是變長(zhǎng)報(bào)文 ! ? 參考 HTTP, 報(bào)頭 (元數(shù)據(jù)部分 )是文本 , 報(bào)體可以是二進(jìn)制數(shù)據(jù) . ? 另外 , 冒號(hào)分隔的 keyvalue行文本報(bào)頭格式 , 是最簡(jiǎn)單最通用的報(bào)文格式 . ? 把 TCP/IP協(xié)議詳解 卷 1, Unix網(wǎng)絡(luò)編程 卷 1, 計(jì)算機(jī)網(wǎng)絡(luò) 這幾本書好好看一遍 ! FAQ IT牛人 FIN Thanks 。 } } ? RUN_IN_NEW_THREAD表示創(chuàng)建線程 , 這個(gè)線程叫做 工作線程 . 原始多線程并發(fā)網(wǎng)絡(luò)服務(wù)器 (續(xù) ) ?缺點(diǎn) : ? 線程的數(shù)量無法得到控制 . ? 如果是短連接 , 創(chuàng)建線程的成本可能相對(duì)請(qǐng)求處理的成本更大 ?要解決的問題 : ? 如何控制線程的數(shù)量 ? ? 如何避免創(chuàng)建線程對(duì)性能的影響 線程池并發(fā)網(wǎng)絡(luò)服務(wù)器 ? 初始化時(shí)創(chuàng)建線程池 ? 主進(jìn)程中 accept()之后 , 把 socket傳給工作線程 ? 但又帶來了一個(gè)問題 : 雖然可以不斷地接受連接 , 但畢竟工作線程有限 , 還是會(huì)出現(xiàn)連接排隊(duì)等線程的情況 . 當(dāng)連接數(shù)少時(shí)是線程等連接 , 但當(dāng)連接數(shù)多時(shí)是連接等線程 . ? 怎么解決 ? ? 調(diào)優(yōu)工作線程的數(shù)量 . ? 硬件問題 , 不是軟件所能解決的 , 增加機(jī)器 . ? 改變服務(wù)器架構(gòu) , to be continued... IO多路復(fù)用 (IO Multiplex) ?前面的架構(gòu)瓶頸在哪 ? ?把 IO委托給操
畢業(yè)設(shè)計(jì)相關(guān)推薦
鄂ICP備17016276號(hào)-1