原理一 http請求和web伺服器
一、http請求
1）使用者輸入
2）瀏覽器解析出主機名。
3）瀏覽器查詢這個主機名的ip位址如192.168.0.1（即dns解析）並獲得埠號如80
4）瀏覽器發起到192.168.0.1:80的連線。（tcp連線首次握手）
5）瀏覽器向伺服器傳送一條http get或post報文。（有可能會先傳送給proxy或gateway，再由它們**給伺服器，如nginx做反向**以實現負載均衡）
6）瀏覽器從伺服器讀取http響應報文。
7）瀏覽器關閉連線。
以上便是一條http請求的大致過程，理論上所有的http通訊都是由tcp/ip承載的，即http使用tcp連線，其保證了在資源傳輸過程中是可靠的／不會丟失或損壞的。
二：web伺服器
web伺服器可以用來表示web伺服器的軟體，也可以表示提供web頁面的特定裝置或機器。這邊主要是指通用軟體web伺服器，如apache或nginx。
《http權威指南》中有乙份用perl指令碼寫的web伺服器的原始碼，實現了最簡單的收發客戶端報文的功能。
1）接受乙個客戶端（瀏覽器）連線，或者拒絕該客戶端的連線並將其關閉。
2）接受請求，從網路中讀取一條http請求報文並解析。
3）處理請求，對請求報文進行解析。
4）訪問資源，訪問報文中指定的資源，有可能是快取好的html靜態頁面或資源，也有可能是動態資源，如php檔案，此時web server會通過fastcgi請求php應用程式以此產生動態資源，下面會詳細講。
5）建立http響應報文，並回送給客戶端。
6）紀錄事務處理過程，即記log。
原理二：cgi與fastcgi
為了解決不同的語言直譯器(如php、python直譯器)與webserver的通訊，於是出現了cgi協議。只要你按照cgi協議去編寫程式，就能實現語言直譯器與webwerver的通訊。如php-cgi程式。
講fastcgi之前需要先講cgi，cgi是為了保證web server傳遞過來的資料是標準格式的，它是乙個協議，方便cgi程式的編寫者。fastcgi是cgi的更高階的一種方式，是用來提高cgi程式效能的。
web server（如nginx）只是內容的分發者。比如，如果請求/index.html，那麼web server會去檔案系統中找到這個檔案，傳送給瀏覽器，這裡分發的是靜態資源。
如果現在請求的是/index.php，根據配置檔案，nginx知道這個不是靜態檔案，需要去找php解析器來處理，那麼他會把這個請求簡單處理後交給php解析器。此時cgi便是規定了要傳什麼資料／以什麼格式傳輸給php解析器的協議。
當web server收到/index.php這個請求後，會啟動對應的cgi程式，這裡就是php的解析器。接下來php解析器會解析php.ini檔案，初始化執行環境，然後處理請求，再以cgi規定的格式返回處理後的結果，退出程序。web server再把結果返回給瀏覽器。
那麼cgi相較於fastcgi而言其效能瓶頸在哪呢？cgi針對每個http請求都是fork乙個新程序來進行處理，處理過程包括解析php.ini檔案，初始化執行環境等，然後這個程序會把處理完的資料返回給web伺服器，最後web伺服器把內容傳送給使用者，剛才fork的程序也隨之退出。 如果下次使用者還請求動態資源，那麼web伺服器又再次fork乙個新程序，周而復始的進行。
而fastcgi則會先fork乙個master，解析配置檔案，初始化執行環境，然後再fork多個worker。當請求過來時，master會傳遞給乙個worker，然後立即可以接受下乙個請求。這樣就避免了重複的勞動，效率自然是高。而且當worker不夠用時，master可以根據配置預先啟動幾個worker等著；當然空閒worker太多時，也會停掉一些，這樣就提高了效能，也節約了資源。這就是fastcgi的對程序的管理。大多數fastcgi實現都會維護乙個程序池。注：swoole作為httpserver，實際上也是類似這樣的工作方式。
原理三、php-fpm
php-fpm(fastcgi process manager：fastcgi程序管理器)是乙個php
fastcgi管理器
1）php-fpm是乙個實現了fastcgi的程式，php的直譯器只能解析請求，返回結果，不會程序管理，那麼便需要能夠排程php-cgi程序的程式，如lighthttpd分離出來的spawn-fcgi，php-fpm也是。
2）php-fpm是乙個php fastcgi管理器，是只用於php的
3）php-cgi和php-fpm都是cgi的實現，並提供程序管理的功能
原理
四、正向與反向**
正向**的過程：它隱藏了真實的請求客戶端，服務端不知道真實的客戶端是誰，客戶端請求的服務都被**伺服器代替來請求。
反向**的過程：它隱藏了真是的伺服器，當我們請求www.baidu.com的時候，就像撥打10086一樣，背後可能有成千上萬臺伺服器為我們服務，但不清楚具體是哪一台，www.baidu.com就是我們的反向**伺服器，nginx就是效能很好的反向**伺服器，用來做負載均衡。
正向與反向**的區別在於**的物件不同，正向****的物件是客戶端，反向****的物件是服務端。
原理五、nginx + php-fpm執行原理詳解
nginx 是乙個高效能的http和反向**伺服器，php-fpm是fastcgi的實現，並提供程序管理的功能（按照cgi協議編寫程式，就能實現語言直譯器於webserver的通訊。）
nginx通過反向**功能將動態請求轉向後台php-fpm。
原理六、wsgi /uwsgi/uwsgi這三個概念的區分
wsgi：(web server gateway inte***ce/python web server gateway inte***ce) ,是為python語言定義的web伺服器和web應用程式或框架之間的一種簡單而通用的介面、閘道器（閘道器的作用就是在協議之間進行轉換）。
作用：
1）重寫環境變數後，根據目標url,將請求訊息路由到不同的應用物件。
2）允許在乙個程序中同時執行多個應用程式或應用框架。
3）負載均衡和遠端處理，通過在網路上**請求和響應訊息。
4）進行內容後處理，例如應用xslt樣式表。
uwsgi協議是乙個uwsgi伺服器自有的協議，它用於定義傳輸資訊的型別（type of information）, 每個uwsgi packet 前4 bypte 為傳輸資訊型別描述。
uwsgi 是乙個web伺服器，它實現了wsgi協議，uwsgi、http等協議。
原理七、flask + uwsgi + nginx執行原理詳解
flask：flask是乙個python實現的web開發微服務框架。
uwsgi: uwsgi是乙個web伺服器，它實現了wsgi協議、uwsgi、http協議等
釋疑：單獨flask也可以啟動並提供web服務，但是flask畢竟只是乙個web框架，它的web服務只能用於開發環境，不能用於生產環境。(自帶了wsgi server)
uwsgi本身就是乙個web伺服器，這裡引入nginx的原因是因為nginx是乙個反向**，這樣，一些靜態資源可用nginx提供服務，而其他**給uwsgi。
flask + uwsgi + nginx + php-fpm的示意圖
原 SQL相關路徑查詢指令碼
1.查詢機器名 select servername as 機器名稱 查詢已安裝的sql例項名 select from sys.servers 2.查詢sql安裝路徑 declare installpath varchar 200 exec master.dbo.xp regread hkey loc...
原環套原環
今天在除錯兄弟的程式的時候發現了乙個問題，就是在組合資料的時候，有些時候可以成功，有些時候失敗，感覺十分奇怪。功能大概是這樣的，就是在一棵樹上掛資料，所有的節點都可以有資料，不只是葉子的，在組合資料的時候，可以從任意節點取資料，但是不能是重複的資料。資料可能出現的情況如圖a b c所示，圖a是沒有干...
MongoDB writeConcern原理解析
mongodb支援客戶端靈活配置寫入策略 writeconcern 以滿足不同場景的需求。db.collection.insert mongodb支援的writeconncern選項如下 w 資料寫入到number個節點才向用客戶端確認 j 寫入操作的journal持久化後才向客戶端確認 wtime...