HTTP wird hauptsächlich zum Anzeigen von Webseiten verwendet. Coap ist eine vereinfachte Version von HTTP für IoT oder WSNs. Obwohl COAP auf UDP basiert, sollte es ACK-Nachrichten zum Emulieren von TCP haben. Da COAP einfacher als HTTP ist, wird es eine geringere Latenz haben und weniger Strom verbrauchen Warum ersetzen Browser und Webserver HTTP nicht durch COAP? Wird erwartet, dass COAP das HTTP vollständig ersetzen wird? Ist es nur eine Frage der Zeit? Gibt es irgendwelche Funktionen, die nur von HTTP unterstützt werden?
Wenn coap effizienter ist, kann ich sagen, dass http in der Zukunft nutzlos ist, wenn wir sie durch coap ersetzen?
Der Branchenplan sieht vor, HTTP durch die Umstellung auf HTTP / 2 zu verbessern, und HTTP / 2 enthält (neben anderen Funktionen) eine Header-Komprimierung, die Ihnen ähnliche Vorteile bietet wie CoAP.
Während die meisten Webserver und einige Browser heute HTTP / 2 bereits unterstützen, unterstützt AFAIK kein Browser und kein Server CoAP. Das gleiche gilt für TLS vs. DTLS.
Gibt es Features, die Coap nicht unterstützen kann, aber http?
Wie Sie gesagt haben, ist HTTP TCP-basiert, während CoAP UDP-basiert ist. UDP erfordert, dass Sie alle paar Sekunden UDP-Pings senden, um die NAT / Firewall-Verbindung offen zu halten, während TCP in der Regel nur alle 15 Minuten benötigt wird. Wenn Sie also die Verbindung offen halten müssen (z. B. für Push-Technologien), ist CoAP weniger effizient als HTTP (und HTTP / 2).
CoAP war nie dazu gedacht, HTTP zu ersetzen, während es scheint, HTTP zu "emulieren", nur weil es dem REStful Paradigma folgt. CoAP ist als Anwendungsschicht für das Gerät und insbesondere für das Constraint-Gerät vorgesehen.
Das REStful-Design wurde auch gewählt, um die Proxy-Operation durch http zu erleichtern (es gibt eine Empfehlung, dies im RFC zu tun). Aber wieder war nie beabsichtigt, HTTP zu ersetzen.
CoAP ist mit wenig Ressourcen aufgebaut. Der kleine Header und die verschiedenen Funktionen von CoAP sorgen dafür, dass Constraint-Geräte über Standards verfügen, um im Internet zu kommunizieren.
HTTP und CoAP haben jeweils ihren eigenen Zweck.
CoAP ist optimiert für ressourcenbeschränkte Netzwerke und Geräte, die typisch für IoT und M2M Anwendungen sind. Es verwendet weniger Ressourcen als HTTP und kann eine Umgebung für die Kommunikation in WSNs, IoTs und M2M-Comm bereitstellen. Es ersetzt HTTP nicht.
HTTP hat verschiedene Anwendungsszenarien, während CoAP ein anderes hat. HTTP ist hauptsächlich für Internet-Geräte gedacht, bei denen die Stromversorgung und andere Einschränkungen keine wichtigen Probleme darstellen. HTTP ist zuverlässiger als CoAP, da TCP verwendet wird.
CoAP und HTTP können für verschiedene Zwecke verwendet werden. CoAP wurde für die IoT- und M2M-Umgebung implementiert, mit anderen Worten, um kurze Nachrichten mit UDP zu senden. Zum Beispiel:
Ein typischer CoAP-Austausch besteht aus zwei Nachrichten, d. h. einer Anfrage und einem Antwort. Im Gegensatz dazu erfordert eine HTTP-Anforderung zunächst, dass der Client ein TCP erstellt Verbindung und später beenden Sie es. Dies führt zu mindestens 9 Nachrichten für nur einen Anfrage [11]. Beachten Sie, dass dieses Argument nicht unbedingt für große Nutzlasten gilt. Nach TCP's Slow-Start-Phase, kann es mehrere Pakete gleichzeitig senden und bestätigen alle mit einer einzigen Bestätigung. CoAPs blockweise Übertragung [8] obwohl, erfordert eine Bestätigung für jeden Block und führt zu mehr Nachrichten und höher Transferzeit. Da wir erwarten, dass die Mehrzahl der CoAP-Nachrichten eher kurz ausfallen wird ist von geringerer Bedeutung. Der blockweise Mechanismus von CoAP erlaubt jedoch eine Einschränkung Server, um eine große Anfrage nicht nur zu empfangen, sondern auch blockweise zu verarbeiten. Dies wäre nicht möglich, wenn wir HTTP und TCP verwendet hätten. ( Skalierbarkeit für IoT CLoud Services von Martin Lanter)
Tatsächlich kann Firefox CoAP mit dem Plug-in Copper (CU) unterstützen. ;)