京東老板細(xì)說：Nginx反向代理時(shí)保持長(zhǎng)連接，直呼"學(xué)到了！"
深入了解nginx，get到nginx一些性能優(yōu)化方向。除了了解如何保持長(zhǎng)連接外，我們還學(xué)習(xí)了開源中間件的一些常見定位思路和優(yōu)化方法。HTTP1.1之后，HTTP協(xié)議支持持久連接，也就是長(zhǎng)連接，優(yōu)點(diǎn)在于在一個(gè)TCP多個(gè)可以在連接上傳輸HTTP請(qǐng)求和響應(yīng)減少了建立和關(guān)閉連接的消耗和延遲。假如我們用了nginx作為反向代理或負(fù)載平衡，從客戶端到服務(wù)器端的長(zhǎng)連接請(qǐng)求將轉(zhuǎn)換為短連接。我們需要支持長(zhǎng)連接nginx在服務(wù)器上做一些配置。到長(zhǎng)連接，我們必須做到以下兩點(diǎn)：i.從client到nginx是長(zhǎng)連接ii.從nginx到server是客戶端的長(zhǎng)連接，nginx其實(shí)扮演著server反之，角色server，nginx就是一個(gè)client。保持和Client我們想要實(shí)現(xiàn)長(zhǎng)連接Client與Nginx需要保持長(zhǎng)連接：i.Client發(fā)送的請(qǐng)求攜帶keep-alive”header。ii.Nginx設(shè)置支持keep-alive。默認(rèn)情況下，nginx已經(jīng)開對(duì)了client連接的keepalive 支持。相關(guān)參數(shù)可在特殊場(chǎng)景中進(jìn)行調(diào)整。在大多數(shù)情況下，keepalive_requests = 100也夠用，但對(duì)于 QPS 在較高的場(chǎng)景中，有必要增加此參數(shù)，以避免大量的連接被生成和拋棄，減少TIME_WAIT。QPS=10000 每秒發(fā)送客戶端 10000 個(gè)請(qǐng)求 (通常建立多個(gè)長(zhǎng)連接)，每個(gè)連接最多只能運(yùn)行 100 第二個(gè)請(qǐng)求意味著平均每秒都會(huì)有 100 因此，個(gè)長(zhǎng)連接被接 nginx 關(guān)閉。這也意味著保持 QPS，客戶端必須每秒鐘重建一次 100 個(gè)連接。所以，如果用netstat看客戶端機(jī)器的命令，你會(huì)發(fā)現(xiàn)有很多TIME_WAIT的socket連接 (即使此時(shí)keepalive已經(jīng)在 Client 和 NGINX 兩者生效)。保持和Server長(zhǎng)連接想讓Nginx和Server最簡(jiǎn)單的設(shè)置如下：upstream配置upstream有一個(gè)特別重要的參數(shù)，那就是keepalive和以前一樣http里面的 keepalive_timeout 不一樣。該參數(shù)的含義是連接池中最大的空閑連接數(shù)。不理解？沒關(guān)系。讓我們舉個(gè)例子：有一個(gè)例子HTTP服務(wù)，作為upstream響應(yīng)時(shí)間為100毫秒的服務(wù)器接收請(qǐng)求。要求性能達(dá)到1000萬 QPS，我們需要在nginx與upstream大約1000條服務(wù)器之間的建立HTTP請(qǐng)求。（1000/0.1s=假設(shè)要求非常均勻穩(wěn)定，每個(gè)要求都是1000ms，請(qǐng)求結(jié)束將立即放入連接池中idle(空閑)狀態(tài)。我們以0.1s為單位：1. 我們現(xiàn)在keepalive值為10，每0.1s鐘連接1000個(gè)。2. 第0.1s我們收到并釋放了1000個(gè)請(qǐng)求。3. 第0.2s我們又來了1000個(gè)請(qǐng)求，0.2s最后釋放。要求和應(yīng)答均勻，0.1s釋放的連接就夠了，不需要建立新的連接，連接池中也沒有idle狀態(tài)連接。答案很穩(wěn)定，但請(qǐng)求不穩(wěn)定1.0.3s由于網(wǎng)絡(luò)延遲等原因，我們只收到了500個(gè)請(qǐng)求，500個(gè)請(qǐng)求沒有進(jìn)來。這個(gè)時(shí)候，Nginx檢測(cè)到500個(gè)連接池idle狀態(tài)連接直接關(guān)閉(500-10)個(gè)連接。2.第0.4s我們收到了1500個(gè)請(qǐng)求，但現(xiàn)在池里只有(500 10)連接，所以Nginx必須重建(1500-510)個(gè)連接。如果在第四步中沒有關(guān)閉490個(gè)連接，則只需重建500個(gè)連接。請(qǐng)求非常穩(wěn)定，但響應(yīng)不穩(wěn)定1. 第0.3s我們收到了1500個(gè)請(qǐng)求。但此時(shí)池內(nèi)只有1000個(gè)連接，Nginx又創(chuàng)建了500個(gè)連接，共1500個(gè)連接。2.第0.3s的時(shí)候，第0.3s的連接全部被釋放，我們收到了500個(gè)請(qǐng)求。 Nginx池內(nèi)檢測(cè)到1000個(gè)idle狀態(tài)連接，因此必須釋放(1000-10)個(gè)連接。這是導(dǎo)致連接數(shù)量反復(fù)震蕩的推手keepalive 這個(gè)最大空閑連接數(shù)。以上兩種情況都是說的 keepalive不合理的設(shè)置Nginx釋放和創(chuàng)建多次連接的過程，造成資源浪費(fèi)。keepalive 這個(gè)參數(shù)設(shè)置一定要小心，尤其是對(duì)于 QPS 一般根據(jù)網(wǎng)絡(luò)環(huán)境要求較高或不穩(wěn)定的場(chǎng)景 QPS 值和 平均響應(yīng)時(shí)間可以大致計(jì)算所需的長(zhǎng)連接數(shù)量。然后將keepalive將長(zhǎng)連接數(shù)設(shè)置為10%至30%。location配置HTTP 從協(xié)議中對(duì)長(zhǎng)連接的支持來看 1.1 版本之后才有，最好通過proxy_http_version 指令設(shè)置為 1.1。HTTP1.0不支持keepalive不使用特性HTTP1.后端服務(wù)將返回101錯(cuò)誤，然后斷開連接。而“Connection” header 即使可以選擇清洗，也可以選擇清洗 Client 和 Nginx 之間是短連接，Nginx 和 upstream 長(zhǎng)連接也可以打開。另一種先進(jìn)的方式http里面的map轉(zhuǎn)發(fā)到代理服務(wù)器的功能是： "Connection" 頭字段的值取決于客戶端請(qǐng)求頭的值"Upgrade" 字段值。如果$http_upgrade沒有匹配，那 "Connection" 頭字段的值會(huì)是upgrade。如果$http_upgrade如果是空字符串，那 "Connection" 頭字段的值會(huì)是 close。NGINX支持WebSocket。對(duì)于NGINX必須明確設(shè)置從客戶端到后臺(tái)服務(wù)器的升級(jí)請(qǐng)求Upgrade和Connection標(biāo)題。這也是上述情況下非常常用的場(chǎng)景。HTTP的Upgrade協(xié)議頭機(jī)制用于連接連接HTTP連接升級(jí)到WebSocket連接，Upgrade機(jī)制使用了Upgrade協(xié)議頭和Connection協(xié)議頭。為了讓Nginx可以來自客戶端Upgrade要求發(fā)送到后端服務(wù)器，Upgrade和Connection頭部信息必須顯式設(shè)置。在nginx如果當(dāng)前模塊中沒有配置文件proxy_set_header從上層繼承配置。繼承順序如下：http, server, location。若在下一層使用proxy_set_header修改了header所有的值header值可能會(huì)改變，所有以前繼承的配置都將被丟棄。所以，盡量在同一個(gè)地方進(jìn)行proxy_set_header，否則可能會(huì)出現(xiàn)其他問題。
誰能解釋？nginx反向代理是什么意思？
nginx反向代理是指代理內(nèi)部服務(wù)器對(duì)外服務(wù)nginx代理服務(wù)。
nginx反向代理的反向性在于：Nginx作為負(fù)載均衡服務(wù)Nginx內(nèi)部可以直接支持Rails和PHP也可以支持程序外部服務(wù)HTTP對(duì)外服務(wù)代理服務(wù)。
反向代理的方向與正向代理相反，代表外部網(wǎng)絡(luò)用戶向內(nèi)部服務(wù)器發(fā)出請(qǐng)求，即接收來自Internet用戶的連接請(qǐng)求，并將這些請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，然后將從內(nèi)部服務(wù)器中獲得的響應(yīng)Internet請(qǐng)求連接客戶。
反向效應(yīng)：對(duì)于用戶來說，反向代理服務(wù)器相當(dāng)于目標(biāo)服務(wù)器，即用戶可以通過直接訪問反向代理服務(wù)器獲得目標(biāo)服務(wù)器的資源。用戶不需要知道目標(biāo)服務(wù)器的地址Web降低網(wǎng)絡(luò)和服務(wù)器的負(fù)載，提高訪問效率。
擴(kuò)展資料：
反向代理的優(yōu)勢(shì)：
1.內(nèi)部服務(wù)器訪問速度加快
將兩個(gè)反向代理服務(wù)器放置在內(nèi)部服務(wù)器前，分別連接到教育網(wǎng)絡(luò)和公共網(wǎng)絡(luò)，使公共網(wǎng)絡(luò)用戶可以直接通過公共網(wǎng)絡(luò)線路訪問學(xué)校服務(wù)器，避免公共網(wǎng)絡(luò)和教育網(wǎng)絡(luò)之間擁擠的鏈路。反向代理服務(wù)器的緩存功能也加速了用戶的訪問。
節(jié)約有限IP資源
除了使用教育網(wǎng)地址外，校園網(wǎng)內(nèi)部服務(wù)器還將使用公共網(wǎng)絡(luò)IP地址提供外部服務(wù)，公共網(wǎng)絡(luò)分配IP地址數(shù)量有限。如果每個(gè)服務(wù)器都有一個(gè)公共網(wǎng)絡(luò)地址，那就不可能通過反向代理技術(shù)得到很好的解決IP地址不足的問題。
參考資料來源：
百度百科-nginx
參考資料來源：
百度百科-反向代理
nginx反向代理 是不是 每臺(tái)機(jī)器都要裝
centos（community enterprise operating system，中文意思是:社區(qū)企業(yè)操作系統(tǒng))linux它來自發(fā)行版之一red hat enterprise linux根據(jù)開源代碼規(guī)定釋放的源代碼編譯而成。由于源代碼相同，一些服務(wù)器需要高度穩(wěn)定性centos取代商業(yè)版red hat enterprise linux使用。兩者的區(qū)別在于centos不包括封閉源代碼軟件。
nginx 可以使用域名反向代理嗎
1. 已安裝nginx相關(guān)環(huán)境只顯示相關(guān)反向代理的配置。. 默認(rèn)nginx.confi配置可能與下圖不同，重要的是后面的配置。
以上就是【我不敢相信第2個(gè)！小程序nginx反向代理(nginx反向代理跨域)】的全部?jī)?nèi)容。
評(píng)論