網絡優化

個人原創，允許轉載，請註明出處，作者，否則追究法律責任。

數據庫優化【IO問題優化】-------memcache 加快提供數據的速度

web優化 ---- 緩存 varnish

web服務器
1 接受用戶請求
2 處理請求
3 響應請求

最初：業務量很少
a 前端後端放在一臺機器，實用普通機械硬盤。 對cpu 內存 磁盤等等資源都會進行搶占。
b 把後端服務器拆分出來。【也可以保證數據安全。】
c 將前端頁面中的動態頁面和靜態頁面分離。------靜態頁面走緩存，比如varnish、或者買CDN。動態頁面走memcache、redis。。
d 通過集群方式增加web的處理能力。
lvs： nat
DR 必須在同一個機房，沒法異地容災。
tun
keeplive 組播，VPN【虛擬專用網絡】
單播 多播【組播】 廣播
【fullnat】
nginx 速度不如lvs，但是靈活性強。
haproxy

單個集群處理能力終究有限。
多集群協同處理用戶請求？ 路由分發
OSPF【開放式最短路徑優先】

Client 首頁分發 route【ospf】 多個集群 lvs分發 RS
route【ospf】 多個集群 lvs分發 RS
route【ospf】 多個集群 lvs分發 RS
首頁分發：根據業務不同進行拆分。
天貓超市、男裝、女裝、天貓國際。。。。。

天貓超市：
route【ospf】 多個集群 lvs分發 RS
天貓國際：
route【ospf】 多個集群 lvs分發 RS

PV page view 用戶訪問一次頁面。
UV user view 用戶訪問的數量。

峰值pv【每秒並發數】：日pv量/86400*[峰值倍數5-8倍]
2000000/86400*8=185

帶寬（單位bit）=PV數*頁面的大小(單位byte)*8
185*10M*8=14814mb/s 1M=100元
a cdn緩存將超過80%的靜態頁面緩存下來。
b 客戶端本地有緩存。

請求數（QPS） query per sec 每秒請求數。
web通過子進程分開處理不同的請求。
峰值請求數=日pv量/86400*每個pv的請求數*響應一個請求的平均時間*峰值倍數【5】
2000000/86400*50*1*5=5787

運營成本的計算：
設備成本
帶寬成本
人員成本 ----- 2 10 3
10000 12% 1200
2000 12% 240

買cdn

dell 710 3000/月
雲服務器 16核 32G 節約一半成本。

lsof -i:80| wc -l
ps aux

網絡連接狀態：
netstat
-a 顯示所有選項，默認不顯示listen相關的信息
-n 以數字的形式顯示
-t 顯示tcp相關信息
-u 顯示udp相關信息
-p PID/Program name 顯示PID和程序名稱
-l 僅顯示listen狀態的服務
-r 顯示路由信息
-e 顯示擴展信息
-c 刷新間隔，每隔多少時間執行一次netstat命令

常用的：
netstat -antp ---查看所有的端口
netstat -ntlp ---查看監聽的端口

IPV4 : 32位
IPV6 : 128位
0-9 a b c d e f
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
IPV6的私有地址：fe80:....
:: 代表所有的ip
0.0.0.0 代表所有的ipv6的地址
0000:0000:0000:0000:0000:0000:0000:0000 縮寫成: "::"
IPV6縮寫原則：左邊的零可以省略
0100:1000:0010
100:1000:10

linux 用戶打開的最大文件限制：
默認為 1024個
ulimit -n
1024
個人電腦使用，不用改，但服務器必需改這個。幾千上萬，一下子就上來了
手動修改：
方法一：
vi /etc/security/limits.conf
* soft nofile 102400 (nofile:number file 文件數量)（*　可以改成Apache 指定用戶）
* hard nofile 102400
方法二：
修改內存：ulimit -HSn 102400 （H：hard，S：soft）

內核調優：
兩種方法：
1，修改 /proc/.... 這時修改內存裏面的參數，源文件是從內核參數中讀取的。重啟失效。
2，修改內核參數：
vim /etc/sysctl.conf
...
systemctl -p (讓修改立馬生效，重啟後仍然有效。)
修改內核參數：/etc/systctl.conf
這個文件的裏的內容和內存中的文件一一對應。比如：
net.ipv4.tcp_syscookies = 1 就是對應的： /proc/sys/net/ipv4/tcp_syscookies這個文件

listen連接數，定義了最大的監聽隊列。每一個端口最大能監聽多大的隊列。
vim /proc/sys/net/core/somaxconn

引申：Apache的配置文件：

<IfModule prefork.c> ---------------------------- prefork模式下
StartServers 8 默認啟動多少個進程
MinSpareServers 5 最小空閑進程
MaxSpareServers 20 最大
ServerLimit 256 進程數限制
MaxClients 256 最大連接數限制，請求的並發量 （這個值不能超過上面的進程數限制）
MaxRequestsPerChild 4000 一個子進程能夠處理多少個請求。

apache同時能夠處理的並發數=MaxClients*進程的線程數（在perfork模式下，一個進程產生一個線程。）

worker --------------------------- worker模式下

StartServers 2 #啟動apache時啟動的httpd進程個數。
MaxClients 150 #最大並發連接數。
MinSpareThreads 25 #服務器保持的最小空閑線程數。
MaxSpareThreads 75 #服務器保持的最大空閑線程數。
ThreadsPerChild 25 #每個子進程的產生的線程數。
MaxRequestsPerChild 0 #每個子進程被請求服務多少次後被kill掉。0表示不限制，推薦設置為1000。

</IfModule>
該模式下，子進程的數量是固定的，線程數不受限制。當客戶端連接到服務器時，又空閑的線程提供服務。 如果空閑線程數不夠，子進程自動產生線程來為新的連接服務。該模式用於多站點服務器。

/proc/sys/net/ipv4:
tcp_syn_retries 默認是5，服務器發送syn的次數【主動連接】，可以修改為2.
tcp_max_syn_backlog 默認1024，服務器維護的tcp syn隊列的長度【被動連接時】。
tcp_synack_retries 默認5，放棄連接之前發送synack的次數。改成2.
tcp_syncookies 紅帽默認為1，開啟狀態，
tcp_retries1 默認3，放棄回應一個tcp前，要重試幾次。
tcp_retries2 默認15，放棄一個已經建立連接的tcp之前重試幾次， 建議改為5.

tcp預分配的緩沖區大小：
tcp_rmem 接收緩沖區的大小
4096 87380 4194304 最小 默認 最大 單位字節
tcp_wmem 發送緩沖區的大小
4096 16384 4194304
tcp_mem 第一個值是內存使用的下限，第二個是壓力模式， 第三個是內存使用的上限。
176928 235904 353856 【單位 是內存頁，4KB】

tcp雙工協議。會話的雙方都可以接受和發送數據。
發送窗口：取決於對面的接收窗口的大小。
接收窗口：取決於硬件、系統、應用等的限制。

發送緩存：
1 已經發送並收到對面的ack
2 已經發送但是沒有收到對面的ack
3 沒有發送但是準備發送
4 沒有發送也不準備發送
2+3 是發送窗口

對於接收緩存：
1 已接收
2 未接收準備接收
3 未接收也不準備接收
2 是接收窗口

接收窗口和發送窗口稱為 滑動窗口

[[email protected] core]# cat rmem_default
124928 改 248000
[[email protected] core]# cat wmem_default
124928 248000
[[email protected] core]# cat wmem_max
124928 496000
[[email protected] core]# cat rmem_max
124928 496000

tcp長連接設置：ipv4中
tcp_keepalive_intvl 默認75，單位為秒，探測間隔，改成30秒
tcp_keepalive_probes 默認9，單位為次數，探測次數，改成3次
tcp_keepalive_time 默認7200單位為秒，2小時，長連接時間，改為1800

四次斷開：
tcp_fin_timeout time wait的回收時間60，改成30秒
tcp_tw_reuse 默認0，不建議修改。
tcp_tw_recycle 默認0，time wait的快速回收，也不建議修改。

網絡優化