Résoudre les problèmes QUIC dans .NET
Dans cet article, vous allez apprendre à diagnostiquer les problèmes les plus courants liés à QUIC dans .NET.
La bibliothèque System.Net.Quic est basée sur l’implémentation QUIC open source MsQuic. Pour cette raison, le comportement diffère des sockets ordinaires, parfois par conception. En outre, il est basé sur le protocole UDP et il ne fournit pas exactement la même expérience qu’avec TCP.
L’écouteur est en cours d’exécution, mais ne reçoit aucune donnée
Si un écouteur s’exécute mais ne reçoit jamais de données, cela peut être dû à l’écoute d’un autre processus sur le même port. Pour vérifier quel processus utilise l’exécution du port :
sudo ss -tulpw
Ce comportement est conçu lorsque MsQuic utilise SO_REUSEPORT pour obtenir de meilleures performances. Pour plus d’informations, consultez la documentation ListenerStart et le problème d’origine dotnet/runtime#59382.
Notes
Ce problème ne se produit pas sur Windows, où MsQuic tente d’effectuer une réservation de port. Cela entraîne l’échec du démarrage de l’application qui tente d’ouvrir le deuxième écouteur sur le même port.
QuicListener est toujours à l’écoute, QUELLE QUE SOIT l’adresse
Même si une adresse spécifique est fournie via la propriété ListenEndpoint, QuicListener ouvre toujours un socket générique à double pile. Ce comportement est inhérent à la conception de MsQuic. L’adresse IP d’écoute est toujours utilisée pour effectuer un filtrage au sein de MsQuic. Pour plus d’informations, consultez la documentation ListenerStart et le problème d’origine [dotnet/runtime#92812].
Le client reçoit une erreur ALPN inattendue
Le client tente de se connecter, mais reçoit Application layer protocol negotiation error was encountered malgré l’utilisation du même ALPN que le serveur.
Ce qui se passe, c’est que l’écouteur est toujours lié à l’adresse générique en mode double, quelle que soit la spécification de l’application. Ensuite, il correspond aux connexions entrantes par adresse IP et ALPN. Si aucune correspondance n’est trouvée, il signale l’erreur mentionnée ci-dessus. Par conséquent, une incompatibilité entre l’adresse IP d’écoute et la connexion d’une adresse IP entraîne une erreur ALPN.
Pour éviter cette erreur, assurez-vous de vous connecter à la même adresse pour laquelle l’écouteur a été démarré. Par exemple, imprimez l’adresse d’écoute de votre écouteur :
await using var listener = QuicListener.ListenAsync(new() /* appropriate options */);
Console.WriteLine(listener.LocalEndPoint);
Ce problème peut se produire dans plusieurs scénarios différents, comme dans ce problème dotnet/runtime#85412. Le serveur a été démarré pour l’adresse Loopback (127.0.0.1) et tout fonctionnait lors de l’exécution sur le même ordinateur. Mais lorsque le client essayait de se connecter à partir d’un autre, l’adresse ne correspondait pas à l’adresse de bouclage du serveur et a été rejetée avec une erreur ALPN.
Notes
Cela se produit lorsque l’écouteur utilise MsQuic, par exemple via .NET QuicListener.
L’écouteur réussit à démarrer pour IPv6 malgré sa désactivation
Bien qu’IPv6 soit désactivé, QuicListener.ListenAsync réussit avec une adresse IPv6. Cela est associé au problème précédent lorsque MsQuic lie à l’adresse générique et réussit donc à le faire. Par conséquent, l’écouteur est démarré, mais aucune connexion ne peut y être établie. Il s’agit d’une différence de comportement par rapport aux sockets, qui se déclenchent dans ce cas.
Il existe de nombreuses façons de vérifier si IPv6 est activé, par exemple sur Linux, vérifier l’état du module IPv6 :
cat /sys/module/ipv6/parameters/disable
# 0 - IPv6 is enable
# 1 - IPv6 is disabled
Comme indiqué ci-dessus, le comportement de MsQuic est intentionnel. Toutefois, ce problème particulier peut être atténué du côté .NET à l’avenir. Pour plus d’informations, consultez dotnet/runtime#75343.
L’écouteur ne parvient pas à démarrer avec l’erreur QUIC_STATUS_ADDRESS_IN_USE
Il s’agit d’un problème spécifique à Windows. L’écouteur génère une QuicExceptionavec l’erreur QUIC_STATUS_ADDRESS_IN_USE malgré aucun autre processus en cours d’exécution sur une adresse et un port particuliers. L’erreur est due à la plage d’exclusion de port définie pour le même port que celui sur lequel l’écouteur tente d’écouter. Pour vérifier l’exécution des plages exécutez :
netsh.exe int ip show excludedportrange protocol=udp
L’échec de la tentative de liaison sur un port provenant de la plage exclue est un comportement attendu. Pour cette raison, il n’existe aucun plan immédiat pour résoudre ce problème. Plus d’informations sur dotnet/runtime#71518.
