Устранение неполадок QUIC в .NET
В этой статье вы узнаете, как диагностировать наиболее распространенные проблемы с QUIC в .NET.
Библиотека System.Net.Quic основана на реализации MsQuic открытый код QUIC. Из-за этого поведение отличается от обычных сокетов, иногда по дизайну. Кроме того, он основан на протоколе UDP, и он не предоставляет точно такой же интерфейс, как и с TCP.
Прослушиватель работает, но не получает никаких данных
Если прослушиватель работает, но никогда не получает данные, это может быть вызвано другим процессом прослушивания на том же порту. Чтобы проверить, какой процесс используется, какой порт выполняется:
sudo ss -tulpw
Это поведение выполняется путем проектирования, так как MsQuic используется SO_REUSEPORT для повышения производительности. Дополнительные сведения см . в документации listenerStart и исходной проблеме dotnet/runtime#59382.
Примечание.
Эта проблема не возникает в Windows, где MsQuic попытается выполнить резервирование портов. Это приводит к тому, что приложение пытается открыть второй прослушиватель на том же порту не удается запустить.
QuicListener всегда прослушивает любой адрес
Даже если определенный адрес предоставляется через ListenEndpoint свойство, QuicListener по-прежнему открывает дикий дикий стек с двойным стеком карта сокет. Это поведение выполняется по MsQuicпроектированию. IP-адрес прослушивания по-прежнему используется для фильтрации внутри MsQuic. Дополнительные сведения см . в документации listenerStart и исходной проблеме [dotnet/runtime#92812].
Клиент получает непредвиденная ошибка ALPN
Клиент пытается подключиться, но получает Application layer protocol negotiation error was encountered , несмотря на использование того же ALPN, что и сервер.
То, что происходит, прослушиватель всегда привязывается к дикому режиму с двумя режимами карта адрес независимо от указанного приложения. Затем он соответствует входящим подключениям по IP-адресу и ALPN. Если совпадение не найдено, он сообщает об ошибке, указанной выше упоминание. В результате несоответствие между IP-адресом прослушивания и подключением приведет к ошибке ALPN.
Чтобы избежать этой ошибки, убедитесь, что вы подключаетесь к тому же адресу, для которого был запущен прослушиватель. Например, распечатайте адрес прослушивателя:
await using var listener = QuicListener.ListenAsync(new() /* appropriate options */);
Console.WriteLine(listener.LocalEndPoint);
Эта проблема может возникнуть в нескольких различных сценариях, например в этой проблеме dotnet/runtime#85412. Сервер был запущен для Loopback адреса (127.0.0.1), и все работало при запуске на одном компьютере. Но когда клиент пытался подключиться из другого, адрес не будет соответствовать адресу обратного цикла сервера и был отклонен с ошибкой ALPN.
Примечание.
Это происходит, когда прослушиватель использует MsQuic, например через .NET QuicListener.
Прослушиватель успешно запускается для IPv6, несмотря на его отключение
Несмотря на отключение IPv6, QuicListener.ListenAsync выполняется успешно с IPv6-адресом. Это связано с предыдущей проблемой, так как MsQuic привязка к диким карта адрес и, таким образом, успешно выполняет это. В результате прослушиватель запускается, но подключение к нему не может быть выполнено. Это различие поведения от сокетов, которые вызывают в таком случае.
Существует множество способов проверка, если IPv6 включен, например в Linux проверка состояние модуля IPv6:
cat /sys/module/ipv6/parameters/disable
# 0 - IPv6 is enable
# 1 - IPv6 is disabled
Как упоминалось выше, поведение MsQuic здесь намеренно. Однако эта конкретная проблема может быть устранена на стороне .NET в будущем. Дополнительные сведения см. в разделе dotnet/runtime#75343.
Прослушиватель не может начаться с QUIC_STATUS_ADDRESS_IN_USE ошибки
Это конкретная проблема с Windows. Прослушиватель вызывает QuicException ошибку, QUIC_STATUS_ADDRESS_IN_USE несмотря на отсутствие других процессов, выполняемых на определенном адресе и порту. Ошибка вызвана диапазоном исключений портов, определенным для того же порта, что и прослушиватель пытается прослушивать. Чтобы проверка для диапазонов исключений, выполните следующие действия:
netsh.exe int ip show excludedportrange protocol=udp
Сбой при попытке привязаться к порту, который является из исключенного диапазона, является ожидаемым поведением. По этой причине нет немедленных планов по устранению этой проблемы. Дополнительные сведения можно найти в dotnet/runtime#71518.
