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