rhce紅帽權威認證技術含csa考試費環(huán)境真題自測腳本1對1輔導nginx

本筆記為千鋒V2017.1《05企業(yè)級自動化項目及公有云運維實戰(zhàn)》，筆記中所涉及到的項目均基于Centos7u3x86_64Centos6u8環(huán)境，筆記內容不包括擴展及提高部分，高級及實戰(zhàn)內容以授課為準。千鋒所有學員均可自由使用和該筆記，為了尊重作者的辛勞，敬請注明出處！ (天云tianyun)mail:yangsNginx基礎NginxNginx(enginex)是一個高性能的HTTP和反向服務器，也是一個IMAP/POP3/SMTP服務高性能的HTTPServer，解決C10k高性能的反向服務器，給加做為LB集群的前端一個負載均衡器IO多路復用I/Omultiplexing【多并發(fā)】第法就是最傳統(tǒng)的多進程并發(fā)模型(每進來一個新的I/O流會分配一個新的進程管理。)第二種方法就是I/O多路復用(單個線程，通過記錄每個I/O流(sock)的狀態(tài)，來同時管理多個I/O流。)I/Omultiplexing這里面的multiplexing指的其實是在單個線程通過記錄每一個流)的狀態(tài)來同時管理多個I/O流。發(fā)明它的原因，是盡量多的提高服務器的吞吐能力。在同一個線程里面，通過撥開關的方式，來同時傳輸多個I/Ongnix會有很多連接進來，epoll會把他們都監(jiān)視起來，然后像撥開關一樣，誰有數(shù)據(jù)就撥向誰，然后調用相應的代碼處理。selectpoll,epoll都是I/O多路復用的具體的實現(xiàn)，其實是他們出現(xiàn)是有先后順序的。I/O多路復用這個概念被提出來以后，select是第一個實現(xiàn)(1983左右在BSD里面實現(xiàn)的)。select被實現(xiàn)以后，很快就出了很多問題。select會修改傳入的參數(shù)數(shù)組，這個對于一個需要調用很多次的函數(shù)，是非常不友好的。select如果任何一個sock(I/Ostream)出現(xiàn)了數(shù)據(jù)，select僅僅會返回，但是并不會告訴你是那個sock上有數(shù)據(jù)，于是你只能自己一個一個的找，10幾個sock可能還好，要是幾萬的sock每次都找一遍select只能監(jiān)視1024個select不是線程安全的，如果你把一個sock加入到select然后突然另外一個線程發(fā)現(xiàn)，這個sock不用，要收回，這個select不支持的，如果你喪心病狂的竟然關掉這個sock,select的標準行為是不可預于是14年以后(1997年）一幫人又實現(xiàn)了poll,poll修復了select的很多問題，比如poll去掉了1024個的限制，于是要多少呢，主人你開心就好poll從設計上來說，不再修改傳入數(shù)組，不過這個要看你的平臺了，所以行走江湖，還是為妙。其實拖14年那么久也不是效率問題，而是那個時代的硬件實在太弱，一臺服務器處理1千多個簡直就是神一樣的存在了，select很長段時間已經(jīng)滿足需求。但是poll仍然不是線程安全的，這就意味著，不管服務器有多強悍，你也只能在一個線程里面處理一組I/O流。你當然可以那多進程來配合了，不過然后你就有了多進程的各種問題。于是5年以后在2002DavideLibenzi實現(xiàn)了epoll可以說是I/O多路復用的一個實現(xiàn)，epoll修復了poll和select絕大部分問題,比如epoll現(xiàn)在是線程安全的。epoll現(xiàn)在不僅告訴你sock組里面數(shù)據(jù)，還會告訴你具體哪個sock有數(shù)據(jù)，你不用自己去找異步，非阻塞$pstree|grep|-+=81666rootnginx:masterprocess||82500nobodynginx:worker|82501nobodynginxworkerprocess1個master進程，2個work進程每進來一個request，會有一個worker進程去處理。但不是全程的處理，處理到什么程度呢？處理到可能發(fā)生阻塞的地方，比如向上游（后端）服務器轉發(fā)request，并等待請求返回。那么，這個處理的worker不會這么一直等著，他會在發(fā)送完請求后，一個：“如果upstream返回了，告訴我一聲，我再接著干”。于是他就休息去了。這就是異步。此時，如果再有request進來，他就可以很快再按這種方式處理。這就是非阻塞和IO多路復用。而一旦上游服務器返回了，就會觸發(fā)這個worker接手，這個request才會接著往下走。這就是異步回調。ECS及解Nginx部署-Nginx部署-Nginx版本類型Mainlineversion：主線版，即開發(fā)版Stable 穩(wěn)定版，生產(chǎn)環(huán)境上建議使用的版Legacy 遺留的老版本的穩(wěn)定版Yum安裝[root@tianyun~]#yum-yinstallnginx[root@tianyun~]#systemctlstartnginx[root@tianyun~]#systemctlenablenginx[root@tianyun~]#systemctlstatusfirewalld.service-firewalld-dynamicfirewallLoaded:loaded(/usr/lib/systemd/system/firewalld.service;disabled;vendorpreset:enabled) Active:inactive(dead)Docs:[root@tianyun~]#nginx-vnginxversion:[root@tianyun~]#nginx-Vnginxversion:nginx/1.12.1builtbygcc4.8.5 (RedHat4.8.5-11)(GCC)builtwithOpenSSL1.0.1e-fips11Feb2013TLSSNIsupport=/usr/lib64/nginx/modules--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/run/nginx.lock--http- _temp--http- _temp--http-fastcgi-temp-path=/var/cache/nginx/cache/nginx/scgi_temp--user=nginx--group=nginx pat--with-file-aio--with-threads--with-http_addition_module--with-http_auth_request_module--with-http_dav_module--with-http_flv_module--with-http_gunzip_module--with-http_gzip_static_module--with-http_mp4_module--with-http_random_index_module--with-http_realip_module--with-http_secure_link_module--with-http_slice_module--with-http_ssl_module--with-http_stub_status_module--with-http_sub_module--with-http_v2_module--with-mail--with-mail_ssl_module--with-stream--with-stream_realip_module--with-stream_ssl_module--with-stream_ssl_preread_module--with-cc-opt='-O2-g-pipe-Wall-Wp,-D_FORTIFY_SOURCE=2-fexceptions-fstack-protector-strong--param=ssp-buffer-size=4-grecord-gcc-switches-m64-mtune=generic-fPIC'--with-ld-opt='-Wl,-z,relro-Wl,-z,now-pie'NginxNginx[root@tianyun~]#rpm-ql[root@tianyun~]#ls_temp _tempscgi_temp[root@tianyun~]#ls/var/log/nginx/access.logerror.log[root@tianyun~]#rpm-qcNginxNginx[root@tianyun~]#nginx-Vnginxversion:nginx/1.12.1builtbygcc4.8.5 (RedHat4.8.5-11)(GCC)builtwithOpenSSL1.0.1e-fips11Feb2013TLSSNIsupportenabledconfigurearguments: --with-cc-opt='-O2-g-pipe-Wall-Wp,-D_FORTIFY_SOURCE=2-fexceptions-fstack-protector-strong--[root@tianyun~]#psaux|grep 9706Ss 0:00nginx:masterprocess/usr/sbin/nginx-c/etc/nginx/nginx.conf 9876S 0:00nginx:workerprocessNginxNginx模塊 驅動模 http[root@tianyun~]#catuserworker_processes1; //啟動的worker進程數(shù)量（CPU數(shù)量一致或error_log/var/log/nginx/error.logwarn; events use //驅動模型epoll【默認 worker_connections1024; //每個worker進程允許處理的最大連接數(shù)，例如}http default_typeapplication/octet- log_formatmain'$remote_addr-$remote_user[$time_local]"$request" access_log/var/log/nginx/access.log keepalive_timeout #gzip include}[root@tianyun~]#cat/etc/nginx/conf.d/default.confserver{ server_name #charsetkoi8- #access_log/var/log/nginx/host.access.log location/ indexindex.html #error_page #redirectservererrorpagestothestaticpage 500502503504 location=/50x.html # thePHPscriptstoApachelisteningon:80 #location~\.php$ #passthePHPscriptstoFastCGIserverlisteningon #location~\.php$ fastcgi_index fastcgi_paramSCRIPT_FILENAME #denyaccessto.htaccessfiles,ifApache's root #concurswithnginx's #location~/\.ht deny }Nginx日志nginx日志配置相關指令:Nginx有非常靈活的日志記錄模式。每個級別的配置可以有各自獨立的日志。日志格式通過log_format命令定義。Syntax:log_formatname[escape=default|json]string...;Default:log_formatcombined"...";Context: 表示格式名稱 表示定義的格式log_format有默認的無需設置的combined日志格式，相當于 bined日志格式，日志格式如下：log_formatcombined'$remote_addr-$remote_user[$time_local] '"$request"$status$body_bytes_sent '"$http_referer""$http_user_agent"注：如果Nginx位于負載均衡器，squid，nginx反向之后，web服務器無法直接獲取到客戶端真實的IP地址。$remote_addr獲取的是反向的IP地址。反向服務器在轉發(fā)請求的http頭信息中，可以增加X-Forwarded-For信息，用來記錄客戶端IP地址和客戶端請求的服務器地址。日志格式如下：log_formatporxy'$http_x_forwarded_for-$remote_user[$time_local] '"$request"$status$body_bytes_sent '"$http_referer""$http_user_agent"日志格式允許包含的變量：$remote_addr$http_x_forwarded_for記錄客戶端IP 記錄客戶端用戶名稱 記錄請求的URL和HTTP 記錄請求狀態(tài) 發(fā)送給客戶端的字節(jié)數(shù)，不包括響應頭的大小 發(fā)送給客戶端的總字節(jié)數(shù) 連接的序列號$connection_requests當前通過接獲得的請求數(shù)量 日志寫入時間。單位為秒，精度是毫秒。 如果請求是通過HTTP流水線(pipelined)發(fā)送，pipe值為“p”，否則為“.” 記錄從哪個頁 過來的 記錄客戶端瀏覽器相關信息 請求的長度（包括請求行，請求頭和請求正文） 請求處理時間，單位為秒，精度毫秒；從讀入客戶端的第一個字節(jié)開始，直到把最后一個字符發(fā)送給客戶端后進行日志寫入為止。 ISO8601標準格式下的本地時間。 通用日志格式下的本地時間。access_logpath[format[buffer=size][gzip[=level]][flush=time][if=condition]];access_logsyslog:server=address[,parameter=value][format];access_logDefault:access_loglogs/access.logContext:http,server,location,ifinlocation, 壓縮等級buffer設置內存緩存區(qū)大小 保存在緩存區(qū)中的最長時間使用默認combined格式記錄日志：access_loglogs/access.logaccess_loglogs/access.log open_log_file_cachemax=N[inactive=time][min_uses=N][valid=time];open_log_file_cacheoff;Default:open_log_file_cacheContext:http,server,對于每一條日志記錄，都將是先打開文件，再寫入日志，然后關閉?？梢允褂弥萌罩疚募彺?默認是off)，格式如下：參數(shù)注釋如下： 設置緩存中的最大文件描述符數(shù)量，如果緩存被占滿，采用LRU算法將描述符關 設置存活時間，默認是min_uses:設置在inactive時間段內，日志文件最少使用多少次后，該日志文件描述符記入緩存中，默認是1次 設置檢查頻率，默認60s 禁用緩存open_log_file_cachemax=1000inactive=20svalid=1mNginx[root@tianyun~]#rpm-qlnginx|grep輪轉規(guī)則文件日志格式：日志條目：1.1.統(tǒng) 量22統(tǒng)計一天內最多的10個IP（ip3.3.統(tǒng) 大于100次的4統(tǒng)計最多的10個頁面（$requesttop55統(tǒng)計每個內容總大小{printi,size[i]}}' .log|sort-k2rn66統(tǒng)計每個狀態(tài)碼數(shù)量7統(tǒng)計狀態(tài)碼為404及出現(xiàn)次數(shù)8統(tǒng)計前一分鐘的PV99統(tǒng)計狀態(tài)碼是4041010統(tǒng)計 Nginx模塊 Context:server,Nginx編譯參數(shù)配置Nginxserver{ server_namelocalhost;#charsetUTF-8;#access_loglogs/host.access.loglocation{rootindexindex.htmlindex.htm}{allowallow}}[root@tianyun~]#systemctlrestart[root@tianyun~]#firefoxActiveconnections:serveracceptshandledrequests2727434Reading:2Writing:1Waiting:Activeconnections 當前活動的連接數(shù)serveracceptshandledrequests2727434 總連接數(shù) 成功的連接數(shù) 失敗連接＝（總連接數(shù)－成功連接數(shù) 總共處理的請求數(shù) 連接數(shù)，tcp連 Reading:客戶端Header的信息數(shù)Writing:Reading:客戶端Header的信息數(shù)Writing:Waiting:返回給客戶端的header的信息數(shù)等待的請求數(shù)，開啟了keepaliveSyntax:random_indexon|off;Default:random_indexoff;Context:location[root@tianyun~]#mkdir/app/tianyun.me-p[root@tianyun~]#cd/app/tianyun.me/[root@tianyuntianyun.me]#lsblue.htmlgreen.htmlred.html[root@tianyuntianyun.me]#catgreen.html<title>green<h1>greenlocation/ #index #indexindex.html random_index}[root@tianyuntianyun.me]#ls-...blue.htmlgreen.htmlred.html 響應內假如站點出現(xiàn)什么敏感文字，想修改但很耗時間，不妨試試該模塊；或者想臨時在站點中加上一個通用js或者css之類的文件，也可以使用這個模塊。Syntax:sub_filterstringre Default:—Context:http,server, sub_filter_onceon|off;Default:sub_filter_onceon;Context:http,server,location示例location/ indexindex.htmlindex.htm;sub_filternginx'tianyun';sub_filter_onceon;}示例location/ indexindex.htmlindex.htm;sub_filternginx'';sub_filter_onceoff;}示例[root@tianyun~]#cat/usr/share/nginx/html/ o(){ o} indexindex.htmlsub_filter</head>'</head><scripttype="text/javascript"src=" sub_filter_onceon;}其他比較實用的用法如果我們用模板生成的時候，因為疏漏或者別的原因造成代碼不如意，但是此時因為文件數(shù)量巨大，不方便全部重新生成，那么這個時候我們就可以用此模塊來暫時實現(xiàn)糾錯。另一方面，我們也可以利用這個實現(xiàn)服務器端文字過濾的效果。Nginx限ngx_http_limit_conn_module連接頻率限制經(jīng)常會遇到這種情況，服務器流量異常，負載過大等等。對于大流量的 會帶來帶寬的浪費，服務器壓力，影響業(yè)務，往往考慮對同一個ip的連接數(shù)，并發(fā)數(shù)進行限制。ngx_http_limit_conn_module模塊可以根據(jù)定義的key來限制每個鍵值的連接數(shù)，如同一個IP來源的連接數(shù)。 Context: Context:http,server,http}serverlocation/limit_connconn_zone}}ab測試[root@tianyun~]#ab-n100-c10ThisisApacheBench,Version2.3<$Revision: arkinglocalhost(bepatient). ServerSoftware: ServerHostname: ServerPort: 80 Concurrency Timetakenfortests: Completerequests: Failed Write Totaltransferred: 90400bytesHTML 67100Requestspersecond:15873.02[#/sec](mean)Timeperrequest: 0.630[ms](mean)Timeperrequest: 0.063[ms](mean,acrossallconcurrentrequests)Transferrate: 14012.90[Kbytes/sec]receivedConnectionTimesminmean[+/-sd]median 0 010 000 11Percentageoftherequestsservedwithinacertaintime(ms) 1(longest[root@tianyun~]#tail-fhttp請求，http請求，連接，tcp客戶端的IP地址作為鍵。 變量的長度為7字節(jié)到15$binary_remote_addr變量的長度是固定的4如果共享內存空間被耗盡，服務器將會對后續(xù)所有的請求返回503(ServiceTemporarilyngx_http_limit_req_module請求頻率限制 limit_req_zonekeyzone=name:sizerate=rate; Context: limit_reqzone=name[burst=number][nodelay]; Context:http,server,httpserverlocation/root/usr/share/nginx/html;indexindex.htmlindex.htm;limit_reqzone=req_zone;#limit_reqzone=req_zoneburst=5;#limit_reqzone=req_zoneburst=5nodelay;}｝｝[root@tianyun~]#ab-n100-c10ThisisApacheBench,Version2.3<$Revision: arkinglocalhost(bepatient). ServerSoftware: ServerHostname: ServerPort: ConcurrencyTimetakenforCompleteFailed(Connect:0,Receive:0,Length:99,Exceptions:Write Non-2xx Totaltransferred: HTMLtransferred: 53834bytesRequestspersecond:16131.63[#/sec](mean)Timeperrequest: 0.620[ms](mean)Timeperrequest: 0.062[ms](mean,acrossallconcurrentrequests)Transferrate: 11543.10[Kbytes/sec]receivedConnectionTimesminmean[+/-sd]median Percentageoftherequestsservedwithinacertaintime(ms) 11111111(longest[root@tianyun~]#tail-f2017/10/0801:05:08[error]23287#23287:*720limitingrequests,excess:5.109byzone:01,server:localhost,request:"GET/HTTP/1.0",host:"tianyun.me"2017/10/0801:05:08[error]23287#23287:*721limitingrequests,excess:5.078byzone:01,server:localhost,request:"GET/HTTP/1.0",host:"tianyun.me"2017/10/0801:05:08[error]23287#23287:*722limitingrequests,excess:5.062byzone:01,server:localhost,request:"GET/HTTP/1.0",host:"tianyun.me"2017/10/0801:05:08[error]23287#23287:*723limitingrequests,excess:5.037byzone:01,server:localhost,request:"GET/HTTP/1.0",host:"tianyun.me"2017/10/0801:05:08[error]23287#23287:*724limitingrequests,excess:5.010byzone:01,server:localhost,request:"GET/HTTP/1.0",host:Nginx控用戶控Nginx控制基于用戶 auth_basicstring|off;Default:auth_basicoff;Context:http,server,location, Default:—Context:http,server,location,基于用戶 控建立口令文件[root@tianyun~]#htpasswd-cm/usr/local/nginx/passwduser10[root@tianyun~]#htpasswd-m/usr/local/nginx/passwduser20[root@tianyun~]#cat/usr/local/nginx/passwd實現(xiàn)認證[root@tianyun~]#vim/usr/local/ngin server{ location/ indexindex.htmlindex.htm;auth_basic"nginxaccesstest!";}}測試[root@tianyun~]#systemctlreloadnginx[root@tianyun~]#linksLDAP輕量 協(xié)LDAPServer能夠提供集中的認證主機控Nginx控制基于主機 allowaddress|CIDR|unix:|all;Default:—Context:http,server,location,基于基于主機 控HTTPHTTP請求的內容通稱為"資源"。”資源“這一概念非常寬泛，它可以是一份文檔，一張圖片，或所有其他你能夠想到的格式。每個資源都由一個(URI來進行標識。URL即統(tǒng)一資源定位符，它是URI的一種。URI的最常見形式是統(tǒng)一資源定位符(URL)，它也被稱為Web在瀏覽器的地址欄中輸入上述任一地址，瀏覽器就會加載相應的網(wǎng)頁（資源）URL由多個必須或可選的組件構成。下面給出了一個復雜的URL： URN是另一種形式的URI，它通過特定命名空間中的唯一名稱來標識資源。上面兩個URN標識了下面的資源：喬治·奧威爾所著的《1984IETF規(guī)范7230，超文本傳輸協(xié)議(HTTP/1.1)：MessageSyntaxand(URI)"http:/告訴瀏覽器使用何種協(xié)議。對于大部分Web資源，通常使用HTTP協(xié)議或其安全版本，HTTPS協(xié)議。另外，瀏覽器也知道如何處理其他協(xié)議。例如，“mailto協(xié)議指示瀏覽器打開郵件客戶端；“ftp:”協(xié)議指示瀏覽器處理文件傳輸。常見的方案有：既是一個，也代表管理該的機構。它指示了需要向網(wǎng)絡上的一臺主機發(fā)起請求。當然，也可以直接向主機的IPaddress地址發(fā)起請求。但直接使用IP地址的場景并不:80是端口。它表示用于Web服務器上資源的技術“門”。如果的該Web服務器使用HTTP協(xié)議的標準端口（HTTP為80，HTTPS為443）授予對其資源的權限，則通常省略此部分。否則端口就是URI必須的部分。/path/to/myfile.htmlWeb服務器上資源的路徑。在Web的早期，類似這樣的路徑表示W(wǎng)eb服務器上的物理文件位置。現(xiàn)在，它主要是由沒有任何物理實體的Web服務器抽象處理而成的。?key1=value1&key2=value2是提供給Web服務器的額外參數(shù)。這些參數(shù)是用&符號分隔的鍵/值對列表。Web服務器可以在將資源返回給用戶之前使用這些參數(shù)來執(zhí)行額外的操作。每個Web服務器都有自己的參數(shù)規(guī)則，想知道特定Web服務器如何處理參數(shù)的唯一可靠方法是詢問該Web服務器所有者。 是資源本身的某一部分的一個。代表資源內的一種“書簽”，它給予瀏覽器顯示位于該“加書簽”點的內容的指示。例如，在HTML文檔上，瀏覽器將滾動到定義的那個點上；在或音頻文檔上，瀏覽器將轉到代表的那個時間。值得注意的是#號后面的部分，也稱為片段標識符，不會與請求一起發(fā)送到服務器。:http

HTTPHTTP是一種能夠獲取如HTML這樣的網(wǎng)絡資源的通訊協(xié)議。它是Web上數(shù)據(jù)交換的基礎，是一種-server協(xié)議，也就是說請求通常是由像瀏覽器這樣的接受方發(fā)起的。一個完整的文檔是由不同的子文檔重新組建而成的，像是文本、布局描述、、、等等客戶端和服務端通過交換各自的消息來進行交互。通常由像瀏覽器這樣的客戶端發(fā)出的消息叫做requests，那么被服務端回應的消息就叫做responsesHTTP被設計于上20世紀90年代初期，是一種可擴展性的協(xié)議。它是應用層的協(xié)議，雖然理論上它可以通過任何可靠的傳輸協(xié)議來發(fā)送，但是它還是通過TCP，或者是TLS－加密的TCP連接來發(fā)送。因為它很好的擴展性，時至今日它不僅被用來傳輸超文本文檔，還用來傳輸、或者向服務器發(fā)送如HTML表單這樣的信息。HTTP還可以根據(jù)網(wǎng)頁需求，來獲取部分web文檔的內容來更新網(wǎng)HTTP是一個 -server協(xié)議：請求通過一個實體被發(fā)出，實體也就是用戶。大多數(shù)情況下，這個用戶都是指瀏覽器，當然它也可能是任何東西，比如一個爬取網(wǎng)頁來生成和搜索引擎索引的機器。每一個發(fā)送到服務器的請求，都會被服務器處理并且返回一個消息，也就是response。在間，還有許許多多的被稱為proxies的實體，他們的作用與表現(xiàn)各不相同，比些是網(wǎng)關，還有些是caches等。客戶端：user-嚴格意義來說，user-agent就是任何能夠為用戶發(fā)起行為的工具。但實際上，這個角色通常都是由瀏覽器來扮演。對于發(fā)起請求來說，瀏覽器總是作為發(fā)起一個請求的實體。要渲染出一個網(wǎng)頁，瀏覽器首先要發(fā)送第一個請求來獲取這個頁面的HTML文檔，再解析它并根據(jù)文檔中的資源 其他的請求來獲取信息，或者CSS來進行頁面布局渲染，還有一些其它的頁面資源（如 等）。然后，它把這些資源結合到一起，展現(xiàn)出來一個完整的文檔，也就是網(wǎng)頁。打開一個網(wǎng)頁后，瀏覽器還可以根據(jù)內容來獲取的資源來更新網(wǎng)頁一個網(wǎng)頁就是一個超文本文檔，也就是說有一部分顯示的文本可能是，啟動它（通常是鼠標的點擊）就可以獲取一個新的網(wǎng)頁。網(wǎng)頁使得用戶可以控制它的user-agent來導航Web。瀏覽器來負責翻譯HTTP請求令，并翻譯HTTP的返回消息讓用戶能明白返回消息的內容。在上述通信過程的另一端，就是一個WebServer來服務并提供客戶端請求的文檔。只是虛擬意義上：它可以是許多共同分擔負載（負載平衡）的一組服務器組成的計算機群，也可以是一種復雜的軟件，通過向其他計算機發(fā)起請求來獲取部分或全部資源的軟件。在瀏覽器和服務器之間，有許多計算機和其他設備轉發(fā)了HTTP的消息。因為Web棧層次結構的原因，它們大多數(shù)都出現(xiàn)在傳輸層、網(wǎng)絡層和物理層上，對于HTTP的應用層來說就是透明的（雖然它們可能會對應用層的性能有重要影響）。而還有一部分表現(xiàn)在應用層上的，就叫做proxies了。Proxies既可以表現(xiàn)得透明，又可以不透明（看請求是否通過它們），主要表現(xiàn)在這幾個功能上：HTTPHTTP是無狀態(tài)，有會話的HTTP是無狀態(tài)的：在同接中，兩個成功執(zhí)行的請求之間是沒有關系的。這就帶來了一個問題，用戶沒辦法在一個進行連續(xù)的交互，比如在一個 里，用戶把某個商品加入了購物車中，換了一個頁面后再次添加商品，兩次添加商品的請求沒有聯(lián)系，瀏覽器無法知道最終用戶都選擇了哪些商品。而用HTTP展，HTTPs就可以解決這個問題。把 s添加到頭部中，創(chuàng)建一個會話來讓每次請求都能共享相同的上下文信息，相同的狀態(tài)。而HTTP的是無狀態(tài)的， s的使用可以創(chuàng)建有狀態(tài)的會HTTP接是由傳輸層來控制的，基本不屬于HTTP的范圍內。然而HTTP并不需要下面?zhèn)鬏攲拥膮f(xié)議是面向連接的，它只需要它是可靠的，就是說不能丟失消息（至少沒有錯誤）。在因特網(wǎng)兩個最常用的傳輸層協(xié)議中，TCP可靠的，而UDP不是。因此，HTTP依賴于TCP進行消息傳遞，雖然TCP是面向連接的，但這并不是必須的。HTTP/1.0曾經(jīng)為每一個請求/回應交換都打開一個TCP連接，導致了2個缺點：打開接需要多次的消息往返因此很慢。但是當多個消息周期性的發(fā)送時，這就變得更加高效：暖連接比冷連接更高為了減少這些負擔，HTTP/1.1引入了流水線的概念（已被證明很難實現(xiàn)）和持久連接的概念：下層的TCP連接可以通過Connection頭部來被部分地控制。HTTP/2則發(fā)展的，通過接多個消息的方式來讓這個連接始終保持為暖連接。HTTPHTTP請求的一個例子：請求由下面的元素組成：一個HTTP的method，經(jīng)常是由一個動詞像GET,POST或者一個名詞像OPTIONS，HEAD來定義客戶端的動作行為的。通常客戶端的操作都是獲取資源（GET方法）或者發(fā)送一個HTMLform表單的值（用POST方法），雖然在一些情況下也會有其他的操作。要獲取的資源的路徑，通常是上下文中就很明顯的元素資源的URL，它沒有 （），或是TCP的port（HTTP是80端口）HTTP協(xié)議的版本號。為服務端表達其他信息的可選擇性的headers對于一些像POST這樣的方法，報文的body就包含了發(fā)送的資源，這個body與回應報文的HTTP回應的一個例子：回應報文包含了下面的元素：HTTP的版本號。一個狀態(tài)碼（statuscode），來告知對應的請求發(fā)送成功或失敗，以及失敗的原因。一個狀態(tài)信息，這個信息是非的狀態(tài)碼描述信息，也就是說可以由服務端自行設定HTTPheaders，與請求的很像?？蛇x的，但是比在請求報文中更加常見地包含獲取資源的bodyhttpHTTP [root@tianyun~]#wget-dDEBUGoutputcreatedbyWget1.14onlinux-gnu.User-Agent:Wget/1.14(linux-gnu)Accept:*/*Connection:Keep-HTTPrequestsent,awaitingHTTP/1.1200OKServer:Date:Fri,06Oct201709:05:15Content-Length:981093Last-Modified:Tue,11Jul201715:45:09GMTConnection:keep-aliveKeep-Alive:timeout=15Accept-Ranges:200OKRegisteredsocket3forpersistentSavingto:‘nginx- HTTP協(xié)議版本200 響應的狀態(tài)碼是200，即正常返回數(shù)據(jù)，不同場景會有其它如2xx、3xx4xx、 服務器軟件是Nginx，版本是 從服務器獲取該資源時間，時間差8小時，時區(qū)不同； 響應的數(shù)據(jù)類型，這里的資源是文件，則是application/octet-stream了，其它還有 、json、html、xml、cssContent-Lengthresponsebody的長度，也就是源碼包的字節(jié)大??； 即的文件在服務器端最后修改的時間； keep-aliveNginx開啟了TCP長連接； ETagHTTP響應頭是資源的特定版本的標識符。這可以讓緩存更高效，并節(jié)省帶寬，因為如果內容沒有改變，Web服務器不需要發(fā)送完整的響應；Accept-RangesAccept-Range標識自身支持范圍請求，字段值用于定義范圍請求的單 --range選項支持向服務器發(fā)送Range請求，-i選項指定顯示響應頭信息[root@tianyun~]#curl-i--range0-99HTTP/1.1206PartialContentServer:nginxConnection:Date:Fri,06Oct201710:13:19Expires:Sun,05Nov201710:13:19Last-Modified:Tue,26Sep201705:13:42GMTContent-Range:bytes0-99/148270Content-Length:100ETag:"59c9e206-2432e"X-Daa-Tunnel:206PartialAccept-Ranges告訴我們服務器是否支持指定范圍請求及哪種類型的分段請求，這里是byteContent-Range告訴我們在整個返回體中本部分的字節(jié)位置，我們請求的是的前100字如果能夠找到Content-Range響應頭則表明服務器支持斷點續(xù)傳。Nginx服務器默認支持斷點傳的，無須做任何額外配置。httpHTTP消息是服務器和客戶端之間交換數(shù)據(jù)的方式。有兩種類型的消息︰請求--由客戶端發(fā)送用來觸發(fā)一個服務器上的動作；響應--來自服務器的應答。HTTP消息由采用ASCII編碼的多行文本構成。在HTTP/1.1及早期版本中，這些消息通過連接公開地發(fā)送。在HTTP/2中，為了優(yōu)化和性能方面的改進，曾經(jīng)可人工閱讀的消息被分到多個HTTP幀中。Web開發(fā)人員或管理員，很少自己手工創(chuàng)建這些原始的HTTP消息︰由軟件、瀏覽器、或服務器完成。他們通過配置文件（用于服務器或服務器），API（用于瀏覽器）或其他接口提供HTTP消息。HTTP/2二進制框架機制被設計為不需要改動任何API或配置文件即可應用︰它大體上對用戶是透明的。HTTP請求和響應具有相似的結構，由以下部分組成︰1一行起始行用于描述要執(zhí)行的請求，或者是對應的狀態(tài)，成功或失敗。這個起始行總是單行的。一個可選的HTTP頭集合指明請求或描述消息正文。一個空行指示所有關于請求的元數(shù)據(jù)已經(jīng)發(fā)送完畢。一個可選的包含請求相關數(shù)據(jù)的正文(比如HTML表單內容或者響應相關的文檔。正文的大小有起始行的HTTP頭來指定。起始行和HTTP消息中的HTTP頭統(tǒng)稱為請求頭，而其有效負載被稱為消息正文。HTTPHTTP請求是由客戶端發(fā)出的消息，用來使服務器執(zhí)行動作。起始行(start-line包含三個元一個HTTP方法，一個動詞(像GET,PUT或者POST)或者一個名詞(像HEAD或者OPTIONS描述要執(zhí)行的動作例如GET表示要獲取資源，POST表示向服務器推送數(shù)據(jù)(創(chuàng)建或修改資源,或者產(chǎn)生要返回的臨時文件)。請求目標(requesttarget)，通常是一個URL，或者是協(xié)議、端口和的絕對路徑，通常以請求的環(huán)境為特征。請求的格式因不同的HTTP方法而異。它可以是： ?一個絕對路徑，末尾跟上一個'?'和查詢字符串。這是最常見的形式，稱為原始形式(originform)，被GET，POST，HEAD和OPTIONS方法所使用。POST/HTTPGET/background.pngOPTIONS/anypage.htmlHTTP/1.0一個完整的URL，被稱為絕對形式(absoluteform)，主要在GET連接到時使用 和可選端口（以':'為前綴）組成的URL的authoritycomponent，稱為authorityform。僅在使用CONNECT建立HTTP隧道時才使用。星號形式(asteriskform)，一個簡單的星號('*')OPTIONS方法使用，代表整個服OPTIONS*HTTP(HTTPversion)，定義了剩余報文的結構，作為對期望的響應版本的指示符。來自請求的HTTPheaders遵循和HTTPheader相同的基本結構：不區(qū)分大小寫的字符串，緊跟著的冒號(':')和一個結構取決于header的值。整個header（包括值）由一行組成，這一行可以相當長。有許多請求頭可用，它們可以分為幾組：GeneralheadersVia，適用于整個報文。Requestheaders，例如User-Agent，Accept-Type，通過進一步的定義(例如Accept-Language)，或者給定上下文(例如Referer)，或者進行有條件的限制(例如If-None)來修改EntityheadersContent-Length，適用于請求的body。顯然，如果請求中沒有任何body，則不會發(fā)送這樣的頭文件。請求的最后一部分是它的body。不是所有的請求都有一個body：例如獲取資源的請求，GET，HEAD，DELETE和OPTIONS，通常它們不需要body。有些請求將數(shù)據(jù)發(fā)送到服務器以便更新數(shù)據(jù)：常見的的情況是POST請求（包含HTML表單數(shù)據(jù)）。Body大致可分為兩類：Single-resourcebodies，由一個單文件組成。該類型body由兩個header定義：Content-Type和Content-Length.Multiple-resourcebodies，由多部分body組成，每一部分包含不同的信息位。通常是和HTMLForms連系在一起。HTTPHTTP響應的起始行被稱作狀態(tài)行(statusline)，包含以下信息：協(xié)議版本，通常為HTTP/1.1狀態(tài)碼(statuscode)，表明請求是成功或失敗。常見的狀態(tài)碼是200，404302狀態(tài)文本(statustext)。一個簡短的，純粹的信息，通過狀態(tài)碼的文本描述，幫助人們理解該HTTP消息。一個典型的狀態(tài)行看起來像這樣：HTTP/1.1404NotFound響應的HTTPheaders遵循和任何其它header相同的結構：不區(qū)分大小寫的字符串，緊跟著的冒號(':')和一個結構取決于header類型的值。整個header（包括其值）表現(xiàn)為單行形有許多響應頭可用，這些響應頭可以分為幾組：GeneralheadersVia，適用于整個報文。ResponseheadersVaryAccept-Ranges，提供其它不符合狀態(tài)行的關于服務器的EntityheadersContent-Length，適用于請求的body。顯然，如果請求中沒有任何body，則不會發(fā)送這樣的頭文件。響應的最后一部分是body。不是所有的響應都有body：具有狀態(tài)碼(201204的響應，通常不會有body。Body大致可分為三類：Single-resourcebodies，由已知長度的單個文件組成。該類型body由兩個headerSingle-resourcebodies，由未知長度的單個文件組成，通過將Transfer-Encodingchunked來使用chunksMultiple-resourcebodies，由多部分body組成，每部分包含不同的信息段。但這是比較少HTTP/2HTTP/1.x報文有一些性能上的缺點：Header不像body，它不會被壓縮。兩個報文之間的header通常非常相似，但它們仍然在連接中重復傳輸。無法復用。當在同一個服務器打開幾個連接時：TCP熱連接比冷連接更加有效。HTTP/2引入了一個額外的步驟：它將HTTP/1.x消息分成幀并嵌入到流(stream)中。數(shù)據(jù)幀和報頭幀分離，這將允許報頭壓縮。將多個流組合，這是一個被稱為多路復用(multiplexing)的過程，它允許更有效的底層TCP連接。HTTP幀現(xiàn)在對Web開發(fā)人員是透明的。在HTTP/2中，這是一個在HTTP/1.1和底層傳輸協(xié)議之間附加的步驟。Web開發(fā)人員不需要在其使用的API中做任何更改來利用HTTP幀；當瀏覽器和服務器都可用時，HTTP/2將被打開并使用。HTTP報文是使用HTTP的關鍵；它們的結構簡單，并且具有高可擴展性。HTTP/2幀機制是HTTP/1.x語法和底層傳輸協(xié)議之間增加了一個新的中間層，而沒有從根本上修改它，即它是建立在經(jīng)過驗證的機制之上。httpHTTP這樣的客戶端-服務器協(xié)議中會話分為三個階段客戶端建立一條TCP連接(如果傳輸層不是TCP,也可以是其他適合的連接)客戶端發(fā)送請求并等待應答。服務器處理請求并送回應答包括一個狀態(tài)碼和對應的數(shù)據(jù)。HTTP/1.1開始連接在完成第三階段后不再關閉客戶端可以再次發(fā)起新的請求這意味著第二步和第三步可以進行數(shù)次。建立連接在客戶端-服務器協(xié)議中，連接是由客戶端發(fā)起建立的。在HTTP中打開連接意味著在底層傳輸層啟動連接，通常就是TCP。使用TCP時,HTTP服務器的默認端是80,另外還有8000和8080也很常用。頁面的URL會包含和端,但當后者為80時可以省略掉。前往標識互聯(lián)網(wǎng)上的內容獲取更多細節(jié)。注意:客戶端-服務器模型不允許服務器在沒有顯式請求時發(fā)送數(shù)據(jù)給客戶端。為了解決這個問題web開發(fā)者們使用了許多技術例如使用XMLHTTPRequestFetchAPI周期性地請求服務器,使用HTMLWebSocketsAPI,或其他類似的協(xié)議。發(fā)送客戶端請求一旦連接建立,用戶就可以發(fā)送請求(用戶通常是web瀏覽器,但也可以是任何其他事物,例如爬蟲)。客戶端請求由一系列文本指令組成,并使用CRLF分隔,它們被劃分為三個塊:第一行包括請求方法及其參數(shù):?文檔路徑,即不包括協(xié)議和的絕對路徑使用的HTTP協(xié)議版本接下來的行每一行都表示一個HTTP首部為服務器提供關于所需數(shù)據(jù)的信息(例如語言,或MIME類型)，或是一些改變請求行為的數(shù)據(jù)(例如當數(shù)據(jù)已經(jīng)被緩存時就不再應答).這些HTTP首部組成以一個空行結束的一個塊。最后一塊是可選的數(shù)據(jù)塊,包括了數(shù)據(jù),這主要被POST方法使用的根頁面，即，并告訴服務器用戶代理傾向于該頁面使用法語：GET/Accept-Language:fr注意最后的空行，它把首部與數(shù)據(jù)塊分隔開。由于在HTTP首部中沒有Content-Length，數(shù)據(jù)塊是空的，所以服務器可以在收到代表首部結束的空行后就開始處理請求。例如，發(fā)送表單的結果：Host:Content-Length:64HTTP定義了一組請求方法用來指定對給定資源的行為.盡管它們可以是名詞,但這些請求方法有時會被叫做HTTP動詞.最常用的請求方法是GET和POST:GET方法請求指定的資源。GET請求應該只被用于獲取數(shù)據(jù)。POST方法向服務器發(fā)送數(shù)據(jù)因此會改變服務器狀態(tài)。這個方法經(jīng)常在HTML服務器響應結構當用戶發(fā)送請求之后,web服務器會處理它,并最終送回一個響應.與客戶端請求很類似地,服務器響應由一系列文本指令組成,并使用CRLF分隔,但它們被劃分為三個不同的塊:第一行是狀態(tài)行,包括使用的HTTP協(xié)議版本,狀態(tài)碼和一個狀態(tài)描述(可讀的文本接下來的行每一行都表示一個HTTP首部,為客戶端提供關于所發(fā)送數(shù)據(jù)的一些信息(如數(shù)據(jù)大小,使用的壓縮算法,緩存指示).與客戶端請求的頭部塊類似,HTTP首部組成一個塊,并以一個空行結束.最后一塊是數(shù)據(jù)塊包括響應的數(shù)據(jù)(如果有的話成功的網(wǎng)頁響應：HTTP/1.1200Date:Sat,09Oct201014:28:02Server:Last-Modified:Tue,01Dec200920:18:22GMTETag:"51142bc1-7449-479b075b2891b"Accept-Ranges:bytesContent-Length:29769<!DOCTYPEhtml.29769字節(jié)的網(wǎng)頁信息請求的資源已經(jīng)永久移動：HTTP/1.1301MovedPermanentlyServer:Apache/2.2.3(RedHat)Date:Sat,09Oct201014:30:24GMTLocation:(該資源的新的,服務望用戶去它)Keep-Alive:timeout=15,max=98Accept-Ranges:bytesVia:Moz-Cache-zlb05X-Cache-Info:cachingX-Cache-Info:cachingContent-Length:325(如果用戶不能跟隨新的,那么就顯示一個默認頁面<!DOCTYPEHTMLPUBLIC"-//IETF//DTDHTML<title>301Moved<h1>Moved hasmoved<ahref="<address>Apache/2.2.3(RedHat)SPort請求的資源不存在HTTP/1.1404NotDate:Sat,09Oct201014:33:02Server:Last-Modified:Tue,01May200714:24:39Accept-Ranges:bytesContent-Length:10732<!DOCTYPEhtml.包含一個站點自定義的頁面幫助用戶找到丟失的資源HTTP響應狀態(tài)碼用來表示一個HTTP請求是否成功完成.響應被分為5種類型信息型響應,成功響應,重定向,客戶端錯誤和服務器錯誤.200OK.請求已成功301MovedPermanently這個響應碼表示請求資源的URI已經(jīng)被改變了404NotFound.服務器無法找到請求的資源httpHTTP連接管理是一個HTTP的關鍵話題：打開和保持連接在很大程度上影響著和Web應用程序的性能。在HTTP/1.x里有好些個模型：短連接長連接HTTP流水線。HTTP的傳輸協(xié)議主要依賴于TCP來提供從客戶端到服務器端之間的連接。在早期，HTTP使用一個簡單的模型來處理這樣的連接。這些連接的生命周期是短暫的：每發(fā)起一個請求時都會創(chuàng)建一個新的連接，并在收到應答時立即關閉。這個簡單的模型對性能有的限制：打開每一個TCP連接都是相當耗費資源的操作?？蛻舳撕头掌鞫酥g需要交換好些個消息。當請求發(fā)起時，網(wǎng)絡延遲和帶寬都會對性能造成影響。現(xiàn)代瀏覽器往往要發(fā)起很多次請求(十幾個或者)才能拿到所需的完整信息，證明了這個早期模型的效率低下有兩個新的模型在HTTP/1.1誕生了。首先是長連接模型，它會保持連接去完成多次連續(xù)的請求，減少了不斷重新打開連接的時間。然后是HTTP流水線模型，它還要更先進一些，多個連續(xù)的請求甚至都不用等待立即返回就可以被發(fā)送，這樣就減少了耗費在網(wǎng)絡延遲上的時間。HTTP/2新增了其它連接管理模型。要注意的一個重點是HTTP的連接管理適用于兩個連續(xù)節(jié)點之間的連接，如hop-by-hop，而不是end-to-end。當模型用于從客戶端到第一個服務器的連接和從服務器到目標服務器之間的連接時(或者任意中間)效果可能是不一樣的。HTTP協(xié)議頭受不同連接模型的影響，比如ConnectionKeep-Alivehop-by-hop協(xié)議頭，它們的值是可以被中間節(jié)點修改的。HTTP最早期的模型，也是HTTP/1.0的默認模型，是短連接。每一個HTTP請求都由它自己獨立的連接完成；這意味著發(fā)起每一個HTTP請求之前都會有一次TCP握手，而且是連續(xù)不斷的。TCP協(xié)議握手本身就是耗費時間的，所以TCP可以保持的熱連接來適應負載。短連接破壞了TCP具備的能力，新的冷連接降低了其性能。HTTP/1.0的默認模型(如果沒有指定Connection協(xié)議頭，或者是值被設置為close)。而在HTTP/1.1中，只有當Connection被設置為close時才會用到這個模型。除非是要兼容一個非常古老的，不支持長連接的系統(tǒng)，沒有一個令人信服的理由繼續(xù)使用這個模型。短連接有兩個比較大的問題：創(chuàng)建新連接耗費的時間尤為明顯，另外TCP連接的性能只有在該連接被使用一段時間后(熱連接)才能得到改善。為了緩解這些問題，長連接的概念便被設計出來了，甚至在HTTP/1.1之前?；蛘哌@被稱之為一個keep-alive連接。一個長連接會保持一段時間，重復用于發(fā)送一系列請求，節(jié)省了新建TCP連接握手的時間，還可以利用TCP的性能增強能力。當然這個連接也不會一直保留著：連接在空閑一段時間后會被關閉(服務器可以使用Keep-Alive協(xié)議頭來指定一個最小的連接保持時間)。長連接也還是有缺點的；就算是在空閑狀態(tài)，它還是會消耗服務器資源，而且在重負載時，還有可能DoSattacks。這種場景下，可以使用非長連接，即盡快關閉那些空閑的連接，也能對性能有所提升。HTTP/1.0里默認并不適用長連接。把Connectionclose以外的其它參數(shù)都可以讓其保持長連接，通常會設置為retry-after。在HTTP/1.1里，默認就是長連接的，協(xié)議頭都不用再去它(但我們還是會把它加上，萬一某個時候因為某種原因要退回到HTTP/1.0呢)。HTTP流水線HTTP流水線在現(xiàn)代瀏覽器中并不是默認被啟用的：Web開發(fā)者并不能輕易的遇見和判斷那些搞怪的服務器的各種莫名其妙的行為正確的實現(xiàn)流水線式復雜的：傳輸中的資源大小，多少有效的RTT會被用到，還有有效帶寬，流水線帶來的改善有多大的影響范圍。不知道這些的話，重要的消息可能被延不重要的消息后面。這個重要性的概念甚至會演變?yōu)橛绊懙巾撁娌季?！因此HTTP流水線在大多數(shù)情況下帶來的改善并不明顯。流水線受制于HOL由于這些原因，流水線已經(jīng)被更好的算法給代替，如multiplexing，已經(jīng)用在HTTP/2默認情況下，P請求是按順序發(fā)出的。下一個請求只有在當前請求收到應答過后才會被發(fā)出。由于會受到網(wǎng)絡延遲和帶寬的限制，在下一個請求被發(fā)送到服務器之前，可能需要等待很長時間。流水線是在同一條長連接上發(fā)出連續(xù)的請求，而不用等待應答返回。這樣可以避免連接延遲。理論上講，性能還會因為兩個HTTP請求有可能被打包到一個TCP消息包中而得到提升。就算HTTP請求不斷的繼續(xù)，尺寸會增加，但設置TCP的MSS( umSegmentSize)選項，任然足夠包含一系列簡單的請求。并不是所有類型的HTTP請求都能用到流水線：只有idempotent方式，比如GET、HEAD、PUTDELETE能夠被安全的重試：如果有故障發(fā)生時，流水線的內容要能被輕易的重試。今天，所有遵循HTTP/1.1的和服務器都應該支持流水線，雖然實際情況中還是有很多限制：一個很重要的原因是，任然沒有現(xiàn)代瀏覽器去默認支持這個功能。分片除非你有緊急而迫切的需求，不要使用這一過時的技術，升級到HTTP/2就好了。在HTTP/2里，做分片就沒必要了：HTTP/2的連接可以很好的處理并發(fā)的無優(yōu)先級的請求。分片甚至會影響性能。大多數(shù)HTTP/2的實現(xiàn)還會使用一種稱作連接凝聚的技術去嘗試合并被分片的。作為HTTP/1.x的連接，請求時序列化的，哪怕本來是無序的，在沒有足夠龐大可用的帶寬時，也無從優(yōu)化。一個解決方案是，瀏覽器為每個建立多個連接，以實現(xiàn)并發(fā)請求。曾經(jīng)默認的連接數(shù)量為23個，現(xiàn)在比較常用的并發(fā)連接數(shù)已經(jīng)增加到6條。如果嘗試大于這個數(shù)字，就有觸發(fā)服務器DoS保護的風險。如果服務器端想要更快速的響應或應用程序的應答，它可以迫使客戶端建立的連接。例如，不要在同一個下獲取所有資源，假設有個 ，我可以把它拆分成好幾個 。所有這些都指向同一臺服務器，瀏覽器會同時為每個建立條連接(在我們這個例子中，連接數(shù)會達到18條)。這一技術被稱作分片改進后的連接管理極大的提升了HTTP的性能。不管是HTTP/1.1HTTP/1.0，使用長連直到進入空閑狀態(tài)都能達到最佳的性能。然而，解決流水線故障需要設計更先進的連接管理模型，HTTP/2已經(jīng)在嘗試了。httpNginx靜態(tài)資源非Web服務器端運行處理而生成的文件瀏覽器渲染：HTML、CSS、文件 GIF、文件 MP4、FLV、其它文件 ISO、PDF、TXT、文件文件 sendfileon|off; sendfileoff;Context:http,server,location,ifin tcp_nopushon|off; tcp_nopushoff;Context:http,server,location tcp_nodelayon|off; tcp_nodelayon;Context:http,server,locationlocation/{sendfileon;tcp_nopushon; }未使用sendfile的傳統(tǒng)網(wǎng)絡傳輸過程：kernelbufferuserbufferkernelsocketbuffersendfile來進行網(wǎng)絡傳輸?shù)倪^程：kernelbuffer快速拷貝到kernelsocketbuffer協(xié)議棧sendfile()不但能減少切換次數(shù)而且還能減少拷貝次數(shù)。文件壓縮ngx_http_gzip_module gzipon|off; gzipContext:http,server,location,ifin p_level1;Context:http,server,location gzip_http_version1.0|1.1; gzip_http_version1.1;Context:http,server,location預讀gzipngx_http_gzip_static_module gzip_staticon|off|always; gzip_staticoff;Context:http,server,[root@tianyun~]#tree├──├── └──├── ├──├── └──├──└──~.*\.(jpg|gif|png)${#gzipon;#gzip_http_versionp_level#gzip_typestext/inapplication/javascriptapplication/x-javascripttext/cssapplication/xmltext/javascriptapplication/x-httpd-phpimage/jpegimage/gifimage/png;root}~.*\.(txt|xml)${#gzipon;#gzip_http_versionp_level#gzip_typestext/inapplication/javascriptapplication/x-javascripttext/cssapplication/xmltext/javascriptapplication/x-httpd-phpimage/jpegimage/gifimage/png;root}location~{#gzip_staticon;tcp_nopushon;root}~.*\.(jpg|gif|png)${gzipon;gzip_http_version1.1;p_levelgzip_typestext/inapplication/javascriptapplication/x-javascripttext/cssapplication/xmltext/javascriptapplication/x-httpd-phpimage/jpegimage/gifimage/png;root}~.*\.(txt|xml)${gzipon;gzip_http_versionp_levelgzip_typestext/inapplication/javascriptapplication/x-javascripttext/cssapplication/xmltext/javascriptapplication/x-httpd-phpimage/jpegimage/gifimage/png;root}location~{gzip_staticon;tcp_nopushon;root}HTTP協(xié)議定義的緩存機制ngx_http_headers_module http1.0 http瀏覽器第一次請求無緩存瀏覽器第二次請求有緩存，校驗是否過期 expiresepoch|max| expiresContext:http,server,location,ifinlocation/ indexindex.htmlindex.htm;expires24h;}防止資源用如何區(qū)分哪些是不正常的用戶？HTTPReferer是Header的一部分，當瀏覽器向Web服務器發(fā)送請求的時候，一般會帶上告訴服務器我是從哪個頁面過來的，服務器借此可以獲得一些信息用于處理，例如防的盜鏈、文件等。因此HTTPReferer頭信息是可以通過程序來生成的，所以通信息防盜鏈并非100%可靠，但是，它能夠限制大部分的盜鏈情況。log_formatmain'$remote_addr-$remote_user[$time_local]"$request"''$status$body_bytes_sent"$http_referer"''"$http_user_agent""$http_x_forwarded_for"'; valid_referersnone|blocked|server_names|string...; Context:server,[root@tianyun~]#vim<img [root@tianyun~]#tail-15-- ]"GET/HTTP/1.1"200179"-"Mozilla/5.0(WindowsNT6.1;WOW64;rv:56.0)Gecko/ [root@tianyun~]#tail-1/var/log/nginx/qfcloud.top.access.log5--[15/Oct/2017:15:34:13 ]"GET/Linux1.jp