{"id":38375,"date":"2019-10-31T22:23:21","date_gmt":"2019-10-31T19:23:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\/"},"modified":"2019-10-31T22:23:21","modified_gmt":"2019-10-31T19:23:21","slug":"iot-tuman-i-oblaka-pogovorim-pro-tehnologii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","title":{"rendered":"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?\" src=\"\/wp-content\/uploads\/2019\/09\/89eae3426589d2ed8041fd6dd26498cb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>El desarrollo de tecnolog\u00edas en software y hardware, junto con la aparici\u00f3n de nuevos protocolos de comunicaci\u00f3n, ha llevado a la expansi\u00f3n del Internet de las Cosas (IoT). La cantidad de dispositivos crece d\u00eda a d\u00eda, generando un enorme volumen de datos. Por lo tanto, surge la necesidad de una arquitectura de sistema que pueda procesar, almacenar y transmitir estos datos de manera eficiente.<\/p>\n<p>En la actualidad, se utilizan servicios en la nube para estos fines. Sin embargo, la cada vez m\u00e1s popular paradigma de la computaci\u00f3n en la niebla (Fog) puede complementar las soluciones en la nube, escalando y optimizando la infraestructura de IoT. <\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Las 'nubes' pueden satisfacer la mayor\u00eda de las demandas de IoT. Por ejemplo, pueden proporcionar monitoreo de servicios, procesamiento r\u00e1pido de cualquier volumen de datos generados por los dispositivos, as\u00ed como su visualizaci\u00f3n. Por otro lado, la computaci\u00f3n en la niebla es m\u00e1s efectiva para resolver problemas en tiempo real. Proporciona una respuesta r\u00e1pida a las solicitudes y una m\u00ednima latencia en el procesamiento de datos. Es decir, Fog complementa a las 'nubes', ampliando sus capacidades.<\/p>\n<p>Sin embargo, la pregunta principal es: \u00bfc\u00f3mo debe interactuar todo esto en el contexto de IoT? \u00bfCu\u00e1les protocolos de comunicaci\u00f3n ser\u00e1n los m\u00e1s efectivos en un sistema integrado IoT-Fog-Cloud?<\/p>\n<p>A pesar del aparente dominio de HTTP, se utilizan muchas otras soluciones en los sistemas IoT, Fog y Cloud. Esto se debe a que IoT debe combinar las funcionalidades de diversos sensores de dispositivos con la seguridad, compatibilidad y otros requisitos que exigen los usuarios.<\/p>\n<p>Sin embargo, no hay un consenso sobre una arquitectura de referencia y un est\u00e1ndar de comunicaci\u00f3n. Por lo tanto, la creaci\u00f3n de un nuevo protocolo o la modificaci\u00f3n de uno existente para tareas espec\u00edficas de IoT es una de las tareas m\u00e1s importantes que enfrenta la comunidad de TI.<\/p>\n<p>\u00bfQu\u00e9 protocolos se utilizan actualmente y qu\u00e9 pueden ofrecer? Vamos a profundizar. Pero primero, discutamos los principios de la ecosistema en el que interact\u00faan las nubes, la niebla y el Internet de las cosas.<\/p>\n<h3>Arquitectura IoT Fog-to-Cloud (F2C)<\/h3>\n<p>\nSeguramente has notado los significativos esfuerzos que se realizan para estudiar las ventajas y beneficios asociados con la gesti\u00f3n racional y coordinada de IoT, las nubes y la niebla. Si no, aqu\u00ed tienes tres iniciativas de estandarizaci\u00f3n: <noindex><a rel=\"nofollow\" href=\"https:\/\/www.openfogconsortium.org\/\">OpenFog Consortium<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"http:\/\/en.ecconsortium.org\/Uploads\/file\/20180328\/1522232376480704.pdf\">Edge Computing Consortium<\/a><\/noindex> y <noindex><a rel=\"nofollow\" href=\"http:\/\/www.mf2c-project.eu\/\">mF2C H2020 EU project<\/a><\/noindex>. <\/p>\n<p>Si antes solo se consideraban dos niveles, la nube y los dispositivos finales, la arquitectura propuesta introduce un nuevo nivel: la computaci\u00f3n en la niebla. Este nivel de niebla puede dividirse en varios subniveles, dependiendo de la especificidad de los recursos o del conjunto de pol\u00edticas que determinan el uso de diferentes dispositivos en estos subniveles.<\/p>\n<p>\u00bfC\u00f3mo podr\u00eda lucir esta abstracci\u00f3n? Aqu\u00ed hay un ecosistema t\u00edpico de IoT-Niebla-Nube. Los dispositivos IoT env\u00edan datos a servidores y dispositivos de c\u00f3mputo m\u00e1s potentes para resolver tareas que requieren un bajo nivel de latencia. En este sistema, las nubes son responsables de resolver tareas que requieren una gran cantidad de recursos computacionales o espacio de almacenamiento de datos.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?\" src=\"\/wp-content\/uploads\/2019\/09\/c78ea915ac4743a3def5651778e77873.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos smartphones, los relojes inteligentes y otros dispositivos tambi\u00e9n pueden ser parte del IoT. Sin embargo, tales dispositivos generalmente utilizan protocolos de comunicaci\u00f3n propietarios de grandes desarrolladores. Los datos generados por Internet de las cosas se transfieren al nivel de niebla a trav\u00e9s del protocolo REST HTTP, que garantiza flexibilidad y compatibilidad funcional al crear servicios RESTful. Esto es importante en vista de la necesidad de asegurar la compatibilidad con la infraestructura de computaci\u00f3n existente que opera en computadoras locales, servidores o conjuntos de servidores. Los recursos locales, conocidos como 'nodos de niebla', filtran los datos recibidos y los procesan localmente o los env\u00edan a la nube para su procesamiento adicional.<\/p>\n<p>Las nubes admiten diferentes protocolos de comunicaci\u00f3n, entre los que se encuentran AMQP y REST HTTP. Dado que HTTP es bien conocido y est\u00e1 dise\u00f1ado para internet, podr\u00eda surgir la pregunta: '\u00bfPor qu\u00e9 no utilizarlo para trabajar con IoT y la niebla?'. Sin embargo, este protocolo tiene problemas de rendimiento. Hablaremos de eso m\u00e1s adelante.<\/p>\n<p>En general, existen 2 modelos de protocolos de comunicaci\u00f3n adecuados para nuestro sistema. Estos son la solicitud-respuesta y la publicaci\u00f3n-suscripci\u00f3n. El primer modelo es m\u00e1s conocido, especialmente en la arquitectura cliente-servidor. El cliente solicita informaci\u00f3n del servidor, que recibe la solicitud, la procesa y devuelve un mensaje de respuesta. Los protocolos REST HTTP y CoAP operan bajo este modelo.<\/p>\n<p>El segundo modelo surgi\u00f3 de la necesidad de proporcionar una comunicaci\u00f3n as\u00edncrona, distribuida y d\u00e9bil entre las fuentes que generan datos y los receptores de esos datos.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?\" src=\"\/wp-content\/uploads\/2019\/09\/acf3b411fb9a0b7a61cf0188e4c29292.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nEl modelo prev\u00e9 tres participantes: el publicador (fuente de datos), el corredor (gestor) y el suscriptor (receptor). Aqu\u00ed, el cliente, que act\u00faa como suscriptor, no debe solicitar informaci\u00f3n del servidor. En lugar de enviar solicitudes, se suscribe a ciertos eventos en el sistema a trav\u00e9s del corredor, que es responsable de filtrar todos los mensajes entrantes y su enrutamiento entre publicadores y suscriptores. Y el publicador, cuando ocurre un evento relacionado con un tema espec\u00edfico, lo publica al corredor, quien env\u00eda los datos al suscriptor sobre el tema solicitado.<\/p>\n<p>Este modelo est\u00e1 esencialmente basado en eventos. Y esta forma de interacci\u00f3n es interesante para aplicaciones en IoT, en la nube y en la niebla debido a su capacidad para asegurar escalabilidad y facilitar la interconexi\u00f3n entre diferentes dispositivos, manteniendo una comunicaci\u00f3n din\u00e1mica de \u00abmuchos a muchos\u00bb y comunicaci\u00f3n as\u00edncrona. Algunos de los protocolos de mensajer\u00eda estandarizados m\u00e1s conocidos que utilizan el modelo de \u00abpublicaci\u00f3n-suscripci\u00f3n\u00bb son MQTT, AMQP y DDS.<\/p>\n<p>Es evidente que el modelo de \u00abpublicaci\u00f3n-suscripci\u00f3n\u00bb tiene muchas ventajas:<\/p>\n<ul>\n<li>Los publicadores y suscriptores no necesitan conocer la existencia del otro;<\/li>\n<li>Un suscriptor puede recibir informaci\u00f3n de muchas publicaciones diferentes, y un publicador puede enviar datos a muchos suscriptores diferentes (principio de \u00abmuchos a muchos\u00bb);<\/li>\n<li>El publicador y el suscriptor no tienen que estar activos al mismo tiempo para intercambiar datos, porque el corredor (que act\u00faa como sistema de colas) puede almacenar el mensaje para los clientes que en ese momento no est\u00e1n conectados a la red.<\/li>\n<\/ul>\n<p>\nSin embargo, el modelo de \u00absolicitud-respuesta\u00bb tambi\u00e9n tiene sus puntos fuertes. En aquellos casos donde la capacidad del lado del servidor para procesar solicitudes de m\u00faltiples clientes no es un problema, vale la pena utilizar soluciones ya probadas y fiables.<\/p>\n<p>Tambi\u00e9n existen protocolos que admiten ambos modelos. Por ejemplo, XMPP y HTTP 2.0, que admiten la opci\u00f3n de \"server push\". IETF tambi\u00e9n ha lanzado CoAP. En un intento por resolver el problema del intercambio de mensajes, se han creado varias otras soluciones, como el protocolo WebSockets o el uso de HTTP a trav\u00e9s de QUIC (Quick UDP Internet Connections).<\/p>\n<p>En el caso de WebSockets, aunque se utiliza para la transmisi\u00f3n de datos en tiempo real desde el servidor al cliente web y proporciona conexiones permanentes con retroalimentaci\u00f3n bidireccional simult\u00e1nea, no est\u00e1 dise\u00f1ado para dispositivos con recursos computacionales limitados. QUIC tambi\u00e9n merece atenci\u00f3n, ya que este nuevo protocolo de transporte ofrece muchas nuevas posibilidades. Sin embargo, dado que QUIC a\u00fan no est\u00e1 estandarizado, es prematuro predecir su posible aplicaci\u00f3n e impacto en las soluciones de IoT. As\u00ed que dejaremos WebSockets y QUIC en la memoria con la vista puesta en el futuro, pero no profundizaremos en ellos por ahora.<\/p>\n<h3>\u00bfQui\u00e9n es el m\u00e1s querido del mundo? Comparando protocolos<\/h3>\n<p>\nAhora hablemos de las fortalezas y debilidades de los protocolos. A modo de anticipaci\u00f3n, aclaremos que no hay un l\u00edder claro. Cada protocolo tiene sus propias ventajas y desventajas.<\/p>\n<p><b>Tiempo de respuesta<\/b><\/p>\n<p>Una de las caracter\u00edsticas m\u00e1s importantes de los protocolos de comunicaci\u00f3n, especialmente en lo que respecta a Internet de las Cosas, es el tiempo de respuesta. Sin embargo, entre los protocolos existentes no hay un ganador absoluto que demuestre el nivel m\u00ednimo de latencia en diferentes condiciones. Sin embargo, hay una gran cantidad de investigaciones y comparaciones sobre las capacidades de los protocolos.<\/p>\n<p>Por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.researchgate.net\/publication\/323943358_Performance_Analysis_of_Internet_of_Things_Protocols_Based_FogCloud_over_High_Traffic\">resultados <\/a><\/noindex>Las comparaciones de la eficiencia de HTTP y MQTT al trabajar con IoT mostraron que el tiempo de respuesta para las solicitudes de MQTT es menor que el de HTTP. Y al <noindex><a rel=\"nofollow\" href=\"https:\/\/www.researchgate.net\/publication\/303188719_Comparison_of_two_lightweight_protocols_for_smartphone-based_sensing\">investigar <\/a><\/noindex>el tiempo de env\u00edo y recepci\u00f3n (RTT) de MQTT y CoAP, se descubri\u00f3 que el RTT promedio de CoAP es un 20% menor que el de MQTT.<\/p>\n<p>Otro <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7740559\">un experimento <\/a><\/noindex>El RTT de los protocolos MQTT y CoAP se llev\u00f3 a cabo en dos escenarios: una red local y una red IoT. Result\u00f3 que el RTT promedio es de 2 a 3 veces m\u00e1s alto en la red IoT. MQTT con QoS0 mostr\u00f3 un resultado inferior en comparaci\u00f3n con CoAP, mientras que MQTT con QoS1 demostr\u00f3 un RTT m\u00e1s alto debido a los ACK en los niveles de aplicaci\u00f3n y transporte. Para diferentes niveles de QoS, las latencias en una red sin congesti\u00f3n para MQTT fueron de milisegundos, mientras que para CoAP fueron de cientos de microsegundos. Sin embargo, es importante recordar que al trabajar en redes menos confiables, MQTT, que opera sobre TCP, mostrar\u00e1 resultados completamente diferentes.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.diva-portal.org\/smash\/get\/diva2:1092136\/FULLTEXT01.pdf\">Comparaci\u00f3n <\/a><\/noindex>del tiempo de respuesta de los protocolos AMQP y MQTT al aumentar la carga \u00fatil mostr\u00f3 que bajo poca carga el nivel de latencia es casi el mismo. Sin embargo, al transferir grandes vol\u00famenes de datos, MQTT muestra un tiempo de respuesta menor. En otro <noindex><a rel=\"nofollow\" href=\"http:\/\/www.tfzr.rs\/esociety\/issues\/eSocietyVol3No1.pdf#page=26\">la investigaci\u00f3n <\/a><\/noindex>se compar\u00f3 CoAP con HTTP en un escenario de comunicaci\u00f3n m\u00e1quina a m\u00e1quina con dispositivos desplegados sobre veh\u00edculos y equipados con sensores de gas, sensores meteorol\u00f3gicos, ubicaci\u00f3n (GPS) y una interfaz de red m\u00f3vil (GPRS). El tiempo necesario para transmitir un mensaje CoAP a trav\u00e9s de la red m\u00f3vil fue casi tres veces m\u00e1s corto que el necesario para utilizar mensajes HTTP.<\/p>\n<p>Se realizaron estudios en los que se compararon no dos, sino tres protocolos. Por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7496622\">comparaci\u00f3n <\/a><\/noindex>el rendimiento de los protocolos IoT MQTT, DDS y CoAP en un escenario de aplicaci\u00f3n m\u00e9dica utilizando un emulador de red. DDS super\u00f3 a MQTT en t\u00e9rminos de latencia de telemetr\u00eda probada en diversas condiciones de red adversas. CoAP basado en UDP funcion\u00f3 bien para aplicaciones que requieren una respuesta r\u00e1pida, sin embargo, debido a su naturaleza basada en UDP, se produjo una significativa p\u00e9rdida de paquetes impredecible.<\/p>\n<p><b>Ancho de banda<\/b><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/www.researchgate.net\/publication\/267636202_Performance_evaluation_of_MQTT_and_CoAP_via_a_common_middleware\">Comparaci\u00f3n <\/a><\/noindex>MQTT y CoAP en t\u00e9rminos de eficiencia en el uso del ancho de banda se llev\u00f3 a cabo como un conteo de la cantidad total de datos transmitidos por mensaje. CoAP mostr\u00f3 menor capacidad de ancho de banda que MQTT al enviar mensajes peque\u00f1os. Pero al comparar la eficiencia de los protocolos en funci\u00f3n de la relaci\u00f3n entre la cantidad de bytes de informaci\u00f3n \u00fatil y el total de bytes transmitidos, CoAP result\u00f3 ser m\u00e1s eficaz.<\/p>\n<p>Al <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7496622\">an\u00e1lisis <\/a><\/noindex>del uso del ancho de banda de MQTT, DDS (con TCP como protocolo de transporte) y CoAP revel\u00f3 que CoAP generalmente mostr\u00f3 un consumo de ancho de banda comparativamente m\u00e1s bajo, el cual no aument\u00f3 con el incremento de p\u00e9rdidas de paquetes en la red o con el aumento de la latencia de la red, a diferencia de MQTT y DDS, donde en los escenarios mencionados se observ\u00f3 un aumento en el uso del ancho de banda. En otro escenario se involucr\u00f3 un gran n\u00famero de dispositivos transmitiendo datos simult\u00e1neamente, lo cual es un caso t\u00edpico en entornos IoT. Los resultados mostraron que para cargas m\u00e1s altas, es mejor utilizar CoAP.<\/p>\n<p>Con una carga baja, CoAP utiliz\u00f3 el menor ancho de banda, seguido de MQTT y REST HTTP. Sin embargo, cuando el tama\u00f1o de las cargas \u00fatiles aument\u00f3, los mejores resultados fueron para REST HTTP.<\/p>\n<p><b>Consumo de energ\u00eda<\/b><\/p>\n<p>La cuesti\u00f3n del consumo de energ\u00eda siempre es importante, y en un sistema IoT, especialmente. <noindex><a rel=\"nofollow\" href=\"https:\/\/ieeexplore.ieee.org\/document\/7899537\">comparar <\/a><\/noindex>el consumo de electricidad de MQTT y HTTP, HTTP 'consume' mucho m\u00e1s. CoAP es m\u00e1s <noindex><a rel=\"nofollow\" href=\"https:\/\/www.mdpi.com\/1424-8220\/16\/12\/2044\/htm\">energ\u00e9ticamente eficiente <\/a><\/noindex>en comparaci\u00f3n con MQTT, permitiendo un mejor manejo de la energ\u00eda. En escenarios simples, MQTT es m\u00e1s adecuado para el intercambio de informaci\u00f3n en redes de internet de las cosas, especialmente si no hay restricciones de potencia.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/cgweb1.northumbria.ac.uk\/SubjectAreaResources\/KF7046\/papers\/review\/iot\/lpb15.pdf\">Otro <\/a><\/noindex>un experimento en el que se compararon las capacidades de AMQP y MQTT en un banco de pruebas de una red m\u00f3vil o inal\u00e1mbrica inestable, mostr\u00f3 que AMQP ofrece m\u00e1s capacidades en t\u00e9rminos de seguridad, mientras que MQTT es m\u00e1s energ\u00e9ticamente eficiente.<\/p>\n<p><b>Seguridad<\/b><\/p>\n<p>La seguridad es otra cuesti\u00f3n crucial planteada al estudiar el tema del internet de las cosas y la computaci\u00f3n en la niebla\/nube. El mecanismo de seguridad generalmente se basa en TLS en HTTP, MQTT, AMQP y XMPP, o DTLS en CoAP, adem\u00e1s de soportar ambos DDS.<\/p>\n<p>TLS y DTLS comienzan con un proceso de establecimiento de conexi\u00f3n entre el cliente y el servidor para intercambiar conjuntos de cifrado y claves compatibles. Ambas partes acuerdan los conjuntos para garantizar que la comunicaci\u00f3n posterior ocurra en un canal seguro. La diferencia entre ellos radica en peque\u00f1as modificaciones que permiten a DTLS, basado en UDP, operar sobre una conexi\u00f3n no fiable.<\/p>\n<p>Al <noindex><a rel=\"nofollow\" href=\"http:\/\/www.isg.rhul.ac.uk\/tls\/lucky13.html\">ataques de prueba<\/a><\/noindex> a varias implementaciones diferentes de TLS y DTLS revelaron que TLS manej\u00f3 mejor la tarea. Los ataques a DTLS tuvieron m\u00e1s \u00e9xito debido a su tolerancia a los errores.<\/p>\n<p>Sin embargo, el mayor problema de estos protocolos es que no fueron dise\u00f1ados originalmente para su uso en IoT y no contemplaban operar en la niebla o en la nube. A trav\u00e9s del intercambio acordado (handshaking) a\u00f1aden tr\u00e1fico adicional con cada establecimiento de conexi\u00f3n, lo que agota los recursos computacionales. Se observa un aumento promedio del 6.5% para TLS y del 11% para DTLS en la carga \u00fatil administrativa en comparaci\u00f3n con la comunicaci\u00f3n sin nivel de seguridad. En entornos con recursos abundantes, que generalmente se encuentran en <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloud4y.ru\/cloud-hosting\/cloud-server\/?utm_source=habr&amp;utm_medium=referral&amp;utm_campaign=article\">la nube <\/a><\/noindex>En este nivel, no ser\u00e1 un problema, pero en la relaci\u00f3n entre IoT y el nivel de niebla, esto se convierte en una limitaci\u00f3n importante.<\/p>\n<p>\u00bfQu\u00e9 elegir? No hay una respuesta clara. MQTT y HTTP parecen ser los protocolos m\u00e1s prometedores, ya que se consideran soluciones relativamente m\u00e1s maduras y estables para IoT en comparaci\u00f3n con otros protocolos.<\/p>\n<h3>Soluciones basadas en un \u00fanico protocolo de comunicaci\u00f3n<\/h3>\n<p>\nLa pr\u00e1ctica de soluciones de un solo protocolo tiene muchas desventajas. Por ejemplo, un protocolo que satisface un entorno limitado puede no funcionar en un dominio que tiene estrictos requisitos de seguridad. Teniendo esto en cuenta, nos queda descartar casi todas las posibles soluciones basadas en un solo protocolo en el ecosistema Fog-to-Cloud en IoT, excepto MQTT y REST HTTP.<\/p>\n<p><b>REST HTTP como soluci\u00f3n de un solo protocolo<\/b><\/p>\n<p>Hay un buen ejemplo de la interacci\u00f3n de solicitudes y respuestas de REST HTTP en el \u00e1mbito de IoT-to-Fog: <noindex><a rel=\"nofollow\" href=\"https:\/\/dl.acm.org\/citation.cfm?doid=3152130.3152140\">granja inteligente<\/a><\/noindex>. Los animales est\u00e1n equipados con sensores port\u00e1tiles (cliente IoT, C) y son gestionados a trav\u00e9s de la computaci\u00f3n en la nube por un sistema de granja inteligente (servidor Fog, S).<\/p>\n<p>En el encabezado del m\u00e9todo POST se especifica el recurso a modificar (\/farm\/animals), as\u00ed como la versi\u00f3n de HTTP y el tipo de contenido, que en este caso es un objeto JSON que representa la granja ganadera que debe gestionar el sistema (Dulcinea\/vaca). La respuesta del servidor indica que la solicitud fue exitosa, enviando un c\u00f3digo de estado HTTPS 201 (recurso creado). El m\u00e9todo GET solo debe indicar el recurso solicitado en el URI (por ejemplo, \/farm\/animals\/1), que devuelve la representaci\u00f3n JSON del animal con ese identificador desde el servidor. <\/p>\n<p>El m\u00e9todo PUT se utiliza cuando es necesario actualizar alg\u00fan registro espec\u00edfico del recurso. En este caso, el recurso especifica el URI para el par\u00e1metro a modificar y el valor actual (por ejemplo, indicando que la vaca est\u00e1 en pastoreo, \/farm\/animals\/1?estado=paseando). Finalmente, el m\u00e9todo DELETE se utiliza en igualdad de condiciones que el m\u00e9todo GET, pero simplemente elimina el recurso como resultado de la operaci\u00f3n. <\/p>\n<p><b>MQTT como soluci\u00f3n de un solo protocolo<\/b><\/p>\n<p><img decoding=\"async\" alt=\"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?\" src=\"\/wp-content\/uploads\/2019\/09\/529857b556ea5a186ac1519e2804d1b8.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTomemos la misma granja inteligente, pero en lugar de REST HTTP, usaremos el protocolo MQTT. Un servidor local con la biblioteca Mosquitto instalada act\u00faa como corredor. En este ejemplo, una computadora simple (designada como servidor de la granja) Raspberry Pi sirve como cliente MQTT, implementado a trav\u00e9s de la instalaci\u00f3n de la biblioteca MQTT Paho, completamente compatible con el corredor Mosquitto.<\/p>\n<p>Este cliente corresponde al nivel de abstracci\u00f3n de IoT que representa un dispositivo con capacidades de detecci\u00f3n y c\u00e1lculo. El intermediario, por otro lado, corresponde a un nivel de abstracci\u00f3n m\u00e1s alto, representando un nodo de computaci\u00f3n de niebla, caracterizado por una mayor capacidad en t\u00e9rminos de procesamiento y almacenamiento de datos.<\/p>\n<p>En el escenario propuesto de la \"granja inteligente\", Raspberry Pi se conecta a un aceler\u00f3metro, GPS y sensores de temperatura y publica datos de estos sensores en un nodo de niebla. Como probablemente sepas, MQTT considera los temas como una jerarqu\u00eda. Un publicador MQTT puede publicar mensajes en un conjunto espec\u00edfico de temas. En nuestro caso, hay tres. Para el sensor que mide la temperatura en el establo de animales, el cliente elige el tema (animalfarm\/shed\/temperature). Para los sensores que miden la ubicaci\u00f3n GPS y el movimiento de los animales a trav\u00e9s del aceler\u00f3metro, el cliente publicar\u00e1 actualizaciones (animalfarm\/animal\/GPS) y (animalfarm\/animal\/movement).<\/p>\n<p>Esta informaci\u00f3n ser\u00e1 enviada al corredor, que puede almacenarla temporalmente en una base de datos local por si m\u00e1s tarde aparece otro suscriptor interesado.<\/p>\n<p>Adem\u00e1s del servidor local que act\u00faa como corredor MQTT en la niebla y al que Raspberry Pi, actuando como clientes MQTT, env\u00edan datos de los sensores, puede haber otro corredor MQTT en la nube. En este caso, la informaci\u00f3n enviada al corredor local puede almacenarse temporalmente en una base de datos local y\/o enviarse a la nube. El corredor MQTT de niebla en esta situaci\u00f3n se utiliza para vincular todos los datos con el corredor MQTT en la nube. Con esta arquitectura, el usuario de la aplicaci\u00f3n m\u00f3vil puede estar suscrito a ambos corredores.<\/p>\n<p>En caso de una falla de conexi\u00f3n con uno de los corredores (por ejemplo, en la nube), el usuario final recibir\u00e1 informaci\u00f3n de otro (en la niebla). Esta es una caracter\u00edstica distintiva de los sistemas combinados de niebla y computaci\u00f3n en la nube. Por defecto, la aplicaci\u00f3n m\u00f3vil puede configurarse para la primera conexi\u00f3n a un corredor MQTT de niebla y, en caso de falla, conectarse a un corredor MQTT en la nube. Esta soluci\u00f3n es solo una de muchas en los sistemas IoT-F2C. <\/p>\n<h3>Soluciones multiprotocolo<\/h3>\n<p>\nLas soluciones con un solo protocolo son populares debido a su implementaci\u00f3n m\u00e1s sencilla. Pero es evidente que en los sistemas IoT-F2C tiene sentido combinar diferentes protocolos. La idea es que diferentes protocolos pueden operar en diferentes niveles. Tomemos, por ejemplo, tres abstracciones: los niveles IoT, de niebla y de computaci\u00f3n en la nube. Los dispositivos en el nivel IoT se consideran generalmente limitados. Para este an\u00e1lisis, consideremos los niveles IoT como los m\u00e1s limitados, los de nube como los menos limitados y la computaci\u00f3n de niebla como 'en alg\u00fan lugar intermedio'. As\u00ed, entre IoT y las abstracciones de niebla, las soluciones de protocolo actuales incluyen MQTT, CoAP y XMPP. Entre la niebla y la nube, por otro lado, AMQP es uno de los principales protocolos utilizados junto con REST HTTP, que debido a su flexibilidad tambi\u00e9n se utiliza entre IoT y las capas de niebla. <\/p>\n<p>El principal problema aqu\u00ed es la compatibilidad funcional de los protocolos y la facilidad de traducci\u00f3n de mensajes de un protocolo a otro. Idealmente, en el futuro, la arquitectura del sistema de Internet de las cosas con recursos en la nube y en la niebla ser\u00e1 independiente del protocolo de comunicaci\u00f3n utilizado y proporcionar\u00e1 una buena interacci\u00f3n entre diferentes protocolos.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?\" src=\"\/wp-content\/uploads\/2019\/09\/cddc564cad572966002ae22eff8cb99d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nDado que esto no es as\u00ed en este momento, tiene sentido combinar protocolos que no tengan diferencias significativas. Con este objetivo, una posible soluci\u00f3n se basa en la combinaci\u00f3n de dos protocolos que siguen el mismo estilo arquitect\u00f3nico, REST HTTP y CoAP. Otra soluci\u00f3n propuesta se basa en la combinaci\u00f3n de dos protocolos que ofrecen interacci\u00f3n bajo el modelo de 'publicaci\u00f3n-suscripci\u00f3n', MQTT y AMQP. El uso de conceptos cercanos (tanto MQTT como AMQP utilizan corredores, CoAP y HTTP utilizan REST), simplifica la implementaci\u00f3n de estas combinaciones y requiere menos esfuerzo para la integraci\u00f3n.<\/p>\n<p><img decoding=\"async\" alt=\"IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas?\" src=\"\/wp-content\/uploads\/2019\/09\/395bc75880a154aeab7b61d043476802.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn la figura (a) se muestran dos modelos basados en solicitudes-respuestas, HTTP y CoAP, y su posible ubicaci\u00f3n en la soluci\u00f3n IoT-F2C. Dado que HTTP es uno de los protocolos m\u00e1s conocidos y adaptados en las redes modernas, es poco probable que sea reemplazado completamente por otros protocolos de mensajer\u00eda. Entre los nodos que representan dispositivos potentes, que se sit\u00faan entre la nube y la niebla, REST HTTP es una soluci\u00f3n razonable.<\/p>\n<p>Por otro lado, para los dispositivos con recursos computacionales limitados que se conectan entre los niveles de niebla e IoT, es m\u00e1s eficiente utilizar CoAP. Una de las grandes ventajas de CoAP es de hecho su compatibilidad con HTTP, ya que ambos protocolos se basan en principios REST.<\/p>\n<p>En la figura (b) se muestran dos modelos de interacci\u00f3n de \u2018publicaci\u00f3n-suscripci\u00f3n\u2019 en un escenario, incluidos MQTT y AMQP. Aunque hipot\u00e9ticamente ambos protocolos pueden ser utilizados para la comunicaci\u00f3n entre nodos en cada nivel de abstracci\u00f3n, su ubicaci\u00f3n debe definirse en funci\u00f3n del rendimiento. MQTT fue dise\u00f1ado como un protocolo simplificado para dispositivos con recursos computacionales limitados, por lo que puede usarse para la comunicaci\u00f3n entre IoT y la niebla. AMQP es m\u00e1s adecuado para dispositivos m\u00e1s potentes, que lo situar\u00edan idealmente entre los nodos de niebla y nube. En lugar de MQTT, en IoT se puede utilizar el protocolo XMPP, ya que se considera ligero. Pero no es tan ampliamente utilizado en escenarios similares.<\/p>\n<h3>Conclusiones<\/h3>\n<p>\nEs poco probable que uno de los protocolos analizados sea suficiente para cubrir toda la comunicaci\u00f3n en el sistema, desde dispositivos con recursos computacionales limitados hasta servidores en la nube. La investigaci\u00f3n ha demostrado que las dos opciones m\u00e1s prometedoras que utilizan con mayor frecuencia los desarrolladores son MQTT y RESTful HTTP. Estos dos protocolos son no solo los m\u00e1s maduros y estables, sino que tambi\u00e9n incluyen numerosas implementaciones bien documentadas y exitosas, as\u00ed como recursos en l\u00ednea.<\/p>\n<p>Gracias a su estabilidad y f\u00e1cil configuraci\u00f3n, MQTT es un protocolo que con el tiempo ha demostrado su excelente rendimiento en aplicaciones de IoT con dispositivos limitados. En partes del sistema donde la conectividad y el consumo de bater\u00eda no son problemas, como en algunas \u00e1reas de niebla y en la mayor\u00eda de la computaci\u00f3n en la nube, RESTful HTTP es una elecci\u00f3n sencilla. CoAP tambi\u00e9n debe ser considerado, ya que r\u00e1pidamente se est\u00e1 convirtiendo en un est\u00e1ndar de mensajer\u00eda IoT, y es bastante probable que en un futuro cercano alcance un nivel de estabilidad y madurez comparable a MQTT y HTTP. Sin embargo, el est\u00e1ndar se est\u00e1 desarrollando actualmente, lo que conlleva problemas de compatibilidad a corto plazo.<\/p>\n<p><b>\u00bfQu\u00e9 m\u00e1s \u00fatil se puede leer en el blog? <noindex><a rel=\"nofollow\" href=\"https:\/\/www.cloud4y.ru\/?utm_source=habr&amp;utm_medium=referral&amp;utm_campaign=article\">Cloud4Y<\/a><\/noindex><\/b><\/p>\n<p>\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/466755\/\">La computadora te har\u00e1 delicioso<\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/464155\/\">La IA ayuda a estudiar los animales de \u00c1frica <\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/465251\/\">El verano casi ha terminado. Casi no quedan datos no filtrados<\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/461713\/\">4 maneras de ahorrar en copias de seguridad en la nube<\/a><\/noindex><br \/>\n\u2192 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/467769\/\">Sobre un recurso inform\u00e1tico federal \u00fanico que contiene informaci\u00f3n sobre la poblaci\u00f3n<\/a><\/noindex><\/p>\n<p>Suscr\u00edbete a nuestro <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/cloud4y\">Telegram<\/a><\/noindex>-canal para no perderte el pr\u00f3ximo art\u00edculo. Escribimos no m\u00e1s de dos veces a la semana y solo lo necesario.<br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/cloud4y\/blog\/467711\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438 \u0436\u0435\u043b\u0435\u0437\u0430, \u043f\u043e\u044f\u0432\u043b\u0435\u043d\u0438\u0435 \u043d\u043e\u0432\u044b\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0441\u0432\u044f\u0437\u0438 \u043f\u0440\u0438\u0432\u0435\u043b\u0438 \u043a \u0440\u0430\u0441\u0448\u0438\u0440\u0435\u043d\u0438\u044e \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442\u0430 \u0432\u0435\u0449\u0435\u0439 (IoT). \u041a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u0443\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432 \u0440\u0430\u0441\u0442\u0451\u0442 \u0434\u0435\u043d\u044c \u043e\u0442\u043e \u0434\u043d\u044f, \u0438 \u043e\u043d\u0438 \u0433\u0435\u043d\u0435\u0440\u0438\u0440\u0443\u044e\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u044b\u0439 \u043e\u0431\u044a\u0451\u043c \u0434\u0430\u043d\u043d\u044b\u0445. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u043f\u043e\u0442\u0440\u0435\u0431\u043d\u043e\u0441\u0442\u044c \u0432 \u0443\u0434\u043e\u0431\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0441\u043f\u043e\u0441\u043e\u0431\u043d\u043e\u0439 \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c, \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0438 \u043f\u0435\u0440\u0435\u0434\u0430\u0432\u0430\u0442\u044c \u044d\u0442\u0438 \u0434\u0430\u043d\u043d\u044b\u0435. \u0421\u0435\u0439\u0447\u0430\u0441 \u0434\u043b\u044f \u044d\u0442\u0438\u0445 \u0446\u0435\u043b\u0435\u0439 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044e\u0442 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0435 \u0441\u0435\u0440\u0432\u0438\u0441\u044b. \u041e\u0434\u043d\u0430\u043a\u043e \u0441\u0442\u0430\u043d\u043e\u0432\u044f\u0449\u0430\u044f\u0441\u044f \u0432\u0441\u0451 \u0431\u043e\u043b\u0435\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28806,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-38375","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47IoT, \u0442\u0443\u043c\u0430\u043d \u0438 \u043e\u0431\u043b\u0430\u043a\u0430: \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043f\u0440\u043e \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438? | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:23:21+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:23:21+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47IoT, niebla y nubes: \u00bfhablamos de tecnolog\u00edas? | ProHoster","description":"Desarrollo de tecnolog\u00edas en el \u00e1mbito del software y.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47IoT, \u0442\u0443\u043c\u0430\u043d \u0438 \u043e\u0431\u043b\u0430\u043a\u0430: \u043f\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043c \u043f\u0440\u043e \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0438? | ProHoster","og:description":"\u0420\u0430\u0437\u0432\u0438\u0442\u0438\u0435 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 \u043e\u0431\u043b\u0430\u0441\u0442\u0438 \u0441\u043e\u0444\u0442\u0430 \u0438.","og:url":"https:\/\/prohoster.info\/es\/blog\/news\/iot-tuman-i-oblaka-pogovorim-pro-tehnologii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:23:21+00:00","article:modified_time":"2019-10-31T19:23:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38375","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 21:45:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:10:24","updated":"2026-01-23 21:45:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38375","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=38375"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38375\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/28806"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=38375"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=38375"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=38375"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}