[[333844]]

平常工作生活中，不知你有沒有遇到這種情況，有時(shí)訪問網(wǎng)站異常的快，有時(shí)卻要等待10多秒才會(huì)有響應(yīng)， 這種情況下，我們一般不會(huì)太多的停留在網(wǎng)站，因?yàn)橛绊懥擞脩趔w驗(yàn)。今天就分享記錄下，我工作中遇到的一個(gè)問題。

問題現(xiàn)象

第一次發(fā)現(xiàn)這個(gè)問題，應(yīng)該是在很早之前，我本地用瀏覽器訪問我們公司的業(yè)務(wù)網(wǎng)站，發(fā)現(xiàn)有時(shí)很快，有時(shí)達(dá)到8、9秒以上， 但是也沒有太在意，以為是偶爾一次的。另外我用手機(jī) 4G 網(wǎng)絡(luò)也測(cè)試訪問了下，速度挺快的。

然而當(dāng)站點(diǎn)可用性監(jiān)控系統(tǒng)剛上線運(yùn)營(yíng)的時(shí)候，就經(jīng)常收到報(bào)警的通知，因?yàn)樵O(shè)置了探測(cè) 超時(shí)時(shí)間，我設(shè)置的是5秒。當(dāng)時(shí)覺得可能就這一個(gè)站點(diǎn)誤報(bào)，我單獨(dú)把這個(gè)站點(diǎn)的超時(shí)設(shè)置了10s，但過了幾天后，報(bào)警還是會(huì)誤報(bào)， 終于忍不住了。

這里要自我檢討下，發(fā)現(xiàn)問題時(shí)，我投機(jī)取巧的去掩蓋問題，而沒有去正視這個(gè)問題。這種態(tài)度是要不得的。不然問題會(huì)像滾雪球一樣可怕?。。?/p>

現(xiàn)象總結(jié)：公司某個(gè)網(wǎng)站監(jiān)控得到的響應(yīng)時(shí)間，延遲大，非常不穩(wěn)定, 導(dǎo)致站點(diǎn)可用性監(jiān)控經(jīng)常誤報(bào)警。

環(huán)境介紹分析及測(cè)試

環(huán)境介紹

這里我介紹下整體的大致環(huán)境，這幾臺(tái)業(yè)務(wù)主機(jī)上，每臺(tái)主機(jī)都有一個(gè) nginx，用于處理虛擬主機(jī)。然后最上面有一個(gè)公網(wǎng) LB（負(fù)載均衡器）。它負(fù)責(zé)接收外部的流量，終止 ssl，均衡的分發(fā)請(qǐng)求到每個(gè)主機(jī)的 nginx 上。

還有一點(diǎn)需要介紹下，我們線上還有一個(gè)公網(wǎng)LB，也是轉(zhuǎn)發(fā)流量到這幾臺(tái)主機(jī)nginx上。這倆LB的區(qū)別只是加載的域名ssl證書不一樣，其它配置一摸一樣(讓我一直在糾結(jié)是LB配置的原因)。最后就是監(jiān)控系統(tǒng)是部署在容器集群里的（很大程度的迷惑了自己，我曾以為是容器網(wǎng)絡(luò)出現(xiàn)了延時(shí)問題…）。

分析

當(dāng)時(shí)想了以下幾個(gè)點(diǎn):

• 公網(wǎng) LB 配置錯(cuò)誤
• 某臺(tái)應(yīng)用主機(jī)處理請(qǐng)求時(shí)間過長(zhǎng)
• 監(jiān)控系統(tǒng)部署所在集群的網(wǎng)絡(luò)問題
• 應(yīng)用主機(jī)系統(tǒng)參數(shù)有問題（最后追加上去的，我還真沒想到這塊）

測(cè)試

公網(wǎng) LB 配置錯(cuò)誤

針對(duì)這個(gè)問題，檢查了LB的的配置的超時(shí)時(shí)間，緩存等選項(xiàng)，都沒有啥結(jié)果，后來想到了日志，在haproxy的日子里，經(jīng)?？吹竭@樣的消息。下面是截取的其中一條記錄:

Jun 15 16:45:29 18.19.1.12 haproxy[30952]: 139.1.2.3:61653 [15/Jun/2018:16:45:08.784] lbl-ckv7ynro~ lbl-ckv7ynro_default/lbb-izjpmxrh 327/15003/-1/-1/20331 503 213 - - sCNN 4/3/0/0/+3 0/0 "HEAD /sessions/auth?return_to=%2F HTTP/1.1" 

以前沒咋看過 haproxy 日志，nginx 日志倒是都明白，這一看傻眼了。查查文檔吧。下面是對(duì)每段的解釋:

Jun 15 16:45:29                       # 時(shí)間 
18.19.1.12                            # haproxy ip 
haproxy[30952]:                       # 進(jìn)程ID 
139.1.2.3:61653                       #client_ip+port 
[15/Jun/2018:16:45:08.784]            #通過haproxy接收到連接的確切日期時(shí)間 
lbl-ckv7ynro~                         #前端監(jiān)聽器name 
lbl-ckv7ynro_default/lbb-izjpmxrh     #管理與服務(wù)器連接的后端/ 命中的 真實(shí)server主機(jī) 
 
327/15003/-1/-1/20331    
#327 是在接收到第一個(gè)字節(jié)后等待來自客戶端（不包括正文）的完整HTTP請(qǐng)求花費(fèi)的總時(shí)間（毫秒） 
#15003 是在各種隊(duì)列中等待的總時(shí)間（毫秒）。如果連接在到達(dá)隊(duì)列之前中止，則可以為“-1”。 
#-1 是等待連接建立到最終服務(wù)器的總時(shí)間（以毫秒為單位），包括重試次數(shù)。如果請(qǐng)求在建立連接之前被中止，它可以是“-1”。 
#-1 是等待服務(wù)器發(fā)送完整HTTP響應(yīng)的總時(shí)間（毫秒），不計(jì)算數(shù)據(jù)。如果在接收到完整的響應(yīng)之前請(qǐng)求被中止，它可以是“-1”。它通常與服務(wù)器的請(qǐng)求處理時(shí)間相匹配，盡管它可能會(huì)被客戶端發(fā)送到服務(wù)器的數(shù)據(jù)量所改變。“GET”請(qǐng)求的大部分時(shí)間通常表示重載的服務(wù)器。 
#20331 是請(qǐng)求在haproxy中保持活動(dòng)的時(shí)間，這是在接收到的請(qǐng)求的第一個(gè)字節(jié)和發(fā)送的最后一個(gè)字節(jié)之間經(jīng)過的總時(shí)間（以毫秒為單位）。它涵蓋所有可能的處理，除了握手（見Th）和空閑時(shí)間（參見Ti） 
 
503      #http狀態(tài)碼 
213      #是發(fā)送日志時(shí)發(fā)送到客戶端的總字節(jié)數(shù) 
 
- #是一個(gè)可選的“name = value”條目，指示客戶端在請(qǐng)求中具有此cookie。未設(shè)置 -表示  
- #是一個(gè)可選的“name = value”條目，表示服務(wù)器已經(jīng)返回了一個(gè)具有響應(yīng)的cookie。 
 
sCNN      #http格式下，會(huì)話狀態(tài)，結(jié)束時(shí)會(huì)話的條件：（timeout, error） 
#s 在等待服務(wù)器發(fā)送或接收數(shù)據(jù)時(shí)，服務(wù)器端超時(shí)已過期 
#C 代理正在等待CONNECTION在服務(wù)器上建立。服務(wù)器最多可能已經(jīng)注意到連接嘗試。 
#N client沒有提供cookie。這通常是新的訪客，第一次訪問的情況,所以計(jì)算在日志中這個(gè)標(biāo)志的出現(xiàn)次數(shù),通常表示站點(diǎn)被頻繁訪問的有效趨勢(shì)。 
#N 服務(wù)器沒有提供cookie，也沒有插入任何cookie。4/3/0/0/+3 
 
#4 是會(huì)話記錄時(shí)進(jìn)程上的并發(fā)連接總數(shù) 
#3 是會(huì)話記錄時(shí)前端上的并發(fā)連接總數(shù) 
#0 是會(huì)話記錄時(shí)由后端處理的并發(fā)連接的總數(shù) 
#0 是在會(huì)話記錄時(shí)服務(wù)器上仍然處于活動(dòng)狀態(tài)的并發(fā)連接總數(shù) 
#+3 是嘗試連接到服務(wù)器時(shí)此會(huì)話遇到的連接重試次數(shù) 
0/0   # 前一個(gè)數(shù)字0 是在服務(wù)器隊(duì)列中之前處理的請(qǐng)求的總數(shù)，后一個(gè)數(shù)字0是是在服務(wù)器隊(duì)列中之前處理的請(qǐng)求的總數(shù) 
"HEAD /sessions/auth?return_to=%2F HTTP/1.1"    #是完整的HTTP請(qǐng)求行，包括方法，請(qǐng)求和HTTP版本字符串。 

上面的日志分析中，有很多有價(jià)值的信息，值得關(guān)注的有 4/3/0/0/+3, sCNN. 但是當(dāng)時(shí)我只關(guān)注了超時(shí)這一點(diǎn)，以為是網(wǎng)絡(luò)原因?qū)е碌目蛻舳诉B接后端服務(wù)器的超時(shí)，然后就繼續(xù)排查了。這里其實(shí)差不多已經(jīng)說明了出問題的點(diǎn)：lb 和 后端服務(wù)器之間的故障(后話，我忽略了這一點(diǎn))。

某臺(tái)應(yīng)用主機(jī)處理請(qǐng)求時(shí)間過長(zhǎng)

針對(duì)這個(gè)的測(cè)試，我準(zhǔn)備在夜間流量低峰時(shí)，暫時(shí)禁用掉其它的LB后端，只保留1臺(tái)后端主機(jī)進(jìn)行對(duì)外服務(wù)。很快的我發(fā)現(xiàn)這也行不通。問題依舊會(huì)出現(xiàn)。逐個(gè)的去替換，這一個(gè)測(cè)試沒效果。

監(jiān)控系統(tǒng)部署所在集群的網(wǎng)絡(luò)問題

做這個(gè)測(cè)試時(shí)，我還請(qǐng)了外援。讓別人在他們公司內(nèi)部幫忙用ab 訪問下。分別是外部聯(lián)通、外部電信、Google云主機(jī)、VPC內(nèi)部。下面是ab針對(duì)域名訪問的結(jié)果。LB1: lb1.example.com LB2: lb2.example.com

監(jiān)控系統(tǒng)部署所在集群的網(wǎng)絡(luò)問題

做這個(gè)測(cè)試時(shí)，我還請(qǐng)了外援。讓別人在他們公司內(nèi)部幫忙用ab 訪問下。分別是外部聯(lián)通、外部電信、Google云主機(jī)、VPC內(nèi)部。下面是ab針對(duì)域名訪問的結(jié)果。LB1: lb1.example.com LB2: lb2.example.com

LB1 的 ab 測(cè)試結(jié)果:

聯(lián)通測(cè)試：Server Software:        nginx 
Server Hostname:        lb1.example.com 
Server Port:            443 
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 
Document Path:          /favicon_128.ico/ 
Document Length:        2406 bytes 
Concurrency Level:      1 
Time taken for tests:   17.629 seconds 
Complete requests:      100 
Failed requests:        0 
Write errors:           0 
Non-2xx responses:      100 
Total transferred:      276000 bytes 
HTML transferred:       240600 bytes 
Requests per second:    5.67 [#/sec] (mean) 
Time per request:       176.291 [ms] (mean) 
Time per request:       176.291 [ms] (mean, across all concurrent requests) 
Transfer rate:          15.29 [Kbytes/sec] received 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:       16  121 157.1     20     653 
Processing:     8   55 104.7     11     633 
Waiting:        8   53  99.1     11     633 
Total:         26  176 188.5     36     668 
Percentage of the requests served within a certain time (ms) 
  50%     36 
  66%    241 
  75%    245 
  80%    248 
  90%    452 
  95%    658 
  98%    663 
  99%    668 
 100%    668 (longest request) 

電信測(cè)試：Server Software:        nginx 
Server Hostname:        lb1.example.com 
Server Port:            443 
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 
Document Path:          /favicon_128.ico/ 
Document Length:        2406 bytes 
Concurrency Level:      1 
Time taken for tests:   69.515 seconds 
Complete requests:      100 
Failed requests:        0 
Write errors:           0 
Non-2xx responses:      100 
Total transferred:      276000 bytes 
HTML transferred:       240600 bytes 
Requests per second:    1.44 [#/sec] (mean) 
Time per request:       695.151 [ms] (mean) 
Time per request:       695.151 [ms] (mean, across all concurrent requests) 
Transfer rate:          3.88 [Kbytes/sec] received 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:      108  120   5.7    121     132 
Processing:    40  575 1527.9     45    5049 
Waiting:       40  575 1527.9     45    5049 
Total:        148  695 1527.5    166    5175 
Percentage of the requests served within a certain time (ms) 
  50%    166 
  66%    171 
  75%    173 
  80%    174 
  90%   5154 
  95%   5167 
  98%   5173 
  99%   5175 
 100%   5175 (longest request) 

LB2 的 ab 測(cè)試結(jié)果：

聯(lián)通測(cè)試：Server Software:        nginx 
Server Hostname:        lb2.example.com 
Server Port:            443 
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 
Document Path:          /favicon_128.ico/ 
Document Length:        2406 bytes 
Concurrency Level:      1 
Time taken for tests:   17.168 seconds 
Complete requests:      100 
Failed requests:        0 
Write errors:           0 
Non-2xx responses:      100 
Total transferred:      276000 bytes 
HTML transferred:       240600 bytes 
Requests per second:    5.82 [#/sec] (mean) 
Time per request:       171.675 [ms] (mean) 
Time per request:       171.675 [ms] (mean, across all concurrent requests) 
Transfer rate:          15.70 [Kbytes/sec] received 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:       16  139 161.6     20     840 
Processing:     8   32  87.1     10     641 
Waiting:        8   32  87.1     10     641 
Total:         25  171 176.9    235     852 
Percentage of the requests served within a certain time (ms) 
  50%    235 
  66%    241 
  75%    245 
  80%    248 
  90%    255 
  95%    655 
  98%    667 
  99%    852 
 100%    852 (longest request) 

電信測(cè)試：Server Software:        nginx 
Server Hostname:        lb2.example.com 
Server Port:            443 
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 
Document Path:          /favicon_128.ico/ 
Document Length:        2406 bytes 
Concurrency Level:      1 
Time taken for tests:   16.714 seconds 
Complete requests:      100 
Failed requests:        0 
Write errors:           0 
Non-2xx responses:      100 
Total transferred:      276000 bytes 
HTML transferred:       240600 bytes 
Requests per second:    5.98 [#/sec] (mean) 
Time per request:       167.144 [ms] (mean) 
Time per request:       167.144 [ms] (mean, across all concurrent requests) 
Transfer rate:          16.13 [Kbytes/sec] received 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:      110  122   4.9    122     136 
Processing:    40   45   5.8     45     100 
Waiting:       40   45   5.8     45      99 
Total:        150  167   8.8    166     225 
Percentage of the requests served within a certain time (ms) 
  50%    166 
  66%    170 
  75%    171 
  80%    172 
  90%    175 
  95%    176 
  98%    183 
  99%    225 
 100%    225 (longest request) 

VPC 內(nèi)部測(cè)試（統(tǒng)一出口）:

LB1 的測(cè)試結(jié)果: 
Server Software:        nginx 
Server Hostname:        lb1.example.com 
Server Port:            443 
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 
Document Path:          /favicon_128.ico/ 
Document Length:        2406 bytes 
Concurrency Level:      1 
Time taken for tests:   513.333 seconds 
Complete requests:      100 
Failed requests:        1 
   (Connect: 0, Receive: 0, Length: 1, Exceptions: 0) 
Non-2xx responses:      100 
Total transferred:      273453 bytes 
HTML transferred:       238302 bytes 
Requests per second:    0.19 [#/sec] (mean) 
Time per request:       5133.329 [ms] (mean) 
Time per request:       5133.329 [ms] (mean, across all concurrent requests) 
Transfer rate:          0.52 [Kbytes/sec] received 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:        4    5   2.3      4      21 
Processing:     4 5128 4147.8   5007   20006 
Waiting:        4 5128 4147.8   5007   20006 
Total:          9 5133 4147.6   5012   20011 
 
LB2 的測(cè)試結(jié)果: 
Server Software:        nginx 
Server Hostname:        lb2.example.com 
Server Port:            443 
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256 
Document Path:          /favicon_128.ico/ 
Document Length:        2406 bytes 
Concurrency Level:      1 
Time taken for tests:   1.099 seconds 
Complete requests:      100 
Failed requests:        0 
Non-2xx responses:      100 
Total transferred:      276000 bytes 
HTML transferred:       240600 bytes 
Requests per second:    91.00 [#/sec] (mean) 
Time per request:       10.990 [ms] (mean) 
Time per request:       10.990 [ms] (mean, across all concurrent requests) 
Transfer rate:          245.26 [Kbytes/sec] received 
Connection Times (ms) 
              min  mean[+/-sd] median   max 
Connect:        4    5   1.7      4      16 
Processing:     4    6   2.4      5      22 
Waiting:        4    6   2.4      5      22 
Total:          8   11   2.9     10      26 
Percentage of the requests served within a certain time (ms) 
  50%     10 
  66%     11 
  75%     11 
  80%     12 
  90%     14 
  95%     17 
  98%     24 
  99%     26 
 100%     26 (longest request) 

google 的測(cè)試結(jié)果沒有放上來，相比國(guó)內(nèi)訪問是慢了點(diǎn)。這里主要關(guān)注了在 VPC 內(nèi)部測(cè)試時(shí)，LB1 的結(jié)果很不理想。但是 LB2 的結(jié)果又很正常?？吹街暗沫h(huán)境介紹，再配合這個(gè)結(jié)果，又把我拉回了原來的思路上，即 LB 和 vpc 內(nèi)部網(wǎng)絡(luò)有問題。

忘記說了一件事，我也在 nginx 主機(jī)上和 vpc 內(nèi)部其它主機(jī)上通過修改請(qǐng)求 header，直接訪問內(nèi)部 IP 請(qǐng)求資源，這里是沒有問題的，響應(yīng)特別快。這又能證明主機(jī)上服務(wù)運(yùn)行良好。網(wǎng)絡(luò)也可以排除。這……悲劇了。

應(yīng)用主機(jī)系統(tǒng)參數(shù)有問題 后來請(qǐng)教別人，最后告訴我看看內(nèi)核參數(shù) recycle。然后我又去網(wǎng)上查了下，看看有沒有類似的問題，但是不好查啊，環(huán)境都不一樣。

但是最后查到一條關(guān)于 nat 環(huán)境下， 在應(yīng)用服務(wù)器上設(shè)置內(nèi)核參數(shù)時(shí)，啟用了net.ipv4.tcp_tw_recycle 和 net.ipv4.tcp_tw_reuse。按照這個(gè)思路 導(dǎo)致有些客戶端連接服務(wù)器失敗，根據(jù)這個(gè)我去看了下服務(wù)器的配置，果不其然，有這個(gè)參數(shù)的優(yōu)化。

驗(yàn)證結(jié)果

在手動(dòng)的執(zhí)行下面這條命令后：

sysctl -w net.ipv4.tcp_tw_recycle 

繼續(xù)在 vpc 網(wǎng)絡(luò)內(nèi)部測(cè)試，發(fā)現(xiàn)對(duì)該 LB 的 ab測(cè)試全部都正常了，真是應(yīng)了那句話，差不多一切的問題不是網(wǎng)絡(luò)問題就是配置問題。下面是修改前后的監(jiān)控對(duì)比圖：

分析根本原因

這里提出了2個(gè)問題，便于理解記憶全文。

• 為什么啟用這個(gè) tcp recycle？
• 為什么啟用 tcp recycle 之后，會(huì)阻塞部分用戶的連接請(qǐng)求？

為什么啟用這個(gè) tcp recycle？

這個(gè)是之前在部署應(yīng)用主機(jī)系統(tǒng)時(shí)，修改優(yōu)化了部分內(nèi)核參數(shù)，當(dāng)時(shí)想的是為了增大主機(jī)對(duì) tcp 的連接性能，防止遇到并發(fā)用戶的連接，導(dǎo)致 tcp 連接不能快速釋放，從而引發(fā)服務(wù)器出現(xiàn)性能上的瓶頸（會(huì)導(dǎo)致服務(wù)器內(nèi)存和CPU的暴增）。

因?yàn)?client 與 server 建立鏈接傳輸完數(shù)據(jù)后，會(huì)斷開鏈接，而服務(wù)器這邊還會(huì)有 2MSL 的 time_wait 時(shí)間，超過這個(gè)時(shí)間之后，正常情況下，該 socket 才會(huì)被釋放， 然后才可以接收其它 client 的請(qǐng)求。因?yàn)?server 的端口是有固定范圍的，不是說 65535 個(gè)全部都用來建立連接（可參看系統(tǒng)內(nèi)核配置：net.ipv4.ip_local_port_range）。

另外關(guān)于 time_wait 具體的可以參考 tcp 的4次斷開后的狀態(tài)。所以為了快速回收和重新使用，才開啟了 tcp 的 reuse 和 recycle。但沒想到這個(gè)會(huì)引起這么大的問題。并且這個(gè)參數(shù)之前確實(shí)也在前公司用過。但沒有發(fā)現(xiàn)這個(gè)類似的問題（也可能是當(dāng)時(shí)的監(jiān)控不到位，沒有發(fā)現(xiàn)也不代表該問題不存在）。這里是官方內(nèi)核文檔對(duì)這倆參數(shù)的解釋：

net.ipv4.tcp_tw_recycle: Enable fast recycling TIME-WAIT sockets. Default value is 0. It should not be changed without advice/request of technical experts.

net.ipv4.tcp_tw_reuse: Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. Default value is 0. It should not be changed without advice/request of technical experts.

而TIME-WAIT時(shí)間為 2MSL 的作用就是為了以確保屬于未來連接的數(shù)據(jù)包不會(huì)被誤認(rèn)為是舊連接的延遲數(shù)據(jù)包。tcp_tw_reuse可以在TIME_WAIT 狀態(tài)到期之前使用套接字，內(nèi)核將嘗試確保沒有關(guān)于 TCP 序列號(hào)的沖突。如果啟用 tcp_timestamps（默認(rèn)是開啟的，也就是 PAWS，用于保護(hù)包裝序列號(hào)），它將確保不會(huì)發(fā)生這些沖突。

為什么會(huì)阻塞客戶端（Nat 環(huán)境）請(qǐng)求？

上面說了為什么啟用它，現(xiàn)在在討論下，為什么啟用它后，會(huì)導(dǎo)致部分用戶的鏈接，而不是全部？看了一些文檔及別人提到的解釋：

當(dāng)啟用 tcp_tw_recycle 時(shí)，內(nèi)核變得更具攻擊性，并將對(duì)遠(yuǎn)程的 client 建立連接請(qǐng)求時(shí)使用的時(shí)間戳進(jìn)行假設(shè)。它將跟蹤具有 TIME_WAIT 狀態(tài)連接的每個(gè)遠(yuǎn)程的 client 使用的最后時(shí)間戳， 并允許在時(shí)間戳正確增加時(shí)重新使用套接字。

但是，如果主機(jī)使用的時(shí)間戳發(fā)生更改（即 server 上記錄 time_wait 中有 A 客戶端的上一個(gè)請(qǐng)求的時(shí)間戳是 111112，現(xiàn)在又出現(xiàn)了一個(gè) A 客戶端的數(shù)據(jù)請(qǐng)求，并且序列號(hào)是111111.）， 則 SYN 數(shù)據(jù)包將以靜默的方式丟棄，并且連接將無法建立（將看到類似于“connect timeout”的錯(cuò)誤）。

為什么我看不到關(guān)于 connect timeout 的錯(cuò)誤呢？因?yàn)樵谶@個(gè)環(huán)境下，client 相當(dāng)于是最前面的 LB，即 haproxy，從這里也很好的解釋了，為什么haproxy 的日志有很多連接重試的記錄！

因?yàn)樵?NAT（網(wǎng)絡(luò)地址轉(zhuǎn)換） 環(huán)境下，有很多的 client，流量進(jìn)出都是通過一個(gè)公網(wǎng) IP出去的。

但當(dāng)多個(gè) NAT 網(wǎng)絡(luò)環(huán)境下的用戶同時(shí)或者短時(shí)間內(nèi)去訪問 server 端的話， 因?yàn)閷?duì)于 server 來說，此時(shí)我只知道有一個(gè)IP（client的公網(wǎng)IP）與我建立連接， 并且這里啟用了tcp_tw_recycle，Server主機(jī)內(nèi)核將認(rèn)為有一部分連接請(qǐng)求的時(shí)間戳不是遞增的，那么內(nèi)核將判斷該請(qǐng)求是無效的，就會(huì)丟失該請(qǐng)求。

To keep the same guarantees the TIME-WAIT state was providing, while reducing the expiration timer, when a connection enters the TIME-WAIT state, the latest timestamp is remembered in a dedicated structure containing various metrics for previous known destinations. Then, Linux will drop any segment from the remote host whose timestamp is not strictly bigger than the latest recorded timestamp, unless the TIME-WAIT state would have expired

總結(jié)

不要開啟tcp_tw_recycle,重要的話說三遍。一定要有配置管理！可以方便在系統(tǒng)出問題時(shí)，檢查對(duì)主機(jī)所做的歷史記錄。考慮問題不能光從 軟件程序、網(wǎng)絡(luò)上，還要加入對(duì)主機(jī)系統(tǒng)的分析。tcpdump、ss、還有l(wèi)og等。

另外，針對(duì) Web 應(yīng)用服務(wù)系統(tǒng)幾個(gè)優(yōu)化建議:

設(shè)置 net.ipv4.ip_local_port_range 合理的范圍（10000~63000）；

給 LB 設(shè)置更多的client IP；

配置 LB 有多個(gè)外網(wǎng) IP。