基於 TCP 的基本綁定的 WCF 如何不可靠？

Question

由於我的介紹很糟糕，使人們感到困惑，因此我正在編輯問題並刪除我之前所做的介紹。

現在，這是我現在擔心的商業案例。 C#偽代碼：

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

我很困惑，因為 WSBinding 的存在是可靠的，而 basicHTTPBinding 不是。 我知道具有可靠會話的 WSBinding 可以保證交付、訂單、內容被加密等。但是在我用偽代碼描述的情況下，根據我的觀點，即使使用 basicHttpBinding 和基於 TCP 的 HTTPS，我也支持所有這些。 TCP 為我提供可靠性、順序保證和 HTTPS 加密。

2. (1. 被刪除) 我和以前的有關系嗎？ 或者換個說法：是否有一個例子表明 basicHttpBindind 在指定條件下無法提供與具有可靠會話的 WS 綁定相同的功能？

3. 我的業務案例要求按照發出的順序接受 WCF 調用。 如果我在 foreach 循環中從客戶端同步發送它們（如偽代碼所示），我假設服務器上的順序是有保證的，無論它們是否在一個 TCP 連接內發送，因為我正在等待響應，然后我發送另一個請求。 這里即使是負載均衡器也無法將消息打亂，因為沒有並行化，消息是一條一條同步發送的。 我認為只有在我發送消息而不等待響應的情況下才會發生混亂，並且我使用不同的 TCP 連接。 那么，我在這里嗎？ :)

Answer 1

可靠性一詞有不同的含義，解釋也取決於上下文。 您在問題中對可靠性的解釋是消息已傳遞。 您引用的來源中可靠性的解釋是消息只傳遞一次。 您的困惑來自於采用“HTTP 不可靠”這一陳述，該陳述是對可靠性的一種解釋，並在您對可靠性的不同解釋中使用它。

HTTP 不能保證消息只被傳遞一次，它最多可以保證消息至少被傳遞一次。 在發送請求或接收響應時，底層 TCP 連接可能會中斷。 在這種情況下，客戶端可能會忽略問題或重試，這可能會導致沒有消息傳遞（在發送請求時忽略錯誤），但也會多次傳遞相同的消息（如果在響應期間連接中斷，則重試）。 通過重試直到成功收到響應，可以保證至少收到一次消息，這是您對可靠性的解釋，而不是您引用的聲明中的解釋。