TCP garantit une transmission de données fiable et ordonnée . En cas de perte de paquets, ils sont renvoyés. Cependant, dès que la connexion est interrompue (par exemple en raison d'un délai d'attente ou d'un problème de routage), TCP le détecte immédiatement et termine la connexion.
UDP (QUIC) en revanche, est sans connexion et tolérant aux pertes de paquetsLa base de données 4D (ou QUIC en tant que couche de transport) tente de maintenir les flux de données malgré les perturbations. Cela rend le système plus robuste face aux problèmes réseau temporaires, mais il n'y a aucune garantie à 100 % que tous les paquets de données arrivent dans le bon ordre ou complètement.
En cas de perturbation réseau importante sous UDP
certains paquets UDP sont perdus,
ou les paquets arrivent en retard ou dans le mauvais ordre,
l'état de la synchronisation client-serveur peut devenir incohérent. Exemple :
Exemple :
Le client demande l'enregistrement ID 123 .
Le paquet de réponse est partiellement ou tardivement reçu.
QUIC tente de reconstruire, mais certaines parties du flux sont incohérentes.
Le client reçoit des données qui semblent formellement correctes (car elles peuvent être décodées), mais ne correspondent plus à la requête attendue.
Cela peut entraîner le comportement suivant :
Clic sur l'enregistrement A → affichage d'un autre enregistrement.
Le client « pense » donc être synchronisé avec le serveur, mais ce n'est plus le cas.
Le logiciel antivirus peut intervenir massivement dans le trafic réseau dans les environnements de serveurs terminaux ou de bureaux à distance et cela affecte particulièrement les connexions UDP/QUIC.et cela affecte particulièrement les connexions UDP/QUIC.
De nombreux produits AV modernes (par exemple BitDefender, Kaspersky, ESET, Sophos, etc.) contiennent des modules de protection réseauqui :
interceptent et inspectent tout le trafic réseau, éventuellement,
décodent et réencryptent les connexions TLS/SSL, décodent et réencryptent les connexions TLS/SSL,,
appliquent des heuristiques ou une « détection d'intrusion » et
et rejettent les paquets UDP « anormaux » s'ils ne correspondent pas au schéma attendu.
Cela se produit profondément dans la pile réseau Windows, souvent via :
pilotes NDIS,
LSP (Layered Service Provider),
ou filtres WFP (Windows Filtering Platform).
Ces hooks se situent en dessous du niveau de l'applicationet donc aussi en dessous de 4D..
Cela signifie que 4D ne remarque pas que des paquets ont été bloqués, retardés ou modifiés.
UDP/QUIC est sans état et et critique en termes de temps..
Lorsque des paquets sont retardés, bloqués ou « réordonnés » :
la séquence de paquets attendue n'est plus correcte,
les flux internes de QUIC se terminent de manière asynchrone,
ou certains numéros de séquence « manquent ».
Cela conduit également au phénomène décrit précédemment, où l'application cliente continue de répondre mais fournit des enregistrements erronés ou des résultats de recherche illogiques.
TCP serait moins sensible ici, car TCP détecterait et terminerait une transmission erronée – UDP/QUIC essaie plutôt de « se faufiler » et 4D continue de travailler avec des données incohérentes.
Dans les environnements de serveurs terminaux, il y a :
de nombreuses instances clientes 4D simultanées,
sur la même interface réseau,
souvent via la même couche de surveillance AV.
Cela génère :
de fortes latences (car le pilote AV vérifie chaque flux),
des pertes ou blocages sporadiques de paquets,,
et parfois des fuites de mémoire ou des blocages dans les pilotes de filtre.
Ces phénomènes se produisent particulièrement avec les « suites de sécurité » qui analysent le trafic réseau en temps réel ou activent la « protection contre les connexions suspectes ».