So konfigurieren Sie HTTP-Keepalive in Nginx

http keepalive
In den frühen Tagen von http erforderte jede http-Anfrage das Öffnen einer TPC-Socket-Verbindung, und die TCP-Verbindung wurde nach einmaliger Verwendung getrennt. Die Verwendung von Keep-Alive kann diese Situation verbessern, d. h. mehrere Kopien von Daten können kontinuierlich in einer TCP-Verbindung gesendet werden, ohne dass die Verbindung unterbrochen werden muss. Durch die Verwendung des Keep-Alive-Mechanismus kann die Anzahl der TCP-Verbindungsaufbauzeiten reduziert werden, was auch bedeutet, dass der time_wait-Status der Verbindung reduziert werden kann, wodurch die Leistung verbessert und die Durchsatzrate des httpd-Servers erhöht wird (weniger TCP-Verbindungen bedeuten weniger System). Kernel-Aufrufe, Socket-Accept()- und Close()-Aufrufe). Keep-Alive ist jedoch kein kostenloses Mittagessen. Langfristige TCP-Verbindungen können leicht zu einer ungültigen Nutzung von Systemressourcen führen. Falsch konfigurierte Keep-Alives können manchmal größere Verluste verursachen als die Wiederverwendung von Verbindungen. Daher ist es sehr wichtig, das Keep-Alive-Timeout richtig einzustellen.
Keepalvie-Timeout
Der httpd-Daemon bietet im Allgemeinen Parameter zur Einstellung der Keep-Alive-Timeout-Zeit. Zum Beispiel keepalive_timeout von Nginx und keepalivetimeout von Apache. Dieser keepalive_timout-Zeitwert bedeutet, dass eine von http generierte TCP-Verbindung nach der Übertragung der letzten Antwort keepalive_timeout Sekunden halten muss, bevor sie mit dem Schließen der Verbindung beginnt. Nachdem der httpd-Daemon eine Antwort gesendet hat, sollte er die entsprechende TCP-Verbindung sofort schließen. Nach dem Festlegen von keepalive_timeout möchte der httpd-Daemon noch etwas sagen: „Warten Sie, ob der Browser eine weitere Anfrage gestellt hat.“ ist die keepalive_timeout-Zeit. Wenn der Daemon-Prozess während dieser Wartezeit keine http-Anfrage vom Browser erhält, wird die http-Verbindung geschlossen.
Ich habe ein Skript geschrieben, um das Testen zu erleichtern

<?php
sleep(60); //为了便于分析测试，会根据测试进行调整
echo "www.jb51.net";
?>

1. Wenn die keepalive_timeout-Zeit 0 ist, d -Wege-Handshake, Verbindung herstellen. Es dauert 8898 μs
Zeile 4 bis 5, um die erste HTTP-Anfrage über die hergestellte Verbindung zu senden, und der Server bestätigt den Empfang der Anfrage. Die benötigte Zeit beträgt 5μs

In den Zeilen 5 bis 6 können wir erkennen, dass die Skriptausführungszeit 60s1387μs beträgt, was mit dem PHP-Skript übereinstimmt.

In den Zeilen 6 und 8 sendet der Server eine http-Antwort. Das Senden der Antwort dauerte 90166 μs.
Zeile 7 zeigt an, dass der Server-Daemon die Verbindung aktiv schließt. In Kombination mit den Zeilen 6 und 8 zeigt es, dass der Server die TCP-Verbindung sofort schließt, sobald die HTTP-Antwort gesendet wird. Die Zeilen 7, 9 und 10 zeigen, dass die TCP-Verbindung nacheinander geschlossen wird, was 90963 μs dauert. Es ist zu beachten, dass die Socket-Ressource hier nicht sofort freigegeben wird. Sie muss 2 msl (60 Sekunden) warten, bevor sie tatsächlich freigegeben wird.
Es ist ersichtlich, dass die Erstellung und Freigabe einer Socket-Ressource dauert, wenn keepalive_timeout nicht festgelegt ist: Aufbau einer TCP-Verbindung + Übertragen einer HTTP-Anfrage + Ausführen eines PHP-Skripts + Übertragen einer HTTP-Antwort + Schließen der TCP-Verbindung + 2 msl. (Hinweis: Die Zeit hier kann nur als Referenz verwendet werden. Die spezifische Zeit wird hauptsächlich durch die Netzwerkbandbreite und die Antwortgröße bestimmt)
2. Wenn die keepalive_timeout-Zeit größer als 0 ist, d. h. wenn Keep-Alive aktiviert ist, wird die Lebenszyklus einer TCP-Verbindung. Um die Analyse zu erleichtern, setzen wir keepalive_timeout auf 300s

#tcpdump -n host 218.1.57.236 and port 80

20:36:50.792731 ip 218.1.57.236.43052 > 222.73.211.215.http: s 1520902589:1520902589(0) win 65535
20:36:50.792798 ip 222.73.211.215.http > 218.1.57.236.43052: s 290378256:290378256(0) ack 1520902590 win 5840
20:36:50.801629 ip 218.1.57.236.43052 > 222.73.211.215.http: . ack 1 win 3276820:36:50.801838 ip 218.1.57.236.43052 > 222.73.211.215.http: p 1:797(796) ack 1 win 32768
20:36:50.801843 ip 222.73.211.215.http > 218.1.57.236.43052: . ack 797 win 5920:37:50.803230 ip 222.73.211.215.http > 218.1.57.236.43052: p 1:287(286) ack 797 win 59
20:37:50.803289 ip 222.73.211.215.http > 218.1.57.236.43052: f 287:287(0) ack 797 win 59
20:37:50.893396 ip 218.1.57.236.43052 > 222.73.211.215.http: . ack 288 win 32625
20:37:50.894249 ip 218.1.57.236.43052 > 222.73.211.215.http: f 797:797(0) ack 288 win 32625
20:37:50.894252 ip 222.73.211.215.http > 218.1.57.236.43052: . ack 798 win 59

Schauen wir uns zunächst die Zeilen 6 bis 8 an. Der Unterschied zum letzten Beispiel besteht darin, dass der Server-httpd-Daemon den TCP nicht aktiv geschlossen hat Verbindung sofort herstellen.
Zeile 8, kombiniert mit Zeile 6, können wir sehen, dass der Server nach 5 Minuten (300 Sekunden) die TCP-Verbindung aktiv schließt. Dies ist genau die Zeit, die wir keepalive_timeout festgelegt haben.
Es ist ersichtlich, dass bei festgelegter keepalive_timout-Zeit die Zeit, die von der Einrichtung eines Sockets bis zu seiner Freigabe benötigt wird, länger ist als die keepalive_timeout-Zeit.

3. Wenn die keepalive_timeout-Zeit größer als 0 ist und mehrere http-Antworten über dieselbe TCP-Verbindung gesendet werden. Um die Analyse hier zu erleichtern, setzen wir keepalive_timeout auf 180 Sekunden. Mit diesem Test möchten wir herausfinden, ob keepalive_timeout mit der Zeitmessung am Ende der ersten Antwort beginnt oder mit der Zeitmessung am Ende der letzten Antwort. Die Testergebnisse bestätigten, dass es sich um Letzteres handelt. Hier haben wir alle 120 Sekunden eine Anfrage gesendet und 3 Anfragen über eine TCP-Verbindung gesendet.

# tcpdump -n host 218.1.57.236 and port 80

22:43:57.102448 ip 218.1.57.236.49955 > 222.73.211.215.http: s 4009392741:4009392741(0) win 65535
22:43:57.102527 ip 222.73.211.215.http > 218.1.57.236.49955: s 4036426778:4036426778(0) ack 4009392742 win 5840
22:43:57.111337 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 1 win 3276822:43:57.111522 ip 218.1.57.236.49955 > 222.73.211.215.http: p 1:797(796) ack 1 win 32768
22:43:57.111530 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 797 win 59
22:43:59.114663 ip 222.73.211.215.http > 218.1.57.236.49955: p 1:326(325) ack 797 win 59
22:43:59.350143 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 326 win 3260522:45:59.226102 ip 218.1.57.236.49955 > 222.73.211.215.http: p 1593:2389(796) ack 650 win 32443
22:45:59.226109 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 2389 win 83
22:46:01.227187 ip 222.73.211.215.http > 218.1.57.236.49955: p 650:974(324) ack 2389 win 83
22:46:01.450364 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 974 win 3228122:47:57.377707 ip 218.1.57.236.49955 > 222.73.211.215.http: p 3185:3981(796) ack 1298 win 32119
22:47:57.377714 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 3981 win 108
22:47:59.379496 ip 222.73.211.215.http > 218.1.57.236.49955: p 1298:1622(324) ack 3981 win 108
22:47:59.628964 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 1622 win 3276822:50:59.358537 ip 222.73.211.215.http > 218.1.57.236.49955: f 1622:1622(0) ack 3981 win 108
22:50:59.367911 ip 218.1.57.236.49955 > 222.73.211.215.http: . ack 1623 win 32768
22:50:59.686527 ip 218.1.57.236.49955 > 222.73.211.215.http: f 3981:3981(0) ack 1623 win 32768
22:50:59.686531 ip 222.73.211.215.http > 218.1.57.236.49955: . ack 3982 win 108

第一组，三个ip包表示tcp三次握手建立连接，由浏览器建立。
第二组，发送第一次http请求并且得到响应，服务端守护进程输出响应之后，并没马上主动关闭tcp连接。而是启动keepalive_timout计时。
第三组，2分钟后，发送第二次http请求并且得到响应，同样服务端守护进程也没有马上主动关闭tcp连接，重新启动keepalive_timout计时。
第四组，又2分钟后，发送了第三次http请求并且得到响应。服务器守护进程依然没有主动关地闭tcp连接（距第一次http响应有4分钟了,大于keepalive_timeout值），而是重新启动了keepalive_timout计时。
第五组，跟最后一个响应keepalive_timeout(180s)内，守护进程再没有收到请求。计时结束，服务端守护进程主动关闭连接。4次挥手后，服务端进入time_wait状态。
这说明，当设定了keepalive_timeout，一个socket由建立到释放，需要时间是：tcp建立 + (最后一个响应时间 – 第一个请求时间) + tcp关闭 + 2msl。红色加粗表示每一次请求发送时间、每一次请求脚本执行时间、每一次响应发送时间，还有两两请求相隔时间。进一步测试，正在关闭或者 time_wait状态的tcp连接，不能传输http请求和响应。即，当一个连接结束keepalive_timeout计时，服务端守护进程发送第一 个fin标志ip包后，该连接不能再使用了。
http keep-alive与tcp keep-alive
http keep-alive与tcp keep-alive，不是同一回事，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是tcp的一种检测tcp连接状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数：

echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 15 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

keepalive是tcp保鲜定时器，当网络两端建立了tcp连接之后，闲置idle（双方没有任何数据流发送往来）了 tcp_keepalive_time后，服务器内核就会尝试向客户端发 送侦测包，来判断tcp连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该tcp连接。tcp连接默认闲置时间是2小时，一般 设置为30分钟足够了。也就是说，仅当nginx的keepalive_timeout值设置高于tcp_keepalive_time，并且距此tcp连接传输的最后一 个http响应，经过了tcp_keepalive_time时间之后，操作系统才会发送侦测包来决定是否要丢弃这个tcp连接。一般不会出现这种情况， 除非你需要这样做。
keep-alive与time_wait
使用http keep-alvie，可以减少服务端time_wait数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。

Das obige ist der detaillierte Inhalt vonSo konfigurieren Sie HTTP-Keepalive in Nginx. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!