Preguntas y respuestas sobre UDP, TCP y control de flujo
Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones
Escrito el en 
español con un tamaño de 7,58 KB
- ¿Qué sucede si por error recibiera UDP un datagrama UDP destinado a otra máquina? La cabecera UDP tiene un checksum opcional, que utiliza para su cálculo la dirección IP destino para comprobar si el datagrama UDP ha llegado correctamente. Hay dos opciones:
- Checksum a cero: no lleva checksum, por tanto el proceso UDP intentará entregar los datos a través del puerto especificado en el datagrama UDP.
- Checksum distinto de cero: al comprobarlo se detectaría el error y se descartaría el datagrama.
- ¿Por qué es necesario incluir el checksum en IP, TCP y opcionalmente en UDP, cuando a nivel de trama ya se aplica uno? El checksum a nivel de trama solo capta errores a nivel de transmisión. Cuando el router intermedio extrae el datagrama, lo comprueba y lo vuelve a encapsular, al encapsular las cabeceras pueden haber errores de procesamiento que no serían detectados por el checksum de trama, en cambio si usamos checksum IP, TCP y UDP si lo podríamos detectar.
- ¿Cómo se puede distinguir a qué aplicación debe entregar UDP el datagrama que acaba de llegar? Tras verificar si el checksum es correcto, entregará el contenido a la aplicación que se encuentre escuchando en el puerto destino, información que indica la cabecera del mensaje UDP.
- ¿Tiene algún sentido hablar de conexión entre dos computadores que se comunican mediante UDP? No lo tiene puesto que UDP no es un servicio orientado a conexión.
- Si la pseudocabecera no se transmite, ¿cómo se puede comprobar en el destino si el checksum es correcto? En el origen se calcula el checksum sobre el datagrama UDP, al que se le anexa una pseudocabecera. Cuando el destino recibe el datagrama UDP primero tiene que reconstruir la pseudocabecera, pidiéndole al protocolo IP toda la información necesaria. Cuando se tenga que reconstruir la pseudocabecera, se guardará el valor del checksum del datagrama UDP entrante y en su lugar se pone un 0, después se adjunta la pseudocabecera al datagrama UDP y se calcula el checksum. Si el checksum calculado no coincide con el que venía en el datagrama UDP significa que hay un error y se descarta el datagrama, si coincide se sigue con el procesamiento del datagrama UDP.
- ¿Por qué es necesario usar timeouts que se adapten a las condiciones dinámicas de la red? Dado que el RTT de una conexión TCP puede cambiar radicalmente, no podemos tener un timeout fijo, puesto que un timeout pequeño provocaría retransmisiones innecesarias y un timeout muy grande una lenta reacción entre segmentos perdidos.
- ¿Qué diferencia hay entre las llamadas de los close y shutdown? ¿Cuándo utilizarías shutdown en vez de close? La diferencia principal es que close elimina el socket y todos los recursos asociados a él, mientras que shutdown realiza un cierre de conexión más detallada. Se utiliza shutdown para sockets de tipo SOCK_STREAM.
- Un hacker transmite mensajes TCP con el bit RST activado en el puerto 80. ¿Qué pretende? ¿Por qué no tiene efecto? ¿Qué le recomendarías? Pretende reiniciar la conexión, no tiene efecto porque si no se solicita un paquete con el RST activado es ignorado. Debería enviar un mensaje a otro usuario para que este le conteste y así establecer conexión y poder enviarlo.
- Control de Congestión TCP. ¿En qué consiste el procedimiento conocido como Slow-Start? ¿Cuándo se aplica? Explicar brevemente. Slow-start es un algoritmo de control de congestión del protocolo TCP. Ni el emisor ni el receptor tienen forma de saber cuál es el máximo volumen de datos que puede transmitir la red, ninguno tiene información sobre los elementos de red que transmitirán la información. Si la red se satura comenzará a descartar paquetes, que tendrán que ser retransmitidos, lo cual puede incrementar aún más la saturación de la red. La solución que plantea este algoritmo consiste en comenzar enviando un volumen de datos pequeño, que se irá aumentando hasta que la red se sature, en cuyo caso se reducirá la tasa de envío para reducir la saturación.
- En el protocolo TCP, la duración de los temporizadores para la retransmisión es crítica. ¿Qué sucede si su duración es demasiado corta? ¿Qué pasa si, por el contrario, su duración es demasiado larga? Timeout largo: lenta reacción de los segmentos perdidos. Timeout corto: retransmisiones innecesarias.
- El protocolo TCP utiliza un control de flujo basado en ventana deslizante. Las ventanas de recepción son de tamaño variable, pudiendo cerrarse completamente. ¿Qué utilidad puede tener esto? ¿Por qué no se definen de tamaño fijo, facilitando el manejo de las mismas? En TCP, el tamaño de las ventanas de recepción es variable. Cuando se establece la conexión se negocian los tamaños iniciales de las mismas, pudiendo variar a lo largo de la conexión. Esto nos permite realizar un control de flujo extremo a extremo que el TCP gestiona en función de los recursos disponibles (memoria).
- En una LAN con RTT estimado de 1ms, indica la velocidad máxima de transmisión que debe alcanzar esta red (BW efectivo) para que se logre una utilización del 100% de su ancho de banda con una única conexión TCP. RTT=1ms, 64KB ----- 1ms, Máximo 64KB por RTT, X KB ------- 1000ms, X = 64*10^3 = 64KB*10^3 segundos = 512 MB/s
- Una conexión TCP abierta, está caracterizada en uno de sus extremos por los siguientes parámetros: A partir de entonces, se producen los siguientes eventos (Ti < Ti+1):
T1 – Se recibe un nuevo ACK válido: Si se recibe un ACK válido, la ventana de congestión aumenta exponencialmente y valdría 8. Lo demás es constante.
T2 – Se recibe un nuevo ACK válido: La ventana de congestión pasaría a 9 y como la ventana de transmisión es la menor entre la ventana de recepción y la ventana de congestión sería 9.
T3 – Se recibe un segmento con indicación de ventana de recepción de 20 MSS: La ventana de congestión serían 10, la ventana de recepción serían 20 y como la ventana de transmisión es la menor de las 2 sería 10.
T4 – Se produce un timeout: Al producirse un timeout, la ventana de congestión se reiniciaría a 1 y se aplicaría otra vez el slow start, el threshold se reduce a la mitad que son 5. La ventana de recepción sigue siendo 20. - ¿Por qué al hacer la llamada bind en un servidor siempre debemos especificar la dirección del socket local? ¿Por qué no es necesario especificar la dirección local cuando el bind se hace a través de un connect en un cliente? Porque asocias una dirección de socket local y un puerto BC. No es necesario connect porque este asigna a nuestro socket la dirección IP de nuestra máquina y un número de puerto libre.
- ¿Qué efecto tiene una llamada a la función connect sobre un socket UDP? Establece una asociación entre cliente y servidor. Tras el connect, se pueden enviar los datos sin identificar el destino, solo se aceptan datagramas en la dirección correcta.
- ¿Para qué sirve la llamada al sistema BIND? Asigna la dirección local a un socket recién creado, también asigna una dirección que identifique al socket.
- ¿Para qué sirve la llamada al sistema LISTEN? Pasa al socket a modo pasivo, dispuesto a encajar posiciones de connect. Antes de ACCEPT, después de BIND, solo para sockets de tipo SOCK_STREAM (TCP).