一、研究Nginx前的準備工作 1.Nginx特點:更快、高擴展性、高可靠性、低內(nèi)存消耗、單機支持10萬以上的并發(fā)連接、熱部署、最自由的BSD許可協(xié)議 2.退出nginx nginx -s stop nginx -s quit
3.日志回滾:nginx -s reopen 二、Nginx的配置 A.運行中的Nginx進程間的關系 一般情況下,worker進程的數(shù)量與服務器上的CPU數(shù)量相等
B.Nginx服務的基本配置 1.用于調(diào)試進程和定位問題的配置項 daemon on | off;:是否以守護進程方式運行Nginx,默認on master_process on | off;:是否以master/worker方式工作,默認on error_log pathfile level;:error日志的設置 debug_points [stop|abort]:幫助用戶跟蹤調(diào)試nginx,一般不用 debug_connection [IP | CIDR]:僅對指定的客戶端輸出debug級別的日志,對定位高并發(fā)請求下發(fā)生的問題有用,需要configure時加入?yún)?shù)--with-debug worker_rlimit_core size;:限制coredump核心轉(zhuǎn)儲文件的大小 working_directory path;:指定coredump文件生成的目錄
2.正常運行的配置項 evn VAR|VAR=VALUE:讓用戶直接設置操作系統(tǒng)上的環(huán)境變量 include pathfile;:嵌入其他配置文件 pid path/file;pid文件的路徑 user username [groupname];:Nginx worker進程運行的用戶及用戶組 worker_rlimit_nofile limit;:指定Nginx worker進程可以打開的最大句柄描述符個數(shù) worker_rlimit_sigpending limit;:限制信號隊列
3.優(yōu)化性能的配置 worker_processes number;:定義worker進程的個數(shù) worder_cpu_affinity cpumask [cpumask...];:綁定worker進程到指定的CPU內(nèi)核 ssl_engine device;:SSL硬件加速 timer_resolution t;:系統(tǒng)調(diào)用gettimeofday的執(zhí)行頻率 worker_priority nice;:worker進程優(yōu)先級設置
4.事件類配置項 accept_mutex [on | off];:是否打開accept鎖,可以讓多個worker進程輪流地、序列化地與新的客戶端建立TCP連接 lock_file path/file;:lock文件的路徑 accept_mutex_delay ms;:使用accept鎖后到真正建立連接之間的延遲時間 multi_accept on | off;:批量建立新連接 use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];:選擇事件模型 worker_connections number;:每個worker的最大連接數(shù)
C.用HTTP核心模塊配置一個靜態(tài)Web服務器 1.虛擬主機與請求的分發(fā) listen address:port[default|default_server|[backlog=num|rcvbuf=size|sndbuf=size|accept_filter=filter|deferred|bind|ipv6only=[on|off]|ssl]];:監(jiān)聽端口,配置在server塊 server_name name[...];:主機名稱,配置在server塊 server_names_hash_bucket_size size;:設置每個散列表占用的內(nèi)存大小,nginx使用散列表來存儲server_name server_names_hash_max_size size;:影響散列表的沖突率,越大消耗的內(nèi)存越多,但散列key的沖突則會降低,檢索速度也快 server_name_in_redirect on|off;:重定向主機名稱的處理 location [=|~|~*|^~|@]/uri/{...}:根據(jù)請求的URI來匹配進入location{}塊中的配置來處理用戶請求,配置在server塊
2.文件路徑的定義 root path;:以root方式設置資源路徑 alias path;:別名,將uri映射到真實的磁盤文件上,只能在location塊中 index file ...;:訪問首頁 error_page code[code...][=|=answer-code]uri|@named_location:根據(jù)HTTP返回碼重定向頁面 recursive_error_pages [on|off];:是否允許遞歸使用error_page try_files path1[path2]uri;:嘗試按照順序訪問每一個path
3.內(nèi)存及磁盤資源的分配 client_body_in_file_only on|clean|off;:HTTP包體只存儲到磁盤文件中 client_body_in_single_buffer on|off;:HTTP包體盡量寫入到一個內(nèi)存buffer中 client_header_buffer_size size;:存儲HTTP頭部的內(nèi)存buffer大小 large_client_header_buffers number size;:定義了Nginx接收一個超大HTTP頭部請求的buffer個數(shù)和每個buffer的大小 client_body_buffer_size size;:存儲HTTP包體的內(nèi)存buffer大小 client_body_temp_path dir-path[level1[level2[level3]]];:HTTP包體的臨時存放目錄 connection_pool_size size;:Nginx對于每個建立成功的TCP連接會預先分配一個內(nèi)存池,這個配置將指定個內(nèi)存池的初始大小,用于減少內(nèi)核對于小塊內(nèi)存的分配次數(shù) request_pool_size size;:Nginx會為每個請求分配一個內(nèi)存池,配置將指定這個內(nèi)存池的初始大小
4.網(wǎng)絡連接的設置 client_header_timeout time:讀取HTTP頭部的超時時間 client_body_timeout time:讀取HTTP包體的超時時間 send_timeout time;:發(fā)送響應的超時時間 reset_timeout_connection on|off;:連接超時后將通過向客戶端發(fā)送RST包來直接重置連接,這個選項打開后,Nginx將直接向用戶發(fā)送RST重置包,不再等待用戶應答,直接釋放緩存 lingering_close off|on|always;:控制Nginx關閉用戶連接的方式 lingering_time time;:對上傳大文件很有用,當超過時間后,不管是否仍在上傳,都會關閉連接 ligering_timeout time;:在lingering_close生效后,在關閉連接前,會檢測是否有用戶發(fā)送的數(shù)據(jù)到達服務器,如果超過時間后還沒有數(shù)據(jù)可讀,就直接關閉連接 keepalive_disable [msie6|safari|none]...:對某些瀏覽器禁用keepalive功能 keepalive_timeout time time:keepalive超時時間 keepalive_requests n;:一個keepalive長連接上允許承載的請求最大數(shù) tcp_nodelay on|off;:確定對keepalive連接是否使用TCP_NODELAY選項 tcp_nopush on|off;:在打開sendfile選項時,確定是否開啟FreeBSD系統(tǒng)上的TCP_NOPUSH或Linux系統(tǒng)上的TCP_CORK功能
5.MIME類型的設置 type{...};:MIME type與文件擴展的映射 default_type MIME-type;:默認MIME type types_hash_bucket_size size;:設置散列表占用的內(nèi)存大小 types_hash_max_size size;:影響散列表的沖突率
6.對客戶端請求的限制 limit_except method...{...}:按HTTP方法名限制用戶請求 client_max_body_size size;:HTTP請求包體的最大值 limit_rate speed;:對客戶端請求限制每秒傳輸?shù)淖止?jié)數(shù) limit_rate_after time;:表示nginx向客戶端發(fā)磅的響應長度超過limit_rate_after后才開始限速
7.文件操作的優(yōu)化 sendfile on|off;:啟用sendfile系統(tǒng)調(diào)用來發(fā)送文件 aio on|off;:表示是否在FreeBSD或Linux系統(tǒng)上啟用內(nèi)核級別的異步I/O功能,與sendfile是互斥的 directio size|off;:在FreeBSD和Linux系統(tǒng)上使用O_DIRECT選項去讀取文件,與sendfile互斥 directio_alignment size;:與directio配合,指定directio方式讀取文件時的對齊方式 open_file_cache max=N[inactive=time]|off;:打開文件緩存 open_file_cache_errors on|off;:是否緩存打開文件錯誤的信息 open_file_cache_min_uses number;:不被淘汰的最小訪問次數(shù),與open_file_cache的inactive配合使用,如果超過了,則不會被淘汰出緩存 open_file_cache_valid time;:檢驗緩存中元素有效性的頻率
8.對客戶端請求的特殊處理 ignore_invalid_headers on|off;:忽略不合法的HTTP頭部 underscores_in_headers on|off;:HTTP頭部是否允許下劃線 if_modified_since [off|exact|before];:對If-Modified-Since頭部的處理策略 log_not_found on|off;:文件未找到時是否記錄到error日志 merge_slashes on|off;:是否合并相鄰的/ resolver address...;:廢黜DNS名字解析服務器的地址 resolver_timeout time;:DNS解析超時時間 server_tokens on|off;:返回錯誤頁面時是否在Server中注明Nginx版本
D.用HTTP proxy module配置一個反向代理服務器 1.負載均衡的基本配置 upstream name {...}:定義了一個上游服務器的集群,便于反向代理中的proxy_pass使用,配置在http塊 server name [weight=number,max_fails=number,fail_timeout=time,down,backup]:指定一臺上游服務器的名字,可以是域名、ip地址端口、UNIX句柄等,配置在upstream塊中 ip_hash;:根據(jù)客戶IP地址將請求始終落在固定的一臺上游服務器中,與weight配置不可同時使用
2.反向代理的基本配置 proxy_pass URL;:將當前請求反向代理到URL參數(shù)指定的服務器上,URL可使用是域名、ip地址端口、UNIX句柄或upstream塊,配置在location、if塊中 proxy_set_header Host $host;:轉(zhuǎn)發(fā)請求中的Host頭,默認proxy_pass不轉(zhuǎn)發(fā) proxy_method method;:轉(zhuǎn)發(fā)時的協(xié)議方法名 proxy_hide_header the_header;:可以指定哪些HTTP頭部字段不能被轉(zhuǎn)發(fā) proxy_pass_header the_header;:與proxy_hide_header相反 proxy_pass_request_body on|off;:確定是否向上游服務器發(fā)送HTTP包體部分 proxy_pass_request_headers on|off;:確定是否轉(zhuǎn)發(fā)HTTP頭部 proxy_redirect [default|off|redirect replacement];:當上游服務器返回重定向或刷新請求時,可以重設HTTP頭部的location或refresh字段 proxy_next_upstream [ errpo,timeout,invalid_header,http500,http_502,http503,http_504,http_404,off]:當一臺上游服務器轉(zhuǎn)發(fā)請求出現(xiàn)錯誤時,繼續(xù)換一臺處理這個請求
三、開發(fā)一個簡單的HTTP模塊 1.整型的封裝:ngx_int_t、ngx_uint_t 2.字符串:ngx_str_t 3.鏈表容器:ngx_list_t 4.key/value對:ngx_table_elt_t 5.緩沖區(qū):ngx_buf_t 6.與ngx_buf_t配合使用的鏈接結(jié)構:ngx_chain_t 四、配置、error日志和請求上下文 五、訪問第三方服務 1.upstream可以保證在與第三方服務器交互時(包括三次握手建立TCP連接、發(fā)送請求、接收響應、四次握手關閉TCP連接等)不會阻塞Nginx進程處理其他請求 2.subrequest是分解復雜請求的一種設計模式,最終也是基于upstream實現(xiàn)的 3.當我們希望把第三方服務的內(nèi)容幾乎原封不動地返回給用戶時,一般使用upstream方式,可以非常高效地透傳HTTP;如果訪問第三方服務只是為了獲取某些信息,再依據(jù)這些信息來構造 響應并傳送給客戶,應該使用subrequest方式 六、開發(fā)一個簡單的HTTP過濾模塊 七、Nginx提供的高級數(shù)據(jù)結(jié)構 八、Nginx基礎架構 九、事件模塊 十、HTTP框架的初始化 十一、HTTP框架的執(zhí)行流程 十二、upstream機制的設計與實現(xiàn) 十三、郵件代理模塊 十四、進程間的通信機制 十五、變量 十六、slab共享內(nèi)存
|