国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

前端開發者必備的Nginx知識

pumpkin9 / 2301人閱讀

摘要:反向代理是為服務端服務的,反向代理可以幫助服務器接收來自客戶端的請求,幫助服務器做請求轉發,負載均衡等。如何實現負載均衡指定后端服務器地址列表在中攔截響應請求,并將請求轉發到中配置的服務器列表。

nginx在應用程序中的作用

解決跨域

請求過濾

配置gzip

負載均衡

靜態資源服務器

nginx是一個高性能的HTTP和反向代理服務器,也是一個通用的TCP/UDP代理服務器,最初由俄羅斯人Igor Sysoev編寫。

nginx現在幾乎是眾多大型網站的必用技術,大多數情況下,我們不需要親自去配置它,但是了解它在應用程序中所擔任的角色,以及如何解決這些問題是非常必要的。

下面我將從nginx在企業中的真實應用來解釋nginx在應用程序中起到的作用。

為了便于理解,首先先來了解一下一些基礎知識,nginx是一個高性能的反向代理服務器那么什么是反向代理呢?

正向代理與反向代理

代理是在服務器和客戶端之間假設的一層服務器,代理將接收客戶端的請求并將它轉發給服務器,然后將服務端的響應轉發給客戶端。

不管是正向代理還是反向代理,實現的都是上面的功能。

正向代理
正向代理,意思是一個位于客戶端和原始服務器(origin server)之間的服務器,為了從原始服務器取得內容,客戶端向代理發送一個請求并指定目標(原始服務器),然后代理向原始服務器轉交請求并將獲得的內容返回給客戶端。

正向代理是為我們服務的,即為客戶端服務的,客戶端可以根據正向代理訪問到它本身無法訪問到的服務器資源。

正向代理對我們是透明的,對服務端是非透明的,即服務端并不知道自己收到的是來自代理的訪問還是來自真實客戶端的訪問。

反向代理
 反向代理(Reverse Proxy)方式是指以代理服務器來接受internet上的連接請求,然后將請求轉發給內部網絡上的服務器,并將從服務器上得到的結果返回給internet上請求連接的客戶端,此時代理服務器對外就表現為一個反向代理服務器。

反向代理是為服務端服務的,反向代理可以幫助服務器接收來自客戶端的請求,幫助服務器做請求轉發,負載均衡等。

反向代理對服務端是透明的,對我們是非透明的,即我們并不知道自己訪問的是代理服務器,而服務器知道反向代理在為他服務。
圖片描述

基本配置 配置結構

下面是一個nginx配置文件的基本結構:

events { 

}

http 
{
    server
    { 
        location path
        {
            ...
        }
        location path
        {
            ...
        }
     }

    server
    {
        ...
    }

}

main:nginx的全局配置,對全局生效。

events:配置影響nginx服務器或與用戶的網絡連接。

http:可以嵌套多個server,配置代理,緩存,日志定義等絕大多數功能和第三方模塊的配置。

server:配置虛擬主機的相關參數,一個http中可以有多個server。

location:配置請求的路由,以及各種頁面的處理情況。

upstream:配置后端服務器具體地址,負載均衡配置不可或缺的部分。

內置變量

下面是nginx一些配置中常用的內置全局變量,你可以在配置的任何位置使用它們。

| 變量名 | 功能 |
| ------ | ------ |
| $host| 請求信息中的Host,如果請求中沒有Host行,則等于設置的服務器名 |
| $request_method | 客戶端請求類型,如GET、POST
| $remote_addr | 客戶端的IP地址 |
|$args | 請求中的參數 |
|$content_length| 請求頭中的Content-length字段 |
|$http_user_agent | 客戶端agent信息 |
|$http_cookie | 客戶端cookie信息 |
|$remote_addr | 客戶端的IP地址 |
|$remote_port | 客戶端的端口 |
|$server_protocol | 請求使用的協議,如HTTP/1.0、·HTTP/1.1` |
|$server_addr | 服務器地址 |
|$server_name| 服務器名稱|
|$server_port|服務器的端口號|

解決跨域

先追本溯源以下,跨域究竟是怎么回事。

跨域的定義

同源策略限制了從同一個源加載的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用于隔離潛在惡意文件的重要安全機制。通常不允許不同源間的讀操作。

同源的定義

如果兩個頁面的協議,端口(如果有指定)和域名都相同,則兩個頁面具有相同的源。

nginx解決跨域的原理

例如:

前端server的域名為:fe.server.com

后端服務的域名為:dev.server.com

現在我在fe.server.comdev.server.com發起請求一定會出現跨域。

現在我們只需要啟動一個nginx服務器,將server_name設置為fe.server.com,然后設置相應的location以攔截前端需要跨域的請求,最后將請求代理回dev.server.com。如下面的配置:

server {
        listen       80;
        server_name  fe.server.com;
        location / {
                proxy_pass dev.server.com;
        }
}

這樣可以完美繞過瀏覽器的同源策略:fe.server.com訪問nginxfe.server.com屬于同源訪問,而nginx對服務端轉發的請求不會觸發瀏覽器的同源策略。

請求過濾

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/404.jpg)

根據狀態碼過濾

error_page 500 501 502 503 504 506 /50x.html;
    location = /50x.html {
        #將跟路徑改編為存放html的路徑。
        root /root/static/html;
    }

根據URL名稱過濾,精準匹配URL,不匹配的URL全部重定向到主頁。

location / {
    rewrite  ^.*$ /index.html  redirect;
}

根據請求類型過濾。

if ( $request_method !~ ^(GET|POST|HEAD)$ ) {
        return 403;
    }
配置gzip

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/gzip.jpg)

GZIP是規定的三種標準HTTP壓縮格式之一。目前絕大多數的網站都在使用 GZIP 傳輸 HTML、CSS、JavaScript 等資源文件。

對于文本文件,GZip 的效果非常明顯,開啟后傳輸所需流量大約會降至 1/4 ~ 1/3。

并不是每個瀏覽器都支持gzip的,如何知道客戶端是否支持gzip呢,請求頭中的Accept-Encoding來標識對壓縮的支持。

啟用gzip同時需要客戶端和服務端的支持,如果客戶端支持gzip的解析,那么只要服務端能夠返回gzip的文件就可以啟用gzip了,我們可以通過nginx的配置來讓服務端支持gzip。下面的responecontent-encoding:gzip,指服務端開啟了gzip的壓縮方式。

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/gzip2.png)

    gzip                    on;
    gzip_http_version       1.1;        
    gzip_comp_level         5;
    gzip_min_length         1000;
    gzip_types text/csv text/xml text/css text/plain text/javascript application/javascript application/x-javascript application/json application/xml;
gzip

開啟或者關閉gzip模塊

默認值為 off

可配置為 on / off

gzip_http_version

啟用 GZip 所需的 HTTP 最低版本

默認值為 HTTP/1.1

這里為什么默認版本不是1.0呢?

HTTP 運行在 TCP 連接之上,自然也有著跟 TCP 一樣的三次握手、慢啟動等特性。

啟用持久連接情況下,服務器發出響應后讓TCP連接繼續打開著。同一對客戶/服務器之間的后續請求和響應可以通過這個連接發送。

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/keepalive.png)

為了盡可能的提高 HTTP 性能,使用持久連接就顯得尤為重要了。

HTTP/1.1 默認支持 TCP 持久連接,HTTP/1.0 也可以通過顯式指定 Connection: keep-alive 來啟用持久連接。對于 TCP 持久連接上的 HTTP 報文,客戶端需要一種機制來準確判斷結束位置,而在 HTTP/1.0 中,這種機制只有 Content-Length。而在HTTP/1.1 中新增的 Transfer-Encoding: chunked 所對應的分塊傳輸機制可以完美解決這類問題。

nginx同樣有著配置chunked的屬性chunked_transfer_encoding,這個屬性是默認開啟的。

Nginx 在啟用了GZip的情況下,不會等文件 GZip 完成再返回響應,而是邊壓縮邊響應,這樣可以顯著提高 TTFB(Time To First Byte,首字節時間,WEB 性能優化重要指標)。這樣唯一的問題是,Nginx 開始返回響應時,它無法知道將要傳輸的文件最終有多大,也就是無法給出 Content-Length 這個響應頭部。

所以,在HTTP1.0中如果利用Nginx 啟用了GZip,是無法獲得 Content-Length 的,這導致HTTP1.0中開啟持久鏈接和使用GZip只能二選一,所以在這里gzip_http_version默認設置為1.1。

gzip_comp_level

壓縮級別,級別越高壓縮率越大,當然壓縮時間也就越長(傳輸快但比較消耗cpu)。

默認值為 1

壓縮級別取值為1-9

gzip_min_length

設置允許壓縮的頁面最小字節數,Content-Length小于該值的請求將不會被壓縮

默認值:0

當設置的值較小時,壓縮后的長度可能比原文件大,建議設置1000以上

gzip_types

要采用gzip壓縮的文件類型(MIME類型)

默認值:text/html(默認不壓縮js/css)

負載均衡 什么是負載均衡

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx3.jpg)

如上面的圖,前面是眾多的服務窗口,下面有很多用戶需要服務,我們需要一個工具或策略來幫助我們將如此多的用戶分配到每個窗口,來達到資源的充分利用以及更少的排隊時間。

把前面的服務窗口想像成我們的后端服務器,而后面終端的人則是無數個客戶端正在發起請求。負載均衡就是用來幫助我們將眾多的客戶端請求合理的分配到各個服務器,以達到服務端資源的充分利用和更少的請求時間。

nginx如何實現負載均衡

Upstream指定后端服務器地址列表

upstream balanceServer {
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

在server中攔截響應請求,并將請求轉發到Upstream中配置的服務器列表。

    server {
        server_name  fe.server.com;
        listen 80;
        location /api {
            proxy_pass http://balanceServer;
        }
    }

上面的配置只是指定了nginx需要轉發的服務端列表,并沒有指定分配策略。

nginx實現負載均衡的策略

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/loadBalancing.png)

輪詢策略

默認情況下采用的策略,將所有客戶端請求輪詢分配給服務端。這種策略是可以正常工作的,但是如果其中某一臺服務器壓力太大,出現延遲,會影響所有分配在這臺服務器下的用戶。

upstream balanceServer {
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx5.png)

最小連接數策略

將請求優先分配給壓力較小的服務器,它可以平衡每個隊列的長度,并避免向壓力大的服務器添加更多的請求。

upstream balanceServer {
    least_conn;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

![image](https://lsqimg-1257917459.cos-website.ap-beijing.myqcloud.com/blog/nginx4.png)

最快響應時間策略

依賴于NGINX Plus,優先分配給響應時間最短的服務器。

upstream balanceServer {
    fair;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}

客戶端ip綁定

來自同一個ip的請求永遠只分配一臺服務器,有效解決了動態網頁存在的session共享問題。

upstream balanceServer {
    ip_hash;
    server 10.1.22.33:12345;
    server 10.1.22.34:12345;
    server 10.1.22.35:12345;
}
靜態資源服務器
location ~* .(png|gif|jpg|jpeg)$ {
    root    /root/static/;  
    autoindex on;
    access_log  off;
    expires     10h;# 設置過期時間為10小時          
}

匹配以png|gif|jpg|jpeg為結尾的請求,并將請求轉發到本地路徑,root中指定的路徑即nginx本地路徑。同時也可以進行一些緩存的設置。

小結

nginx的功能非常強大,還有很多需要探索,上面的一些配置都是公司配置的真實應用(精簡過了)。

文中如有錯誤,歡迎在評論區指正,如果這篇文章幫助到了你,歡迎點贊和關注。

想閱讀更多優質文章、可關注我的github博客,你的star?、點贊和關注是我持續創作的動力!

推薦大家使用Fundebug,一款很好用的BUG監控工具~

推薦關注我的微信公眾號【code秘密花園】,每天推送高質量文章,我們一起交流成長。

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/40374.html

相關文章

  • Web前端必備-Nginx知識匯總

    摘要:安裝簡單配置簡潔啟動快速便捷支持熱部署支持擁有高度模塊化的設計。備注在版本之前,不能在中使用權重。不能與同時使用。當有服務器需要剔除,必須手動掉。表示把請求轉發給連接數較少的后端服務器。表示當前的暫時不參與負載均衡。表示預留的備份機器。 本文已同步到專業技術網站 www.sufaith.com, 該網站專注于前后端開發技術與經驗分享, 包含Web開發、Nodejs、Python、Lin...

    whatsns 評論0 收藏0
  • IT運維必備技能

    摘要:熟練使用等抓包工具底層大神級,內核其它素養處理方式除了技能,我覺得素養態度也可以談談安全運維人員的權限很大,所以一定要保證帳號私鑰的安全。應該第一時間和開發部門確認,要求優化代碼。進取心不斷學習運維的知識范圍很廣,要不斷學習。 寫代碼寫了10多年, 從小公司到大公司, 前端, 后端, 數據庫, 運維什么都做, 最后還是專職做運維了. 整理下運維的一些技能, 部分是網上資料并整理. Li...

    lily_wang 評論0 收藏0
  • 平時積累前端資源,持續更新中。。。

    本文收集學習過程中使用到的資源。 持續更新中…… 項目地址 https://github.com/abc-club/f... 目錄 vue react react-native Weex typescript Taro nodejs 常用庫 css js es6 移動端 微信公眾號 小程序 webpack GraphQL 性能與監控 高質文章 趨勢 動效 數據結構與算法 js core 代碼規范...

    acrazing 評論0 收藏0

發表評論

0條評論

pumpkin9

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<