上篇說到關於 Process 的起來，最主要相關的服務是 W3SVC 和 WAS，讓我們這篇多說一些關於背後起來的交互方式。

先上一張圖(圖源來自官方文檔)

在介紹整體關係之前，這張圖有一個地方大家可能比較不熟悉，就是 HTTP.sys。

可以看到圖的上半跟下半畫了一條虛線，上半是 User Mode，下半是 Kernel Mode。 Kernel Mode 能掌管所有硬體和系統層級的處理，User Mode 則是一般使用者使用的場景，當萬一需要調動到系統資源，才會再和 Kernel Mode 做溝通，讓 Kernel Mode 來調動。

Http.sys 就是被註冊於 Kernel mode 的網路驅動程式，實體位置位於 C:\Windows\System32\drivers\http.sys(不建議去動這個檔案，只是提供資訊)。主要負責監聽來自 internet 的 http request。 Http.sys 也有 cache 功能來針對部分內容作快取，增加回應速度，在這篇官方文檔裡，有反向列出不會被 cache 的場景，當要調整讀取效能的時候是一個參考依據，可以思考應該被使用的類型及調整方式。另外如果想知道那些被 cache 住了，可以透過這個 cmd 裡打這個 command 來做確認。

netsh http show cache [ [url= ] URL]
//sample : show cachestate url=https://www.contoso.com:80/myresource

在 Http.sys 出錯的 request log 會被寫在 C:\Windows\System32\LogFiles\HTTPERR，在 W3SVC/WAS 層面出錯的會寫在 System Event Viewer，

現在可以來說說 Process 是怎麼被建立的了(下列數字對應到上圖中的數字)：

(1)當一個 Http request 來到這個 endpoint

(2)首先他會去問 WAS 拿 config

(3)WAS 從存著 config 的地方拿到對應到哪個站點/ application pool 的設定，寫入 C:\inetpub\temp\appPools\ 位置，當收到通知會跟著更新

(4)W3SVC取出對應的細部 site / application pool 的設定

(5)W3SVC 返回資訊給 Http.sys 並設定

(6)WAS 依設定方式起對應的 Process (W3WP.exe)
(7)W3WP.exe 處理 request 內容並把回應傳給 Http.sys

(8)Http.sys 把訊息回給 Client 端

可以看到在第 6 步會處理到 Process 的建立，這邊說的就是 Worker Process，W3WP.exe。如果 request 碰到這邊，有設定對應的 Logging module，那 Log 就會被寫入 IIS Log(C:\intepub\logs\LogFiles\W3SVC*)中(依情況也可能於 System Event log 留下相對應紀錄)。

另外在 Task Scheduler 中你要怎麼分辨哪個是 w3wp.exe 是屬於哪個網站呢？執行中的 Process 都會有 unique 的 process Id，各網站的 process Id 你可以在這個介面裡找到

如上圖，我們知道現在這個 DemoWebsite 他的 process Id 是 27620，我們打開 task manager 就可以找到對應 id 的 process。

另外，command line 通常會有實體執行相關的資訊，如果你新增欄位，也可能可以直接從這邊就知道這個 process 歸屬於哪個 application。

今天的分享大致講述了幾個 request 處理流程中會互動到的主要組件，也說明了誰會起 process， process 該如何查看實體等等，是一個比較高層面的概覽。另外也提到了各組件寫 Log 的地方，只要問題發生，第一步其實應該先診斷是哪裡出問題，或反向透過 Log 有紀錄的地方來發現這一點，關於各個 Log 的解讀與工具，我們會留在後面一一分享。