Rozwiązywanie problemów z quic na platformie .NET
W tym artykule dowiesz się, jak zdiagnozować najczęstsze problemy z quiC na platformie .NET.
Biblioteka System.Net.Quic jest oparta na implementacji QUIC typu open source MsQuic. W związku z tym zachowanie różni się od zwykłych gniazd, czasami zgodnie z projektem. Ponadto jest on oparty na protokole UDP i nie zapewnia dokładnie takiego samego środowiska, jak w przypadku protokołu TCP.
Odbiornik jest uruchomiony, ale nie odbiera żadnych danych
Jeśli odbiornik jest uruchomiony, ale nigdy nie odbiera danych, może to być spowodowane przez inny proces nasłuchiwania na tym samym porcie. Aby sprawdzić, który proces używa, który port jest uruchamiany:
sudo ss -tulpw
Takie zachowanie jest celowe w miarę MsQuic wykorzystania SO_REUSEPORT w celu uzyskania lepszej wydajności. Aby uzyskać więcej informacji, zobacz dokumentację ListenerStart i oryginalny problem dotnet/runtime#59382.
Uwaga
Ten problem nie występuje w systemie Windows, gdzie msQuic podejmie próbę wykonania rezerwacji portów. Powoduje to, że nie można uruchomić aplikacji próbującej otworzyć drugiego odbiornika na tym samym porcie.
QuicListener zawsze nasłuchuje na dowolnym adresie
Nawet jeśli określony adres jest dostarczany za pośrednictwem ListenEndpoint właściwości, QuicListener nadal otworzy dwustosowe gniazdo wieloznaczne. To zachowanie jest projektowane przez MsQuicprogram . Adres IP nasłuchiwania jest nadal używany do filtrowania wewnątrz MsQuicelementu . Aby uzyskać więcej informacji, zobacz dokumentację ListenerStart i oryginalny problem [dotnet/runtime#92812].
Klient otrzymuje nieoczekiwany błąd ALPN
Klient próbuje nawiązać połączenie, ale otrzymuje Application layer protocol negotiation error was encountered pomimo użycia tej samej nazwy ALPN co serwer.
Dzieje się tak, że odbiornik zawsze wiąże się z adresem wieloznacznymi w trybie podwójnym, niezależnie od tego, co określono w aplikacji. Następnie pasuje do połączeń przychodzących według adresu IP i ALPN. Jeśli nie znaleziono dopasowania, zgłasza on powyższy błąd. W rezultacie niezgodność między adresem IP nasłuchiwania i nawiązywaniem połączenia spowoduje wystąpienie błędu ALPN.
Aby uniknąć tego błędu, upewnij się, że nawiązujesz połączenie z tym samym adresem, dla którego odbiornik został uruchomiony. Na przykład wyświetl adres nasłuchiwania dla odbiornika:
await using var listener = QuicListener.ListenAsync(new() /* appropriate options */);
Console.WriteLine(listener.LocalEndPoint);
Ten problem może wystąpić w kilku różnych scenariuszach, takich jak w tym problemie dotnet/runtime#85412. Serwer został uruchomiony dla Loopback adresu (127.0.0.1) i wszystko działało po uruchomieniu na tej samej maszynie. Jednak gdy klient próbował nawiązać połączenie z innego, adres nie pasuje do adresu sprzężenia zwrotnego serwera i został odrzucony z powodu błędu ALPN.
Uwaga
Dzieje się tak, gdy odbiornik używa biblioteki MsQuic, na przykład za pośrednictwem platformy .NET QuicListener.
Odbiornik kończy się powodzeniem, aby uruchomić protokół IPv6, mimo że jest wyłączony
Pomimo wyłączenia QuicListener.ListenAsync protokołu IPv6 adres IPv6 kończy się powodzeniem. Jest to związane z poprzednim problemem, ponieważ MsQuic wiąże się z adresem wieloznacznymi, a tym samym kończy się powodzeniem. W związku z tym odbiornik jest uruchamiany, ale nie można nawiązać z nim połączenia. Jest to różnica behawioralna od gniazd, które zgłaszają w takim przypadku.
Istnieje wiele sposobów sprawdzania, czy protokół IPv6 jest włączony, na przykład w systemie Linux sprawdź stan modułu IPv6:
cat /sys/module/ipv6/parameters/disable
# 0 - IPv6 is enable
# 1 - IPv6 is disabled
Jak wspomniano powyżej, zachowanie MsQuic tutaj jest zamierzone. Jednak ten konkretny problem może zostać rozwiązany po stronie platformy .NET w przyszłości. Aby uzyskać więcej informacji, zobacz dotnet/runtime#75343.
Nie można uruchomić odbiornika z QUIC_STATUS_ADDRESS_IN_USE powodu błędu
Jest to problem specyficzny dla systemu Windows. Odbiornik zgłasza QuicExceptionQUIC_STATUS_ADDRESS_IN_USE błąd pomimo braku innego procesu uruchomionego na określonym adresie i porcie. Błąd jest spowodowany przez zakres wykluczeń portów zdefiniowany dla tego samego portu co odbiornik próbuje nasłuchiwać. Aby sprawdzić, czy zakresy wykluczeń są uruchamiane:
netsh.exe int ip show excludedportrange protocol=udp
Niepowodzenie próby powiązania z portem, który pochodzi z wykluczonego zakresu, jest oczekiwane. Z tego powodu nie ma natychmiastowych planów rozwiązania tego problemu. Więcej szczegółów można znaleźć w pliku dotnet/runtime#71518.
