System.IO.IOException：由于意外 > 数据包格式，握手失败？答案

【问题标题】：System.IO.IOException: The handshake failed due to an unexpected > packet format?System.IO.IOException：由于意外 > 数据包格式，握手失败？
【发布时间】：2011-07-07 22:01:09
【问题描述】：

有人知道这是什么意思吗？

System.Net.WebException：底层连接已关闭：一个发送时发生意外错误。 ---> System.IO.IOException：握手失败由于意外数据包格式。在 System.Net.Security.SslState.StartReadFrame（字节[] 缓冲区，Int32 读取字节， AsyncProtocolRequest asyncRequest) 在 System.Net.Security.SslState.StartReceiveBlob（字节 [] 缓冲区，AsyncProtocolRequest 异步请求）在 System.Net.Security.SslState.CheckCompletionBeforeNextReceive（协议令牌消息，AsyncProtocolRequest 异步请求）在 System.Net.Security.SslState.StartSendBlob（字节 [] 传入，Int32 计数， AsyncProtocolRequest asyncRequest) 在 System.Net.Security.SslState.ForceAuthentication（布尔值接收第一，字节[]缓冲区， AsyncProtocolRequest asyncRequest) 在 System.Net.Security.SslState.ProcessAuthentication（LazyAsyncResult 懒惰的结果）在 System.Net.TlsStream.CallProcessAuthentication（对象州）在 System.Threading.ExecutionContext.runTryCode（对象用户数据）在 System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup（TryCode 代码，CleanupCode backoutCode，对象用户数据）在 System.Threading.ExecutionContext.RunInternal（ExecutionContext 执行上下文，上下文回调回调，对象状态）在 System.Threading.ExecutionContext.Run（ExecutionContext 执行上下文，上下文回调回调，对象状态）在 System.Net.TlsStream.ProcessAuthentication（LazyAsyncResult 结果）在 System.Net.TlsStream.Write(字节[] 缓冲区，Int32 偏移量，Int32 大小）在 System.Net.PooledStream.Write(字节[] 缓冲区，Int32 偏移量，Int32 大小）在 System.Net.ConnectStream.WriteHeaders（布尔值 async) --- 内部异常结束堆栈跟踪 --- 在 System.Net.HttpWebRequest.GetResponse() 在 System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply（时间跨度超时）在

编辑：

这是我调用的方法：

_productsService = new ProductsPortTypeClient(); _productsService.GetResortProducts(GetProductsCredentials(), GetResortProductParams());

【问题讨论】：

遇到异常时你在做什么？也许您可以发布完整的堆栈跟踪？
只是一个常规的网络服务 - 见编辑
此 Web 服务是否配置为 NTLM/Kerberoes 身份验证？
也许服务定义已更改，您需要刷新对它的引用？
如果您在 uri 中混合了 http 和 https，则可能会出现此问题。这是一个容易犯（和修复）的错误！

标签： c# wcf

【解决方案1】：

看起来是 SSL 身份验证的问题，在握手阶段失败，可能两种实现不兼容，您可以检查响应的 WSDL 格式，确定应该使用哪种格式进行通信并检查是否发送由您遵守（您可以使用任何类型的网络监控软件，例如 Microsoft Network Monitor）

【讨论】：

【解决方案2】：

我只是想根据其中一个 cmets 做一个答案，因为它可能会导致此错误发生。

在某些情况下，如果您在调用API 时有一个BaseURL，那么如果您混淆了http 和https，就会出现问题。这发生在我打电话给谷歌API时。在某些情况下，这是一个简单的解决方法，任何人都可能发生。

希望有人能帮上忙。

【讨论】：

简而言之，尝试通过 HTTPS 访问 HTTP 端点会出现此错误消息。

【解决方案3】：

在我的例子中，是 Skype 阻塞了 443 端口。转到 Skype 工具-高级连接并禁用“使用端口 80 和 443 进行连接...”

【讨论】：

呃，这是一些令人讨厌的 Skype 行为。我数不清有多少次我不得不使用 Skype 进行电话会议并且忘记了我让它一直运行，然后我开始琢磨为什么我正在处理的 Web 服务器应用程序无法启动。

【解决方案4】：

总结：使用了错误的端口。

我的服务在端口：58328 上的开发中运行，但下次我调试它在端口：44315 上运行，这导致了问题。因此，将客户端的端口更改为 44315 有助于解决问题！

【讨论】：