El síndrome del aprendiz de brujo ( SAS ) es una falla de protocolo de red en las versiones originales de TFTP . Lleva el nombre del poema de Goethe de 1797 " Der Zauberlehrling " (popularizado por el segmento " El aprendiz de brujo " de la película animada Fantasía de 1940 ), porque los detalles de su operación se parecen mucho al desastre que le sobreviene al aprendiz de brujo: el problema resultó en una replicación cada vez mayor de cada paquete en la transferencia.
El problema se produjo debido a un modo de falla conocido de la internetwork que, debido a un error por parte de los diseñadores del protocolo TFTP, no se tuvo en cuenta cuando se diseñó el protocolo; el modo de falla interactuó con varios detalles de los mecanismos de TFTP para producir SAS.
Experiencia técnica
TFTP funciona en un simple paso de bloqueo : solo hay un paquete pendiente en cualquier momento, y cada paquete recibido por cualquiera de las partes provoca que se envíe un paquete en respuesta (hasta la finalización de la transferencia). La especificación TFTP dijo que en cualquier momento cualquiera se recibió de paquetes, el receptor se requiere para enviar el paquete de respuesta adecuada. Por tanto, la recepción de un bloque de datos desencadenó el envío de un "acuse de recibo", y la recepción de un acuse de recibo desencadenó el envío del siguiente bloque de datos.
TFTP también, como todos los protocolos diseñados para operar en una red poco confiable, incluye tiempos de espera . Después de enviar un paquete, espera una respuesta, por lo que inicia un temporizador. Si el temporizador expira sin recibir respuesta, toma alguna acción; normalmente reenviar el paquete original.
Detalles
SAS ocurrió cuando un paquete no se perdió en la internetwork, sino que simplemente se retrasó y luego se entregó con éxito, después de que se agotó el tiempo de espera (en cualquier lado).
El tiempo de espera hace que se envíe una segunda copia del paquete anterior para reemplazar el paquete 'perdido'. Sin embargo, la primera copia no se perdió, y dado que, según la especificación TFTP, la recepción de cualquier paquete siempre obligaba a generar un paquete de respuesta, se generaron dos respuestas (una para cada copia). Aquellos forzaron la generación de dos respuestas a ellos, y así sucesivamente. Un escenario típico fue el siguiente:
- La computadora S (fuente) envía el bloque de datos X a la computadora D (destino)
- La computadora D recibe el bloque X y envía un acuse de recibo para X de regreso a S
- El paquete que contiene el acuse de recibo de X se retrasa en la internetwork
- La computadora S agota el tiempo de espera y reenvía el bloque de datos X a D
- La computadora S recibe el acuse de recibo retrasado para X y envía el bloque de datos X + 1
- La computadora D recibe la segunda copia del bloque X y envía otro acuse de recibo para X de regreso a S
- La computadora D recibe el bloque X + 1 y envía un acuse de recibo para X + 1 de regreso a S
- La computadora S recibe el segundo reconocimiento para X y envía una segunda copia del bloque de datos X + 1
- La computadora S recibe el acuse de recibo para X + 1 y envía el bloque de datos X + 2
- La computadora D recibe la segunda copia del bloque X + 1 y envía otro acuse de recibo para X + 1 de regreso a S
- La computadora D recibe el bloque X + 2 y envía un acuse de recibo para X + 2 de regreso a S
Se verá que en este punto la situación ahora es estable y se repite; todos los paquetes a partir de ese momento se duplican (es decir, se envían dos copias idénticas a través de la red).
Peor aún, el mayor número de paquetes que se envían a través de la red probablemente cause congestión , lo que probablemente provocaría que un paquete se retrasara más allá del tiempo de espera una vez más, lo que provocaría que se generara otro paquete duplicado por un tiempo de espera. ya partir de ese momento se enviaría una tercera copia de cada paquete. No hace falta decir que, en ese punto, la situación normalmente se multiplicaría y se generarían más copias, de ahí el nombre que se le da a este patrón de comportamiento.
Para un archivo pequeño, la transferencia se completaría y los paquetes duplicados eventualmente se agotarían de la internetwork. Sin embargo, si el archivo fuera grande, se produciría un colapso congestivo , y solo cuando la transferencia fallara, la masa de paquetes se drenaría de la internetwork.
Solución
La solución a SAS implicó modificar la especificación TFTP para romper el ciclo. [1] Solo la primera instancia de un acuse de recibo recibido debe hacer que se envíe el siguiente bloque de datos; Se ignorarían más copias del acuse de recibo para un bloque de datos en particular, interrumpiendo así el bucle de retransmisión. En la nueva versión del protocolo, un bloque solo se retransmitirá en el tiempo de espera.
Este cambio también permite simplificar la implementación del extremo receptor (a menudo, un programa de arranque escrito en un lenguaje de bajo nivel) omitiendo el temporizador de retransmisión, ya que cualquier paquete perdido provocaría la retransmisión del último paquete enviado por el remitente. Sin embargo, mantener el temporizador tiene sus beneficios, como lidiar con los ACK perdidos de manera más eficiente.
Referencias
- ^ Braden, Robert , ed. (Octubre de 1989). "Síndrome del aprendiz de brujo" . Requisitos para hosts de Internet: aplicación y soporte (rfc) . IETF . págs. 43–45. segundo. 4.2.3.1. doi : 10.17487 / RFC1123 . RFC 1123 . Consultado el 5 de octubre de 2012 .