1，編譯安裝nginx應用，提供wordpress服務
wget?http://nginx.org/download/nginx-1.14.2.tar.gz #下載nginx源碼包? ??
tar?-zxf?nginx-1.12.1.tar.gz? #解壓包
yum groupinstall "Development Tools"? #下載編譯包組
yum?install?openssl-devel?pcre-devel?libevent-devel?-y #下載所需依賴的包
cd nginx-1.14.2 #進入解壓目錄
nginx-1.14.2]#?./configure?\? #執行編譯操作指定選項
--prefix=/usr/local/nginx?\
--sbin-path=/usr/sbin/nginx?\
--conf-path=/etc/nginx/nginx.conf?\
--error-log-path=/var/log/nginx/error.log?\
--http-log-path=/var/log/nginx/access.log?\
--pid-path=/var/run/nginx.pid?\
--lock-path=/var/lock/subsys/nginx.lock?\
--user=nginx?--group=nginx?\
--with-http_ssl_module?\
--with-http_v2_module?\
--with-http_dav_module?\
--with-threads?\
--with-file-aio?\
--with-http_stub_status_module
make?&&?make?install #編譯并且復制文件到指定的目錄下
nginx-1.14.2]#?useradd?nginx??#同名組自動創建
因為在進行編譯配置的時候我們就將nginx的二進制文件寫到了“/usr/sbin/”下，所以我們可以直接使用命令來啟動nginx：
nginx-1.14.2]#?nginx
接下來我們使用命令來查看nginx是否啟動成功：
nginx-1.14.1=2]# ss -tnl
使用命令停掉httpd（如果沒啟動就不用管了）：
~]#?service?httpd?stop
????此時在真實主機上就可以通過瀏覽器訪問“192.168.1.198”（這個IP是剛才虛擬機的IP）
這樣的Nginx的配置就完成了，下面開始配置1個虛擬主機，1個虛擬主機的根目錄我存放在“/myweb/wordpress
?mkdir?-pv?/myweb/wordpress
nginx-1.12.1]#?vim?/etc/nginx/nginx.conf
在“http”的大括號中添加下面這條：
include?/etc/nginx/conf/*.conf"
? ? 接下來我們在“/etc/nginx/conf/”下創建一個以“.conf”結尾的片段配置文件并寫入內容：
server?{
??listen?80;
??server_name?myweb.wordpress.com;
??location?/?{
????root?/myweb/wordpress;
????index?index.html;
??}
}
?保存并退出之后，使用“nginx -t”命令檢查配置文件是否有錯誤，如果沒有錯誤，就使用“nginx -s reload”命令重新載入配置：
wordpress需要依賴數據庫，所以需要先安裝數據庫，我這里默認安裝為mariadb
yum install mariadb-server
https://cn.wordpress.org/latest-zh_CN.zip
然后分別解壓到各自對應的目錄中：
~]# tar -zxf?wordpress-4.9.4-zh_CN.tar.gz?-C /myweb/wordpress/
systemctl start mariadb 啟動數據庫
CREATE USER 'wordpress'@'%' IDENTIFIED BY '123456';?這種方法允許任何遠程連接
[root@centos7 wordpress]# cp ../wordpress/wp-config-sample.php ./wp-config.php
[root@centos7 wordpress]# vim wp-config.php
先拷貝一份wordpress自帶的配置文件，并修改其配置信息：
yum install php php-fpm && systemctl start php #安裝并啟動phpfpm協議
置完成之后，我們還需要回到剛才配置虛擬主機那里把剛才的配置增加幾條選項，變成下面的樣子（因為Nginx默認將PHP注釋掉了，需要我們自己開啟）：
server?{
??listen?80;
??server_name?192.168.1.198;??
??location?/?{
????root?/myweb/wordpress/wordpress;
????index?index.html?index.php;
??}?????
??location?~?\.php$?{
????root?/myweb/wordpress/wordpress;
??include????????fastcgi_params;
??fastcgi_pass???127.0.0.1:9000;
??fastcgi_index??index.php;
??fastcgi_param??SCRIPT_FILENAME??$document_root$fastcgi_script_name;
??}?????
}
yum install php php-fpm && systemctl start php #安裝并啟動phpfpm協議
搭建成功
2，簡述nginx特性，并與apache簡單對比
程序環境
配置文件的組成部分：
主配置文件：nginx.conf
include conf.d/*.conf
fastcgi， uwsgi，scgi等協議相關的配置文件
mime.types：支持的mime類型
主程序文件：/usr/sbin/nginx
Unit File：nginx.service
注意：
(1) 指令必須以分號結尾；
(2) 支持使用配置變量；
內建變量：由Nginx模塊引入，可直接引用；
自定義變量：由用戶使用set命令定義；
set variable_name value;
引用變量：$variable_name
主配置文件結構：
main block：主配置段，也即全局配置段；
event {
...
}：事件驅動相關的配置；
http {
...
}：http/https 協議相關的配置段；
mail {
...
}
stream {
...
}
http協議相關的配置結構
http {
...
...：各server的公共配置也稱全局配置
server {
...
}：每個server用于定義一個虛擬主機；
server {
...
listen
server_name
root
alias
location [OPERATOR] URL {
...
if CONDITION {
...
Nginx（2）
配置指令：
main配置段常見的配置指令：
分類：
正常運行必備的配置
優化性能相關的配置
用于調試及定位問題相關的配置
事件驅動相關的配置
正常運行必備的配置：
1、user
Syntax: user user [group];
Default: user nobody nobody;
Context: main
Defines user and group credentials used by worker processes. If group is omitted, a group whose name equals that of user is used.
2、pid /PATH/TO/PID_FILE;
指定存儲nginx主進程進程號碼的文件路徑；
3、include file | mask;
指明包含進來的其它配置文件片斷；
4、load_module file;
指明要裝載的動態模塊；
性能優化相關的配置：
1、worker_processes number | auto;
worker進程的數量；通常應該等于小于當前主機的cpu的物理核心數；
auto：當前主機物理CPU核心數；
2、worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
CPU MASK：
00000000：
00000001：0號CPU
00000010：1號CPU
... ...
3、worker_priority number;
指定worker進程的nice值，設定worker進程優先級；[-20,20]
4、worker_rlimit_nofile number;
worker進程所能夠打開的文件數量上限；
調試、定位問題：
1、daemon on|off;
是否以守護進程方式運行Nignx；
2、master_process on|off;
是否以master/worker模型運行nginx；默認為on；
3、error_log file [level];
事件驅動相關的配置:
events {
...
}
1、worker_connections number;
每個worker進程所能夠打開的最大并發連接數數量；
worker_processes * worker_connections
2、use method;
指明并發連接請求的處理方法；
use epoll;
3、accept_mutex on | off;
處理新的連接請求的方法；on意味著由各worker輪流處理新請求，Off意味著每個新請求的到達都會通知所有的worker進程；
web服務中的http中字段配置
1、server { ... }
配置一個虛擬主機；
server {
listen address[:PORT]|PORT;
server_name SERVER_NAME;
root /PATH/TO/DOCUMENT_ROOT;
}
2、listen PORT|address[:port]|unix:/PATH/TO/SOCKET_FILE
? ? ? listen address[:port] [default_server] [ssl] [http2 | spdy]? [backlog=number] [rcvbuf=size] [sndbuf=size]
default_server：設定為默認虛擬主機；
ssl：限制僅能夠通過ssl連接提供服務；
backlog=number：后援隊列長度；
rcvbuf=size：接收緩沖區大小；
sndbuf=size：發送緩沖區大小；
3、server_name name ...;
指明虛擬主機的主機名稱；后可跟多個由空白字符分隔的字符串；
支持*通配任意長度的任意字符；server_name *.magedu.com? www.magedu.*
支持~起始的字符做正則表達式模式匹配；server_name ~^www\d+\.magedu\.com$
匹配機制：
(1) 首先是字符串精確匹配;
(2) 左側*通配符；
(3) 右側*通配符；
(4) 正則表達式；
定義路徑相關的配置：
6、root path;
設置web資源路徑映射；用于指明用戶請求的url所對應的本地文件系統上的文檔所在目錄路徑；可用的位置：http, server, location, if in location；
7、location [ = | ~ | ~* | ^~ ] uri { ... }
Sets configuration depending on a request URI.
在一個server中location配置段可存在多個，用于實現從uri到文件系統的路徑映射；ngnix會根據用戶請求的URI來檢查定義的所有location，并找出一個最佳匹配，而后應用其配置；
=：對URI做精確匹配；例如, http://www.magedu.com/, http://www.magedu.com/index.html
location? =? / {
...
}
~：對URI做正則表達式模式匹配，區分字符大小寫；
~*：對URI做正則表達式模式匹配，不區分字符大小寫；
^~：對URI的左半部分做匹配檢查，不區分字符大小寫；
不帶符號：匹配起始于此uri的所有的url；
匹配優先級：=, ^~, ～/～*，不帶符號；
root /vhosts/www/htdocs/
http://www.magedu.com/index.html --> /vhosts/www/htdocs/index.html
server {
root? /vhosts/www/htdocs/
location /admin/ {
root /webapps/app1/data/
}
}
alias path;
定義路徑別名，文檔映射的另一種機制；僅能用于location上下文；
注意：location中使用root指令和alias指令的意義不同；
(a) root，給定的路徑對應于location中的/uri/左側的/；
(b) alias，給定的路徑對應于location中的/uri/右側的/；
9、index file ...;
默認資源；http, server, location；
10、error_page code ... [=[response]] uri;
Defines the URI that will be shown for the specified errors.
# error_page 404 /404.html; #自定義404的錯誤頁面
#? ? ? ? ? ? location = /40x.html {
#? ? ? ? }
ngx_http_access_module模塊：
實現基于ip的訪問控制功能
location / {
? ? deny? 192.168.1.1;
? ? allow 192.168.1.0/24;
? ? allow 10.1.1.0/16;
? ? allow 2001:0db8::/32;
? ? deny? all;
}
ngx_http_stub_status_module模塊
用于輸出nginx的基本狀態信息；
Active connections: 291
server accepts handled requests
16630948 16630948 31070465
Reading: 6 Writing: 179 Waiting: 106
Active connections: 活動狀態的連接數；
accepts：已經接受的客戶端請求的總數；
handled：已經處理完成的客戶端請求的總數；
requests：客戶端發來的總的請求數；
Reading：處于讀取客戶端請求報文首部的連接的連接數；
Writing：處于向客戶端發送響應報文過程中的連接數；
Waiting：處于等待客戶端發出請求的空閑連接數；
ngx_http_log_module模塊
he ngx_http_log_module module writes request logs in the specified format.
31、log_format name string ...;
string可以使用nginx核心模塊及其它模塊內嵌的變量；
32、access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;
訪問日志文件路徑，格式及相關的緩沖的配置；
buffer=size
flush=time
33、open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
open_log_file_cache off;
緩存各日志文件相關的元數據信息；
max：緩存的最大文件描述符數量；
min_uses：在inactive指定的時長內訪問大于等于此值方可被當作活動項；
inactive：非活動時長；
valid：驗正緩存中各緩存項是否為活動項的時間間隔；
格式內容
log_format compression '$remote_addr - $remote_user [$time_local] '
? ? ? ? ? ? ? ? ? ? ? '"$request" $status $bytes_sent '
? ? ? ? ? ? ? ? ? ? ? '"$http_referer" "$http_user_agent" "$gzip_ratio"';
access_log /spool/logs/nginx-access.log compression buffer=32k;
http://nginx.org/en/docs/varindex.html?nginx常用變量查看
ngx_http_gzip_module：#nginx的壓縮模塊
ngx_http_gzip_module模塊是一個使用“gzip”方法壓縮響應的過濾器。 這通常有助于將傳輸數據的大小減少一半甚至更多。
1、gzip on | off;
Enables or disables gzipping of responses.
2、gzip_comp_level level;
設置響應的gzip壓縮級別。 可接受的值范圍為1到9。
3、 gzip_disable regex ...;
對具有與任何指定正則表達式匹配的“User-Agent”標頭字段的請求禁用gzipping響應。
4、 gzip_min_length length;
啟用壓縮功能的響應報文大小閾值（下限）；
5、gzip_buffers number size;
支持實現壓縮功能時為其配置的緩沖區數量及每個緩存區的大小；
6、gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ...;
nginx作為代理服務器接收到從被代理服務器發送的響應報文后，在何種條件下啟用壓縮功能的；
off：對代理的請求不啟用
no-cache, no-store，private：表示從被代理服務器收到的響應報文首部的Cache-Control的值為此三者中任何一個，則啟用壓縮功能；
示例：
gzip? on;#開啟壓縮
gzip_comp_level 6;#壓縮登記
gzip_min_length 64;#低于64字節不壓縮
gzip_proxied any; #任何被代理的也需要壓縮
gzip_types text/xml text/css? application/javascript; #壓縮類型
Module ngx_http_ssl_module
http { .
????.. server{?
?listen 443 ssl;
keepalive_timeout 70; #連接超時時長
ssl_protocols ???? TLSv1 TLSv1.1 TLSv1.2;?
?ssl_ciphers ???? AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
?ssl_certificate ???? /usr/local/nginx/conf/cert.pem;? ##私鑰
?ssl_certificate_key ????/usr/local/nginx/conf/cert.key;#證書路徑
#ssl_session_cache??? ??shared:SSL:10m;#ssl會話
ssl_session_timeout?? ??10m;##會話超時時長
?}
mkdir /etc/nginx/certs
? 100? cd /etc/nginx/certs/
?openssl genrsa-out nginx.key 2048
openssl genrsa -out nginx.key 2048? openssl req -new -x509 -key nginx.key -out nginx.cert -days 3650 -subj "/CN www.ilinux.io"
?openssl req -new -x509 -key nginx.key -out nginx.cert -days 3650 -subj "/CN=www.ilinux.io"
生成秘鑰并且自簽名證書實現ssl
ngx_http_rewrite_module模塊：
The ngx_http_rewrite_module module is used to change request URI using PCRE regular expressions, return redirects, and conditionally select configurations.
bbs.magedu.com/ --> www.magedu.com/bbs/,? http://www.magedu.com/ --> https://www.magedu.com/
http://www.magedu.com/login.php;username=tom --> http://www.magedu.com/tom/
http://www.ilinux.io/bbs/ --> http://bbs.ilinux.io/
將用戶請求的URI基于regex所描述的模式進行檢查，而后完成替換；
1、rewrite regex replacement [flag]
將用戶請求的URI基于regex所描述的模式進行檢查，匹配到時將其替換為replacement指定的新的URI；
注意：如果在同一級配置塊中存在多個rewrite規則，那么會自下而下逐個檢查；被某條件規則替換完成后，會重新一輪的替換檢查，因此，隱含有循環機制；[flag]所表示的標志位用于控制此循環機制；
如果replacement是以http://或https://開頭，則替換結果會直接以重向返回給客戶端；
301：永久重定向；
[flag]：
last：重寫完成后停止對當前URI在當前location中后續的其它重寫操作，而后對新的URI啟動新一輪重寫檢查；提前重啟新一輪循環；
break：重寫完成后停止對當前URI在當前location中后續的其它重寫操作，而后直接跳轉至重寫規則配置塊之后的其它配置；結束循環；
redirect：重寫完成后以臨時重定向方式直接返回重寫后生成的新URI給客戶端，由客戶端重新發起請求；不能以http://或https://開頭；302
permanent:重寫完成后以永久重定向方式直接返回重寫后生成的新URI給客戶端，由客戶端重新發起請求；301
ngx_http_referer_module模塊：
The ngx_http_referer_module module is used to block access to a site for requests with invalid values in the “Referer” header field.
1、valid_referers none | blocked | server_names | string ...;
定義referer首部的合法可用值；
none：請求報文首部沒有referer首部；
blocked：請求報文的referer首部沒有值；
server_names：參數，其可以有值作為主機名或主機名模式；
arbitrary_string：直接字符串，但可使用*作通配符；
regular expression：被指定的正則表達式模式匹配到的字符串；要使用~打頭，例如 ~.*\.magedu\.com；
配置示例：
valid_referers none block server_names *.magedu.com *.mageedu.com magedu.* mageedu.* ~\.magedu\.;
if($invalid_referer) {
return http://www.magedu.com/invalid.jpg;
}
ngx_http_proxy_module模塊：
The ngx_http_proxy_module module allows passing requests to another server.
1、proxy_pass URL;
Context: location, if in location, limit_except
注意：proxy_pass后面的路徑不帶uri時，其會將location的uri傳遞給后端主機；
server {
...
server_name HOSTNAME;
location /uri/ {
proxy http://hos[:port];
}
...
}
http://HOSTNAME/uri --> http://host/uri
proxy_pass后面的路徑是一個uri時，其會將location的uri替換為proxy_pass的uri；
server {
...
server_name HOSTNAME;
location /uri/ {
proxy http://host/new_uri/;
}
...
}
http://HOSTNAME/uri/ --> http://host/new_uri/
如果location定義其uri時使用了正則表達式的模式，或在if語句或limt_execept中使用proxy_pass指令，則proxy_pass之后必須不能使用uri; 用戶請求時傳遞的uri將直接附加代理到的服務的之后；
server {
...
server_name HOSTNAME;
location ~|~* /uri/ {
proxy http://host;
}
...
}
http://HOSTNAME/uri/ --> http://host/uri/；
docker run --name websrv1 -it -v /vols/websrv1:/web/htdocs busybox #啟動容器充當后端服務器 并且添加首頁文件，運行程序在前端
/ # httpd -f -h /web/htdocs/
[root@centos7 websrv1]# curl 172.17.0.2 #請求
hello proxy web1 返回成功
2、proxy_set_header field value;?
設定發往后端主機的請求報文的請求首部的值；Context: http, server, location
proxy_set_header X-Real-IP? $remote_addr; #修改向后端發送請求的真正客戶段ip地址
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
修改容器中的日志格式IP地址為X-Real-IP選項指定為真實機器ip
修改nginx代理添加首部X-Real-IP 和ip地址至后端
kill -1 在容器重新加載配置文件
9、proxy_hide_header field;
默認情況下，nginx不會從代理服務器對客戶端的響應中傳遞標題字段“Date”，“Server”，“X-Pad”和“X-Accel -...”。 proxy_hide_header指令設置了不會傳遞的其他字段。
proxy_connect_timeout time;
定義與代理服務器建立連接的超時。 應該注意，此超時通常不會超過75秒。
proxy_read_timeout time;
定義從代理服務器讀取響應的超時。 僅在兩個連續的讀操作之間設置超時，而不是為整個響應的傳輸。
proxy_send_timeout time;
設置將請求傳輸到代理服務器的超時。 僅在兩次連續寫操作之間設置超時，而不是為整個請求的傳輸。 如果代理服務器在此時間內未收到任何內容，則關閉連接。
ngx_http_fastcgi_module模塊：
The ngx_http_fastcgi_module module allows passing requests to a FastCGI server.
配置示例1：
前提：配置好fpm server和mariadb-server服務；
location ~* \.php$ {
root? ? ? ? ? /usr/share/nginx/html;?
fastcgi_pass? 127.0.0.1:9000;#指定fpm地址和端口
fastcgi_index? index.php; #指定首頁
fastcgi_param? SCRIPT_FILENAME? /usr/share/nginx/html$fastcgi_script_name;#指定參數，fastcgi_script_name為uri路徑變量，前面的路徑為fastcgi協議網頁的根目錄
include? ? ? ? fastcgi_params; #包含/etc/nginx/fast_param的文件
}
配置示例2：通過/pm_status和/ping來獲取fpm server狀態信息；
location ~* ^/(pm_status|ping)$ {
include? ? ? ? fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param? SCRIPT_FILENAME? $fastcgi_script_name;
}
4、fastcgi_cache_path path [levels=levels] [use_temp_path=on|off] keys_zone=name:size [inactive=time] [max_size=size] [manager_files=number] [manager_sleep=time] [manager_threshold=time] [loader_files=number] [loader_sleep=time] [loader_threshold=time] [purger=on|off] [purger_files=number] [purger_sleep=time] [purger_threshold=time];
定義fastcgi的緩存；緩存位置為磁盤上的文件系統，由path所指定路徑來定義；
levels=levels：緩存目錄的層級數量，以及每一級的目錄數量；levels=ONE:TWO:THREE
leves=1:2:2
keys_zone=name:size
k/v映射的內存空間的名稱及大小
inactive=time
非活動時長
max_size=size
磁盤上用于緩存數據的緩存空間上限
5、fastcgi_cache zone | off;
調用指定的緩存空間來緩存數據；http, server, location
6、fastcgi_cache_key string;
定義用作緩存項的key的字符串；
7、fastcgi_cache_methods GET | HEAD | POST ...;
為哪些請求方法使用緩存；
8、fastcgi_cache_min_uses number;
緩存空間中的緩存項在inactive定義的非活動時間內至少要被訪問到此處所指定的次數方可被認作活動項；
9、fastcgi_cache_valid [code ...] time;
不同的響應碼各自的緩存時長；
示例：
http {
...
fastcgi_cache_path /var/cache/nginx/fastcgi_cache levels=1:2:1 keys_zone=fcgi:20m inactive=120s;
...
server {
...
location ~* \.php$ {
...
fastcgi_cache fcgi;
fastcgi_cache_key $request_uri;
fastcgi_cache_valid 200 302 10m;
fastcgi_cache_valid 301 1h;
fastcgi_cache_valid any 1m;
...
}
...
}
...
}
3，簡述I/O模型及同步/異步消息通知機制
普及：
用戶空間與內核空間：
?? ?現在操作系統都是采用虛擬存儲器，那么對32位操作系統而言，它的尋址空間（虛擬存儲空間）為4G（2的32次方）。操作系統的核心是內核，獨立于普通的應用程序，可以訪問受保護的內存空間，也有訪問底層硬件設備的所有權限。為了保證用戶進程不能直接操作內核（kernel），保證內核的安全，操作系統將虛擬空間劃分為兩部分，一部分為內核空間，一部分為用戶空間。針對linux操作系統而言，將最高的1G字節（從虛擬地址0xC0000000到0xFFFFFFFF），供內核使用，稱為內核空間，而將較低的3G字節（從虛擬地址0x00000000到0xBFFFFFFF），供各個進程使用，稱為用戶空間。
進程切換：
?? ?為了控制進程的執行，內核必須有能力掛起正在CPU上運行的進程，并恢復以前掛起的某個進程的執行。這種行為被稱為進程切換。因此可以說，任何進程都是在操作系統內核的支持下運行的，是與內核緊密相關的。
從一個進程的運行轉到另一個進程上運行，這個過程中經過下面這些變化：
保存處理機上下文，包括程序計數器和其他寄存器。
更新PCB信息。
把進程的PCB移入相應的隊列，如就緒、在某事件阻塞等隊列。
選擇另一個進程執行，并更新其PCB。
更新內存管理的數據結構。
恢復處理機上下文。
注：總而言之就是很耗資源，具體的可以參考這篇文章：
http://guojing.me/linux-kernel-architecture/posts/process-switch/
進程阻塞：
?? ?正在執行的進程，由于期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新數據尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由運行狀態變為阻塞狀態。可見，進程的阻塞是進程自身的一種主動行為，也因此只有處于運行態的進程（獲得CPU），才可能將其轉為阻塞狀態。當進程進入阻塞狀態，是不占用CPU資源的。
文件描述符：
?? ?文件描述符（File descriptor）是計算機科學中的一個術語，是一個用于表述指向文件的引用的抽象化概念。
文件描述符在形式上是一個非負整數。實際上，它是一個索引值，指向內核為每一個進程所維護的該進程打開文件的記錄表。當程序打開一個現有文件或者創建一個新文件時，內核向進程返回一個文件描述符。在程序設計中，一些涉及底層的程序編寫往往會圍繞著文件描述符展開。但是文件描述符這一概念往往只適用于UNIX、Linux這樣的操作系統。
緩存IO：
?? ?緩存 IO 又被稱作標準 IO，大多數文件系統的默認 IO 操作都是緩存 IO。在 Linux 的緩存 IO 機制中，操作系統會將 IO 的數據緩存在文件系統的頁緩存（ page cache ）中，也就是說，數據會先被拷貝到操作系統內核的緩沖區中，然后才會從操作系統內核的緩沖區拷貝到應用程序的地址空間。
緩存IO的缺點：
?? ?數據在傳輸過程中需要在應用程序地址空間和內核進行多次數據拷貝操作，這些數據拷貝操作所帶來的 CPU 以及內存開銷是非常大的。
Linux IO模型：
?? ?網絡IO的本質是socket的讀取,socket在linux系統中被抽象為流,IO可以理解為對流的操作.對于一次IO訪問,數據會先被拷到操作系統內核的緩沖區中,然后才會從操作系統內核的緩沖區拷貝到應用程序的地址空間,所以說當一個read操作發生時,它會經理兩個階段:
1
2
第一階段：等待數據準備 (Waiting?for?the data to be ready)。
第二階段：將數據從內核拷貝到進程中 (Copying the data from the kernel to the process)。
?? ?對socket流而言:
1
2
第一步：通常涉及等待網絡上的數據分組到達，然后被復制到內核的某個緩沖區。
第二步：把數據從內核緩沖區復制到應用進程緩沖區。
網絡應用需要處理的無非就是兩大類問題，網絡IO，數據計算。相對于后者，網絡IO的延遲，給應用帶來的性能瓶頸大于后者。網絡IO的模型大致有如下幾種：
同步模型（synchronous IO）
???阻塞IO（bloking IO）
???非阻塞IO（non-blocking IO）
???多路復用IO（multiplexing IO）
???信號驅動式IO（signal-driven IO）
異步IO（asynchronous IO）
同步4個：阻塞IO、非阻塞IO、多路復用IO、信號驅使式IO
異步1個：異步IO
注：由于信號驅動式(signal driven IO)在實際中并不常用，所以我這只提及剩下的四種IO Model。
在深入介紹Linux IO各種模型之前，讓我們先來探索一下基本 Linux IO 模型的簡單矩陣。如下圖所示：
每個 IO 模型都有自己的使用模式，它們對于特定的應用程序都有自己的優點。
同步和異步主要針對C（client）端
同步：
所謂的同步，就是在c端發出一個功能調用時，在沒有得到結果之前，該調用步返回，也就是說必須一件一件事做，等前一件事完了之后才做后一件事。
如：普通的B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回，這期間客戶端瀏覽器不能干任何事
異步：
與同步相對。當C端一個異步過程調用發出之后，調用者不能立即得到結果，實際處理這個調用的部件在完成后，通過狀態，通知和回調來通知調用者。
如：請求通過事件觸發->服務器處理（瀏覽器仍然可以做其他事情）->處理完畢
阻塞和非阻塞主要針對S端（server）
阻塞：
阻塞調用是指調用結果返回之前，當前線程會被掛起（線程進入非可執行狀態，在這個狀態，cpu不會分配時間片，線程暫停運行）函數只有得到結果返回。
阻塞調用和同步調用的區別：對同步來說，很多時候當前線程還是激活的，只是邏輯上沒有返回，如，在socket編程中調用recv函數，如果緩沖區沒有數據，這個函數就會一直等待，直到有數據返回。而此前當前線程還有可能繼續處理各種各樣的消息。
阻塞的例子：比如去取A樓一層（假設是內核緩沖區）取快遞，但是比不知道什么時候來，你有不能干別的事情，只能死等著但是可以睡覺（進程處于休眠狀態)，因為你知道快遞把貨送來時一定會給比大電話
非阻塞：
非阻塞與阻塞概念想對應，指在不能立即得到結果之前，該函數不會阻塞當前線程，而會立即返回。
非阻塞的例子：還是等快遞，如果用輪詢的方式，每隔5分鐘去A樓一層（內核緩沖區）去看快遞來了沒，沒來，立即返回，如果快遞來了，就放到A樓一層，等你去取。
對象是否處于阻塞模式和函數是不是阻塞調用有很強的相關性，但不是一一對應的。阻塞對象上可以有非阻塞的調用方式，我們可以通過輪詢狀態，在適當的時候調用阻塞函數，就可以避免阻塞，而對于非阻塞對象，調用函數可以進入阻塞調用，對于select：
1：同步?
1我客戶端（C端調用者）一個功能，該功能沒有結束前，我死等結果。
2：異步
我（c端調用者）調用一個功能，不知道該功能結果，該功能有結果后通知我，即回調通知
同步和異步主要針對c端，但是跟s端不是完全沒關系，同步和異步必須s端配合才能實現，同步和異步由c端控制，但是s端是否為阻塞還是非阻塞，c端不關心。
3：阻塞
1就是調用我（s端被調用者，函數），我（s端被調用者，函數）沒有完全接受完數據或者沒有得到結果之前，我不會返回。
4：非阻塞
1就是調用我（s端被調用者，函數），我（s端被調用者，函數）立即返回，通過select通知調用者
同步I/O與異步I/O的區別在與數據訪問的時候進程是否阻塞
阻塞I/O與非阻塞I/O的區別在與：應該程序的調用是否立即返回。
阻塞和非阻塞是指server端的進程訪問的數據如果尚未就緒，進程是否需要等待，簡單說這相當于函數內部的實現區別，也就是未就緒時時直接返回還是等待就緒。
就同步和異步是指client端訪問數據的機制，同步一般指主動請求并等待I/O操作完畢的方式，當數據就緒后再讀寫額時候必須阻塞，異步則指主動請求數據后便可以繼續處理其他任務，隨后等待I/O，操作完畢的通知。
一、阻塞I/O模型：
簡介：進程會一直阻塞，直到數據拷貝完成
應用程序調用一個I/O函數，導致應用程序阻塞，等待數據準備好，如果數據沒有準備好，一直等待。。數據準備好，從內核拷貝到用戶空間，I/O函數返回成功
阻塞I/O模型圖：在調用recv()/recvfrom()，發生在內核中等待數據和復制數據過程。
當調用recv()函數時，系統首先檢查是否有準備好的數據，如果數據沒有準備好，那么系統就處于等待狀態，當數據準備好后，將數據從系統緩沖區復制到用戶空間，然后函數返回。在套接應用程序中，當調用recv()函數時，未必用戶空間就已經存在數據，那么此時recv()函數處于等待狀態
二、非阻塞I/O模型：
簡介：我們把一個套接口設置為非阻塞就是告訴內存，當所請求的I/O操作無法完成時，不要驚進程睡眠，而是返回一個錯誤，河陽I/O函數會不斷的測試數據是否準備好，沒有準備好，繼續測試，直到數據準備好為止。在測試的過程中會占用大量的CPU時間。
三、I/O復用模型：
簡介：主要是select和epoll；對于一個I/O端口，兩次調用，兩次返回，比阻塞I/O并沒有什么優勢，只是能實現同時對多個I/O端口進行監聽。
I/O復用模型會調用select，poll函數，這幾個函數也會使進程阻塞，但是和阻塞I/O不同的，這個函數可以同時阻塞多個I/O操作，而且可以同時對多個讀操作，多個寫操作的I/O函數進行檢測，直到有數據可讀或可寫時，才真正調用I/O操作函數。
四、信號驅動I/O：
簡介：兩次調用，兩次返回
首先允許套接口進行信號驅動I/O，并安裝一個信號處理函數，進程繼續運行并不阻塞。昂數據準備好時，進程會收到一個SIGIO信號，可以在信號處理函數中調用I/O操作函數處理數據。
五、異步I/O模型：
簡介：數據拷貝的時候進程無需阻塞
當一個異步過程調用發出后，調用者不能立刻得到結果。實際處理這個調用的部件在完成后，通過狀態，通知和回調通知調用者輸入輸出操作。
同步I/O引起進程阻塞，直到I/O操作完成
異步I/O不會引起進程阻塞
I/O復用先通過select調用阻塞
NGINX：
nginx 支持多種并發模型，并發模型的具體實現根據系統平臺而有所不同。
在支持多種并發模型的平臺上，nginx 自動選擇最高效的模型。但我們也可以使用 use 指令在配置文件中顯式地定義某個并發模型。
NGINX中支持的并發模型：
select：
1IO多路復用、標準并發模型。在編譯 nginx 時，如果所使用的系統平臺沒有更高效的并發模型，select?模塊將被自動編譯。configure 腳本的選項：--with-select_module 和 --without-select_module 可被用來強制性地開啟或禁止?select?模塊的編譯
poll：
1IO多路復用、標準并發模型。與?select?類似，在編譯 nginx 時，如果所使用的系統平臺沒有更高效的并發模型，poll 模塊將被自動編譯。configure 腳本的選項：--with-poll_module 和 --without-poll_module 可用于強制性地開啟或禁止 poll 模塊的編譯
epoll：
1IO多路復用、高效并發模型，可在 Linux 2.6+ 及以上內核可以使用
kqueue：
1IO多路復用、高效并發模型，可在 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0, and Mac OS X 平臺中使用
/dev/poll：
1高效并發模型，可在 Solaris 7 11/99+, HP/UX?11.22+ (eventport), IRIX 6.5.15+, and Tru64 UNIX 5.1A+ 平臺使用
eventport：
1高效并發模型，可用于 Solaris 10 平臺，PS：由于一些已知的問題，建議 使用/dev/poll替代。
為什么epoll快？
比較一下Apache常用的select，和Nginx常用的epoll
select：
1、最大并發數限制，因為一個進程所打開的 FD （文件描述符）是有限制的，由 FD_SETSIZE 設置，默認值是 1024/2048?，因此 Select 模型的最大并發數就被相應限制了。自己改改這個 FD_SETSIZE ？想法雖好，可是先看看下面吧 …
2、效率問題，?select?每次調用都會線性掃描全部的 FD 集合，這樣效率就會呈現線性下降，把 FD_SETSIZE 改大的后果就是，大家都慢慢來，什么？都超時了。
3、內核 / 用戶空間 內存拷貝問題，如何讓內核把 FD 消息通知給用戶空間呢？在這個問題上?select?采取了內存拷貝方法，在FD非常多的時候，非常的耗費時間。
總結為：1、連接數受限 2、查找配對速度慢 3、數據由內核拷貝到用戶態消耗時間
epoll：
1、Epoll 沒有最大并發連接的限制，上限是最大可以打開文件的數目，這個數字一般遠大于 2048, 一般來說這個數目和系統內存關系很大 ，具體數目可以?cat?/proc/sys/fs/file-max?查看。
2、效率提升， Epoll 最大的優點就在于它只管你“活躍”的連接 ，而跟連接總數無關，因此在實際的網絡環境中， Epoll 的效率就會遠遠高于?select?和 poll 。
3、內存共享， Epoll 在這點上使用了“共享內存 ”，這個內存拷貝也省略了。
4,，實現lnmp提供多個虛擬主機，nginx和php使用不同主機
使用容器搭建
docker pull php:7-fpm-alpine?
docker run --name fpmsrv1 -d --network bridge -v /vols/phpsrv1:/appdata php:7-fpm-alpine #創建容器
[root@centos7 nginx]# vim /vols/phpsrv1/index.php #創建測試頁
<?php
? ? ? ? phpinfo();
?>
[root@centos7 nginx]# vim /etc/nginx/nginx.conf #修改配置文件
server {
? ? ? ? listen 8080;
? ? ? ? server_name 192.168.1.198;
? ? ? ? root "/web/nginx/html";
? ? ? ? location / {
? ? ? ? ? ? ? ? root "/web/nginx/html";
? ? ? ? ? ? ? ? index index.html;
? ? ? ? }
? ? ? ? location = /ngx_status {
? ? ? ? ? ? ? ? stub_status;
? ? ? ? }
? ? ? ? location /bbs/ {
? ? ? ? ? ? ? ? rewrite ^/bbs/(.*)$ /froum/$1 break;
? ? ? ? }
? ? ? ? location ~* \.php$ {
? ? ? ? ? ? ? ? fastcgi_pass 172.17.0.3:9000;
? ? ? ? ? ? ? ? fastcgi_index index.php;
? ? ? ? ? ? ? ? fastcgi_param SCRIPT_FILENAME /appdata$fastcgi_script_name;將后端fpm地址映射至本地路徑
? ? ? ? ? ? ? ? include fastcgi_params;#將本地的/etc/nginx/fastcgi_params包含進來
? ? ? ? }
}
5，自定義錯誤404和5xx錯誤頁，文本靜態內容傳輸壓縮
10、error_page code ... [=[response]] uri;
Defines the URI that will be shown for the specified errors.
# error_page 404 /404.html; #自定義404的錯誤頁面
#? ? ? ? ? ? location = /40x.html {
#? ? ? ? }
error_page 502 503 /50x.html;
location = /50x.html {
? ? root /usr/share/nginx/50x.html;
}?
error_page 404 403 /40x.html;
location = /50x.html {
? ? root /usr/share/nginx40x.html;
}?
error_page 404 /404.html 可顯示自定義404頁面內容，正常返回404狀態碼。
error_page 404 = /404.html 可顯示自定義404頁面內容，但返回200狀態碼。
error_page 404 /404.php 如果是動態404錯誤頁面，包含 header 代碼（例如301跳轉），將無法正常執行。正常返回404代碼。
error_page 404 = /404.php 如果是動態404錯誤頁面，包含 header 代碼（例如301跳轉），加等號配置可以正常執行，返回php中定義的狀態碼。但如果php中定義返回404狀態碼，404狀態碼可以正常返回，但無法顯示自定義頁面內容（出現系統默認404頁面），這種情況可以考慮用410代碼替代（ header("HTTP/1.1 410 Gone"); 正常返回410狀態碼，且可正常顯示自定義內容）。
ngx_http_gzip_module：#nginx的壓縮模塊
ngx_http_gzip_module模塊是一個使用“gzip”方法壓縮響應的過濾器。 這通常有助于將傳輸數據的大小減少一半甚至更多。
1、gzip on | off;
Enables or disables gzipping of responses.
2、gzip_comp_level level;
設置響應的gzip壓縮級別。 可接受的值范圍為1到9。
3、 gzip_disable regex ...;
對具有與任何指定正則表達式匹配的“User-Agent”標頭字段的請求禁用gzipping響應。
4、 gzip_min_length length;
啟用壓縮功能的響應報文大小閾值（下限）；
5、gzip_buffers number size;
支持實現壓縮功能時為其配置的緩沖區數量及每個緩存區的大小；
6、gzip_proxied off | expired | no-cache | no-store | private | no_last_modified | no_etag | auth | any ...;
nginx作為代理服務器接收到從被代理服務器發送的響應報文后，在何種條件下啟用壓縮功能的；
off：對代理的請求不啟用
no-cache, no-store，private：表示從被代理服務器收到的響應報文首部的Cache-Control的值為此三者中任何一個，則啟用壓縮功能；
示例：
gzip? on;#開啟壓縮
gzip_comp_level 6;#壓縮登記
gzip_min_length 64;#低于64字節不壓縮
gzip_proxied any; #任何被代理的也需要壓縮
gzip_types text/xml text/css? application/javascript; #壓縮類型
6，實現4個虛擬主機，混合使用三種類型的虛擬主機，僅開放給來自于本地網絡中的主機訪問
server {
? ? ? ? listen 8088;
? ? ? ? server_name www.stephenzhong.com;
? ? ? ? proxy_set_header X-Real-IP $remote_addr;
? ? ? ? location / {
? ? ? ? ? ? ? ? proxy_pass http://172.17.0.2/;
? ? ? ? }
? ? ? ? location ~* \.(jpg|jepg|png) {
? ? ? ? ? ? ? ? proxy_pass http://172.17.0.2;
? ? ? ? }
}? ? ? ?
? ? server {
? ? ? ? listen 8080;
? ? ? ? server_name 192.168.1.198;
? ? ? ? root "/web/nginx/html";
? ? ? ? location / {
? ? ? ? ? ? ? ? root "/web/nginx/html";
? ? ? ? ? ? ? ? index index.html;
? ? ? ? }
? ? ? ? location = /ngx_status {
? ? ? ? ? ? ? ? stub_status;
? ? ? ? }
? ? ? ? location /bbs/ {
? ? ? ? ? ? ? ? rewrite ^/bbs/(.*)$ /froum/$1 break;
? ? ? ? }
? ? ? ? location ~* \.php$ {
? ? ? ? ? ? ? ? fastcgi_pass 172.17.0.3:9000;
? ? ? ? ? ? ? ? fastcgi_index index.php;
? ? ? ? ? ? ? ? fastcgi_param SCRIPT_FILENAME /appdata$fastcgi_script_name;
? ? ? ? ? ? ? ? include fastcgi_params;
? ? ? ? }
}
mkdir /etc/nginx/certs
? 100? cd /etc/nginx/certs/
?openssl genrsa-out nginx.key 2048
openssl genrsa -out nginx.key 2048? openssl req -new -x509 -key nginx.key -out nginx.cert -days 3650 -subj "/CN www.ilinux.io"
?openssl req -new -x509 -key nginx.key -out nginx.cert -days 3650 -subj "/CN=www.ilinux.io"
生成秘鑰并且自簽名證書實現ssl
7，實現lnmp，提供多個虛擬主機?
? ? 1）http，提供wordpress
wget?http://nginx.org/download/nginx-1.14.2.tar.gz #下載nginx源碼包? ??
tar?-zxf?nginx-1.12.1.tar.gz? #解壓包
yum groupinstall "Development Tools"? #下載編譯包組
yum?install?openssl-devel?pcre-devel?libevent-devel?-y #下載所需依賴的包
cd nginx-1.14.2 #進入解壓目錄
nginx-1.14.2]#?./configure?\? #執行編譯操作指定選項
--prefix=/usr/local/nginx?\
--sbin-path=/usr/sbin/nginx?\
--conf-path=/etc/nginx/nginx.conf?\
--error-log-path=/var/log/nginx/error.log?\
--http-log-path=/var/log/nginx/access.log?\
--pid-path=/var/run/nginx.pid?\
--lock-path=/var/lock/subsys/nginx.lock?\
--user=nginx?--group=nginx?\
--with-http_ssl_module?\
--with-http_v2_module?\
--with-http_dav_module?\
--with-threads?\
--with-file-aio?\
--with-http_stub_status_module
make?&&?make?install #編譯并且復制文件到指定的目錄下
nginx-1.14.2]#?useradd?nginx??#同名組自動創建
因為在進行編譯配置的時候我們就將nginx的二進制文件寫到了“/usr/sbin/”下，所以我們可以直接使用命令來啟動nginx：
nginx-1.14.2]#?nginx
接下來我們使用命令來查看nginx是否啟動成功：
nginx-1.14.1=2]# ss -tnl
使用命令停掉httpd（如果沒啟動就不用管了）：
~]#?service?httpd?stop
????此時在真實主機上就可以通過瀏覽器訪問“192.168.1.198”（這個IP是剛才虛擬機的IP）
這樣的Nginx的配置就完成了，下面開始配置1個虛擬主機，1個虛擬主機的根目錄我存放在“/myweb/wordpress
?mkdir?-pv?/myweb/wordpress
nginx-1.12.1]#?vim?/etc/nginx/nginx.conf
在“http”的大括號中添加下面這條：
include?/etc/nginx/conf/*.conf"
? ? 接下來我們在“/etc/nginx/conf/”下創建一個以“.conf”結尾的片段配置文件并寫入內容：
server?{
??listen?80;
??server_name?myweb.wordpress.com;
??location?/?{
????root?/myweb/wordpress;
????index?index.html;
??}
}
?保存并退出之后，使用“nginx -t”命令檢查配置文件是否有錯誤，如果沒有錯誤，就使用“nginx -s reload”命令重新載入配置：
wordpress需要依賴數據庫，所以需要先安裝數據庫，我這里默認安裝為mariadb
yum install mariadb-server
https://cn.wordpress.org/latest-zh_CN.zip
然后分別解壓到各自對應的目錄中：
~]# tar -zxf?wordpress-4.9.4-zh_CN.tar.gz?-C /myweb/wordpress/
systemctl start mariadb 啟動數據庫
CREATE USER 'wordpress'@'%' IDENTIFIED BY '123456';?這種方法允許任何遠程連接
[root@centos7 wordpress]# cp ../wordpress/wp-config-sample.php ./wp-config.php
[root@centos7 wordpress]# vim wp-config.php
先拷貝一份wordpress自帶的配置文件，并修改其配置信息：
yum install php php-fpm && systemctl start php #安裝并啟動phpfpm協議
置完成之后，我們還需要回到剛才配置虛擬主機那里把剛才的配置增加幾條選項，變成下面的樣子（因為Nginx默認將PHP注釋掉了，需要我們自己開啟）：
server?{
??listen?80;
??server_name?192.168.1.198;??
??location?/?{
????root?/myweb/wordpress/wordpress;
????index?index.html?index.php;
??}?????
??location?~?\.php$?{
????root?/myweb/wordpress/wordpress;
??include????????fastcgi_params;
??fastcgi_pass???127.0.0.1:9000;
??fastcgi_index??index.php;
??fastcgi_param??SCRIPT_FILENAME??$document_root$fastcgi_script_name;
??}?????
}
yum install php php-fpm && systemctl start php #安裝并啟動phpfpm協議
搭建成功
? ? 2）https，提供pma
