根據計算機系統的工做原理，咱們知道了整體思路爲：從CPU到內存，再到磁盤的過程。內存分爲：內核空間和用戶空間。相應的CPU也分爲內核模式和用戶模式。那一個用戶級的計算機應用，又如何的詳細工做過程呢？如下以WEB讀文件爲例：html
Round1:linux
內核模式到用戶模式的轉換：nginx
對於一次IO訪問（這回以read舉例），數據會先被拷貝到操做系統內核的緩衝區中，而後纔會從操做系統內核的緩衝區拷貝到應用程序的緩衝區，最後交給進程。因此說，當一個read操做發生時，它會經歷兩個階段：
1. 等待數據準備 (Waiting for the data to be ready)
2. 將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)。算法
問題：apache
以上兩個階段，用戶空間一直處理阻塞狀態，即等待完成。經過一個進程沒法快速響應結束，再接受另外一個WEB請求。網絡
解決方案：多線程
採用prefork模型（apache）,即多進程模式。異步
1.控制權限的httpd進程，監聽80端口；
2.主進程（httpd）管理服務子進程的調度，派生和銷燬,響應用戶的請求。async
Round2:函數
問題：
多進程運做，當進程過多的時候，進程間切換會愈加頻繁。但進程間切換開銷又過大。
解決方案：
1.worker模式（apache），即多進程多線程模式。
優勢：a.線程切換是輕量級的，線程間能夠共享不少資源，好比內存；
b.單線程崩潰，會形成父進程崩潰；線程過多，進行切換，會形成線程抖動。因此採用了多進程，而不是徹底依賴多線程。
2.單進程綁定CPU解決，直接杜絕了進程切換。nginx支持。
Round3:
問題：因爲兩次數據複製過程，進程都處於阻塞狀態，浪費了進程數和相關資源。
解決方案： IO優化。
linux系統產生了下面五種網絡模式的方案：
-- 阻塞 I/O（blocking IO）
-- 非阻塞 I/O（nonblocking IO）
-- I/O 多路複用（ IO multiplexing）
-- 信號驅動 I/O（ signal driven IO）
-- 異步 I/O（asynchronous IO）
阻塞I/O模式：內核準備數據和數據從內核拷貝到進程內存地址，這兩個過程應用進程都是阻塞的；
非阻塞I/O模式：內核準備數據階段不阻塞，可是進程須要週期詢問內核數據是否準備好；而後再從內核拷貝到進程內存地址階段是阻塞的；
I/O多路複用：兩個過程都是阻塞的，可是使用了select算法，一個進程或者線程能夠同時處理多個I/O請求；poll算法也支持。
信號驅動I/O：同非阻塞I/O模式，可是不用進程輪詢，而是事件驅動，在內核數據準備好以後，向進程通知，epoll算法支持。
異步I/O：兩個過程都不阻塞，告知內核須要取的數據以後，內核負責準備數據，並拷貝到用戶空間，再通知進程。而不是非阻塞裏面的，進程來詢問內核。
備註：
a.apahce除了prefork、worker模式，還有就是event模式。event模式，即信號驅動I/O模式。另外還優化了長鏈接。
基於長鏈接，長期keep-alive在線，浪費線程，所以專門設定一個管理進程來管理這些長鏈接，在特定條件下，能夠回收線程資源，而不會出現空閒線程。
b.nginx採用了異步I/O模式，有效解決了C10K問題。將系統性能提高了三倍以上。
另外nginx還使用了虛擬內存的機制，調用了mmap函數，即作了內存映射。並不將磁盤的文件複製到內存中，而是直接映射到內存中。只須要一次複製突出，而不須要兩次。
原文出處：https://www.cnblogs.com/daiaiai/p/11073493.html