應用服務器知識(7)--Nginx詳解

本文轉載自：http://blog.csdn.net/zouyujie1127/article/details/41605063

Nginx是什麼

代理服務器:一般是指局域網內部的機器通過代理服務器發送請求到互聯網上的服務器,代理服務器一般作用在客戶端。應用比如：GoAgent，翻牆神器.

一個完整的代理請求過程爲：客戶端首先與代理服務器創建連接，接着根據代理服務器所使用的代理協議，請求對目標服務器創建連接、或者獲得目標服務器的指定資源。 Web代理（proxy）服務器是網絡的中間實體。代理位於Web客戶端和Web服務器之間，扮演“中間人”的角色。HTTP的代理服務器即是Web服務器又是Web客戶端。

代理服務器是介於客戶端和Web服務器之間的另一臺服務器，有了它之後，瀏覽器不是直接到Web服務器去取回網頁而是向代理服務器發出請求，信號會先送到代理服務器，由代理服務器來取回瀏覽器所需要的信息並傳送給你的瀏覽器。

正向代理是一個位於客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，然後代理向原始服務器轉交請求並將獲得的內容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。

反向代理服務器：在服務器端接受客戶端的請求，然後把請求分發給具體的服務器進行處理，然後再將服務器的響應結果反饋給客戶端。Nginx就是其中的一種反向代理服務器軟件。

Nginx：Nginx (“engine x”) ，Nginx (“engine x”) 是俄羅斯人Igor Sysoev(塞索耶夫)編寫的一款高性能的 HTTP 和反向代理服務器。也是一個IMAP/POP3/SMTP代理服務器；也就是說，Nginx本身就可以託管網站，進行HTTP服務處理，也可以作爲反向代理服務器使用。

說明：客戶端必須設置正向代理服務器，當然前提是要知道正向代理服務器的IP地址，還有代理程序的端口。

反向代理正好與正向代理相反，對於客戶端而言代理服務器就像是原始服務器，並且客戶端不需要進行任何特別的設置。客戶端向反向代理的命名空間(name-space)中的內容發送普通請求，接着反向代理將判斷向何處(原始服務器)轉交請求，並將獲得的內容返回給客戶端。

用戶A始終認爲它訪問的是原始服務E5��B而不是代理服務器Z，但實際上反向代理服務器接受用戶A的應答，

從原始資源服務器B中取得用戶A的需求資源，然後發送給用戶A。由於防火牆的作用，只允許代理服務器Z訪問原始資源服務器B。儘管在這個虛擬的環境下，防火牆和反向代理的共同作用保護了原始資源服務器B，但用戶A並不知情。

Nginx的應用現狀

Nginx 已經在俄羅斯最大的門戶網站── Rambler Media（www.rambler.ru）上運行了3年時間，同時俄羅斯超過20%的虛擬主機平臺採用Nginx作爲反向代理服務器。

在國內，已經有淘寶、新浪博客、新浪播客、網易新聞、六間房、56.com、Discuz!、水木社區、豆瓣、YUPOO、海內、迅雷在線等多家網站使用 Nginx 作爲Web服務器或反向代理服務器。

Nginx的特點

跨平臺：Nginx 可以在大多數 Unix like OS編譯運行，而且也有Windows的移植版本。

配置異常簡單：非常容易上手。配置風格跟程序開發一樣，神一般的配置

非阻塞、高併發連接：數據複製時，磁盤I/O的第一階段是非阻塞的。官方測試能夠支撐5萬併發連接，在實際生產環境中跑到2～3萬併發連接數.(這得益於Nginx使用了最新的epoll模型)

事件驅動：通信機制採用epoll模型，支持更大的併發連接。

Nginx的事件處理機制

對於一個基本的web服務器來說，事件通常有三種類型，網絡事件、信號、定時器。

首先看一個請求的基本過程：建立連接—接收數據—發送數據。

再次看系統底層的操作：上述過程（建立連接—接收數據—發送數據）在系統底層就是讀寫事件。

1）如果採用阻塞調用的方式，當讀寫事件沒有準備好時，必然不能夠進行讀寫事件，那麼久只好等待，等事件準備好了，才能進行讀寫事件。那麼請求就會被耽擱。阻塞調用會進入內核等待，cpu就會讓出去給別人用了，對單線程的worker來說，顯然不合適，當網絡事件越多時，大家都在等待呢，cpu空閒下來沒人用，cpu利用率自然上不去了，更別談高併發了。

2）既然沒有準備好阻塞調用不行，那麼採用非阻塞方式。非阻塞就是，事件，馬上返回EAGAIN，告訴你，事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了爲止，在這期間，你就可以先去做其它事情，然後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你可以做更多的事情了，但帶來的開銷也是不小的

小結：非阻塞通過不斷檢查事件的狀態來判斷是否進行讀寫操作，這樣帶來的開銷很大。

3）因此纔有了異步非阻塞的事件處理機制。具體到系統調用就是像select/poll/epoll/kqueue這樣的系統調用。他們提供了一種機制，讓你可以同時監控多個事件，調用他們是阻塞的，但可以設置超時時間，在超時時間之內，如果有事件準備好了，就返回。這種機制解決了我們上面兩個問題。

以epoll爲例：當事件沒有準備好時，就放入epoll(隊列)裏面。如果有事件準備好了，那麼就去處理；如果事件返回的是EAGAIN，那麼繼續將其放入epoll裏面。從而，只要有事件準備好了，我們就去處理她，只有當所有事件都沒有準備好時，纔在epoll裏面等着。這樣，我們就可以併發處理大量的併發了，當然，這裏的併發請求，是指未處理完的請求，線程只有一個，所以同時能處理的請求當然只有一個了，只是在請求間進行不斷地切換而已，切換也是因爲異步事件未準備好，而主動讓出的。這裏的切換是沒有任何代價，你可以理解爲循環處理多個準備好的事件，事實上就是這樣的。

4）與多線程的比較：
與多線程相比，這種事件處理方式是有很大的優勢的，不需要創建線程，每個請求佔用的內存也很少，沒有上下文切換，事件處理非常的輕量級。併發數再多也不會導致無謂的資源浪費（上下文切換）。

小結：通過異步非阻塞的事件處理機制，Nginx實現由進程循環處理多個準備好的事件，從而實現高併發和輕量級。

master/worker結構：一個master進程，生成一個或多個worker進程

內存消耗小：處理大併發的請求內存消耗非常小。在3萬併發連接下，開啓的10個Nginx 進程才消耗150M內存（15M*10=150M）成本低廉：Nginx爲開源軟件，可以免費使用。而購買F5 BIG-IP、NetScaler等硬件負載均衡交換機則需要十多萬至幾十萬人民幣

內置的健康檢查功能：如果 Nginx Proxy 後端的某臺 Web 服務器宕機了，不會影響前端訪問。

節省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭。

穩定性高：用於反向代理，宕機的概率微乎其微

Nginx的不爲人知的特點

1、nginx代理和後端web服務器間無需長連接；

2、接收用戶請求是異步的，即先將用戶請求全部接收下來，再一次性發送後端web服務器，極大的減輕後端web服務器的壓力

3、發送響應報文時，是邊接收來自後端web服務器的數據，邊發送給客戶端的

4、網絡依賴型低。NGINX對網絡的依賴程度非常低，理論上講，只要能夠ping通就可以實施負載均衡，而且可以有效區分內網和外網流量

5、支持服務器檢測。NGINX能夠根據應用服務器處理頁面返回的狀態碼、超時信息等檢測服務器是否出現故障，並及時返回錯誤的請求重新提交到其它節點上

Nginx的內部(進程)模型

nginx是以多進程的方式來工作的，當然nginx也是支持多線程的方式的,只是我們主流的方式還是多進程的方式，也是nginx的默認方式。nginx採用多進程的方式有諸多好處 .

(1) nginx在啓動後，會有一個master進程和多個worker進程。master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發送信號，監控 worker進程的運行狀態,當worker進程退出後(異常情況下)，會自動重新啓動新的worker進程。而基本的網絡事件，則是放在worker進程中來處理了。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。 worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致，這裏面的原因與nginx的進程模型以及事件處理模型是分不開的。

(2)Master接收到信號以後怎樣進行處理（./nginx -s reload ）?首先master進程在接到信號後，會先重新加載配置文件，然後再啓動新的進程，並向所有老的進程發送信號，告訴他們可以光榮退休了。新的進程在啓動後，就開始接收新的請求，而老的進程在收到來自master的信號後，就不再接收新的請求，並且在當前進程中的所有未處理完的請求處理完成後，再退出 .

(3) worker進程又是如何處理請求的呢？我們前面有提到，worker進程之間是平等的，每個進程，處理請求的機會也是一樣的。當我們提供80端口的http服務時，一個連接請求過來，每個進程都有可能處理這個連接，怎麼做到的呢？首先，每個worker進程都是從master進程fork過來，在master進程裏面，先建立好需要listen的socket之後，然後再fork出多個worker進程，這樣每個worker進程都可以去accept這個socket(當然不是同一個socket，只是每個進程的這個socket會監控在同一個ip地址與端口，這個在網絡協議裏面是允許的)。一般來說，當一個連接進來後，所有在accept在這個socket上面的進程，都會收到通知，而只有一個進程可以accept這個連接，其它的則accept失敗，這是所謂的驚羣現象。當然，nginx也不會視而不見，所以nginx提供了一個accept_mutex這個東西，從名字上，我們可以看這是一個加在accept上的一把共享鎖。有了這把鎖之後，同一時刻，就只會有一個進程在accpet連接，這樣就不會有驚羣問題了。accept_mutex是一個可控選項，我們可以顯示地關掉，默認是打開的。當一個worker進程在accept這個連接之後，就開始讀取請求，解析請求，處理請求，產生數據後，再返回給客戶端，最後才斷開連接，這樣一個完整的請求就是這樣的了。我們可以看到，一個請求，完全由worker進程來處理，而且只在一個worker進程中處理。

(4)nginx採用這種進程模型有什麼好處呢？採用獨立的進程，可以讓互相之間不會影響，一個進程退出後，其它進程還在工作，服務不會中斷，master進程則很快重新啓動新的worker進程。當然，worker進程的異常退出，肯定是程序有bug了，異常退出，會導致當前worker上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。當然，好處還有很多，大家可以慢慢體會。

(5).有人可能要問了，nginx採用多worker的方式來處理請求，每個worker裏面只有一個主線程，那能夠處理的併發數很有限啊，多少個worker就能處理多少個併發，何來高併發呢？非也，這就是nginx的高明之處，nginx採用了異步非阻塞的方式來處理請求，也就是說，nginx是可以同時處理成千上萬個請求的。對於IIS服務器每個請求會獨佔一個工作線程，當併發數上到幾千時，就同時有幾千的線程在處理請求了。這對操作系統來說，是個不小的挑戰，線程帶來的內存佔用非常大，線程的上下文切換帶來的cpu開銷很大，自然性能就上不去了，而這些開銷完全是沒有意義的。我們之前說過，推薦設置worker的個數爲cpu的核數，在這裏就很容易理解了，更多的worker數，只會導致進程來競爭cpu資源了，從而帶來不必要的上下文切換。而且，nginx爲了更好的利用多核特性，提供了cpu親緣性的綁定選項，我們可以將某一個進程綁定在某一個核上，這樣就不會因爲進程的切換帶來cache的失效

Nginx是如何處理一個請求

首先，nginx在啓動時，會解析配置文件，得到需要監聽的端口與ip地址，然後在nginx的master進程裏面，先初始化好這個監控的socket(創建socket，設置addrreuse等選項，綁定到指定的ip地址端口，再listen)，然後再fork(一個現有進程可以調用fork函數創建一個新進程。由fork創建的新進程被稱爲子進程 )出多個子進程出來，然後子進程會競爭accept新的連接。此時，客戶端就可以向nginx發起連接了。當客戶端與nginx進行三次握手，與nginx建立好一個連接後，此時，某一個子進程會accept成功，得到這個建立好的連接的socket，然後創建nginx對連接的封裝，即ngx_connection_t結構體。接着，設置讀寫事件處理函數並添加讀寫事件來與客戶端進行數據的交換。最後，nginx或客戶端來主動關掉連接，到此，一個連接就壽終正寢了。

當然，nginx也是可以作爲客戶端來請求其它server的數據的（如upstream模塊），此時，與其它server創建的連接，也封裝在ngx_connection_t中。作爲客戶端，nginx先獲取一個ngx_connection_t結構體，然後創建socket，並設置socket的屬性（比如非阻塞）。然後再通過添加讀寫事件，調用connect/read/write來調用連接，最後關掉連接，並釋放ngx_connection_t。

說明：nginx在實現時，是通過一個連接池來管理的，每個worker進程都有一個獨立的連接池，連接池的大小是worker_connections。這裏的連接池裏面保存的其實不是真實的連接，它只是一個worker_connections大小的一個ngx_connection_t結構的數組。並且，nginx會通過一個鏈表free_connections來保存所有的空閒ngx_connection_t，每次獲取一個連接時，就從空閒連接鏈表中獲取一個，用完後，再放回空閒連接鏈表裏面。

在這裏，很多人會誤解worker_connections這個參數的意思，認爲這個值就是nginx所能建立連接的最大值。其實不然，這個值是表示每個worker進程所能建立連接的最大值，所以，一個nginx能建立的最大連接數，應該是worker_connections * worker_processes。當然，這裏說的是最大連接數，對於HTTP請求本地資源來說，能夠支持的最大併發數量是worker_connections * worker_processes，而如果是HTTP作爲反向代理來說，最大併發數量應該是worker_connections * worker_processes/2。因爲作爲反向代理服務器，每個併發會建立與客戶端的連接和與後端服務的連接，會佔用兩個連接。

Nginx典型的應用場景

負載均衡技術在現有網絡結構之上提供了一種廉價、有效、透明的方法，來擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。它有兩方面的含義：首先，大量的併發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間；其次，單個重負載的運算分擔到多臺節點設備上做並行處理，每個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力得到大幅度提高

Nginx的應用

1、到官網下載Windows版本，下載地址：http://nginx.org/en/download.html

2、解壓到磁盤任一目錄

3、修改配置文件：具體參考備註。

4、啓動服務：

直接運行nginx.exe，缺點控制檯窗口關閉，服務關閉。

守護進程的方式啓動：start nginx.exe

5、停止服務：nginx -s stop

重新加載配置：nginx -s reload

Nginx常見配置說明

worker_processes 8;

#nginx進程數，建議設置爲等於CPU總核心數

worker_connections 65535;

#單個進程最大連接數（最大連接數=連接數*進程數）

client_header_buffer_size 32k; #上傳文件大小限制

large_client_header_buffers 4 64k; #設定請求緩存頭大小

client_max_body_size 8m; #設定請求緩存體最大值

autoindex on; #開啓目錄列表訪問，合適下載服務器，默認關閉。

tcp_nopush on; #防止網絡阻塞

keepalive_timeout 120; #長連接超時時間，單位是秒

gzip on; #開啓gzip壓縮輸出

gzip_min_length 1k; #最小壓縮文件大小

gzip_buffers 4 16k; #壓縮緩衝區大小

gzip_http_version 1.0; #壓縮版本（默認1.1，前端如果是squid2.5請使用1.0）

gzip_comp_level 2; #壓縮等級

upstream blog.ha97.com {

#upstream的負載均衡，weight是權重，可以根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的機率越大。

server 192.168.80.121:80 weight=3;

server 192.168.80.122:80 weight=2;

server 192.168.80.123:80 weight=3;

}

#虛擬主機的配置

server

#監聽端口

listen 80;

#域名可以有多個，用空格隔開

server_name www.ha97.com ha97.com;

index index.html index.htm index.php;

root /data/www/ha97;

location ~ .*.(php|php5)?$

{

fastcgi_pass 127.0.0.1:9000;

fastcgi_index index.php;

include fastcgi.conf;

}

模塊參數

#定義Nginx運行的用戶和用戶組  

user www www;  


#nginx進程數，建議設置爲等於CPU總核心數。  

worker_processes 8;  


#全局錯誤日誌定義類型，[ debug | info | notice | warn | error | crit ]  

error_log ar/loginx/error.log info;  


#進程文件  

pid ar/runinx.pid;  


#一個nginx進程打開的最多文件描述符數目，理論值應該是最多打開文件數（系統的值ulimit -n）與nginx進程數相除，但是nginx分配請求並不均勻，  
所以建議與ulimit -n的值保持一致。  

worker_rlimit_nofile 65535;  



#工作模式與連接數上限  

events  

{  

#參考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; epoll模型是Linux 2.6以上版本內核中的高性能網絡I/O模型，  
如果跑在FreeBSD上面，就用kqueue模型。  

use epoll;  

#單個進程最大連接數（最大連接數=連接數*進程數）  

worker_connections 65535;  

}  


#設定http服務器  

http  

{  

include mime.types; #文件擴展名與文件類型映射表  

default_type application/octet-stream; #默認文件類型  

#charset utf-8; #默認編碼  

server_names_hash_bucket_size 128; #服務器名字的hash表大小  

client_header_buffer_size 32k; #上傳文件大小限制  

large_client_header_buffers 4 64k; #設定請求緩  

client_max_body_size 8m; #設定請求緩  

sendfile on; #開啓高效文件傳輸模式，sendfile指令指定nginx是否調用sendfile函數來輸出文件，對於普通應用設爲 on，如果用來進行下載等應用磁盤IO重負載應用，  
可設置爲off，以平衡磁盤與網絡I/O處理速度，降低系統的負載。注意：如果圖片顯示不正常把這個改成off。  

autoindex on; #開啓目錄列表訪問，合適下載服務器，默認關閉。  

tcp_nopush on; #防止網絡阻塞  

tcp_nodelay on; #防止網絡阻塞  

keepalive_timeout 120; #長連接超時時間，單位是秒  



#FastCGI相關參數是爲了改善網站的性能：減少資源佔用，提高訪問速度。下面參數看字面意思都能理解。  

fastcgi_connect_timeout 300;  

fastcgi_send_timeout 300;  

fastcgi_read_timeout 300;  

fastcgi_buffer_size 64k;  

fastcgi_buffers 4 64k;  

fastcgi_busy_buffers_size 128k;  

fastcgi_temp_file_write_size 128k;  


#gzip模塊設置  

gzip on; #開啓gzip壓縮輸出  

gzip_min_length 1k; #最小壓縮文件大小  

gzip_buffers 4 16k; #壓縮緩衝區  

gzip_http_version 1.0; #壓縮版本（默認1.1，前端如果是squid2.5請使用1.0）  

gzip_comp_level 2; #壓縮等級  

gzip_types text/plain application/x-javascript text/css application/xml;  

#壓縮類型，默認就已經包含textml，所以下面就不用再寫了，寫上去也不會有問題，但是會有一個warn。  

gzip_vary on;  

#limit_zone crawler $binary_remote_addr 10m; #開啓限制IP連接數的時候需要使用  



upstream blog.ha97.com {  

#upstream的負載均衡，weight是權重，可以根據機器配置定義權重。weigth參數表示權值，權值越高被分配到的機率越大。  

server 192.168.80.121:80 weight=3;  

server 192.168.80.122:80 weight=2;  

server 192.168.80.123:80 weight=3;  

}  



#虛擬主機的配置  

server  

{  

#監聽端口  

listen 80;  

#域名可以有多個，用空格隔開  

server_name www.ha97.com ha97.com;  

index index.html index.htm index.php;  

root /data/www/ha97;  

location ~ .*.(php|php5)?$  

{  

fastcgi_pass 127.0.0.1:9000;  

fastcgi_index index.php;  

include fastcgi.conf;  

}  

#圖片緩存時間設置  

location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$  

{  

expires 10d;  

}  

#JS和CSS緩存時間設置  

location ~ .*.(js|css)?$  

{  

expires 1h;  

}  

#日誌格式設定  

log_format access '$remote_addr - $remote_user [$time_local] "$request" '  

'$status $body_bytes_sent "$http_referer" '  

'"$http_user_agent" $http_x_forwarded_for';  

#定義本虛擬主機的訪問日誌  

access_log ar/loginx/ha97access.log access;  



#對 "/" 啓用反向代理  

location / {  

proxy_pass http://127.0.0.1:88;  

proxy_redirect off;  

proxy_set_header X-Real-IP $remote_addr;  

#後端的Web服務器可以通過X-Forwarded-For獲取用戶真實IP  

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  

#以下是一些反向代理的配置，可選。  

proxy_set_header Host $host;  

client_max_body_size 10m; #允許客戶端請求的最大單文件字節數  

client_body_buffer_size 128k; #緩衝區代理緩衝用戶端請求的最大字節數，  

proxy_connect_timeout 90; #nginx跟後端服務器連接超時時間(代理連接超時)  

proxy_send_timeout 90; #後端服務器數據回傳時間(代理髮送超時)  

proxy_read_timeout 90; #連接成功後，後端服務器響應時間(代理接收超時)  

proxy_buffer_size 4k; #設置代理服務器（nginx）保存用戶頭信息的緩衝區大小  

proxy_buffers 4 32k; #proxy_buffers緩衝區，網頁平均在32k以下的設置  

proxy_busy_buffers_size 64k; #高負荷下緩衝大小（proxy_buffers*2）  

proxy_temp_file_write_size 64k;  

#設定緩存文件夾大小，大於這個值，將從upstream服務器傳  

}  



#設定查看Nginx狀態的地址  

location /NginxStatus {  

stub_status on;  

access_log on;  

auth_basic "NginxStatus";  

auth_basic_user_file confpasswd;  

#htpasswd文件的內容可以用apache提供的htpasswd工具來產生。  

}  



#本地動靜分離反向代理配置  

#所有jsp的頁面均交由tomcat或resin處理  

location ~ .(jsp|jspx|do)?$ {  

proxy_set_header Host $host;  

proxy_set_header X-Real-IP $remote_addr;  

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  

proxy_pass http://127.0.0.1:8080;  

}  

#所有靜態文件由nginx直接讀取不經過tomcat或resin  

location ~ .*.(htm|html|gif|jpg|jpeg|png|bmp|swf|ioc|rar|zip|txt|flv|mid|doc|ppt|pdf|xls|mp3|wma)$  

{ expires 15d; }  

location ~ .*.(js|css)?$  

{ expires 1h; }  

}  

}

更詳細的模塊參數請參考：http://wiki.nginx.org/Main

案例

Nginx+IIS服務器搭建服務器集羣

配置靜態資源

location ~ \.(jpg|png|jpeg|bmp|gif|swf|css)$  
        {  
            expires 30d;  
             root /nginx-1.4.7;#root:  
            break;  
        }

擴展

負載均衡策略：http://baidutech.blog.51cto.com/4114344/1033718/

Mrzhoug

發佈了88 篇原創文章 · 獲贊 31 · 訪問量 22萬+

私信關注

應用服務器知識(7)--Nginx詳解

Nginx是什麼

Nginx的應用現狀

Nginx的特點

Nginx的事件處理機制

Nginx的不爲人知的特點

Nginx的內部(進程)模型

Nginx是如何處理一個請求

Nginx典型的應用場景

Nginx的應用

Nginx常見配置說明

模塊參數

案例

配置靜態資源

擴展

.Net 8.0 下的新RPC，IceRPC之試試的新玩法"打洞"

完美替代postman的軟件

Vue mockjs mock.js

關於遊戲付費的一點想法

我通過CKA和CKS啦！

《最新出爐》系列入門篇-Python+Playwright自動化測試-42-強大的可視化追蹤利器Trace Viewer

大數據怎麼學？對大數據開發領域及崗位的詳細解讀，完整理解大數據開發領域技術體系

由《炮灰模型——女生選擇追求者模型》到“微軟鑽石題”

應用服務器知識(1)--JBoss

應用服務器知識(3)--Tomcat啓動框架

編譯原理知識(1)--Java實現本地時間獲取

編譯原理知識(2)--編譯過程

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結