Nginx安全優化包括:刪除不要的模塊、修改版本信息、限制併發、拒絕非法請求、防止buffer溢出。
MySQL安全優化包括:初始化安全腳本、密碼安全、備份與還原、數據安全。
Tomcat安全優化包括:隱藏版本信息、降權啓動、刪除默認測試頁面.javascript
###################################################################php
vim /usr/local/nginx/logs/access.log //訪問日誌css
keepalive_timeout //長時間不訪問,服務器斷開鏈接html
[root@proxy ~]# curl http://192.168.4.5/statusjava
Active connections: 1 //多少人同時訪問 server accepts handled requests 10 10 3 Reading: 0 Writing: 1 Waiting: 0
客戶端訪問10次 TCP握手鍊接數
服務器接收10次
發送3次請求 點頁面的次數nginx
###################################################################web
http是tcp協議面試
worker_processes 2; //與CPU核心數量一致json
events {
worker_connections 50000; //併發鏈接數
}vim
即便修改了配置文件的併發鏈接數,可是內核的默認參數仍是不變的。
###################################################################
優化Linux內核參數(最大文件數量)
ulimit-a
open files (- n) 1024
ulimit -Hn 100000 //硬限制 不能超過這個數
(都是臨時規則)
ulimit -Sn 100000 //軟限制 只是警告
vim /etc/security/limits.conf //永久配置
soft nofile 100000 //軟限制
####################################################################
優化Nginx數據包頭緩存
1)優化前,使用腳本測試長頭部請求是否能得到響應
[root@proxy ~]# cat lnmp_soft/buffer.sh
#!/bin/bash
URL=http://192.168.4.5/index.html?
for i in {1..5000}
do
URL=${URL}v$i=$i
done
curl $URL //通過5000次循環後,生成一個長的URL地址欄
[root@proxy ~]# ./buffer.sh
.. ..
<center><h1>414 Request-URI Too Large</h1></center> //提示頭部信息過大`
url=192.168.4.5/
for i in 1..5000
url=$url_v$i=$i
url=192.168.4.5/v1=1
usl=http://192.168.4.5/v1=1v2=2v3=3 v5000=5000
服務器和客戶端都會報錯414,說明服務器給的內存過小,地址欄過長
修改配置文件,能存更多的地址欄
414報錯,優化緩存大小,讓他處理地址欄數據更大
修改Nginx配置文件,增長數據包頭部緩存大小
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
http }
client_header_buffer_size 1k; //默認請求包頭信息的緩存
large_client_header_buffers 4 4k; //大請求包頭部信息的緩存個數與容量
}
[root@proxy ~]# nginx -s reload
######################################################################
瀏覽器自帶緩存功能
若是你訪問的是 (多媒體) jpg,視頻,mp3
expries 30; //緩存多久
修改Nginx配置文件,定義對靜態頁面的緩存時間
[root@proxy ~]# vim /usr/local/nginx/conf/nginx.conf
server {
listen 80;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
location ~* .(jpg|jpeg|gif|png|css|js|ico|xml)$ {
expires 30d; //定義客戶端緩存時間爲30天
}
}
[root@proxy ~]# cp /usr/share/backgrounds/day.jpg /usr/local/nginx/html
[root@proxy ~]# nginx -s reload
#請先確保nginx是啓動狀態,不然運行該命令會報錯,報錯信息以下:
#[error] open() "/usr/local/nginx/logs/nginx.pid" failed (2: No such file or directory)
###############################################################################
日誌切割
日誌文件愈來愈大怎麼辦?單個文件10G? 如何切割?(很是常見的面試題)
步驟:
1)手動執行
備註:/usr/local/nginx/logs/nginx.pid文件中存放的是nginx的進程PID號。
[root@proxy ~]# mv access.log access2.log
[root@proxy ~]# kill -USR1 $(cat /usr/local/nginx/logs/nginx.pid)
2)自動完成
每週5的03點03分自動執行腳本完成日誌切割工做。
[root@proxy ~]# vim /usr/local/nginx/logbak.sh
#!/bin/bash
date=date +%Y%m%d
logpath=/usr/local/nginx/logs
mv $logpath/access.log $logpath/access-$date.log
mv $logpath/error.log $logpath/error-$date.log
kill -USR1 $(cat $logpath/nginx.pid)
[root@proxy ~]# crontab -e
03 03 5 /usr/local/nginx/logbak.sh
########################################################################
/usr/local/nginx/conf/mime.types
步驟七:對頁面進行壓縮處理
1)修改Nginx配置文件
[root@proxy ~]# cat /usr/local/nginx/conf/nginx.conf
http {
.. ..
gzip on; //開啓壓縮
gzip_min_length 1000; //小文件不壓縮
gzip_comp_level 4; //壓縮比率
gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;
//對特定文件壓縮,類型參考mime.types
.. ..
}
###################################################################
客戶端能夠經過內存讀取數取,不經過硬盤。能夠更快速獲取數據
服務器內存緩存
1)若是須要處理大量靜態文件,能夠將文件緩存在內存,下次訪問會更快。
http {
open_file_cache max=2000 inactive=20s;
open_file_cache_valid 60s;
open_file_cache_min_uses 5;
open_file_cache_errors off;
//設置服務器最大緩存2000個文件句柄,關閉20秒內無請求的文件句柄
//文件句柄的有效時間是60秒,60秒後過時
//只有訪問次數超過5次會被緩存
//緩存報錯關掉
}
Nginx安全優化包括:刪除不要的模塊、修改版本信息、限制併發、拒絕非法請求、防止buffer溢出。
性能優化:定義狀態頁面、優化NGINX併發量、優化Linux內核參數、優化nginx數據包頭緩存、對頁面進行壓縮處理
服務器內存緩存
#############################################################################
Nginx常見報錯及處理方法
403是很常見的錯誤代碼,通常就是未受權被禁止訪問的意思。
可能的緣由有兩種:
Nginx程序用戶無權限訪問web目錄文件
Nginx須要訪問目錄,可是autoindex選項被關閉
修復方法:
授予Nginx程序用戶權限讀取web目錄文件
設置autoindex目錄爲on
location /path/to/website/folder {
...
autoindex on;
... }
404
第一種:Nginx本身的錯誤頁面
Nginx訪問一個靜態的html 頁面,當這個頁面沒有的時候,Nginx拋出404,那麼如何返回給客戶端404呢?
看下面的配置,這種狀況下不須要修改任何參數,就能實現這個功能。
第二種:反向代理的錯誤頁面
若是後臺Tomcat處理報錯拋出404,想把這個狀態叫Nginx反饋給客戶端或者重定向到某個鏈接,配置以下:
location / {
if ($request_uri ~ ‘^/$’) {
rewrite . http://域名/index.html redirect;
}
第三種:Nginx解析php代碼的錯誤頁面
1
若是後端是php解析的,須要加一個變量
在http段中加一個變量
fastcgi_intercept_errors on 就能夠了。
2
指定一個錯誤頁面:
error_page 404 /404.html;
location = /404.html {
root /usr/share/nginx/html;
}
3
指定一個url地址:
error_page 404 /404.html;
error_page 404 = http://www.test.com/error.html;
413 Request Entity Too Large
通常緣由:通常出如今上傳文件
解決方法:配置nginx.conf相關設置
1.client_max_body_size 10m; //客戶端最大上傳大小
配置php.ini以下(必須和nginx.conf配置一致)
1.post_max_size=10M //設置最大大小
2.upload_max_filesize=2M //上傳最大文件大小
499 Client Closed Request
通常緣由:server處理請求未結束,而client提早關閉了鏈接,此時也會返回499。
解決方法:proxy_ignore_client_abort on; //代理忽視客戶端終止計劃
#讓代理服務端不要主動關閉客戶端的鏈接。
只在作反向代理的時候加入,做爲其餘服務器的時候,關閉爲好,默認設置是關閉的!
若是使用了 proxy_ignore_client_abort on ;
默認 proxy_ignore_client_abort 是關閉的,此時在請求過程當中若是客戶端端主動關閉請求或者客戶端網絡斷掉,那麼 Nginx 會記錄 499
那麼客戶端主動斷掉鏈接以後,Nginx 會等待後端處理完(或者超時),而後記錄「後端的返回信息」到日誌。因此,若是後端返回 200,就記錄 200 ;若是後端放回 5XX ,那麼就記錄 5XX 。
若是超時(默認60s,能夠用 proxy_read_timeout 設置),Nginx 會主動斷開鏈接,記錄 504
500 Internal Server Rrror
通常緣由:腳本錯誤,(php語法錯誤、lua語法錯誤)
訪問量過大,系統資源限制,不能打開過多文件
磁盤空間不足。(access log開啓可能致使磁盤滿溢 關閉)
解決方法:語法錯誤查看nginx_err_log php_err_log。
文件訪問量:
1.修改nginx配置文件
1.worker_rlimit_nofile 65535; //worker進程最大打開文件數
2.修改/etc/security/limits.conf
通常分析思路:
(1)查看nginx error log ,查看php error log;
(2)若是是too many open files,修改nginx的worker_rlimit_nofile參數,使用ulimit查看系統打開文件限制,修改/etc/security/limits.conf;
(3)若是是腳本的問題,則須要修復腳本錯誤,並優化代碼;
(4)各類優化都作好,仍是出現too many open files,那就要考慮作負載均衡,把流量分散到不一樣服務器上去了。
502 Bad Gateway、503 Serveice Unavailable
通常緣由:後端服務沒法處理,業務中斷。
解決方法:從後端日誌獲取錯誤緣由,解決後端服務器問題。
504 Gateway Timeout
通常緣由:後端服務器在超時時間內,未響應Nginx代理請求
解決方法:根據後端服務器實際處理狀況,調正後端請求超時時間。
1.proxy_read_timeout 90;
2.proxy_send_timeout 90;
通常緣由:可能網站頁面緩存大,而fastcgi默認進程響應緩存區8k
解決方法:配置nginx.conf相關設置
1.fastcgi_buffers 8 128k2.send_timeout 60;