站長(zhǎng)資訊網(wǎng)一、知識(shí)準(zhǔn)備
- 在nginx優(yōu)化中有個(gè)經(jīng)常需要設(shè)置的參數(shù)，tcp_nodelay
- 該參數(shù)最核心的功能，就是把小包組成成大包，提高帶寬利用率也就是著名的nagle算法
- tcp協(xié)議中，有一個(gè)現(xiàn)象：應(yīng)用層數(shù)據(jù)可能很低（比如1個(gè)字節(jié)），而傳輸層開銷有40字節(jié)(20字節(jié)的IP頭+20字節(jié)的TCP頭)。這種情況下大部分都是控制包的傳輸，既加大了帶寬的消耗，帶寬利用率也不高
- nagle算法就是為了解決這個(gè)問題。在發(fā)出去的數(shù)據(jù)還未被確認(rèn)之前，或者說還沒有收到對(duì)端的ack之前，新生成的小包是不允許被發(fā)送的，必須要湊滿一個(gè)MSS或者等到收到確認(rèn)后再發(fā)送，直至超時(shí)
二、環(huán)境準(zhǔn)備
| 組件 | 版本 |
|---|---|
| OS | Ubuntu 18.04.1 LTS |
| docker | 18.06.0-ce |
客戶端 : 192.168.17.171
服務(wù)端 : 192.168.17.173
三、打開nagle算法
192.168.17.173，先準(zhǔn)備一個(gè)nginx配置文件，并且打開nagle算法，設(shè)置tcp_nodelay off;
root@k8s-node2:/tmp# more nginx.conf user nginx; worker_processes 1; error_log /var/log/nginx/error.log warn; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; sendfile on; tcp_nodelay off; keepalive_timeout 65; include /etc/nginx/conf.d/*.conf; }
啟動(dòng)容器
root@k8s-node2:/tmp# docker run -d --name nginx_delay -v /tmp/nginx.conf:/etc/nginx/nginx.conf -p 80:80 nginx:latest 6b7d5a5d3c3ed021fed6847d138837754c5732979d1c829ec62107ec80440db8 root@k8s-node2:/tmp# docker ps | grep nginx_delay 6b7d5a5d3c3e nginx:latest "nginx -g 'daemon of…" 7 seconds ago Up 6 seconds 0.0.0.0:80->80/tcp nginx_delay
首先使用tcpdump抓取本機(jī)的80端口的流量：
root@k8s-node2:/tmp# tcpdump -i ens3 port 80 -afexnnvv -w nginx_ab.cap
在192.168.17.171，使用ab壓測(cè)工具對(duì)該端口進(jìn)行放量
注意：必須使用 -k 參數(shù)，使用keepalived模式下才能模擬出nagle算法
root@k8s-node2:~# ab -n 1000 -c 100 -k http://127.0.0.1/ This is ApacheBench, Version 2.3 <$Revision: 1807734 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ ... Time per request: 44.619 [ms] (mean) ...
過濾掉大量信息，我們來到這個(gè)指標(biāo)Time per request，無論怎么測(cè)試，平均延時(shí)總是在40ms左右
我們來看下抓包信息，使用wireshark打開
在大量的數(shù)據(jù)包中，我們先處理一下數(shù)據(jù)包，隨便選取一個(gè)syn，選取與該syn對(duì)應(yīng)的tcp流
選取一個(gè)片段來分析
● 在Linux中，默認(rèn)打開了延遲確認(rèn)，所謂延遲確認(rèn)，就是不是收到每個(gè)請(qǐng)求都發(fā)送一次ack，而是等待一段時(shí)間，如果這段時(shí)間正好有包需要發(fā)送，就坐著“順風(fēng)車”一起發(fā)出，否則超時(shí)后單獨(dú)發(fā)送。所以客戶端會(huì)等待40ms，再發(fā)送這個(gè)ack
● 由于nginx也設(shè)置了nagle算法，如果沒有收到ack，它會(huì)等著包的到來，所以就會(huì)呈現(xiàn)這個(gè)樣子
（1）192.168.17.171首先發(fā)送一個(gè)http get請(qǐng)求（677號(hào)包）
（2）192.167.17.173發(fā)送PSH，ACK（999號(hào)包）
（3）此時(shí)由于Linux默認(rèn)打開延遲確認(rèn)，192.168.17.171會(huì)等待40ms，看看有沒有“順風(fēng)車”；而192.168.17.173上的nginx由于關(guān)閉了tcp_nodelay，它也會(huì)等待著ack的到來再回應(yīng)
（4）40ms過后，192.168.17.171沒有等到“順風(fēng)車”，此時(shí)發(fā)送ack（1109號(hào)包）
（5）192.168.17.173收到ack后發(fā)送了http 200（1118號(hào)包）
（6）192.168.17.171收到數(shù)據(jù)之后發(fā)送確認(rèn)ack（1127號(hào)包）
192.168.17.171:47388 192.168.17.173:80 +-------+ +--------+ | | no.677 http get | | | +---------------------------------> | | | | | | | no.999 PSH,ACK | | | <---------------------------------+ | | | | | | | | | | | | | | | delay 40ms | | | | | | | | | | | | | | | | no.1109 ACK | | | +---------------------------------> | | | | | | | no.1118 http 200 | | | <---------------------------------+ | | | | | | | no.1127 ACK | | | +---------------------------------> | | | | | | | | | +-------+ +--------+四、關(guān)閉nagle
只需要設(shè)置tcp_nodelay on;
root@k8s-node2:/tmp# sed -i '/tcp_nodelay/s/off/on/g' nginx.conf root@k8s-node2:/tmp# docker rm -f nginx_delay nginx_delay root@k8s-node2:/tmp# docker run -d --name nginx_delay -v /tmp/nginx.conf:/etc/nginx/nginx.conf -p 80:80 nginx:latest bac9bcf7a6e392a7a07afae165c3d5b4e3fb2fc43d3470f35802e12d1e7ae70d
再用ab測(cè)試：
root@k8s-node2:~# ab -n 1000 -c 100 -k http://127.0.0.1/ This is ApacheBench, Version 2.3 <$Revision: 1807734 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ ... Time per request: 14.285 [ms] (mean) ...
再來觀察抓包的結(jié)果：
● 由于客戶端依然打開了延遲確認(rèn)，所以192.168.17.171收到數(shù)據(jù)包之后依然沒有及時(shí)回應(yīng)
● 但是nginx，tcp_nodelay on，所以192.168.17.173收到數(shù)據(jù)包后會(huì)立即響應(yīng)ack
● 192.168.17.171收到之后，已經(jīng)有2個(gè)沒有確認(rèn)的數(shù)據(jù)包了，所以會(huì)立即發(fā)送ack進(jìn)行確認(rèn)：
（1）192.168.17.171首先發(fā)送一個(gè)http get請(qǐng)求（447號(hào)包）
（2）192.168.17.173收到之后立即響應(yīng)psh,ack（740號(hào)包）
（3）192.168.17.173發(fā)送http 200（741號(hào)包）
（4）192.168.17.171回應(yīng)ack（742號(hào)包）
192.168.17.171:49718 192.168.17.173:80 +-------+ +--------+ | | no.447 http get | | | +---------------------------------> | | | | | | | no.740 PSH,ACK | | | <---------------------------------+ | | | | | | | no.741 http 200 | | | <---------------------------------+ | | | | | | | no.742 ACK | | | +---------------------------------> | | | | | | | | | +-------+ +--------+五、小結(jié)
● 本文復(fù)現(xiàn)了經(jīng)典的40ms問題
● 本文中提到了2個(gè)名詞，nagle算法與延遲確認(rèn)，它們看上去很相似，但是并不一樣。nagle算法是需要等到對(duì)端ack來臨，或者湊滿一個(gè)mss之后才發(fā)送數(shù)據(jù)包；而延遲確認(rèn)針對(duì)的是ack，ack會(huì)等待“順風(fēng)車”，如果有，就乘坐順風(fēng)車發(fā)送，否則等待超時(shí)之后單獨(dú)發(fā)送
● 本文中延遲確認(rèn)是Linux默認(rèn)打開的功能，所以在實(shí)驗(yàn)中，客戶端都會(huì)有延時(shí)確認(rèn)的情況，要關(guān)閉客戶端延遲確認(rèn)，需要設(shè)置setsockopt中的TCP_QUICKACK
● 本文中主要討論的是nginx的nagle算法，nagle算法完全由tcp協(xié)議的ack機(jī)制決定，如果對(duì)端ACK回復(fù)很快的話，nagle事實(shí)上不會(huì)拼接太多的數(shù)據(jù)包，雖然避免了網(wǎng)絡(luò)擁塞，網(wǎng)絡(luò)總體的利用率依然很低
● nagle算法在與延遲確認(rèn)互相作用的情況下，會(huì)產(chǎn)生嚴(yán)重的延時(shí)效果，這是需要警惕的
● nginx中是否打開nagle算法，要取決于業(yè)務(wù)場(chǎng)景。比如在實(shí)驗(yàn)中看到：
（1）tcp_nodelay off，會(huì)增加通信的延時(shí)，但是會(huì)提高帶寬利用率。在高延時(shí)、數(shù)據(jù)量大的通信場(chǎng)景中應(yīng)該會(huì)有不錯(cuò)的效果
（2）tcp_nodelay on，會(huì)增加小包的數(shù)量，但是可以提高響應(yīng)速度。在及時(shí)性高的通信場(chǎng)景中應(yīng)該會(huì)有不錯(cuò)的效果
