我现在正在使用 Web 服务。我们有两种类型的服务，一种通过 HTTP，另一种通过 TCP。当试图了解这两者之间的区别时，根据我的理解，基于 TCP 的服务在传输层工作，即它们通过两端传输数据。因此，在这种情况下，基于 TCP 的服务将直接在两端之间传输数据。但是我对 HTTP 上的服务不是很清楚。我知道我们有一个客户端服务器模型，REST、SOAP 和 HTTP 是传输数据的协议，但我无法通过 HTTP 正确关联服务的概念！
谁能帮忙解释一下两者之间的区别？
【问题讨论】：
标签： web-services http tcp
正如你所问，我会尽量类比解释，同时不会过多地重复之前的答案。
假设我们有可以通过电话 (TCP) 和短信 (HTTP) 访问的帮助台（服务）。从您（应用程序）的角度来看，无论您选择哪种通信方式，您都应该获得相同的信息。但是这种通信的方式会有所不同，因为电话 (TCP) 是 statefull 通道，而 SMS (HTTP) 是 stateless：
要将 state 引入 SMS 通道，需要在帮助台级别执行其他步骤，例如，您将获得票号，您必须将其与每个相关的 SMS（HTTP cookie/会话）一起发送- 这不会被 GSM 网络自动处理。此状态由帮助台和您的（服务和应用程序）逻辑处理。
两种服务类型各有优缺点。两者都应该有效 - 偏好取决于实际用例。
使用什么方式交换数据没有太大区别（如果延迟可以接受，您甚至可以使用邮局交换邮件）。在实践中，这意味着您可以使用ping (ICMP) 或 DNS 查询或电子邮件来交换数据 - 只要您的应用程序知道如何使用/解码此类通道。
我认为John Saunders in his answer指的是7 layer OSI model，我认为他的观点是正确的。
这个类比不是 100% 正确，我试图解释这个想法：不同之处在于 状态 是如何保存的（通过协议本身，或通过应用程序/框架）。
【讨论】：
在使用 TCP/IP 和在其之上分层的协议时，我会选择 7 层模型和一粒盐。真实的层数会有所不同，与经典的 OSI 模型不匹配。
例如，HTTP 建立在 TELNET 协议之上，该协议位于 TCP 之上。这是否使 TELNET 成为表示层协议？不，它是一个应用层协议，恰好在其之上构建了另一个应用层协议。
然后我们通过 HTTP 运行 SOAP。或者，如果我们愿意，我们可以通过 TCP/IP 运行 SOAP。那么SOAP是哪一层呢？是第 8 层还是第 9 层？
【讨论】：
正如 John Saunders 试图暗示的那样，我同意理解这些协议提供的抽象比在某些模型 (OSI) 中可能调用它们的特定“层”更重要。虽然通用模型有所帮助和适用，但它并未提供实际协议的具体细节。
话虽如此，使用TCP 的所谓传输层服务 与使用HTTP 的应用层服务 之间的区别，恕我直言，可以归结为@ 之间的比较987654326@ 和 HTTP 本身。
我会开始说，我希望任何对这些协议稍有了解的人都知道HTTP 比TCP 更高级别的抽象，实际上它依赖于TCP/IP 本身。因此HTTP 显然继承了TCP/IP 的可靠性等某些 特性。
现在对比-
TCP 服务
设计你自己的应用层协议 - 你设计你自己的应用层协议。例如，客户将如何请求操作来添加一个员工？客户将如何请求找到给定的员工？等等... 您如何指示客户端和服务器之间可以交换数据的格式？您如何区分元数据（如请求信息）和数据？
效率 - 可以高效且紧凑地传输数据。由于您定义了自己的应用层协议，因此可以是任何东西，从二进制到字符串再到 XML 再到您梦寐以求的任何东西。
例如，HTTP 是建立在TCP 之上的，用外行的话来说，主要使用键值对样式请求headers.. vs SOAP，其中传递了很多信息作为消息信封和消息正文（这就是为什么SOAP可以超过HTTP以及其他协议如Message Queues）
性能 - 考虑到拥有非常紧凑的应用层协议的可能性，它也可以相对较快。对于真正的高吞吐量、高性能、延迟敏感的 Intranet 应用程序，这可能是一个决定因素。
开发工作 - 除了灵活性之外，您肯定会在尝试定义和实现自己的应用层协议时编写更多代码。
HTTP 服务
为您定义了更大的应用程序协议部分 - 您通过定义明确的 HTTP 协议设计应用程序。通常HTTP Get 表示查询资源。请求 url 中的查询过滤器可用于搜索。 HTTP POST, PUT and DELETE 同样具有特定的、明确定义的语义。
错误/故障处理 - 使用HTTP 协议中定义的标准来指示错误。例如状态代码200（成功）与400（错误请求）。
效率 - 可能非常冗长。协议几乎定义了必须如何定义请求的所有方面......并且通常是基于文本的......
开发和工具支持 - HTTP 可以更轻松地使用现有的各种工具来发送、接收和调试请求（Fiddler 或 Charles Proxy 是著名的HTTP调试工具）。
互联网/防火墙友好 - HTTP 通常用于端口 80（尽管理论上也可以是其他端口）。这使得它不仅更适合 Intranet 应用程序，您可以在这些应用程序中更好地控制您打开的防火墙和端口......而且还适合通过 Internet 访问这些服务，因为端口 80 通常在几乎世界上的机器......
多个服务的共存 - HTTP 使用如此广泛，以至于在给定的机器上预计会有多个应用程序/服务使用它。操作系统通常有特殊的支持内置在操作系统中以处理此问题（Windows 上的http.sys），您不必担心一个应用程序/服务会因意外使用相同的端口而踩到另一个应用程序/服务（在这种情况下一个会失败）。在这种情况下，客户端和服务器之间的端口协商通常不是问题，因为 HTTP 预计位于端口 80。
保护通信渠道 - 在保护通信安全方面，同样有明确定义的方法来建立相同的......即HTTPS。与基于TCP/IP 的服务不同，您不必发明自己的方案来加密客户端和服务器之间的通信。
托管服务 - 理论上，托管HTTP 服务的方法比托管TCP 服务的方法多，这也是因为HTTP Web 应用程序已经成为常见的场景，像 IIS 这样的 Web 服务器已经满足了。您的HTTP 服务可以利用像IIS 这样的网络服务器已经拥有的无数开箱即用的功能。回收、身份验证、资源管理、请求过滤、缓存、动态压缩和日志记录等等等。等等。免费使用托管在任何成熟网络服务器产品上的HTTP 服务。
跨平台/技术堆栈的互操作性 - 使用HTTP，混合使用任何技术堆栈会容易得多，因为通常会支持协议的实施在各种平台上......从Linux / Unix 到Windows.. 或从.Net 到Java 到Ruby.. 您将从这些平台上支持的现有工具和技术中受益HTTP.. 因此，Http 可能是事实上的选择，例如，如果您希望服务器位于 Windows 上的 .Net 中，但客户端位于 Java 上的 Java 中。
我可以继续.. 这绝不是一个详尽的列表，我相信许多其他人可以在此添加更多内容.. 但希望这能让您对您正在寻找的内容有一个好主意.. 一个可以清楚地看到，这可能是一个非常深奥的话题。根据您的回复和时间，我可能会在将来编辑此答案。或鼓励其他人在他们认为合适的情况下对其进行更新。
旁注 - 有趣的是，尽管 HTTP 比 TCP/IP 增加了很多，使其成为应用程序协议的绝佳且无处不在的选择。. 总是有更多的余地/ 更高级别的抽象.. 如此之多，以至于还有其他更新的服务协议，它们建立在HTTP 之上。例如 - Odata。有兴趣的可以看看OData..
当然，在当今的服务世界中，如果不提及 REST，讨论将是不完整的。
编辑：另一个有趣的附注 - 如果您在 Windows 平台上构建，并使用 .Net 框架，则有像 Windows Communication Foundation aka WCF 这样的框架，它们试图提供这样的抽象，您可以交换您选择的通信协议（客户端和服务器选择必须仍然匹配），从 HTTP 到 TCP 到 MSMQ 到 IPC 等，只需更改配置或托管相同的服务通过创建多个端点来跨越多个通信协议。有关WCF 提供的各种开箱即用选项的高级概述和比较，请参阅Understanding various types of WCF bindings。
【讨论】：