J'essaie de trouver un moyen de désactiver systématiquement la fonction keepalive sur plusieurs machines clientes qui envoient des requêtes HTTP par l'intermédiaire de curl
.
C'est mon serveur cible :
- Ubuntu 18.04.2 LTS
- 4.15.0-47-generic
- HA-Proxy version 1.8.19-1ppa1~bionic 2019/02/12
C'est le client 1 à partir duquel j'émets curl
(installation de vanille) :
- Ubuntu 16.04.3 LTS
- 4.4.0-62-generic
- curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
C'est le client 2 à partir duquel j'émets curl
(installation de vanille) :
- Ubuntu 18.04 LTS
- 4.15.0-20-generic
- curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Pour désactiver keepalive, j'ai essayé d'utiliser -H "Connection: close"
, --no-keepalive
y --keepalive-time 1
et seule la première option semble fonctionner, mais uniquement à partir du client 1.
Sur le client 1 (Ubuntu 16), la connexion ne reste pas ouverte, mais sur le client 2 (Ubuntu 18), la connexion reste ouverte jusqu'à ce qu'elle soit interrompue. Je confirme que, soit en regardant la page d'accueil du serveur cible, soit en regardant la page d'accueil du serveur cible. watch -n 0.1 "netstat -na | fgrep CLIENT_IP_ADDRESS"
ou en utilisant -vvv
sur les deux clients, qui sur le client 1 est toujours * Closing connection 0
et sur le client 2, c'est toujours * Connection #0 to host www.example.com left intact
.
Les différences entre les clients 1 et 2 sont évidemment la version Ubuntu et la version curl. Qu'est-ce qui fait que la connexion est fermée dans le client 1 mais pas dans le client 2 ?
J'ai également découvert que si je change mon serveur cible pour une autre machine utilisant une ancienne distribution avec un ancien apache httpd, si j'envoie Connection: close
ou non ne fait aucune différence et keepalive est toujours utilisé par l'un ou l'autre de mes 2 clients. Je suppose donc que la configuration du serveur cible joue également un rôle dans ce domaine.
Editar : Pour compliquer encore plus les choses, si, à partir des clients 1 et 2, j'envoie des requêtes au serveur cible via ab
alors la connexion est tuée instantanément. Cela est attendu car ab
utilise HTTP/1.0
et non HTTP/1.1
. Mais ensuite, si je cible l'ancienne distro avec apache, dans les deux cas, la connexion reste ouverte. Ce qui signifie qu'en effet, l'extrémité de réception joue également un rôle.
Edición 2 : J'ai attrapé tous les /proc/sys/net/ipv4/
les paramètres des deux clients via :
for file in /proc/sys/net/ipv4/*
do
echo "$file $(cat $file)"
done
et ceux-ci peuvent être trouvés ici :
0 votes
Y a-t-il des changements de paramètres tcp entre ces 2 clients tels que net.ipv4.tcp_syn_retries ?
0 votes
Dans les deux cas, les clients
cat /proc/sys/net/ipv4/tcp_syn_retries
renvoie à6
.0 votes
@asktyagi : J'ai ajouté tout
/proc/sys/net/ipv4/
dans la question.