Protocolo SSDP
0 recomendaciones419 vistas
El documento describe el protocolo SSDP (Simple Service Discovery Protocol), el cual permite el descubrimiento y configuración automática de dispositivos en una red local. SSDP utiliza mensajes HTTP sobre UDP para anunciar y buscar servicios, y HTTP sobre TCP para la transmisión de configuraciones. El protocolo es adecuado para redes domésticas y pequeñas empresas, donde facilita la conexión y uso compartido de dispositivos como impresoras y cámaras.
![Figura 4. Mensaje HTTP puertos TCP y
direcciones IP.
En esta grafica observamos que el servicio se
presta de forma unicast siendo el router un
servidor con puerto 80 en TCP y el equipo
tiene un puerto de 58008, también se observa
que es el router el que envía la información
de configuración al equipo.
Cabe notar que mientras se envían mensajes
m-search y notify de SSDP estos manejan en
capa de transporte el protocolo UDP solo se
activa TCP cuando se confirma que se envía
la configuración o servicio solicitado al
cliente que lo requiere. Esto permite que no
se genere tanta congestión.
APLICACIONES SOBRE REDES
En las redes caseras o de pequeñas empresas
se ha optado por implementar este protocolo
ya que para el usuario normal permite una
configuración rápida de elementos de red
como impresoras, cámaras, televisores, entre
otros sin necesidad de implementar o tener
que instalar protocolos de red para compartir
archivos o dispositivos periféricos.
Con la creciente industria de elementos para
hogar e industria que necesitan de conexión
y configuración LAN de forma ágil este
protocolo permite una gran flexibilidad
permitiendo a cualquier equipo que se
conecte a la red enviar la configuración
necesaria manejando tráfico TCP unicast
solamente cuando el cliente y el router que
presta este servicio se escuchan, mientras
pasa este proceso los mensajes de m-search y
de notify solamente se manejan en UDP pero
en multicast.
Aunque como vemos es un protocolo que
permite una gran flexibilidad es también un
protocolo que debido a su transmisión
multicast puede saturar la red. Se recomienda
en redes pequeñas hogar y pequeñas
empresas, estos mensajes en multicast pueden
ser deshabilitados del router ya que en el
tráfico LAN pueden generar congestión
debido a que el router esta constantemente
notificando que presta dichos servicios. Otro
punto a evaluar es que si existe un intruso
puede emular la prestación de estos servicios
y puede con ello enviar a los equipos
información maliciosa para la configuración
de estos.
CALCULO DE TIEMPO DE RESOLUCIÓN
Y FLUJO DE INFORMACIÓN
Un aspecto importante en el desempeño de
las redes es la cantidad o flujo de información
que se necesita para configurar un equipo en
la red, puesto que si un equipo es conectado
para su uso compartido en la red, ejemplo una
impresora, este generará una carga de
paquetes adicionales en el entorno LAN que
pueden generar colas de transmisión en el
router. Si un protocolo gasta un promedio de
bytes para configurar un dispositivo
determinado podemos como administradores
de una red LAN decidir cuales de estos
protocolos o servicios implementamos para
mejorar el desempeño de la red.
A continuación se muestra un ejemplo que
fue modificado del paper Simple Service
Discovery Protocol/1.0 Operating without an
Arbiter <draft-cai-ssdp-v1-03.txt>.
“Según el algoritmo utilizado por este
protocolo el ancho de banda que utiliza
mediante un periodo de tiempo determinado
en función de las solicitudes de
descubrimiento es “[1]:
((DR*3 + DR*9*RS)*AM)/TP [1]
Donde las siglas de esta ecuación describen lo
siguiente:
DR = Número total de clientes de SSDP que
hacen peticiones de descubrimiento sobre el
periodo de tiempo de la muestra.](https://image.slidesharecdn.com/protocolossdp-130802100446-phpapp01/85/Protocolo-SSDP-3-320.jpg)
![RS = Número total de servicio que
correspondes a SSDP:discover
AM = tamaño medio de los paquetes de
peticiones respuestas
TP = Tiempo o periodo de resolución de un
servicio SSDP:discover.
El 3 es el número de veces que el SSDP:
discover será repetido. El 9 es el número de
veces que las respuestas de unidifusión a la
ssdp:discover. Asumiendo que se repite la
configuración 3 veces debido al mensaje de
descubrimiento enviado.
Con estos datos suministrados colocamos el
ejemplo de una red corporativa de 200
clientes con 40 impresoras, imaginemos que
se conectan a la red y necesitan de dichos
servicio de impresión, si el tiempo TP es de
40 segundos, el tamaño de los paquetes en
promedio es de 512 bytes se obtiene que:
DR = 200 , RS = 40; AM = 512 Bytes, TP =
40 segundos
((200*3+200*9*40)*512)/40 = 929280
Bytes/seg = 0.88623Mbytes/seg
Si la red sufriera un reinicio el total de
información que tiene que enviar para superar
este inconveniente sería de 0.88623
Mbytes/seg * 40 seg = 35,4492 MBytes. Si se
asume que la red de la empresa tiene una red
Ethernet de 10 Mbps y la carga total efectiva
de esta red es de 5 Mbps el tiempo con el cual
la red se estabilizaría sería de 35,4492/5 = 7,1
segundos. Es una respuesta bastante rápida
para un entorno pequeño o red pequeña
empresarial.
CONCLUSIONES
El protocolo SSDP es un protocolo para el
descubrimiento y la configuración de los
dispositivos plug and play de la red, ejemplo
impresoras, cámaras, televisores, etc.
Su configuración esta dada para que funcione
en entornos de redes pequeñas tipo hogar y
pequeñas empresas.
Maneja mensajes de descubrimiento y
notificación estos se manejan multicast con la
dirección 239.255.255.250 y con el puerto
UDP 1900, cuando se realiza el
descubrmiento se maneja la configuración por
HTTP y el protocolo TCP con mensajes
unicast desde el router hasta el equipo cliente
que solicita el servicio.
El flujo de datos por segundo esta dado por
variables como el número de clientes, el
número de servicios el tamaño promedio de
los paquetes de descubrimiento y el tiempo
promedio de la resolución de los mismos, la
formula del algoritmo nos permite calcular el
ancho de banda que consume el protocolo
para configurar la red.
REFERENCIAS
[1] Yaron Y. Goland, Ting Cai, Paul
Leach, Ye Gu, Simple Service Discovery
Protocol/1.0 Operating without an Arbiter,
2010.](https://image.slidesharecdn.com/protocolossdp-130802100446-phpapp01/85/Protocolo-SSDP-4-320.jpg)
Protocolo SSDP
- 1. PROTOCOLO SSDP Alvaro Humberto Cisneros, José Andres Rojas Maestría Ciencias de la información y las comunicaciones Universidad Distrital Francisco José de Caldas Bogotá, Colombia humcis@gmail.com ing.jar@hotmail.com Resumen - El protocolo SSDP es un protocolo de descubrimiento de dispositivos y servicios plug and play de la red, sus siglas responden a Simple Service Discovery Protocol, utiliza un protocolo HTTP para la resolución de descubrimiento y para la prestar el servicio que el cliente esta solicitando. El SSDP esta regulado por la RFC SSDP. Este protocolo se desarrolla bajo ambiente de redes pequeñas LAN y se utiliza para mejorar el proceso de descubrimiento y resolución de servicios de un dispositivo nuevo en la red o que este conectado a un elemento de la red, por ejemplo impresoras, FAX, entre otros elementos. INTRODUCCIÓN En el presente artículo se desarrolla un estudio sobre el protocolo SSDP, este protocolo es utilizado en los ambientes LAN de pequeñas redes para hogar y microempresas, permite el descubrimiento y configuración de dispositivos plug and play. FUNCIONAMIENTO El Protocolo SSDP o Protocolo Simple de Descubrimiento de Servicios (Simple Service Discovery Protocol) es un protocolo que se utiliza para la búsqueda de dispositivos UPnP (Universal Plug and Play) en una red. Su estructura según la versión V1.0 utiliza un mensaje HTTP para el descubrimiento, notificación y configuración, este mensaje en HTTP maneja en su capa de transporte el protocolo UDP en unicast o multicast apuntando al puerto 1900 para anunciar los servicios de un dispositivo. Solo la información más relevante acerca del dispositivo y el servicio que se ofrece se encuentra contenido en los mensajes intercambiados. Este protocolo declara una terminología que se tiene en cuenta para el procedimiento de SSDP El cliente SSDP: Quien solicita o hace uso del servicio SSDP El servicio SSDP: Un recurso HTTP que provee el servicio usado por los clientes SSDP Tipo de servicio: Un identificador uniforme de recursos URI que identifica el tipo o función particular del servicio. Nombre único de servicio USN, una URI que garantiza que el proceso sea único es usado para identificar un servicio en particular de los múltiples servicios que puedan ser generados en la red. El protocolo maneja 2 tipos de paquetes HTTP-Request uno maneja la instrucción “NOTIFY” el otro paquete es “M-SEARCH”, el primero anuncia que tipos de servicio ofrece y segundo es de solicitud de servicios, estos paquetes dejan vacio el cuerpo de HTTP y la cabecera contiene los siguientes elementos de notificación e identificación. Cuando una un servidor se presta a prestar el servicio aparece un mensaje con el código 200 Ok que indica que se prestará el servicio. En general el protocolo SSDP maneja tres mensajes M-SEARCH en multicast para solicitar un servicio y utiliza 9 paquetes unicast para cuando tanto el cliente como el servidor reconocen quien es el cliente y quien el servidor se inicia la transmisición de la configuración de HTTP este maneja en transporte el protocolo TCP y un mensaje unicast desde el router con un puerto TCP 80
- 2. y el equipo con el puerto dirección IP determinadas por el equipo. Cabecera M-SEARCH S: Identificador UNI Host: Dirección Destino consulta, 239.255.255.250:1900 MAN: tipo de servicio de red. “Generalmente de descubrimiento” ST: Identificador simple que especifica que tipo de servicio requiere MX: paquetes a retransmitir, comúnmente en 3. Cabecera NOTIFY Host: Dirección publicación de servicios 239.255.255.250:1900 Cache Control: max-age, máximo tiempo de vida de los paquetes. Location: Dirección IP de la fuente prestadora del servicio. NT: Identificador UNI de servicio a prestar NTS: Identificador de servicio UNI específico similar a S, tiene por lo general los valores "ssdp:alive" para registrarse o "ssdp:byebye" para cancelar el registro o solicitud. USN: Nombre de la unidad de servicio a prestar. Cabecera HTTP OK Es una cabecera normal de HTTP lo que tenemos que tener en cuenta son algunos parámetros como: Status code = 200 Response phase: OK Server: Servicio prestado o suministrado. Las gráficas a continuación muestran el desarrollo de una comunicación SSDP Figura 1. Mensaje SSDP M-Search En la anterior grafica se observa una petición de configuración de puerta de enlace Figura 2. Mensaje SSDP Notify En esta gráfica se observa que el router envía un mensaje multicast para notificar que presta este servicio. Figura 3. HTTP OK identificador 200 En esta gráfica vemos el archivo HTTP 200 Ok que indica la prestación del servicio.
- 3. Figura 4. Mensaje HTTP puertos TCP y direcciones IP. En esta grafica observamos que el servicio se presta de forma unicast siendo el router un servidor con puerto 80 en TCP y el equipo tiene un puerto de 58008, también se observa que es el router el que envía la información de configuración al equipo. Cabe notar que mientras se envían mensajes m-search y notify de SSDP estos manejan en capa de transporte el protocolo UDP solo se activa TCP cuando se confirma que se envía la configuración o servicio solicitado al cliente que lo requiere. Esto permite que no se genere tanta congestión. APLICACIONES SOBRE REDES En las redes caseras o de pequeñas empresas se ha optado por implementar este protocolo ya que para el usuario normal permite una configuración rápida de elementos de red como impresoras, cámaras, televisores, entre otros sin necesidad de implementar o tener que instalar protocolos de red para compartir archivos o dispositivos periféricos. Con la creciente industria de elementos para hogar e industria que necesitan de conexión y configuración LAN de forma ágil este protocolo permite una gran flexibilidad permitiendo a cualquier equipo que se conecte a la red enviar la configuración necesaria manejando tráfico TCP unicast solamente cuando el cliente y el router que presta este servicio se escuchan, mientras pasa este proceso los mensajes de m-search y de notify solamente se manejan en UDP pero en multicast. Aunque como vemos es un protocolo que permite una gran flexibilidad es también un protocolo que debido a su transmisión multicast puede saturar la red. Se recomienda en redes pequeñas hogar y pequeñas empresas, estos mensajes en multicast pueden ser deshabilitados del router ya que en el tráfico LAN pueden generar congestión debido a que el router esta constantemente notificando que presta dichos servicios. Otro punto a evaluar es que si existe un intruso puede emular la prestación de estos servicios y puede con ello enviar a los equipos información maliciosa para la configuración de estos. CALCULO DE TIEMPO DE RESOLUCIÓN Y FLUJO DE INFORMACIÓN Un aspecto importante en el desempeño de las redes es la cantidad o flujo de información que se necesita para configurar un equipo en la red, puesto que si un equipo es conectado para su uso compartido en la red, ejemplo una impresora, este generará una carga de paquetes adicionales en el entorno LAN que pueden generar colas de transmisión en el router. Si un protocolo gasta un promedio de bytes para configurar un dispositivo determinado podemos como administradores de una red LAN decidir cuales de estos protocolos o servicios implementamos para mejorar el desempeño de la red. A continuación se muestra un ejemplo que fue modificado del paper Simple Service Discovery Protocol/1.0 Operating without an Arbiter <draft-cai-ssdp-v1-03.txt>. “Según el algoritmo utilizado por este protocolo el ancho de banda que utiliza mediante un periodo de tiempo determinado en función de las solicitudes de descubrimiento es “[1]: ((DR*3 + DR*9*RS)*AM)/TP [1] Donde las siglas de esta ecuación describen lo siguiente: DR = Número total de clientes de SSDP que hacen peticiones de descubrimiento sobre el periodo de tiempo de la muestra.
- 4. RS = Número total de servicio que correspondes a SSDP:discover AM = tamaño medio de los paquetes de peticiones respuestas TP = Tiempo o periodo de resolución de un servicio SSDP:discover. El 3 es el número de veces que el SSDP: discover será repetido. El 9 es el número de veces que las respuestas de unidifusión a la ssdp:discover. Asumiendo que se repite la configuración 3 veces debido al mensaje de descubrimiento enviado. Con estos datos suministrados colocamos el ejemplo de una red corporativa de 200 clientes con 40 impresoras, imaginemos que se conectan a la red y necesitan de dichos servicio de impresión, si el tiempo TP es de 40 segundos, el tamaño de los paquetes en promedio es de 512 bytes se obtiene que: DR = 200 , RS = 40; AM = 512 Bytes, TP = 40 segundos ((200*3+200*9*40)*512)/40 = 929280 Bytes/seg = 0.88623Mbytes/seg Si la red sufriera un reinicio el total de información que tiene que enviar para superar este inconveniente sería de 0.88623 Mbytes/seg * 40 seg = 35,4492 MBytes. Si se asume que la red de la empresa tiene una red Ethernet de 10 Mbps y la carga total efectiva de esta red es de 5 Mbps el tiempo con el cual la red se estabilizaría sería de 35,4492/5 = 7,1 segundos. Es una respuesta bastante rápida para un entorno pequeño o red pequeña empresarial. CONCLUSIONES El protocolo SSDP es un protocolo para el descubrimiento y la configuración de los dispositivos plug and play de la red, ejemplo impresoras, cámaras, televisores, etc. Su configuración esta dada para que funcione en entornos de redes pequeñas tipo hogar y pequeñas empresas. Maneja mensajes de descubrimiento y notificación estos se manejan multicast con la dirección 239.255.255.250 y con el puerto UDP 1900, cuando se realiza el descubrmiento se maneja la configuración por HTTP y el protocolo TCP con mensajes unicast desde el router hasta el equipo cliente que solicita el servicio. El flujo de datos por segundo esta dado por variables como el número de clientes, el número de servicios el tamaño promedio de los paquetes de descubrimiento y el tiempo promedio de la resolución de los mismos, la formula del algoritmo nos permite calcular el ancho de banda que consume el protocolo para configurar la red. REFERENCIAS [1] Yaron Y. Goland, Ting Cai, Paul Leach, Ye Gu, Simple Service Discovery Protocol/1.0 Operating without an Arbiter, 2010.