Проверка трассировок сети для обмена метаданными HTTP

  • Статья

Для проверки запросов на обмен метаданными HTTP можно использовать любой анализатор сетевых пакетов, который может отображать необработанные пакеты. Рекомендуется Microsoft Network Monitor 3 (Netmon). Дополнительные сведения о Netmon см. в разделах Скачивание Netmon и Примеры фильтров DPWS.

Эта диагностическая процедура может оказаться не столь полезной для клиентов и узлов, использующих безопасный канал для обмена данными, так как содержимое сообщения зашифровано.

Проверка трассировок сети для обмена метаданными HTTP

  1. Настройте узел и клиент для работы по сети (то есть убедитесь, что узел и клиент будут работать на разных компьютерах).

  2. Установите анализатор пакетов (Netmon) на клиенте или узле.

  3. Настройте анализатор пакетов для записи трафика на сетевом адаптере, соединяющем узел и клиент.

  4. Воспроизведите ошибку, запустив узел и клиент или нажав клавишу F5 в Обозреватель сети.

  5. Отфильтруйте результаты, чтобы изолировать трафик обмена WS-Discovery и метаданными. Чтобы просмотреть примеры фильтров Netmon, см. статьи Скачивание Netmon и Примеры фильтров DPWS.

    Примечание

    Это необязательный шаг.

     

  6. Убедитесь, что сообщения, передаваемые между клиентом и узлом, соответствуют основным требованиям к трафику.

Проверка соответствия сообщений требованиям к трафику

Клиенты и узлы WSDAPI должны отправлять сообщения, соответствующие следующим критериям. Общие сведения о шаблонах сообщений см. в разделе Шаблоны сообщений обнаружения и обмена метаданными.

  • Сообщения должны соответствовать требованиям к трафику, приведенным в разделе Проверка трассировок сети для UDP WS-Discovery, если нет абсолютной уверенности в том, что WS-Discovery не используется для обмена метаданными.

  • Необходимо установить TCP-подключение между клиентом и первым транспортным адресом, указанным в элементе XAddrs сообщения ProbeMatches или ResolveMatches . В следующем списке показан типичный обмен пакетами, используемый для установления TCP-подключения.

    • Клиент отправляет пакет TCP SYN на узел через указанный порт.
    • Узел отправляет клиенту пакет TCP SYN/ACK.
    • Клиент отправляет пакет TCP ACK на узел через указанный порт.

    После отправки клиентом пакета TCP ACK устанавливается TCP-подключение. Обратите внимание, что этот обмен сообщениями не будет происходить, если ранее было установлено TCP-подключение.

  • Клиент должен отправить действительный HTTP-запрос и сообщение Get .

  • Узел должен прослушивать URL-путь, указанный в HTTP-запросе Get .

  • Элемент To сообщения Get metadata должен присутствовать, а не пустой. Значение элемента To должно соответствовать одному из адресов конечной точки узла. Адрес конечной точки узла обычно объявляется в сообщении ProbeMatches или ResolveMatches .

  • Узел должен отправить допустимый заголовок HTTP-ответа. Если первоначальный запрос был выполнен успешно, заголовок ответа должен содержать код состояния HTTP/1.1 200.

  • Узел должен отправить допустимое сообщение GetResponse .

  • Элемент RelatesTo сообщения GetResponse должен присутствовать и не должен быть пустым. Его значение должно соответствовать значению элемента MessageId из соответствующего сообщения Get .

Если http-запросы или сообщения обмена метаданными, отправленные программой, не соответствуют этим требованиям к трафику, причина проблемы успешно определена и дальнейшие действия по устранению неполадок не нужны. Перепишите программу таким образом, чтобы она создавала соответствующие сообщения и запросы, и повторно протестируйте программу.

Если источник проблемы по-прежнему не удается определить, обратитесь за помощью в службу поддержки Майкрософт. Прежде чем обращаться в службу поддержки, соберите соответствующие файлы журналов, чтобы определить первопричину проблемы. Дополнительные сведения см. в разделе Включение трассировки WSDAPI.

Диагностические процедуры WSDAPI

начало работы с устранением неполадок WSDAPI

Скачивание Netmon и примеров фильтров DPWS