Http 通过TCP进行基本绑定的WCF如何不可靠？

因为我的介绍不好，让人困惑，所以我正在编辑这个问题，删除我之前的介绍

现在，这是我现在关注的商业案例。C#伪代码：

 Array.ForEach(files, filename =>
                    {
                        try
                        {
                           WcfServiceClient wcfClient = new WcfServiceClient();
                           wcfClient.SomeMethodWhichPostsFile(filename);
                        }
                        catch (Exception ex)
                        {
                            LogException(ex)
                        }
                    }
                );

我感到困惑是因为WSBinding的存在是可靠的，而basicHTTPBinding则不是。我知道使用可靠会话的WSBinding可以保证交付、订单、内容加密等。但在我用伪代码描述的情况下，根据我的观点，即使使用BasichtpBinding和TCP上的HTTPS，我也支持所有这些。TCP为我提供了可靠性、订单保证和HTTPS加密

（1.被删除）我与以前的关系是否正确？或者换一句话：是否有一个例子表明，在特定条件下，basicHttpBindind不能提供与具有可靠会话的WS-binding相同的功能

我的业务案例要求按照WCF呼叫的发出顺序接受WCF呼叫。如果我在foreach循环中从客户机同步发送它们（如伪代码所示），那么我假设服务器上的顺序是有保证的，无论它们是否在一个TCP连接中发送，因为我正在等待响应，然后发送另一个请求。即使loadbalancer在这里也不能对消息进行无序处理，因为没有并行化，消息是一个接一个地同步发送的。 我假设只有在我发送消息而不等待响应的情况下，才会发生混乱，并且我使用不同的TCP连接。 那么，我就在这里吗？：）

---

可靠性一词有不同的含义，解释也取决于上下文。您在问题中对可靠性的解释是信息已传递。相反，您引用的来源中对可靠性的解释是，消息只传递一次。您的困惑来自于将“HTTP不可靠”这句话用于可靠性的一种解释，并在您对可靠性的不同解释中使用它

---

HTTP不能保证消息只传递一次，它最多只能保证消息至少传递一次。在发送请求或接收响应时，底层TCP连接可能会中断。在这种情况下，客户端可能会忽略问题或重试，这可能会导致没有传递消息（发送请求时忽略错误），但也会多次传递相同的消息（如果响应期间连接中断，则重试）。通过重试直到成功接收到响应，可以保证消息至少收到一次，这是您对可靠性的解释，而不是您引用的声明中的解释。

“可以在许多站点发现HTTP不可靠。”-这是一个没有来源的声明。请引用相关来源，确保他们对可靠手段的理解与您的理解相符，并解释这种理解是什么。因为，可靠可能意味着许多不同的事情。例如：“可靠消息传递是指确保发送应用程序发送的消息确实在另一端接收，并且只接收一次。对REST最常见的反对意见之一是REST不提供可靠消息传递。”-不管怎样，可能我的问题是错误的，但这只是对所描述案例的介绍，而不是问题的重点。我问题的重点是，有人确认或否认我对项目1、2和3的理解，我也理解为什么TCP提供WS-Reliability。我感谢您的帮助，这篇文章也起到了帮助作用。通过阅读你的答案，我发现了另一个问题，它的表述比我的好，但本质相同。我将把那个问题的答案标记为这个问题的答案。我对你的答案投了赞成票，很抱歉你对我的问题投了反对票，因为我的介绍不好。引用其他网站并不是关键。我现在认为我的假设2是错误的，但如果能得到你对2的意见，那就太好了。米洛什：回答问题的重要信息应该是问题的一部分，而不是评论。我的否决票被系统锁定，直到你真正编辑问题而不是只添加评论。至于2.+3.：不清楚您对可靠性的实际要求是什么，因此无法回答。考虑到您的代码，它不会提供一次完全交付。它甚至不提供至少一次传递，因为您只对每个请求进行一次尝试，并且忽略在传递过程中TCP连接中断时可能发生的任何故障。