如何優(yōu)化Web服務(wù)器以實(shí)現(xiàn)高吞吐量和低延遲

　　點(diǎn)擊上方“CSDN”，選擇“置頂公眾號(hào)”

　　關(guān)鍵時(shí)刻，第一時(shí)間送達(dá)！

　　作者丨Alexey Ivanov

　　翻譯丨不二

　　譯者注：人們更多的是關(guān)注軟件一類的優(yōu)化，當(dāng)負(fù)載上來后，發(fā)現(xiàn)硬件發(fā)揮不出最大性能。服務(wù)器出廠時(shí)，BIOS 默認(rèn)達(dá)到了性能和能耗之間的良好平衡，以適應(yīng)一般環(huán)境，然而在不同的環(huán)境下可能需要對(duì)服務(wù)器進(jìn)行優(yōu)化，以獲得最大的吞吐量或最低的延遲，本文全面講述如何在硬件層面優(yōu)化web服務(wù)器，請(qǐng)看譯文。

　　這是對(duì)2017年9月6日在NginxConf 2017年演講內(nèi)容的延伸。作為Dropbox Traffice團(tuán)隊(duì)的網(wǎng)絡(luò)可靠性工程師（SRE，Site Reliability Engineer ），我負(fù)責(zé)公司的邊緣網(wǎng)絡(luò)，包括它的可靠性、性能和效率。Dropbox 邊緣網(wǎng)絡(luò)是一個(gè)基于nginx的代理層，用于處理敏感的元數(shù)據(jù)事務(wù)和高吞吐量數(shù)據(jù)傳輸。在處理數(shù)以萬計(jì)敏感事務(wù)的系統(tǒng)中，通過TCP/IP協(xié)議和內(nèi)核，從驅(qū)動(dòng)程序、中斷到庫、應(yīng)用級(jí)調(diào)優(yōu)，整個(gè)代理堆棧中都存在效率/性能優(yōu)化。

　　免責(zé)聲明

　　這篇文章將討論如何調(diào)優(yōu)web服務(wù)器和代理服務(wù)器，并采用科學(xué)的方法，將它們逐一應(yīng)用測(cè)量效果，最終確定是否真的對(duì)所處的環(huán)境有用。

　　這不是一篇關(guān)于Linux性能的文章，盡管它大量引用了bcc工具、eBPF和perf，但不要誤以為是使用性能分析工具的全面指南。如果你想了解更多關(guān)于他們的信息，可以通過Brendan Gregg的博客閱讀。

　　這也不是一篇關(guān)于瀏覽器性能的文章。當(dāng)介紹與延遲相關(guān)的優(yōu)化時(shí)，會(huì)涉及到客戶端的性能，但只是短暫的。如果你想知道更多這方面的，可以閱讀Ilya Grigorik的高性能瀏覽器網(wǎng)絡(luò)。

　　最后，這也不是關(guān)于TLS（傳輸層安全協(xié)議）的最佳實(shí)踐編譯，盡管會(huì)提到TLS庫及其設(shè)置，但那是為了評(píng)估每種方法的性能和安全性。可以使用Qualys SSL測(cè)試，以驗(yàn)證網(wǎng)絡(luò)終端與當(dāng)前的最佳實(shí)踐，如果想了解更多關(guān)于TLS的信息，請(qǐng)考慮閱讀Feisty Duck Bulletproof TLS Newsletter。

　　文章的結(jié)構(gòu)

　　文章將討論系統(tǒng)不同層級(jí)的效率/性能優(yōu)化。從硬件和驅(qū)動(dòng)程序的最低級(jí)別開始：這些調(diào)優(yōu)可以應(yīng)用到幾乎任何高負(fù)載服務(wù)器上。然后將轉(zhuǎn)移到linux內(nèi)核及其TCP/IP協(xié)議棧：這些是在任何一個(gè)TCP-heavy盒子上嘗試的旋鈕。最后將討論庫和應(yīng)用程序級(jí)別的調(diào)優(yōu)，它們主要適用于一般的web服務(wù)器和nginx服務(wù)器。

　　對(duì)于每一個(gè)潛在的優(yōu)化領(lǐng)域，將嘗試提供一些關(guān)于延遲/吞吐量權(quán)衡（如果有的話）的背景知識(shí)，以及監(jiān)控指導(dǎo)方針，最后建議對(duì)不同的工作負(fù)載作調(diào)整。

　　硬件方面

　　CPU

　　對(duì)于良好的非對(duì)稱RSA/EC性能，具有至少AVX2(AVX2 in /proc/ cpuinfo)支持的處理器，最好是具有大型整數(shù)算術(shù)能力硬件(bmi和adx)的處理器。而對(duì)于對(duì)稱的情況，應(yīng)該找AES ciphers和AVX512的ChaCha+Poly。英特爾通過OpenSSL 1.0.2對(duì)不同的硬件產(chǎn)品進(jìn)行了性能比較，說明了這些硬件卸載的影響。

　　CPU延遲敏感的用例，如路由選擇，減少NUMA的節(jié)點(diǎn)和禁用HT會(huì)有幫助。擁有更多內(nèi)核意味著高吞吐量的任務(wù)會(huì)處理得更好，并且將從超線程（除非它們是緩存綁定）中受益，而且通常不會(huì)過多地關(guān)心NUMA。

　　具體地說，如果走英特爾的路線，至少需要haswell或broadwell架構(gòu)的處理器與合適的Skylake CPUs。如果采用AMD，那么EPYC相當(dāng)不錯(cuò)。

　　NIC（網(wǎng)絡(luò)適配器）

　　至少需要10G網(wǎng)卡，最好是25G。如果想要通過TLS單個(gè)服務(wù)器達(dá)到更大的傳輸，這里所描述的調(diào)優(yōu)是不夠的，可能需要將TLS構(gòu)建到內(nèi)核級(jí)別（例如FreeBSD，Linux）。

　　在軟件方面，應(yīng)該尋找具有活動(dòng)郵件列表和用戶社區(qū)的開源驅(qū)動(dòng)程序。如果涉及到調(diào)試與驅(qū)動(dòng)相關(guān)的問題，這將是非常重要的。

　　內(nèi)存

　　選擇的經(jīng)驗(yàn)法則是，延遲敏感的任務(wù)需要更快的內(nèi)存，而吞吐量敏感的任務(wù)需要更多的內(nèi)存。

　　硬盤

　　這取決于緩沖/緩存的需求，如果要緩存大量的內(nèi)容，應(yīng)該選擇基于flash的存儲(chǔ)。有些甚至采用了專門的flash友好文件系統(tǒng)（通常是日志結(jié)構(gòu)的），但是它們并不總是比普通的ext4/xfs性能更好。

　　無論如何，注意不要因?yàn)橥泦⒂肨RIM或更新固件而燒穿了flash。

　　操作系統(tǒng)：低水平

　　固件

　　保持固件最新，以避免痛苦和冗長的故障排除會(huì)話。盡量保持最新的CPU微碼，主板，NICs和ssd固件。這并不意味著要一直花錢，經(jīng)驗(yàn)法則是把固件更新到上一個(gè)版本就行，除非它在最新版本中修復(fù)了關(guān)鍵錯(cuò)誤，否則只要不要太落后就行。

　　驅(qū)動(dòng)

　　更新規(guī)則和固件更新差不多，嘗試保持最新。這里需要注意的是，如果可能的話，嘗試將內(nèi)核升級(jí)與驅(qū)動(dòng)程序更新解耦。例如，可以用DKMS打包驅(qū)動(dòng)程序，或者為使用的所有內(nèi)核版本預(yù)編譯驅(qū)動(dòng)程序。這樣當(dāng)更新內(nèi)核出現(xiàn)故障時(shí)不需要考慮驅(qū)動(dòng)程序。

　　CPU

　　在Ubuntu/Debian中，可以使用一些實(shí)用工具安裝linux工具包，但是現(xiàn)在只使用cpupower、turbostat和x86_energy_perf_policy即可。為了驗(yàn)證cpu相關(guān)的優(yōu)化，可以通過常用的負(fù)載生成工具對(duì)軟件進(jìn)行壓力測(cè)試（例如，Yandex使用Yandex.Tank）。下面是有一份來自NginxConf開發(fā)者的演示，介紹了nginx加載測(cè)試的最佳實(shí)踐：“nginx性能測(cè)試”。

　　cpupower

　　使用這個(gè)工具比crawling /proc/更容易。要查看有關(guān)處理器及其頻率調(diào)控器的信息，請(qǐng)運(yùn)行以下代碼。

　　$ cpupower frequency-info

　　...

　　driver: intel_pstate

　　...

　　available cpufreq governors: performance powersave

　　...

　　The governor "performance" may decide which speed to use

　　...

　　boost state support:

　　Supported: yes

　　Active: yes

　　檢查是否啟用了Turbo Boost，對(duì)于Intel cpu確保運(yùn)行的是intel_pstate，而不是acpi-cpufreq或者pcc-cpufreq。如果堅(jiān)持使用acpic-cpufreq，那么應(yīng)該升級(jí)內(nèi)核，或者如果不能升級(jí)，確保使用的是performance調(diào)控器。在使用intel_pstate運(yùn)行時(shí)，powersave調(diào)控器也應(yīng)該運(yùn)行良好，但這一步需要自己去驗(yàn)證。

　　想看看空載時(shí)CPU到底發(fā)生了什么，可以使用turbostat直接查看處理器的MSRs，獲取電源、頻率和空閑狀態(tài)信息。

　　# turbostat --debug -P

　　... Avg_MHz Busy% ... CPU%c1 CPU%c3 CPU%c6 ... Pkg%pc2 Pkg%pc3 Pkg%pc6 ...

　　這里可以看到實(shí)際的CPU頻率（是的，/proc/cpuinfo欺騙了你），以及核心/包空閑狀態(tài)。

　　如果使用intel_pstate驅(qū)動(dòng)程序，CPU的空閑時(shí)間會(huì)比預(yù)想的要多，可以采取以下措施。

　　設(shè)置性能調(diào)節(jié)。

　　設(shè)置x86_energy_perf_policy性能。

　　或者，對(duì)于非常延遲的關(guān)鍵任務(wù)，還可以這樣做。

　　采用/dev/cpu_dma_latency接口。

　　對(duì)于UDP流量，使用busy-polling方法。

　　更多關(guān)于處理器電源管理的信息，可以在2015年的LinuxCon Europe上由“Linux內(nèi)核”的Intel開源技術(shù)中心發(fā)表的“Linux內(nèi)核中的平衡能力和性能”文章中了解到。

　　CPU親和力

　　還可以通過在每個(gè)線程/流程上應(yīng)用CPU關(guān)聯(lián)性來降低延遲，例如nginx，它具有worker_cpu_affinity指令，可以自動(dòng)將每個(gè)web服務(wù)器進(jìn)程綁定到它自己的核心。這可以消除CPU遷移，減少緩存遺漏和頁面錯(cuò)誤，并稍微增加每個(gè)周期的指令數(shù)。所有這些都可以通過perf stat來驗(yàn)證。

　　遺憾的是，啟用親和性也會(huì)增加等待空閑CPU的時(shí)間，從而對(duì)性能產(chǎn)生負(fù)面影響?？梢酝ㄟ^在pid上運(yùn)行runqlat來監(jiān)控。

　　usecs : count distribution

　　0 -> 1 : 819 | |

　　2 -> 3 : 58888 |****************************** |

　　4 -> 7 : 77984 |****************************************|

　　8 -> 15 : 10529 |***** |

　　16 -> 31 : 4853 |** |

　　...

　　4096 -> 8191 : 34 | |

　　8192 -> 16383 : 39 | |

　　16384 -> 32767 : 17 | |

　　如果看到多毫秒的延遲，那么除了nginx本身之外，服務(wù)器可能在處理其他很多的事，一旦關(guān)聯(lián)將增加延遲，而不是減少。

　　內(nèi)存

　　所有的mm/tunings通常都是非常具體的工作流，可以推薦的方法很少。

　　確定有所幫助的話，設(shè)置THP并進(jìn)行啟用，否則會(huì)適得其反得到一個(gè)數(shù)量級(jí)的減速，而不是20%的目標(biāo)延遲改進(jìn)。

　　針對(duì)單個(gè)NUMA節(jié)點(diǎn)設(shè)置vm.zone_reclaim_mode為0.## NUMA。

　　現(xiàn)代的CPU實(shí)際上包含多個(gè)獨(dú)立的CPU，它們通過高速互連和共享資源，從HT核心的L1緩存開始，經(jīng)過包內(nèi)的L3高速緩存，再到內(nèi)存和套接字內(nèi)PCIe鏈路。這基本上就組成了NUMA，它具有快速互連的多個(gè)執(zhí)行和存儲(chǔ)單元。

　　對(duì)于NUMA的全面概述及其影響，可以參考Frank Denneman的“NUMA深入分析系列”。

　　對(duì)于NUMA長話短說，可以進(jìn)行以下選擇:

　　選擇忽略，在BIOS中禁用它，或者在numactl –interleave=all下運(yùn)行軟件，可以得到一般的性能。

　　通過使用單節(jié)點(diǎn)服務(wù)器來替換它，就像Facebook和OCP Yosemite平臺(tái)一樣。

　　選擇接受，并優(yōu)化用戶和內(nèi)核空間中的CPU/內(nèi)存。

　　現(xiàn)在討論第三種選擇，因?yàn)榍皟煞N方法并沒有太多的優(yōu)化。

　　要合理地使用NUMA需要將每個(gè)NUMA節(jié)點(diǎn)視為一個(gè)單獨(dú)的服務(wù)器，對(duì)此應(yīng)該首先檢查拓?fù)浣Y(jié)構(gòu)，可以通過numactl –hardware查看。

　　考慮的因素有：

　　節(jié)點(diǎn)的數(shù)量。

　　每個(gè)節(jié)點(diǎn)的內(nèi)存大小。

　　每個(gè)節(jié)點(diǎn)的cpu數(shù)量。

　　節(jié)點(diǎn)之間的距離。

　　這是一個(gè)非常糟糕的用例，因?yàn)樗?個(gè)節(jié)點(diǎn)同時(shí)沒有附加內(nèi)存的節(jié)點(diǎn)。在不犧牲系統(tǒng)一半內(nèi)核的情況下，很難把每個(gè)節(jié)點(diǎn)都當(dāng)作獨(dú)立的服務(wù)器來處理。

　　可以通過使用numastat來驗(yàn)證：

　　也可以以/proc/meminfo格式要求numastat輸出每個(gè)節(jié)點(diǎn)的內(nèi)存使用統(tǒng)計(jì)信息。

　　現(xiàn)在看一個(gè)更簡單的拓?fù)鋱D。

　　$ numactl --hardware

　　available: 2 nodes (0-1)

　　node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23

　　node 0 size: 46967 MB

　　node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31

　　node 1 size: 48355 MB

　　由于節(jié)點(diǎn)基本是對(duì)稱的，可以通過numactl –cpunodebind=X –membind=X將應(yīng)用程序的實(shí)例綁定到對(duì)應(yīng)的NUMA節(jié)點(diǎn)，然后在另一個(gè)端口上公開它，這樣就可以通過使用兩個(gè)節(jié)點(diǎn)獲得更好的吞吐量，通過保留內(nèi)存位置獲取更好的延遲。

　　通過對(duì)內(nèi)存操作的延遲來驗(yàn)證NUMA的放置效率，例如使用bcc的funclatency來度量內(nèi)存重操作的延遲，像memmove。

　　在內(nèi)核方面，使用perf stat來觀察效率，并查詢相應(yīng)的內(nèi)存和調(diào)度器事件。

　　對(duì)network-heavy工作負(fù)載，最后一點(diǎn)與numa相關(guān)的優(yōu)化來自于一個(gè)事實(shí)，即網(wǎng)絡(luò)適配器是一個(gè)PCIe設(shè)備，每個(gè)設(shè)備都綁定到自己的numa節(jié)點(diǎn)，因此在與網(wǎng)絡(luò)通信時(shí)，一些cpu的延遲時(shí)間會(huì)較低。討論NIC和CPU親和力時(shí)將涉及到優(yōu)化可以應(yīng)用到哪些地方，現(xiàn)在先說一說PCIe。

　　PCIe

　　通常情況下，除非出現(xiàn)某種硬件故障，否則不需要深入地進(jìn)行PCIe故障排除。因此只需創(chuàng)建“鏈接寬度”、“鏈接速度”，并盡可能為PCIe設(shè)備創(chuàng)建RxErr/BadTLP提醒。當(dāng)硬件損壞或PCIe協(xié)商失敗，這將節(jié)省故障排除時(shí)間。可以使用lspci達(dá)到目的。

　　PCIe可能會(huì)成為一個(gè)瓶頸，如果存在多個(gè)高速設(shè)備競(jìng)爭(zhēng)帶寬（例如將快速網(wǎng)絡(luò)與快速存儲(chǔ)結(jié)合起來），那么可能需要在cpu之間物理地切分PCI總線設(shè)備以獲得最大的吞吐量。

　　圖片來源：https://en.wikipedia.org/wiki/PCI_Express History_and_revisions。

　　Mellanox網(wǎng)站上有篇文章“理解PCIe配置的最大性能”，更深入的介紹了PCIe配置，對(duì)于高速傳輸中出現(xiàn)卡頓和操作系統(tǒng)之間的數(shù)據(jù)包丟失會(huì)有所幫助。

　　英特爾公司表示，有時(shí)PCIe的權(quán)力管理（ASPM）可能導(dǎo)致更高的延遲，從而導(dǎo)致更高的包損失，但可以通過向內(nèi)核cmdline添加pcie_aspm=off禁用它。

　　NIC

　　開始之前需要說明的是，Intel和Mellanox都有自己的性能調(diào)優(yōu)指南，無論選擇哪種供應(yīng)商，都有助于了解它們。同時(shí)，驅(qū)動(dòng)程序通常也有自己的README和一套實(shí)用工具。

　　下一個(gè)需要閱讀的是操作系統(tǒng)的手冊(cè)，例如紅帽企業(yè)版Linux系統(tǒng)網(wǎng)絡(luò)性能調(diào)優(yōu)指南，它提到了下面的大多數(shù)優(yōu)化，甚至更多。

　　Cloudflare也提供了一篇關(guān)于在博客上調(diào)優(yōu)網(wǎng)絡(luò)堆棧的一部分的文章，盡管它主要是針對(duì)低延遲的用例。

　　在優(yōu)化網(wǎng)絡(luò)適配器時(shí)，ethtool將提供很好的幫助。

　　注意，如果正在使用一個(gè)最新的內(nèi)核，應(yīng)該在userland中添加一些部分，比如對(duì)于網(wǎng)絡(luò)操作，可能需要最新的：ethtool,iproute2，以及iptables/nftables包。

　　可以通過ethtool -s了解網(wǎng)卡信息。

　　$ ethtool -S eth0 | egrep 'miss|over|drop|lost|fifo'

　　rx_dropped: 0

　　tx_dropped: 0

　　port.rx_dropped: 0

　　port.tx_dropped_link_down: 0

　　port.rx_oversize: 0

　　port.arq_overflows: 0

　　與NIC制造商進(jìn)行詳細(xì)的統(tǒng)計(jì)描述，例如Mellanox為他們提供了一個(gè)專門的wiki頁面。

　　內(nèi)核方面將看到/proc/interrupts、/proc/softirqs和/proc/net/softnet_stat。這里有兩個(gè)有用的bcc工具，hardirqs和softirqs。優(yōu)化網(wǎng)絡(luò)的目標(biāo)是在沒有數(shù)據(jù)包丟失的情況下，對(duì)系統(tǒng)進(jìn)行優(yōu)化，直至達(dá)到最小的CPU使用量。

　　中斷親和力

　　調(diào)優(yōu)通常從處理器之間的擴(kuò)展中斷開始，具體怎么做取決于工作量。

　　為了獲取最大吞吐量，可以在系統(tǒng)中的所有numa節(jié)點(diǎn)上分發(fā)中斷。

　　為了得到最低延遲，可以將中斷限制為單個(gè)numa節(jié)點(diǎn)。要做到這一點(diǎn)，可能需要減少隊(duì)列的數(shù)量，以適應(yīng)單個(gè)節(jié)點(diǎn)（這通常意味著用ethtool -L將它們的數(shù)量減少一半）。

　　供應(yīng)商通常提供腳本以達(dá)到目的，例如英特爾有set_irq_affinity。

　　環(huán)形緩沖區(qū)大小

　　網(wǎng)卡與內(nèi)核交換信息一般是通過一種叫做“環(huán)”的數(shù)據(jù)結(jié)構(gòu)來完成的，該數(shù)據(jù)結(jié)構(gòu)借助ethtool -g可以查看該“環(huán)”的當(dāng)前/最大尺寸。

　　$ ethtool -g eth0

　　Ring parameters for eth0:

　　Pre-set maximums:

　　RX: 4096

　　TX: 4096

　　Current hardware settings:

　　RX: 4096

　　TX: 4096

　　可以在預(yù)先設(shè)置的最大值與-G之間作調(diào)整，一般來說越大越好（特別是如果使用中斷合并時(shí)），因?yàn)樗鼘⒔o予更多的保護(hù)來防止突發(fā)事件和內(nèi)核內(nèi)的間斷，因此降低了由于沒有緩沖區(qū)空間/錯(cuò)過中斷而減少的數(shù)據(jù)包數(shù)量。但有幾點(diǎn)需要說明:

　　在舊的內(nèi)核，或者沒有BQL支持的驅(qū)動(dòng)程序中，設(shè)置很高的值意味著tx-side更高的緩存過滿。

　　更大的緩沖區(qū)也會(huì)增加緩存的壓力。

　　合并

　　中斷合并允許通過在一個(gè)中斷中聚合多個(gè)事件來延遲通知內(nèi)核的新事件。當(dāng)前設(shè)置可以通過ethtool -c來查看。

　　$ ethtool -c eth0

　　Coalesce parameters for eth0:

　　...

　　rx-usecs: 50

　　tx-usecs: 50

　　可以使用靜態(tài)限制嚴(yán)格限制每秒中斷的最大中斷數(shù)，或者依賴硬件基于吞吐量自動(dòng)調(diào)整中斷率。

　　啟用合并（使用 -c）將增加延遲，并可能引發(fā)包丟失，所以需要避免它對(duì)延遲敏感。另一方面，完全禁用它可能導(dǎo)致中斷節(jié)流，從而影響性能。

　　卸載

　　現(xiàn)代網(wǎng)卡比較智能，可以將大量的工作轉(zhuǎn)移到硬件或仿真驅(qū)動(dòng)程序上。

　　所有可能的卸載都可以通過ethtool -k查看。

　　$ ethtool -k eth0

　　Features for eth0:

　　...

　　tcp-segmentation-offload: on

　　generic-segmentation-offload: on

　　generic-receive-offload: on

　　large-receive-offload: off [fixed]

　　在輸出中，所有不可調(diào)的卸載都采用[fixed]后綴標(biāo)記。

　　關(guān)于它們有很多討論，但這里有一些經(jīng)驗(yàn)法則。

　　不要啟用LRO，使用GRO代替。

　　要小心使用TSO，因?yàn)樗叨纫蕾囉隍?qū)動(dòng)/固件的質(zhì)量。

　　不要在舊的內(nèi)核中啟用TSO/GSO，因?yàn)樗赡軙?huì)導(dǎo)致嚴(yán)重的緩存過滿。所有現(xiàn)代NICs都優(yōu)化了多核硬件，因此他們將包內(nèi)部拆分為虛擬隊(duì)列（通常是一個(gè)CPU）。當(dāng)它在硬件中完成時(shí)，它被稱為RSS，當(dāng)操作系統(tǒng)負(fù)責(zé)交叉cpu的負(fù)載平衡包時(shí)，它被稱為RPS（與TX-counterpart對(duì)應(yīng)的稱為XPS)。當(dāng)操作系統(tǒng)試圖變得智能并路由到當(dāng)前正在處理該套接字的cpu時(shí)，它被稱為RFS。當(dāng)硬件實(shí)現(xiàn)該功能時(shí)，它被稱為“加速RFS”或簡稱“aRFS”。

　　以下是生產(chǎn)中的一些最佳實(shí)踐。

　　如果正在使用最新的25 G+硬件，它可能有足夠的隊(duì)列和一個(gè)巨大的間接表，以便能夠在所有的內(nèi)核中提供RSS。一些老的NICs只使用前16個(gè)cpu。

　　以下情況可以嘗試啟用RPS:

　　當(dāng)有更多的cpu，而不是硬件隊(duì)列，希望為吞吐量犧牲延遲。

　　當(dāng)使用的是內(nèi)部隧道(如GRE / IPinIP)，NIC不能RSS。

　　如果CPU相當(dāng)舊且沒有x2APIC，則不要啟用RPS。

　　通過XPS將每個(gè)CPU綁定到它自己的TX隊(duì)列通常是個(gè)好主意。

　　RFS的有效性很大程度上取決于工作負(fù)載，以及是否將CPU的相關(guān)性應(yīng)用于它。

　　導(dǎo)流器和ATR

　　啟用導(dǎo)流器（或英特爾術(shù)語中的fdir）在應(yīng)用程序的目標(biāo)路由模式中是默認(rèn)操作，該應(yīng)用程序通過取樣包和轉(zhuǎn)向系統(tǒng)來實(shí)現(xiàn)aRFS，并將其控制在可能被處理的核心位置。它的統(tǒng)計(jì)數(shù)據(jù)也可以通過ethtool - s:$ ethtool - s eth0 |egrep “fdir” port.fdir_flush_cnt:0實(shí)現(xiàn)。

　　盡管英特爾聲稱fdir在某些情況下提高了性能，但外部研究表明它也引發(fā)了最多1%的包重新排序，這對(duì)TCP性能有很大的損害。因此可以測(cè)試一下，看看FD是否對(duì)工作負(fù)載有幫助，同時(shí)要注意TCPOFOQueue計(jì)數(shù)器。

　　操作系統(tǒng)：網(wǎng)絡(luò)棧

　　對(duì)于Linux網(wǎng)絡(luò)堆棧的調(diào)優(yōu)，有無數(shù)的書籍、視頻和教程?？杀氖牵罅康摹皊ysctl.conf cargo-culting”隨之而來，即使最近的內(nèi)核版本不需要像10年前那樣多的調(diào)優(yōu)，而且大多數(shù)新的TCP/IP特性在默認(rèn)情況下都是啟用和已調(diào)優(yōu)的，人們?nèi)匀辉趶?fù)制舊的已經(jīng)使用了2.6.18/2.6.32內(nèi)核的sysctls.conf。

　　為了驗(yàn)證與網(wǎng)絡(luò)相關(guān)的優(yōu)化效果，需要：

　　通過/ proc/net/snmp和/ proc/net/netstat收集系統(tǒng)范圍的TCP指標(biāo)。

　　合并從ss -n –extended –info，或者從網(wǎng)頁服務(wù)器內(nèi)部調(diào)用getsockopt(TCP_INFO)/getsockopt(TCP_CC_INFO)獲取的每個(gè)連接的指標(biāo)。

　　采樣TCP流的tcptrace(1)。

　　從應(yīng)用程序/瀏覽器中分析RUM指標(biāo)。

　　對(duì)于關(guān)于網(wǎng)絡(luò)優(yōu)化的信息來源，個(gè)人喜歡由CDN-folks進(jìn)行的會(huì)議討論，因?yàn)樗麄兺ǔＶ涝谧鍪裁?，比如LinuxCon在澳大利亞的快速發(fā)展。聽Linux內(nèi)核開發(fā)人員關(guān)于網(wǎng)絡(luò)的說法也是很有啟發(fā)性的，例如netdevconf對(duì)話和NETCONF記錄。

　　通過PackageCloud深入到Linux網(wǎng)絡(luò)堆棧中時(shí)以下需要注意，特別是當(dāng)側(cè)重監(jiān)視而不是盲目的調(diào)優(yōu)時(shí)。

　　監(jiān)視和調(diào)優(yōu)Linux網(wǎng)絡(luò)堆棧：接收數(shù)據(jù)

　　監(jiān)視和調(diào)優(yōu)Linux網(wǎng)絡(luò)堆棧：發(fā)送數(shù)據(jù)

　　開始之前再次重申：請(qǐng)升級(jí)內(nèi)核！有大量的新網(wǎng)絡(luò)堆棧改進(jìn)，比如關(guān)于新的熱像：TSO自動(dòng)調(diào)整，F(xiàn)Q，步測(cè)，TLP，和機(jī)架，但以后更多。通過升級(jí)到一個(gè)新的內(nèi)核，將得到一大堆拓展性改進(jìn)，如刪除路由緩存、lockless偵聽套接字、SO_REUSEPORT等等。

　　概述

　　最近的Linux網(wǎng)絡(luò)文章中非常顯目的是“讓Linux TCP快速運(yùn)行”。它通過將Linux sender-side TCP堆棧分解為功能塊，從而鞏固了Linux內(nèi)核的多年改進(jìn)。

　　公平隊(duì)列和pacing

　　公平隊(duì)列負(fù)責(zé)改善TCP流之間的公平性和減少行阻塞，這對(duì)包的下降率有積極的影響。以擁塞控制的速度設(shè)定數(shù)據(jù)包，以同樣的間隔時(shí)間間隔來設(shè)置數(shù)據(jù)包，從而進(jìn)一步減少數(shù)據(jù)包損失，最終提高吞吐量。

　　附注一點(diǎn)：在linux中，通過fq qdisc可以獲得公平隊(duì)列和pacing。不要誤以為這些是BBR的要求，它們都可以與CUBIC一同使用以減少15-20%的數(shù)據(jù)包損失，從而提高CCs上損失的吞吐量。只是不要在舊的內(nèi)核（低于3.19版本）中使用它，因?yàn)闀?huì)結(jié)束pacing pure ACKs，并破壞uploads/RPCs。

　　TSO autosizing和TSQ

　　兩種方法都負(fù)責(zé)限制TCP堆棧中的緩沖，從而降低延遲，且不會(huì)犧牲吞吐量。

　　擁塞控制

　　CC算法本身設(shè)計(jì)領(lǐng)域很廣，近年來圍繞它們進(jìn)行了大量的活動(dòng)。其中一些活動(dòng)被編纂為：tcp_cdg(CAIA)、tcp_nv(Facebook)和tcp_bbr(谷歌)。這里不會(huì)太深入地討論他們的內(nèi)部工作，先假設(shè)所有的人都依賴于延遲的增加而不是數(shù)據(jù)包的減少。

　　BBR可以說是所有新的擁塞控制中，文檔完整、可測(cè)試和實(shí)用的?；舅枷胧墙⒁粋€(gè)基于包傳輸速率的網(wǎng)絡(luò)路徑模型，然后執(zhí)行控制循環(huán)，最大限度地提高帶寬，同時(shí)最小化rtt。這正是代理堆棧中需要的。

　　來自BBR實(shí)驗(yàn)的初步數(shù)據(jù)顯示，文件下載速度有提升。

　　在東京的BBR實(shí)驗(yàn)6小時(shí)：x軸表示時(shí)間，y軸表示客戶端下載速度。

　　需要強(qiáng)調(diào)的是有觀察到所有百分位數(shù)的速度都在增長，這不是后端修改引起。通常只會(huì)給p90+用戶帶來好處（互聯(lián)網(wǎng)連接速度最快的用戶），因?yàn)槠渌腥硕际菐捪拗频摹＞W(wǎng)絡(luò)級(jí)的調(diào)優(yōu)，比如改變擁塞控制，或者啟用FQ /pacing顯示用戶沒有帶寬限制，但是他們是“tcp - limited”。

　　如果想了解更多關(guān)于BBR的信息，APNIC有一個(gè)很好的入門級(jí)的BBR概述（它與基于損失的擁擠控制的對(duì)比）。關(guān)于BBR的更深入的信息，可以閱讀bbr-dev郵件列表檔案（它在頂部有許多有用的鏈接）。對(duì)擁塞控制感興趣的，可以關(guān)注網(wǎng)絡(luò)擁塞控制研究小組的有趣活動(dòng)。

　　ACK處理和丟失檢測(cè)

　　關(guān)于擁塞控制已經(jīng)說了很多，下面再次運(yùn)行最新的內(nèi)核討論一下丟失檢測(cè)。那些新的啟發(fā)式方法，比如TLP和RACK，經(jīng)常被添加到TCP，而FACK和ER等舊的東西正在被淘汰。一旦添加，它們是默認(rèn)啟用的，因此在升級(jí)之后不需要調(diào)整任何系統(tǒng)設(shè)置。

　　用戶空間優(yōu)先級(jí)和HOL

　　用戶空間套接字api提供隱式緩沖，一旦被發(fā)送，就無法重新排序塊，因此在多路復(fù)用場(chǎng)景中（例如HTTP/2），可能導(dǎo)致HOL阻塞，以及h2優(yōu)先級(jí)反轉(zhuǎn)。TCP_NOTSENT_LOWAT套接字選項(xiàng)（和相應(yīng)的net.ipv4.tcp_notsent_lowat sysctl）被設(shè)計(jì)用來解決這個(gè)問題，它設(shè)置了一個(gè)閾值，在這個(gè)閾值中，套接字會(huì)認(rèn)為自己是可寫的（即epoll會(huì)對(duì)欺騙應(yīng)用程序）。從而可以解決使用HTTP/2優(yōu)先級(jí)的問題，但它也可能對(duì)吞吐量產(chǎn)生負(fù)面影響。

　　Sysctls

　　在談到網(wǎng)絡(luò)優(yōu)化的時(shí)候，不能不提到關(guān)于sysctls的調(diào)優(yōu)。先從不熟悉的開始。

　　net.ipv4.tcp_tw_recycle=1——不要使用它——它已經(jīng)被NAT的用戶破壞了，但是如果升級(jí)內(nèi)核將有所改善。

　　net.ipv4.tcp_timestamps=0——不要禁用它們，除非已知所有的副作用，而且可以接受它們。例如，一個(gè)不明顯的副作用是可以在syncookie上打開窗口縮放和SACK選項(xiàng)。

　　對(duì)于sysctls需要使用：

　　net.ipv4.tcp_slow_start_after_idle=0——在空閑后緩慢啟動(dòng)的主要問題是“空閑”被定義為一個(gè)RTO，它太小了。

　　net.ipv4.tcp_mtu_probing=1——有用，如果與客戶之間有ICMP的黑名單（很可能有）。

　　net.ipv4.tcp_rmem net.ipv4.tcp_wmem——應(yīng)該調(diào)整為適合BDP，越大并不總是越好。

　　echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect——如果使用的是fq+cubic，這可能有助于tcp_cubic較早的開始。

　　同樣值得注意的是，有一份由curl的作者Daniel Stenberg編寫的RFC草案，命名為HTTP的TCP調(diào)優(yōu)，它試圖整理所有可能對(duì)HTTP有利的系統(tǒng)調(diào)優(yōu)。

　　應(yīng)用程序級(jí)別：中層

　　工具

　　就像內(nèi)核一樣，擁有最新的用戶空間是非常重要的。從升級(jí)工具開始，例如打包最新版本的perf、bcc等。

　　一旦有了新的工具，就可以適當(dāng)?shù)卣{(diào)整和觀察系統(tǒng)的行為。這一部分主要依賴于通過perf top、on-CPU flamegraphs和來自bcc funclatency的臨時(shí)直方圖進(jìn)行on-cpu分析。

　　編譯器工具鏈

　　如果想要編譯硬件優(yōu)化的組件，那么擁有一個(gè)現(xiàn)代的編譯器工具鏈?zhǔn)潜夭豢缮俚?，這在許多web服務(wù)器通常使用的庫中也是存在的。

　　除了性能之外，新的編譯器具有新的安全特性（如-fstack-protector-strong或SafeStack），這些特性是想在邊緣網(wǎng)絡(luò)中應(yīng)用的?，F(xiàn)代工具鏈的另一個(gè)用例是，當(dāng)運(yùn)行測(cè)試工具時(shí)，殺毒軟件（例如AddressSanitizer和friends）編譯的是二進(jìn)制文件。

　　系統(tǒng)庫

　　推薦升級(jí)系統(tǒng)庫，比如glibc，因?yàn)樵谄渌矫?，可能?huì)錯(cuò)過-lc、-lm、-lrt等低級(jí)功能中最近存在的優(yōu)化。

　　Zlib

　　通常，web服務(wù)器將負(fù)責(zé)壓縮。根據(jù)多少數(shù)據(jù)將通過代理，偶爾會(huì)在perf top看到zlib的符號(hào)，例如:

　　# perf top

　　...

　　8.88% nginx [.] longest_match

　　8.29% nginx [.] deflate_slow

　　1.90% nginx [.] compress_block

　　在最低級(jí)別上有一些優(yōu)化的方法：英特爾和Cloudflare，以及一個(gè)獨(dú)立的zlib-ng項(xiàng)目，都有他們的zlib forks，可以通過使用新的指令集提供更好的性能。

　　Malloc

　　在討論優(yōu)化之前，我們主要是面向cpu的，但是現(xiàn)在換一個(gè)角度，討論與內(nèi)存相關(guān)的優(yōu)化。如果使用大量的Lua和FFI或第三方的重模塊來執(zhí)行它們自己的內(nèi)存管理，可能會(huì)由于碎片化而增加內(nèi)存使用?？梢試L試通過切換到j(luò)emalloc或tcmalloc來解決這個(gè)問題。

　　使用自定義malloc有以下好處。

　　將nginx二進(jìn)制文件與環(huán)境分離，glibc版本升級(jí)和操作系統(tǒng)遷移會(huì)減少它的影響。

　　更好的自查、分析和統(tǒng)計(jì)。

　　PCRE

　　如果在nginx configs中使用許多復(fù)雜的正則表達(dá)式，或者嚴(yán)重依賴Lua，perf top會(huì)顯示與pcre相關(guān)的標(biāo)志?？梢酝ㄟ^使用JIT編譯PCRE進(jìn)行優(yōu)化，也可以通過pcre_jit在nginx中啟用它。

　　通過查看火焰圖或者使用funclatency檢查優(yōu)化的結(jié)果。

　　# funclatency /srv/nginx-bazel/sbin/nginx:ngx_http_regex_exec -u

　　...

　　usecs : count distribution

　　0 -> 1 : 1159 |********** |

　　2 -> 3 : 4468 |****************************************|

　　4 -> 7 : 622 |***** |

　　8 -> 15 : 610 |***** |

　　16 -> 31 : 209 |* |

　　32 -> 63 : 91 | |

　　TLS

　　如果在CDN前端的w/o邊緣終止TLS，那么TLS性能優(yōu)化的價(jià)值是非?？捎^的。在討論調(diào)優(yōu)時(shí)主要關(guān)注服務(wù)器端效率。

　　因此需要決定的第一件事是使用哪些TLS庫：Vanilla OpenSSL、OpenBSD LibreSSL或谷歌的BoringSSL。在選擇TLS庫的偏好之后，需要適當(dāng)?shù)貥?gòu)建它，例如，OpenSSL有一堆構(gòu)建時(shí)的啟發(fā)式，可以根據(jù)構(gòu)建環(huán)境進(jìn)行優(yōu)化；BoringSSL具有確定性的構(gòu)建，但遺憾的是它更保守，并且在默認(rèn)情況下禁用了一些優(yōu)化。無論如何，在這里優(yōu)先選擇現(xiàn)代的CPU，大多數(shù)TLS庫可以使用從AES-NI和SSE到ADX和AVX512的所有屬性?？梢允褂脦в蠺LS庫的內(nèi)置性能測(cè)試，例如在BoringSSL案例中，內(nèi)置有bssl speed。

　　大多數(shù)性能不是來自已有的硬件，而是來自將要使用的cipher - suite，因此必須仔細(xì)地優(yōu)化它們。也需要知道這里的變化會(huì)影響web服務(wù)器的安全性——最快的密碼套件不一定是最好的。如果不確定要使用什么加密設(shè)置，Mozilla SSL配置生成器是一個(gè)很好的選擇。

　　非對(duì)稱加密

　　如果服務(wù)處于邊緣，那么可能會(huì)觀察到相當(dāng)數(shù)量的TLS握手，因此CPU占用了大量的非對(duì)稱密碼，這使它成為優(yōu)化的明顯目標(biāo)。

　　為了優(yōu)化服務(wù)器端CPU，可以切換到ECDSA certs，其速度通常比RSA快10倍，而且它們的體積要小得多，因此在出現(xiàn)包丟失時(shí)能加速握手。但是ECDSA也嚴(yán)重依賴于系統(tǒng)的隨機(jī)數(shù)生成器的質(zhì)量，所以如果使用的是OpenSSL，那么一定要有足夠的熵值（使用BoringSSL，不必?fù)?dān)心這一點(diǎn)）。

　　附注一點(diǎn)，越大并不總是越好，例如使用4096個(gè)RSA證書會(huì)降低10倍的性能。

　　$ bssl speed

　　Did 1517 RSA 2048 signing ... (1507.3 ops/sec)

　　Did 160 RSA 4096 signing ... (153.4 ops/sec)

　　更糟糕的是，小的也不一定是最好的選擇：使用non-common p-224字段與更常見的p-256相比，會(huì)降低60%的性。

　　$ bssl speed

　　Did 7056 ECDSA P-224 signing ... (6831.1 ops/sec)

　　Did 17000 ECDSA P-256 signing ... (16885.3 ops/sec)

　　原則上最常用的加密通常是最優(yōu)的加密。

　　在使用RSA certs運(yùn)行適當(dāng)優(yōu)化的基于opentls的庫時(shí)，可以在perf top：AVX2-capable看到以下的跟蹤信息，但不能使用ADX-capable盒子（例如Haswell）。

　　6.42% nginx [.] rsaz_1024_sqr_avx2

　　1.61% nginx [.] rsaz_1024_mul_avx2

　　更新的硬件應(yīng)該使用通用的montgomery模乘算法和ADX codepath。

　　7.08% nginx [.] sqrx8x_internal

　　2.30% nginx [.] mulx4x_internal

　　對(duì)稱加密

　　如果有許多的批量傳輸，如視頻、照片或更通用的文件，需要在分析器的輸出中觀察對(duì)稱加密符號(hào)。只需要確保CPU具有AES-NI支持，并為AES-GCM ciphers設(shè)置服務(wù)器端的首選項(xiàng)。根據(jù)perf top信息適當(dāng)?shù)恼{(diào)整硬件。

　　8.47% nginx [.] aesni_ctr32_ghash_6x

　　不只是服務(wù)器需要解決加密/解密問題，客戶端在缺少可用的CPU時(shí)也會(huì)面臨相同的負(fù)擔(dān)。如果沒有硬件加速，這可能非常具有挑戰(zhàn)性，因此可以考慮使用一種致力于快速而沒有硬件加速的算法，例如chacha20-poly1305。這將減少一些移動(dòng)客戶的TTLB。

　　BoringSSL是支持chacha20-poly1305的，而對(duì)于OpenSSL 1.0.2，可以考慮使用Cloudflare補(bǔ)丁。BoringSSL還支持“相等的首選密碼組”，因此可以使用以下配置，讓客戶端根據(jù)其硬件功能來決定使用什么密碼（從cloudflare/sslconfig中竊?。?/p>

　　ssl_ciphers '[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES';

　　ssl_prefer_server_ciphers on;

　　應(yīng)用程序級(jí)別：高標(biāo)準(zhǔn)的

　　為了分析高標(biāo)準(zhǔn)的優(yōu)化效果，需要收集RUM數(shù)據(jù)。在瀏覽器中，可以使用導(dǎo)航定時(shí)api和資源定時(shí)api收集。收集的主要指標(biāo)是TTFB和TTV/TTI。擁有便于查詢和圖形化格式的數(shù)據(jù)將極大地簡化迭代。

　　壓縮

　　nginx的壓縮從mime.types文件開始，它定義了文件擴(kuò)展和響應(yīng)MIME類型之間的默認(rèn)通信。然后需要定義傳遞給壓縮器的類型。如果想要完整的列表，可以使用mime-db來自動(dòng)生成mime.types并添加.compressible==true到gzip_types。

　　在啟用gzip時(shí)，兩個(gè)方面要注意。

　　增加了內(nèi)存的使用，可以通過限制gzip_buffer來解決。

　　因?yàn)榫彌_，所以增加了TTFB。使用[gzip_no_buffer](http://hg.nginx.org/nginx/file/c7d4017c8876/src/http/modules/ngx_http_gzip_filter_module.c # l182)可以解決問題。

　　附注，http壓縮不僅限于gzip，nginx有第三方ngx_brotli模塊，與gzip相比改善后的壓縮率高達(dá)30%。

　　至于壓縮設(shè)置本身，討論兩個(gè)單獨(dú)的用例：靜態(tài)和動(dòng)態(tài)數(shù)據(jù)。

　　對(duì)于靜態(tài)數(shù)據(jù)，可以通過預(yù)壓縮靜態(tài)資產(chǎn)作為構(gòu)建過程的一部分來歸檔最大壓縮比。過去有討論在部署B(yǎng)rotli中為gzip和Brotli提供靜態(tài)內(nèi)容的詳細(xì)信息。

　　對(duì)于動(dòng)態(tài)數(shù)據(jù)，需要謹(jǐn)慎地平衡一次完整的往返：壓縮數(shù)據(jù)的時(shí)間和傳輸時(shí)間，以便在客戶機(jī)上解壓。因此從CPU的使用和TTFB的角度來看，設(shè)置盡可能高的壓縮級(jí)別是不明智的。

　　在代理中緩存會(huì)極大地影響web服務(wù)器性能，特別是在延遲方面。nginx代理模塊有不同的緩沖開關(guān)，它們?cè)诿總€(gè)位置上都是可轉(zhuǎn)換的?？梢酝ㄟ^proxy_request_buffering和proxy_buffering對(duì)兩個(gè)方向的緩沖進(jìn)行單獨(dú)控制。如果緩沖是啟用了內(nèi)存消耗上限的話，則由client_body_buffer_size和proxy_buffer設(shè)置，達(dá)到請(qǐng)求/響應(yīng)的臨界值后，將緩沖到磁盤。對(duì)于響應(yīng)的臨界值，可以通過將proxy_max_temp_file_size設(shè)置為0來禁用。

　　最常見的緩沖方法有：

　　緩沖請(qǐng)求/響應(yīng)在內(nèi)存中的某個(gè)閾值，然后溢出到磁盤。如果啟用了請(qǐng)求緩沖，那么只需將請(qǐng)求發(fā)送到后端，一旦它被完全接收，并通過響應(yīng)緩沖，就可以在響應(yīng)完成后立即釋放后端線程。這種方法的好處是提高了吞吐量和后端保護(hù)，以增加延遲和內(nèi)存/io的使用（如果使用ssd，這可能不是什么問題）。

　　沒有緩沖。緩沖可能不是延遲敏感路由的好選擇，特別是那些使用數(shù)據(jù)流的。對(duì)于他們來說可能想要禁用它，但是現(xiàn)在的后端需要處理慢速客戶端（包括惡意的慢提交/慢讀類型的攻擊）。

　　Application-controlled響應(yīng)緩沖通過[X-Accel-Buffering](https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/ # X-Accel-Buffering)數(shù)據(jù)頭。

　　無論你選擇哪種方法，都不要忘記測(cè)試它對(duì)TTFB和TTLB的影響。另外，正如前面提到的，緩沖可以影響IO的使用，甚至是后端使用率，因此也要密切關(guān)注它。

　　TLS

　　現(xiàn)在我們將討論TLS的高級(jí)方面和延遲改進(jìn)，可以通過正確配置nginx來實(shí)現(xiàn)。文章提到的大多數(shù)優(yōu)化都包含在高性能瀏覽器網(wǎng)絡(luò)的“優(yōu)化TLS”部分，并在nginx.conf 2014上讓HTTPS更快的討論。此部分中提到的調(diào)優(yōu)將會(huì)影響web服務(wù)器的性能和安全性，如果不確定，請(qǐng)參考Mozilla服務(wù)器端TLS指南和/或與安全團(tuán)隊(duì)協(xié)商。

　　如何驗(yàn)證優(yōu)化結(jié)果。

　　WebpageTest測(cè)試性能影響。

　　采用來自Qualys的SSL服務(wù)器測(cè)試，或Mozilla TLS Observatory測(cè)試安全影響。

　　會(huì)話重用

　　像DBA常說的那樣，“最快的查詢是從來沒有做過的?！盩LS同樣如此，如果你緩存了握手的結(jié)果，可以減少一個(gè)RTT的延遲。有兩種方法緩存握手結(jié)果。

　　要求客戶端存儲(chǔ)所有會(huì)話參數(shù)（以簽名和加密的方式），并在下一次握手時(shí)返回（類似于cookie）。在nginx方面，這是通過ssl_session_tickets指令配置的。雖然不會(huì)消耗服務(wù)器的任何內(nèi)存，但有一些缺點(diǎn)：

　　需要基礎(chǔ)設(shè)施來創(chuàng)建、旋轉(zhuǎn)和分發(fā)LS會(huì)話的隨機(jī)加密/簽名鍵。請(qǐng)記住，不應(yīng)該使用源控件來存儲(chǔ)ticket keys，也不應(yīng)該從其他非臨時(shí)的材料中生成這些鍵，比如日期或證書。

　　PFS不會(huì)在每個(gè)會(huì)話的基礎(chǔ)上，而是在每個(gè)tls-ticket的基礎(chǔ)上，因此如果攻擊者獲得了ticket key，他們就可以在ticket的持續(xù)時(shí)間內(nèi)對(duì)任何捕獲的流量進(jìn)行解密。

　　加密將限制票務(wù)鑰匙的大小。如果使用的是128位的票證，那么使用AES256沒有多大意義，因?yàn)镹ginx同時(shí)支持128位和256位TLS票號(hào)。

　　并不是所有的客戶都支持ticket key（盡管所有的現(xiàn)代瀏覽器都支持它們）。

　　或者，可以在服務(wù)器上存儲(chǔ)TLS會(huì)話參數(shù)，只給客戶端提供一個(gè)引用(id)，通過ssl_session_cache指令完成。它的好處是在會(huì)話之間保留PFS，并極大地限制表面的攻擊。當(dāng)然ticket keys也有缺點(diǎn)：

　　在服務(wù)器上每次會(huì)話消耗約256字節(jié)的內(nèi)存，這意味著不能將它們存儲(chǔ)太長時(shí)間。

　　不能在服務(wù)器之間輕松共享。因此要么需要負(fù)載平衡器（loadbalancer ，發(fā)送相同的客戶端到相同的服務(wù)器以保存緩存位置），要么寫一個(gè)分布式TLS會(huì)話存儲(chǔ)類似ngx_http_lua_module。

　　附注一點(diǎn)，如果使用session ticket方法，那么值得使用3個(gè)鍵而不是一個(gè)鍵值，例如：

　　ssl_session_tickets on;

　　ssl_session_timeout 1h;

　　ssl_session_ticket_key /run/nginx-ephemeral/nginx_session_ticket_curr;

　　ssl_session_ticket_key /run/nginx-ephemeral/nginx_session_ticket_prev;

　　ssl_session_ticket_key /run/nginx-ephemeral/nginx_session_ticket_next;

　　即便始終使用當(dāng)前的密鑰進(jìn)行會(huì)話加密，也會(huì)接受使用之前和之后密鑰加密的會(huì)話。

　　OCSP Stapling

　　需要對(duì)OCSP響應(yīng)作staple，否則:

　　TLS握手可能需要更長的時(shí)間，因?yàn)榭蛻舳诵枰c證書頒發(fā)機(jī)構(gòu)聯(lián)系以獲取OCSP狀態(tài)。

　　在OCSP的取回失敗可能導(dǎo)致可用性攻擊。

　　可能會(huì)破壞用戶的隱私，因?yàn)橛脩舻臑g覽器會(huì)聯(lián)系第三方服務(wù)，表明想要連接到當(dāng)前網(wǎng)站。

　　要staple OCSP響應(yīng)，可以定期從證書頒發(fā)機(jī)構(gòu)獲取它，將結(jié)果分發(fā)給web服務(wù)器，并使用ssl_stapling_file指令來調(diào)用。

　　ssl_stapling_file /var/cache/nginx/ocsp/www.der;

　　TLS記錄大小

　　TLS將數(shù)據(jù)分解成記錄塊，在完全接收到它之前，無法對(duì)其進(jìn)行驗(yàn)證和解密?？梢詮木W(wǎng)絡(luò)堆棧和應(yīng)用程序的角度來度量這一延遲。

　　默認(rèn)的nginx使用16k塊，甚至不適合IW10擁塞窗口，因此需要額外的往返。nginx提供了一種通過ssl_buffer_size指令設(shè)置記錄大小的方法：

　　為了優(yōu)化低延遲，你應(yīng)該把它設(shè)置成小的，例如4k。從CPU使用的角度來看，進(jìn)一步減少它將會(huì)更加昂貴。

　　為了優(yōu)化高通量，您應(yīng)該將其保留在16k。

　　靜態(tài)調(diào)優(yōu)的兩個(gè)問題。

　　需要手動(dòng)調(diào)優(yōu)它。

　　只能將ssl_buffer_size設(shè)置為per-nginx config或per-server塊，因此如果有一個(gè)具有混合延遲/吞吐量工作負(fù)載的服務(wù)器，則需要折衷。

　　還有一種替代方法：動(dòng)態(tài)記錄大小調(diào)整。來自Cloudflare的nginx補(bǔ)丁為動(dòng)態(tài)記錄大小提供了支持。最初對(duì)它進(jìn)行配置可能是一種痛苦，但一旦配置完成，它就會(huì)運(yùn)行得很好。

　　TLS 1.3

　　TLS 1.3的功能確實(shí)很不錯(cuò)，但是除非有足夠的資源來解決TLS的問題，否則不建議啟用它，因?yàn)橐韵略颉?/p>

　　它仍然是一個(gè)草案。

　　0-RTT握手有一些安全隱患，應(yīng)用程序需要為此做好準(zhǔn)備。

　　仍然有一些中間盒子（反病毒，DPIs等）阻止未知的TLS版本。

　　避免Eventloop Stalls

　　Nginx是一個(gè)基于事件循環(huán)的web服務(wù)器，意味著它只能一次只做一件事。盡管它似乎同時(shí)做了所有這些事情，比如在分時(shí)復(fù)用中，所有的nginx都只是在事件之間快速切換，處理一個(gè)接一個(gè)。這一切都有效，因?yàn)樘幚砻總€(gè)事件只需幾微秒。但如果它開始花費(fèi)太多時(shí)間，例如，因?yàn)樗枰D(zhuǎn)到旋轉(zhuǎn)盤上，延遲就會(huì)飆升。

　　如果注意到nginx在ngx_process_events_and_timer函數(shù)中花費(fèi)了很多時(shí)間，并且分布是雙向的，那么可能會(huì)受到eventloop stalls的影響。

　　# funclatency '/srv/nginx-bazel/sbin/nginx:ngx_process_events_and_timers' -m

　　msecs : count distribution

　　0 -> 1 : 3799 |****************************************|

　　2 -> 3 : 0 | |

　　4 -> 7 : 0 | |

　　8 -> 15 : 0 | |

　　16 -> 31 : 409 |**** |

　　32 -> 63 : 313 |*** |

　　64 -> 127 : 128 |* |

　　AIO和Threadpools

　　因?yàn)锳IO和Threadpools是eventloop的主要來源，特別是在旋轉(zhuǎn)磁盤上的IO，所以應(yīng)該優(yōu)先查看，還可以通過運(yùn)行文件記錄來觀察受它影響的程度。

　　# fileslower 10

　　Tracing sync read/writes slower than 10 ms

　　TIME(s) COMM TID D BYTES LAT(ms) FILENAME

　　2.642 nginx 69097 R 5242880 12.18 0002121812

　　4.760 nginx 69754 W 8192 42.08 0002121598

　　4.760 nginx 69435 W 2852 42.39 0002121845

　　4.760 nginx 69088 W 2852 41.83 0002121854

　　為了解決這個(gè)問題，nginx支持將IO卸載到一個(gè)threadpool（它也支持AIO，但是Unixes的本地AIO很不友好，所以最好避免它），基本的設(shè)置很簡單。

　　aio threads;

　　aio_write on;

　　對(duì)于更復(fù)雜的情況可以設(shè)置自定義[線程池](http://nginx.org/en/docs/ngx_core_module.html # thread_pool)的預(yù)留磁盤，如果一個(gè)驅(qū)動(dòng)器失效，它不會(huì)影響其他的請(qǐng)求。線程池可以極大地減少處于D狀態(tài)的nginx進(jìn)程的數(shù)量，從而提高延遲和吞吐量。但是它不會(huì)完全消除eventloop，因?yàn)椴⒉皇撬蠭O操作都被卸載。

　　日志

　　記錄日志也會(huì)花費(fèi)相當(dāng)多的時(shí)間，因?yàn)樗谧x寫磁盤?？梢酝ㄟ^運(yùn)行ext4slower檢查是否存在日志，并查找access/error日志引用。

　　# ext4slower 10

　　TIME COMM PID T BYTES OFF_KB LAT(ms) FILENAME

　　06:26:03 nginx 69094 W 163070 634126 18.78 access.log

　　06:26:08 nginx 69094 W 151 126029 37.35 error.log

　　06:26:13 nginx 69082 W 153168 638728 159.96 access.log

　　通過使用access_log指令的緩沖區(qū)參數(shù)，在編寫它們之前，通過在內(nèi)存中對(duì)訪問日志進(jìn)行欺騙，可以解決這個(gè)問題。再使用gzip參數(shù)，將日志寫入磁盤之前壓縮日志，從而減少IO壓力。

　　但是要在日志中完全消除IO檔位，只能通過syslog編寫日志，這樣日志將與nginx事件循環(huán)完全集成。

　　打開文件緩存

　　因?yàn)閛pen(2)調(diào)用本質(zhì)上是阻塞的，而web服務(wù)器通常是打開/讀取/關(guān)閉文件，因此緩存打開的文件可能是有益的。通過查看ngx_open_cached_file函數(shù)延遲，可以看到便利所在。

　　# funclatency /srv/nginx-bazel/sbin/nginx:ngx_open_cached_file -u

　　usecs : count distribution

　　0 -> 1 : 10219 |****************************************|

　　2 -> 3 : 21 | |

　　4 -> 7 : 3 | |

　　8 -> 15 : 1 | |

　　如果看到有太多的開放調(diào)用，或者有一些花費(fèi)太多時(shí)間的調(diào)用，可以啟用文件緩存。

　　open_file_cache max=10000;

　　open_file_cache_min_uses 2;

　　open_file_cache_errors on;

　　在啟用open_file_cache之后，可以通過查看opensnoop來觀察所有的緩存遺漏，最終決定是否需要調(diào)整緩存限制。

　　# opensnoop -n nginx

　　PID COMM FD ERR PATH

　　69435 nginx 311 0 /srv/site/assets/serviceworker.js

　　69086 nginx 158 0 /srv/site/error/404.html

　　...

　　總結(jié)

　　本文描述的所有優(yōu)化都是基于本地的Web服務(wù)器。其中一些提高了拓展性和性能。另外一些與最小延遲或更快地將字節(jié)傳送給客戶機(jī)是相關(guān)的。但在以往的體驗(yàn)中，大量用戶可見的性能來自于更高級(jí)的優(yōu)化，這些優(yōu)化會(huì)影響到整個(gè)Dropbox 邊緣網(wǎng)絡(luò)的行為，比如ingress/egress流量工程和智能的內(nèi)部負(fù)載平衡。這些問題處于知識(shí)的邊緣，而行業(yè)才剛剛開始接近它們。

　　-------- 熱聞回顧 --------

　　2017年最受歡迎的10個(gè)編程挑戰(zhàn)網(wǎng)站