Delais
Ce que chaque delai detecte
| Delai | Detecte | Defaut |
|---|---|---|
sftp.login_grace_secs | une connexion SSH qui ne s’authentifie pas | 120 s |
uploads.idle_timeout_secs | un client vivant qui n’envoie plus rien pendant un upload (suspendu, bloque) | 30 s |
uploads.min_rate_bytes_per_sec | un upload au goutte-a-goutte | desactive |
[tcp_keepalive] | un pair disparu sans rien en vol (machine eteinte, NAT qui a oublie la connexion) | ~60 s |
tcp_keepalive.user_timeout_secs | un pair disparu alors que le serveur lui envoyait quelque chose ; un client qui ne lit plus | 65 s (SFTP), 35 s (HTTP) |
sftp.inactivity_timeout_secs | une connexion SSH sans aucun paquet | 600 s |
sftp.keepalive_interval_secs | un client SSH fige tout entier | desactive |
admin.header_read_timeout_secs | une requete HTTP dont les en-tetes n’arrivent pas | 10 s |
Uploads : [uploads]
[uploads]
idle_timeout_secs = 30
min_rate_bytes_per_sec = 1024 # 1 Kio/s en moyenne ; absent ou 0 : desactive
min_rate_grace_secs = 60
Toutes les cles : Reference [uploads].
Le delai d’inactivite
Le chronometre ne court que quand le serveur attend le client. Le temps passe par le serveur sur son stockage (S3 lent, NFS qui cale) ne compte jamais.
| Porte | Le chronometre |
|---|---|
| REST | repart a chaque octet du corps |
| SFTP | un par handle d’ecriture : part a l’OPEN, repart a chaque WRITE complet de ce handle, quoi que fasse la session par ailleurs ; un paquet doit arriver en entier dans le delai qui suit son premier octet |
Au bout du delai, le partiel est jete (fichier en cours de transfert supprime, multipart S3 annule) et rien n’est publie.
Un upload vivant atteint son fichier au moins toutes les 2 x
idle_timeout_secs : le menage des restes et la reprise des verrous s’y
fient, donnez la meme valeur a toutes les instances qui partagent un
stockage. Relevez-la pour les clients qui gardent un fichier ouvert sans
ecrire (sshfs, client graphique qui demande une confirmation, lien tres
lent : au defaut, un paquet de 32 Kio demande ~1,1 Ko/s).
Le debit minimal
Passe min_rate_grace_secs d’attente, un upload doit avoir recu en moyenne
au moins min_rate_bytes_per_sec, comme RequestReadTimeout ... MinRate
d’Apache. La moyenne court depuis le debut : un client en rafales garde le
credit de ses rafales, un goutte-a-goutte est coupe a la fin de la grace.
Les octets comptes sont ceux des WRITE acceptes, pas l’offset atteint.
En dessous, l’upload est coupe comme pour l’inactivite. 1 Kio/s coupe un goutte-a-goutte et laisse passer un lien de 10 Kio/s qui cale.
Keepalive TCP : [tcp_keepalive]
Pose sur chaque connexion acceptee, sur le port SFTP et sur le port HTTP.
Toutes les cles : Reference [tcp_keepalive].
Coupure du reseau en plein transfert : TCP_USER_TIMEOUT
Le keepalive ne sonde qu’une connexion sans rien en vol. Quand le serveur
envoie quelque chose a un client disparu (les reponses aux WRITE d’un
upload SFTP, un telechargement), c’est TCP_USER_TIMEOUT qui coupe.
user_timeout_secs | Port SFTP | Port HTTP |
|---|---|---|
0 ou absent | 2 x idle_timeout_secs + 5 s (65 s) | idle_timeout_secs + 5 s (35 s) |
N | N | N |
La connexion est ainsi coupee 5 s apres l’abandon de l’upload. Sous Linux,
ce delai remplace count : une connexion inoccupee dont le pair a disparu
est coupee a la premiere sonde qui le depasse (vers 70 s en SFTP). Il vaut
aussi pour un client qui ne lit plus : un telechargement REST dont le client
est suspendu est coupe a 35 s. Une coupure reseau plus longue (perte de
couverture, VPN qui se reconnecte) tue le transfert ; relevez
user_timeout_secs si vos clients en traversent.
Hors Linux, rien n’est pose.
SSH : [sftp]
login_grace_secs et inactivity_timeout_secs coupent la connexion (0 :
jamais) ; keepalive_interval_secs (0 : aucun) sonde le client,
keepalive_max (3) coupe apres autant de sondes sans reponse. Les cles :
[sftp].
La reponse a un keepalive SSH compte comme de l’activite : avec un keepalive
plus court que inactivity_timeout_secs, une session vivante mais inoccupee
n’est plus coupee par l’inactivite, seul un client qui ne repond plus l’est.
C’est pourquoi le keepalive SSH est desactive par defaut.
HTTP : delai de lecture des en-tetes
admin.header_read_timeout_secs (10 s, de 1 a 300,
CRAFT_FILE_GATE_ADMIN_HEADER_READ_TIMEOUT_SECS) borne, sur le port de
l’API d’administration et de l’API de fichiers, l’attente des en-tetes d’une
requete : depuis la connexion, la poignee de main TLS ou la reponse
precedente en keep-alive. Au-dela, la connexion est fermee sans reponse. Il
ne borne ni un corps ni une reponse.
Le port ne sert que HTTP/1.1 ; en HTTPS, l’ALPN n’offre que http/1.1, et
les clients HTTP/2 s’y rabattent.
Ce que vous verrez
| Quand | Ligne |
|---|---|
| demarrage | INFO idle and liveness timeouts in force: ..., une valeur par champ, et from_config : les cles fixees par le fichier |
| pair disparu | INFO SSH session ended: the connection timed out: ... |