Поделиться через


Проверка трассировок сети для обмена метаданными 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