HTTP 主要用于浏览网页。 Coap 是用于 IoT 或 WSN 的 HTTP 的简化版本。虽然 COAP 基于 UDP，但它应该有 ACK 消息来模拟 TCP。由于 COAP 比 HTTP 更简单，因此它具有更低的延迟和更少的功耗。
那么，为什么浏览器和 Web 服务器不使用 COAP 代替 HTTP 呢？鉴于前面的论点，预计 COAP 将完全取代 HTTP 吗？这只是时间问题吗？有没有只有 HTTP 支持的功能？
【问题讨论】：
CoAP 和 HTTP 可用于不同的目的。 CoAP 已针对 IoT 和 M2M 环境实施，即使用 UDP 发送短消息。例如：
一个典型的 CoAP 交换由 2 个消息组成，即一个请求和一个 回复。相比之下，一个 HTTP 请求首先需要客户端建立一个 TCP 连接，然后终止它。这将导致至少 9 条消息仅用于一条 请求 [11]。请注意，对于大型有效负载，此参数不一定正确。后 TCP的慢启动阶段，可以同时发送多个数据包并确认 所有这些都只有一个确认。 CoAP 的分块传输 [8] 但是， 需要对每个块进行确认并导致更多消息和更高 转移时间。由于我们预计大多数 CoAP 消息都相当短，因此 不太重要。然而，CoAP 的分块机制允许一个受约束的 服务器不仅可以接收而且可以逐块处理大型请求。这 如果我们使用 HTTP 和 TCP，这是不可能的。 （物联网云服务的可扩展性，作者：Martin Lanter）
实际上，Firefox 可以通过 Copper(CU) 插件支持 CoAP。 ;)
【讨论】：
CoAP 针对资源受限的网络和IoT 和M2M 应用的典型设备进行了优化。它比 HTTP 使用更少的资源，并且可以为 WSN、IoT 和 M2M 通信中的通信提供环境。它不是用来代替 HTTP 的。
HTTP有不同的应用场景，而CoAP有不同的应用场景。 HTTP 主要是为那些电源和其他限制不是重要问题的 Internet 设备设计的。 HTTP 比 CoAP 更可靠，因为它使用 TCP。
【讨论】：
CoAP 从未打算取代 HTTP，虽然它似乎“模仿”了 http，但这只是因为它遵循 RESTful 范式。 CoAP 旨在作为设备的应用层，更具体地说，是为约束设备设计的。
选择 RESTful 设计也是为了便于通过 http 进行代理操作（在 RFC 中有这样做的建议）。但同样从未打算取代 HTTP。
CoAP 在构建时考虑到了少量资源。 CoAP 的小头和不同的特性已经到位，以确保约束设备具有标准的互联网通信方式。
HTTP 和 CoAP 各有各的用途。
【讨论】：
如果coap效率更高，我能说以后如果我们把它们换成coap，http就没有用了吗？
行业计划是通过迁移到 HTTP/2 来改进 HTTP，并且 HTTP/2 包括（以及其他功能）标头压缩，它应该为您带来与 CoAP 类似的好处。
虽然当今大多数 Web 服务器和一些浏览器已经支持 HTTP/2，但 AFAIK 没有浏览器也没有任何服务器支持 CoAP。 TLS 与 DTLS 也是如此。
是否有 coap 不支持但 http 可以的功能？
如您所说，HTTP 是基于 TCP 的，而 CoAP 是基于 UDP 的。 UDP 要求您每隔几秒发送一次 UDP ping 以保持 NAT/防火墙连接打开，而在 TCP 中通常只需要每 15 分钟左右一次。 因此，如果您需要保持连接打开（例如对于推送技术），那么 CoAP 的效率低于 HTTP（和 HTTP/2）。
【讨论】：