1 # Guia 1: Nivel de Aplicación 2 3 Redes de Comunicaciones (TB067) - 2C2024 - FIUBA 4 Martin Klöckner - [mklockner@fi.uba.ar](mailto:mklockner@fi.uba.ar) 5 6 \vspace{1em} 7 8 > 1. Para una sesión de comunicación entre un par de procesos, ¿qué proceso es 9 > el cliente y cuál es el servidor? 10 11 El proceso cliente es aquel que inicia la comunicación entre un par de procesos, 12 mientra que el proceso servidor es aquel que espera a que otro proceso inicié la 13 comunicación. 14 15 > 2. Para una aplicación de intercambio de archivos P2P, ¿está de acuerdo con la 16 > afirmación: “No existe la noción de los lados cliente y servidor de una 17 > sesión de comunicación”? ¿Por qué o por qué no? 18 19 No sé está de acuerdo, ya que existe la noción de cliente y servidor en una 20 sesión de transferencia de archivos P2P, solo que cualquier proceso puede 21 ser servidor o cliente, es decir, cualquier proceso puede iniciar la 22 comunicación con otro, o esperar a que otro proceso inicie la comunicación. 23 24 > 3. ¿Qué es un "socket"? 25 26 Un "socket" es un conjunto de datos que permite la comunicación entre dos 27 procesos. Cuando se establece una conexión entre dos procesos, cada proceso debe 28 asignar un socket a esa comunicación. La estructura del socket queda 29 determinada por los procesos que se intentan conectar. 30 31 En el modelo TCP/IP, se habla de un socket de internet, el cual permite la 32 comunicación entre dos procesos, por lo general pertenecientes a computadoras 33 distintas. Los sockets de internet se identifican por su numero de socket, el 34 cual se crea a partir de el protocolo de transporte utilizado en la 35 comunicación, la dirección IP de fuente y destino y el el número de puerto local 36 y de destino. 37 38 > 4. Mencione una aplicación que requiera que no haya pérdida de datos y que 39 > también sea extremadamente sensible al tiempo. 40 41 Un ejemplo puede ser el protocolo SMTP utilizado para la comunicación de correos 42 electrónicos, en este caso es extremadamente importante que no ocurra perdida de 43 datos, ya que pueden transportar información sensible y/o importante; en cuanto 44 al tiempo no es tan importante ya los usuarios pueden permitirse que se demore 45 unos segundos. 46 47 Existen diversos ejemplos siendo la mayoría correspondiente a servicios 48 interactivos en tiempo real, como la telefonía por internet (VoIP), las 49 teleconferencias, o los juegos multijugador. 50 51 > 5. ¿Cuáles son algunas diferencias entre TCP y UDP? 52 53 La principal diferencia entre TCP y UDP es que TCP es más confiable ya que es 54 mas robusto debido a varios mecanismos que lo diferencian de UDP y que lo hacen 55 mas seguro, por ejemplo el proceso de 3 pasos que se utiliza en TCP para 56 iniciar una sesión, o el procedimiento 57 58 > 6. ¿Por qué TCP y UDP no tienen mecanismos de cifrado? 59 60 Porque son protocolos relativamente viejos, los cuales en un principio no 61 estaban pensados en términos de seguridad, y eran relativamente simples. 62 63 Esta falencia se logró compensar con otro protocolo denominado Transport Layer 64 Security (TLS) el cual permite el cifrado de la comunicación a través de una 65 red. 66 67 > 7. ¿Por qué HTTP, SMTP e IMAP se ejecutan sobre TCP en lugar de UDP? 68 69 Porque son protocolos que requieren que no haya perdida de datos. En el caso de 70 SMTP o IMAP que se utilizan para la transmisión de correo electrónicos, la 71 perdida de datos implicaría perdida de la información, la cual puede ser 72 importante. 73 74 > 8. ¿Cuál es la diferencia entre una conexión HTTP persistente y una conexión 75 > no persistente? 76 77 La diferencia radica en que la conexión HTTP persistente una vez finalizada la 78 transferencia de datos continua esperando por datos del usuario hasta que se 79 termine el tiempo de conexión, mientras que la conexión HTTP no persistente 80 termina una vez finalizada la transferencia. 81 82 > 9. ¿El almacenamiento en caché web reducirá la demora para todos los objetos 83 > solicitados por un usuario o solo para algunos de los objetos? ¿Por qué? 84 > ¿En qué casos un almacenamiento en caché web no mejora el tiempo de 85 > respuesta? 86 87 El almacenamiento en caché web (también llamado servidor proxy) siempre reduce 88 la demora en la carga de archivos, ya que por lo general están mas cerca de los 89 usuarios; en tal caso se evita la transferencia desde el servidor, que por lo 90 general suele estar mas lejos al cliente. 91 92 Puede que la copia de datos almacenada en el servidor caché sea obsoleta con 93 respecto a los datos del servidor, en ese caso el servidor caché tendrá que 94 obtener los datos desde el servidor, y en ese caso existe una demora mayor que 95 si no hubiera servidor caché. 96 97 > 10. La siguiente cadena de caracteres ASCII ha sido capturada por Wireshark 98 > cuando el navegador enviaba un mensaje GET HTTP. Responda a las siguientes 99 > cuestiones, indicando en qué parte del siguiente mensaje GET HTTP se 100 > encuentra la respuesta. 101 > a. ¿Cuál es el URL del documento solicitado por el navegador? 102 > b. ¿Qué versión de HTTP se está ejecutando en el navegador? 103 > c. ¿Qué tipo de conexión solicita el navegador, persistente o no 104 > persistente? 105 > d. ¿Cuál es la dirección IP del host en el que se está ejecutando el 106 > navegador? 107 > e. ¿Qué tipo de navegador inicia este mensaje? ¿Por qué es necesario 108 > indicar el tipo de navegador en un mensaje de solicitud HTTP? 109 > ``` 110 > GET /cs453/index.html HTTP/1.1<cr><lf> 111 > Host: gaia.cs.umass.edu<cr><lf> 112 > User-Agent: Mozilla/5.0 (Windows;U; Windows NT 5.1; en-US; rv:1.7.2) 113 > Gecko/20040804 Netscape/7.2 (ax)<cr><lf> 114 > Accept:ext/xml, application/xml, application/xhtml+xml, text/html;q=0.9, 115 > text/plain;q=0.8, > image/png,*/*;q=0.5<cr><lf> 116 > Accept-Language: en-us,en;q=0.5<cr><lf> 117 > Accept-Encoding: zip,deflate<cr><lf> 118 > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7<cr><lf> 119 > Keep-Alive: 300<cr><lf> 120 > Connection:keep-alive<cr><lf><cr><lf> 121 > ``` 122 123 a. La URL del documento solicitado se compone de un protocolo junto con el 124 nombre de host completo, en este caso el protocolo es HTTP y el nombre del 125 host se puede obtner de la seccion `Host` del encabezado, teniendo todo esto 126 en cuenta la URL resultante es `http://gaia.cs.umass.edu/cs453/index.html` 127 b. El navegador está ejecutando la version `1.1` de HTTP, esto se puede ver en 128 la sección `GET /cs453/index.html HTTP/1.1`. En esta version de HTTP es 129 obligatorio incluir el campo `Host` en el encabezado, como se puede ver. 130 c. El navegador solicita una conexión de tipo persistente, la cual es la 131 acción por defecto del protocolo HTTP. Esto se puede ver en la ultima linea del 132 encabezado la cual indica: `Connection:keep-alive`. 133 d. La dirección IP del host en que se esta ejecutan el navegador no se puede 134 sabe ya que no se indica en el encabezado HTTP. 135 e. El tipo de navegador se puede ver en la parte `User-Agent` del encabezado 136 HTTP, en este caso es el navegador Netscape version 7.2 de escritorio, en 137 particular corriendo sobre el sistema operativo Windows NT 5.1; `Mozilla/5.0` 138 indica que es compatible con ese navegador, y se incluye por razones 139 históricas. 140 141 > 11. El siguiente texto muestra la respuesta devuelta por el servidor al mensaje 142 > de solicitud GET HTTP del problema anterior. Responda a las siguientes 143 > cuestiones, indicando en qué parte del siguiente mensaje se encuentran las 144 > respuestas. 145 > a. ¿Ha podido el servidor encontrar el documento? ¿En qué momento se 146 > suministró la respuesta con el documento? 147 > b. ¿Cuándo fue modificado por última vez el documento? 148 > c. ¿Cuántos bytes contiene el documento devuelto? 149 > d. ¿Cuáles son los primeros cinco bytes del documento que se está devolviendo? 150 > e. ¿Ha acordado el servidor emplear una conexión persistente? 151 > ``` 152 > HTTP/1.1 200 OK<cr><lf>Date: Tue, 07 Mar 2008 12:39:45GMT<cr><lf>Server: 153 > Apache/2.0.52 (Fedora) <cr><lf>Last-Modified: Sat, 10 Dec2005 18:27:46 154 > GMT<cr><lf>ETag: ”526c3-f22-a88a4c80”<cr><lf>Accept- Ranges: 155 > bytes<cr><lf>Content-Length: 3874<cr><lf> Keep-Alive: 156 > timeout=max=100<cr><lf>Connection: Keep-Alive<cr><lf>Content-Type: 157 > text/html; charset= ISO-8859-1<cr><lf><cr><lf><!doctype html public ”- 158 > //w3c//dtd html 4.0transitional//en”><lf><html><lf> <head><lf> <meta 159 > http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1”><lf> 160 > <meta name=”GENERATOR” content=”Mozilla/4.79 [en] (Windows NT 5.0; U) 161 > Netscape]”><lf> <title>CMPSCI 453 / 591 / NTU-ST550ASpring 2005 162 > homepage</title><lf></head><lf> <aquí continúa el texto del documento (no 163 > mostrado)> 164 > ``` 165 166 a. Si lo ha podido encontrar ya que el codigo de respuesta es `200 OK`, el 167 moemnto en que se suministro la respuesta fue en la fecha `Tue, 07 Mar 2008 168 12:39:45 GMT`. 169 b. El documento recibido por el servidor fue modificado por utilma vez en la 170 fecha `Sat, 10 Dec 2005 18:27:46 GMT`, como se puede ver en la seccion 171 `Last-Modified` del encabezado. 172 c. El documento devuelto contiene `3874` bytes, esto se puede ver en la etiqueta 173 `Length` del encabezado. 174 d. Los primeros 5 bytes son `<!doc`, la secuencia `<cr><lf><cr><lf>`` indica el 175 termino del encabezado HTTP y luego comienza el documento devuelto 176 (recordemos que cada caracter ocupa 1 byte). 177 e. Si, se puede ver en la etiqueta `Connection:` del encabezado HTTP, la cual 178 indica `Keep-Alive`. 179 180 <!-- `fix vim syntax --> 181 182 > 12. Haga Telnet a un servidor web y envíe un mensaje de solicitud multilínea. 183 > Incluya en el mensaje de solicitud la línea de encabezado 184 > `If-modified-since:` para forzar un mensaje de respuesta con el código de 185 > estado 304 No modificado. 186 187 Se accede utilizando telnet al servidor web `www.example.com` en el puerto 80, 188 de la siguiente manera: 189 190 ```console 191 $ telnet www.example.com 80 192 Connected to example.com. 193 Escape character is '^]'. 194 ``` 195 196 Luego se envia un mensaje multilinea de peticion de `index.html` con el codigo 197 `If-Modified-Since: Wed, 10 Oct 2024 10:00:00 GMT`, con lo cual el servidor 198 responde 199 200 ```console 201 HTTP/1.1 304 Not Modified 202 Accept-Ranges: bytes 203 Age: 596825 204 Cache-Control: max-age=604800 205 Date: Thu, 17 Oct 2024 16:10:53 GMT 206 Etag: "3147526947+gzip" 207 Expires: Thu, 24 Oct 2024 16:10:53 GMT 208 Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT 209 Server: ECAcc (mid/871B) 210 Vary: Accept-Encoding 211 X-Cache: HIT 212 ``` 213 214 Notese que se agrega el campo `Host: example.com` ya que este servidor acepta 215 HTTP versión 1.1 y en esa version es obligatorio este campo. 216 217 > 13. La LAN de una universidad tiene una velocidad de transmisión de 100 Mbps. 218 > Para acceder a Internet tiene un enlace de acceso cuya velocidad de 219 > transmisión es de 10 Mbps. La velocidad media de paquetes es de 20 220 > solicitudes / seg. Si cada paquete es de 1Mbit, se pide: 221 > a. La velocidad media de los bits en bits/seg. 222 > b. La intensidad de tráfico en la LAN. 223 > c. La intensidad de tráfico en el enlace de acceso. 224 > d. ¿Cómo son las intensidades de tráfico calculadas comparadas con 1? ¿Qué 225 > significa esa comparación en términos de retardos? 226 > e. Proponga dos soluciones posibles para bajar la intensidad de tráfico en 227 > el enlace de acceso. 228 > f. Suponga que la universidad instala una caché y que la tasa de acierto 229 > es de 0,45. ¿Qué porcentaje de solicitudes serán satisfechas casi de 230 > inmediato?¿Qué porcentaje de solicitudes serán satisfechas por los 231 > servidores de origen? 232 233 a. Por enunciado cada paquete es de `1 Mbit`, y ademas cada solicitud 234 corresponde con un pquete, por lo tanto la velocidad emdia resulta: 235 \vspace{0.25em} 236 $$V_{media} = 1 \nicefrac{Mbit}{Paquete}\cdot 20 237 \ \nicefrac{Paquete}{s}\Rightarrow \boxed{V_{media} = 20 \nicefrac{Mbit}{s} = 238 20 Mbps}$$ 239 b. La intensidad de trafico se puede calcular mediante la siguiente expresión: 240 $$I = \frac{L\cdot a}{V_{trans}} = \frac{V_{media}}{V_{trans}}$$ 241 \vspace{0.25em} 242 Donde $L$ es la longitud de un paquete, $a$, la velocidad media de un 243 paquete, $V_{media}$ la velocidad media de los paquetes y $V_{trans}$ la 244 velocidad de transmisión de la red LAN. Reemplazando con los valores resulta: 245 $$I = \frac{20\ Mbps}{100\ Mbps} \Rightarrow\boxed{I = 0.2}$$ 246 \vspace{0.25em} 247 c. Reutilizando la expresion anterior pero reemplazando la velocidad de 248 transmisión de la red LAN por la red de acceso resulta: 249 $$I = \frac{20\ Mbps}{10\ Mbps} \Rightarrow\boxed{I = 2}$$ 250 d. En el primer caso es menor a 1, mientra que en el segundo caso es mayor. Que 251 sea mayor a 1 implica que va a haver un retardo en la transmision de paquetes 252 ya que la red no da abasto. 253 e. Una solución puede ser incrementar la velocidad de transmisión, otra solucion 254 puede ser decrementar la longitud de los paquetes, otra solucion tambien 255 puede ser implementar un servidor caché. 256 f. El porcentaje de las solicitudes que serán satisfechas casi de inmediato será 257 el 45\% de las solicitudes, el 55\% restante tendran que ser satisfechas por 258 los servidores de origen. 259 260 > 14. Un cliente HTTP desea recuperar un documento web que se encuentra en un 261 > URL dado. Inicialmente, la dirección IP del servidor HTTP es desconocida. 262 > ¿Qué protocolos de la capa de aplicación y de la capa de transporte además 263 > de HTTP son necesarios en este escenario? 264 265 En principio para obtener la direccion IP del servidor HTTP se necesita el 266 protocolo del nivel de aplicacion DNS, de manera tal que resuelva la URL y 267 obtenga asi la direccion IP del servidor, luego se necesita un protocolo de la 268 capa de aplicacion que realice una peticion al servidor HTTP por el archivo, por 269 ejemplo FTP; el protocolo FTP utiliza el protocolo de transporte TCP para obtner 270 los archivos del servidor. 271 272 > 15. Mencione 3 motivos por los cuales un servidor de DNS no puede ser 273 > centralizado. 274 275 En principio porque un servidor DNS es critico para resolver la URL de otros 276 servidores de internet, por lo que ser centralizado implicaria la 277 **dependencia** de una sola organizacion o servidor central. Otro motivo es la 278 enorme cantidad de **tráfico** que este servidor centralizado tendria que 279 manejar. Por ultimo que un servidor sea centralizado implicaria una enorme 280 perdida de **rendimiento**, ya que cualquier region que quiera acceder a 281 internet deberia pasar por este servidor centralizado, que puede que esté a una 282 distancia muy lejana. 283 284 > 16. Dada la jerarquía de servidores DNS (Servidores DNS raíz, Servidores de 285 > dominio de nivel superior y servidores autoritativos) se pide 286 > a. ¿Qué direcciones IP proporcionan cada uno? 287 > b. Cuando un host realiza una consulta DNS, ¿a qué tipo de servidor de 288 > DNS, que actúa como proxy llega? 289 > c. Llamamos R al Servidor DNS raíz, T al Servidor TLD, A al servidor 290 > autoritativo, L al servidor local y H al host que realiza la consulta. 291 > Suponíamos que el servidor TLD conoce el servidor DNS autoritativo 292 > correspondiente al nombre de host. Indique el trayecto del mensaje de 293 > consulta desde que el host lo inicia hasta que obtiene la dirección IP 294 > del host consultado mediante la letra correspondiente, un guión, la 295 > letra siguiente y así sucesivamente. 296 > d. ¿Cuántos mensajes DNS se necesitan enviar para obtener la dirección 297 > correspondiente a un nombre de host si no se encuentra en el proxy del 298 > servidor local y el servidor TLD conoce el servidor DNS autoritativo 299 > correspondiente al nombre del host consultado? 300 301 a. Supongamos el host `www.example.com`, para resolver la dirección IP de este 302 host se comienza a resolver la dirección IP de cada campo separado por punto 303 `.` de derecha a izquierda. 304 En primer lugar el cliente quien desea hallar la dirección IP del host, hace 305 una petición a un servidor DNS raíz por la dirección IP del campo `com`, el 306 DNS devuelve las direccionen IP de los servidores DNS de dominio de nivel 307 superior (TLD) correspondientes a `com`, luego el cliente hace una nueva 308 petición a uno de estos servidores TLD, el cual responde con la dirección IP 309 de un servidor DNS autoritativo para el dominio `example.com`, finalmente 310 este servidor DNS autoritativo es quien resuelve la dirección IP del host 311 `www.example.com`. 312 b. Cuando un host realiza una consulta DNS, esta se envía al servidor DNS local, 313 el cual actúa como proxy. Este servidor DNS local, no pertenece a la 314 jerarquía de servidores DNS, si no que cada proveedor de internet (ISP) 315 dispone de servidor DNS local. 316 c. Suponiendo que el servidor TLD conoce el servidor DNS autoritativo 317 correspondiente al nombre de host, entonces el mensaje de consulta sigue el 318 siguiente trayecto: `H -> L -> R -> T -> A` 319 d. Se requiere un total de 8 mensajes 4 de petición y 4 respuestas, las 320 321 > 17. ¿Cuál es la diferencia entre consultas de DNS iterativas y consultas 322 > recursivas? 323 324 Una consulta DNS recursiva ocurre cuando un servidor DNS se comunica con otros 325 servidores DNS para intentar resolver una dirección URL y devolverla al cliente, 326 en cambio, una consulta DNS iterativa ocurre cuando el cliente se comunica 327 directamente con cada servidor DNS involucrado en la resolución de la dirección 328 URL[^1]. 329 330 Por lo general los clientes realizan consultas iterativas a los servidores DNS y 331 estos si realizan consultas recursivas para resolver la dirección IP solicitada 332 por el cliente. 333 334 [^1]: [https://www.cloudflare.com/learning/dns/what-is-recursive-dns/](https://www.cloudflare.com/learning/dns/what-is-recursive-dns/) 335 336 > 18. Dado que la correspondencia entre el nombre de un host y su dirección IP 337 > puede cambiar, ¿cuál es el comportamiento de un servidor de DNS respecto 338 > de la información almacenada en su caché DNS para prevenir esto? 339 340 Para prevenir esto los servidores DNS descartan la información almacenada en 341 cache pasado un cierto tiempo, por lo general un par de días. 342 343 > 19. Un cliente se conecta a una aplicación de home banking basada en la web 344 > mediante protocolo HTTP, el cual no tiene memoria del estado de la 345 > conexión. Una vez que inició sesión, ¿cómo identifica el servidor al 346 > cliente? 347 348 El servidor identifica al cliente mediante el uso de Cookies. Para que un sitio 349 pueda utilizar Cookies se necesitan 4 cosas: 350 351 * Una linea de cabecera de la cookie en el mensaje de respuesta. 352 * Una línea de cabecera de la cookie en el mensaje de solicitud HTTP. 353 * El archivo de cookies almacenado en el sistema terminal del usuario y 354 * gestionado por el navegador del usuario. 355 * Una base de datos back-end en el sitio web. 356 357 > 20. Supongamos que estás realizando un análisis de tráfico de red y te 358 > encuentras con la siguiente captura de dos paquetes DNS relacionados con 359 > la resolución de nombres de dominio para "wireshark.org". 360 > a. ¿Qué tipo de consulta DNS se envía en el primer paquete y quién la 361 > realiza? 362 > b. ¿Cuál es la dirección IP del servidor DNS al que se envía la consulta 363 > DNS en el primer paquete? 364 > c. ¿Qué tipo de respuesta se recibe en el segundo paquete y cuál es la 365 > dirección IP asociada al nombre de dominio "wireshark.org"? 366 > d. ¿Cuáles son las direcciones MAC de origen y destino en ambos paquetes 367 > Ethernet? 368 > e. ¿Puedes explicar por qué el puerto de origen y destino cambia entre la 369 > consulta DNS en el primer paquete y la respuesta DNS en el segundo 370 > paquete? 371 >  372 373 a. En el primer paquete se envía una petición de resolución del dominio 374 `wireshark.org`. La consulta es de tipo A, por lo que se espera la dirección 375 IPv4 de ese dominio. 376 b. El servidor DNS al que se realiza la consulta tiene la dirección IP 377 `205.152.37.23`. 378 c. Se recibe una respuesta exitosa del servidor DNS con la dirección IP 379 `128.121.50.122`. La respuesta que se recibe una entrada de tipo A, la cual 380 corresponde con una dirección IPv4. 381 d. Las dirección MAC del paquete que realiza la consulta y la del paquete que 382 envía la respuesta es `00:16:ce:6e:8b:24` y `00:05:5d:21:99:4c` 383 respectivamente. 384 e. Puede que sea debido a que el servidor DNS al que se hace la consulta no 385 dispone de la entrada correspondiente a esa dirección IP, por lo que debe 386 realizar peticiones recursivas a otros servidores DNS. 387 388 > 21. Descargar, analizar mediante Wireshark y contestar las preguntas sobre la 389 > transmisión de datos HTTP relacionada con la descarga de un archivo de 390 > imagen desde un servidor web a partir de la captura de paquetes de 391 > HTTP.cap del siguiente enlace: 392 > [https://packetlife.net/captures/category/web/](https://packetlife.net/captures/category/web/) 393 > a. ¿Qué recurso se está solicitando en el primer paquete HTTP y quién 394 > realiza la solicitud? 395 > b. ¿Cuál es el código de estado de la respuesta del servidor en el segundo 396 > paquete y qué significa este código? 397 > c. ¿Qué tipo de archivo se está transfiriendo según la información 398 > proporcionada en la captura? 399 > d. ¿Cuál es el tamaño del contenido (en bytes) de la imagen que se está 400 > transfiriendo según la respuesta del servidor? 401 > e. ¿Cuál es la longitud de la respuesta HTTP (en bytes) en el segundo 402 > paquete? 403 > f. ¿Cuál es la fecha y hora en que se envió la respuesta del servidor al 404 > cliente según los datos proporcionados en la captura? 405 406 Teniendo en cuenta que el contenido, cuya URL es la del enunciado, ya no está 407 disponible, se utiliza el contenido brindado por el sitio web 408 [http://www.columbia.edu/~fdc/sample.html](http://www.columbia.edu/~fdc/sample.html), 409 en particular se utiliza la imagen cuyo link es el siguiente 410 [http://www.columbia.edu/~fdc/picture-of-something.jpg](http://www.columbia.edu/~fdc/picture-of-something.jpg). 411 412 Para la descarga de la imagen se utiliza la herramienta de linea de comandos 413 [wget](https://linux.die.net/man/1/wget) proporcionando el link de la imagen a 414 descargar como único argumento, como se muestra a continuación: 415 416 ```console 417 $ wget http://www.columbia.edu/~fdc/picture-of-something.jpg 418 ``` 419 420 a. Descartando las consultas DNS, y luego de establecida la sesión TCP 421 (protocolo correspondiente al nivel de transporte), el encabezado HTTP del 422 primer mensaje HTTP contiene lo siguiente: 423 424 ```text 425 GET /~fdc/picture-of-something.jpg 426 HTTP/1.1 Host: www.columbia.edu 427 User-Agent: Wget/1.21.3 428 Accept: */* Accept-Encoding: identity Connection: 429 Keep-Alive 430 ``` 431 432 Se puede ver que realiza una consulta HTTP version 1.1 por el archivo cuya 433 ruta es `/~fdc/picture-of-something.jpg`, luego se incluye el Host, el cual 434 es obligatorio en esta version de HTTP y también se puede ver que la conexión 435 es de tipo `Keep-Alive` 436 b. La primer linea del encabezado del mensaje HTTP que responde el servidor, 437 contiene `HTTP/1.1 200 OK` por lo tanto, el servidor responde con código de 438 respuesta `200 OK`. 439 c. El archivo que se esta transfiriendo es de formato `image/jpeg`, se puede ver 440 el campo `Content-Type` de la cabecera de respuesta. 441 d. El campo `Content-Length` indica el tamaño en bytes del archivo transferido, 442 en este caso el campo en la cabecera indica `44566` bytes. 443 e. En total, contando la cabecera HTTP, la cual ocupa `1605` bytes y el archivo 444 enviado, cuyo tamaño es `44566` bytes, el tamaño en bytes de la respuesta del 445 servidor resulta de `46205` bytes, 446 f. Según el campo `Date` del encabezado del mensaje de respuesta, la fecha en la 447 que se envió es `Sat, 19 Oct 2024 22:18:03 GMT`. 448 449 > 22. Enviar un mensaje de consulta DNS directamente desde el host en el que 450 > está trabajando al servidor `google.com.ar` mediante el comando 451 > `nslookup`. 452 > a. ¿Qué información devuelve este comando? 453 > b. ¿Cuál es la dirección IP del servidor web de google.com.ar? 454 > c. ¿Cuál es la dirección IP del servidor DNS que proporcionó la respuesta 455 > al comando `nslookup`? 456 > d. La respuesta de este comando proporciona dos datos, ¿Que representa 457 > cada uno? 458 > e. Existen tres clases de servidores DNS: los servidores DNS raíz, los 459 > servidores DNS de dominio de nivel superior (TLD, Top-Level Domain) y 460 > los servidores DNS autoritativos. ¿Qué servidor, según el esquema de 461 > la figura siguiente, devuelve esta información? 462 > { width=45% } 463 464 a. Al ejecutar el comando, se obtiene la salida que se muestra a continuación: 465 466 ```console 467 $ nslookup google.com.ar 468 ;; Got recursion not available from 186.130.128.250, trying next server 469 ;; Got recursion not available from 186.130.129.250 470 Server: 186.130.129.250 471 Address: 186.130.129.250#53 472 473 Non-authoritative answer: 474 Name: google.com.ar 475 Address: 172.217.173.227 476 ;; Got recursion not available from 186.130.128.250, trying next server 477 Name: google.com.ar 478 Address: 2800:3f0:4002:80f::2003 479 ``` 480 Se puede ver que el comando hace una consulta DNS de la dirección pasada como 481 argumento. 482 b. Según la salida del comando anterior la dirección IPv4 es `172.217.173.227`, 483 mientras que la dirección IPv6 es `2800:3f0:4002:80f::2003`. 484 c. Se puede ver que la salida del comando sugiere que se realiza una consulta 485 recursive del servidor cuya dirección IPv4 es `186.130.128.250` al servidor 486 cuya dirección IPv4 es `186.130.129.250`, siendo esta ultima la que 487 proporciona una respuesta al cliente quien ejecuta el comando `nslookup`. 488 d. La respuesta del comando proporciona dos direcciones IP correspondientes a 489 las dos versiones del protocolo: IPv4 e IPv6. 490 e. Según el esquema quien proporciona la respuesta es un servidor Local 491 492 > 23. Para el comando `nslookup -type=NS fi.uba.ar` se pide: 493 > a. ¿Qué información devuelve el comando? 494 > b. ¿La respuesta al comando `nslookup` provino de un servidor autorizado o 495 > no autorizado? 496 > c. ¿Qué significa “Respuesta no autoritativa” en la respuesta? 497 > d. ¿De qué tipo es el archivo de recursos que contiene la información 498 > devuelta? 499 > e. ¿Por qué hay dos tipos diferentes de direcciones IP? 500 501 a. Al ejecutar el comando se obtiene los siguiente: 502 503 ```console 504 $ nslookup -type=NS fi.uba.ar 505 Server: 186.130.128.250 506 Address: 186.130.128.250#53 507 508 Non-authoritative answer: 509 fi.uba.ar nameserver = ns1.fi.uba.ar. 510 fi.uba.ar nameserver = ns4.fi.uba.ar. 511 fi.uba.ar nameserver = ns1.uba.ar. 512 fi.uba.ar nameserver = ns2.fi.uba.ar. 513 514 Authoritative answers can be found from: 515 ``` 516 517 Lo cual corresponde con todos los servidores autoritativos de la dirección de 518 host `fi.uba.ar`. 519 b. La salida del comando sugiere que la respuesta provino de un servidor no 520 autorizado. 521 c. Respuesta no autoritativa significa que el servidor tenia almacenada la 522 información porque provino de otro servidor, es decir, no es información que 523 alguien haya grabado manualmente en los archivos de ese servidor. 524 525 > 24. ¿Qué respuesta aparece en la pantalla con el comando `nslookup 157.92.1.1`? 526 527 La respuesta que aparece es la siguiente 528 529 ```console 530 $ nslookup 157.92.1.1 531 1.1.92.157.in-addr.arpa name = ns1.uba.ar. 532 533 Authoritative answers can be found from: 534 ``` 535 536 > 25. DNS usa UDP en vez de TCP. Si se pierde un paquete DNS, no hay 537 > recuperación automática. ¿Provoca esto un problema y, de ser así, cómo se 538 > resuelve? 539 540 Provoca un problema ya que la consulta DNS obtiene un retardo, pero no es un 541 problema ya que en caso de falla el cliente que realiza la consulta DNS puede 542 realizar otra petición DNS a un servidor diferente. 543 544 > 26. Suponga que en `UDPCliente.py`[^2], después de crear el socket, añadimos esta 545 > línea: `clientSocket.bind((’’, 5432))` 546 > a. ¿Será necesario modificar el programa `UDPServidor.py`[^3]? 547 > b. ¿Cuáles son los números de puerto para los sockets en `UDPCliente.py` y 548 > `UDPServidor.py` luego del cambio? 549 > c. ¿Cuáles eran antes de realizar este cambio? 550 551 [^2]: Kurose, J. F. (2017). Redes de computadoras. Pearson. (p. 133) 552 [^3]: Kurose, J. F. (2017). Redes de computadoras. Pearson. (p. 134) 553 554 El archivo `UDPCliente.py` contiene lo siguiente: 555 556 ```python 557 from socket import * 558 serverName = 'hostname' 559 serverPort = 12000 560 clientSocket = socket(AF_INET, SOCK_DGRAM) 561 message = raw_input('Escriba una frase en minúsculas: ') 562 clientSocket.sendto(message.encode(), (serverName, serverPort)) 563 modifiedMessage, serverAddress = clientSocket.recvfrom(2048) 564 print(modifiedMessage.decode()) 565 clientSocket.close() 566 ``` 567 Mientras que el archivo `UDPServidor.py` contiene lo siguiente: 568 569 ```python 570 from socket import * 571 serverPort = 12000 572 serverSocket = socket(AF_INET, SOCK_DGRAM) 573 serverSocket.bind(('', serverPort)) 574 print("El servidor está listo para recibir") 575 while True: 576 message, clientAddress = serverSocket.recvfrom(2048) 577 modifiedMessage = message.decode().upper() 578 serverSocket.sendto(modifiedMessage.encode(), clientAddress) 579 ``` 580 581 Agregar la linea `clientSocket.bind((’’, 5432))` al archivo `UDPCliente.py` 582 luego de crear el socket resulta en el archivo de la siguiente manera: 583 584 ```python 585 from socket import * 586 serverName = 'localhost' 587 serverPort = 12000 588 clientSocket = socket(AF_INET, SOCK_DGRAM) 589 clientSocket.bind(('', 5432)) 590 message = raw_input(’Escriba una frase en minúsculas:’) 591 clientSocket.sendto(message.encode(),(serverName, serverPort)) 592 modifiedMessage, serverAddress = clientSocket.recvfrom(2048) 593 print(modifiedMessage.decode()) 594 clientSocket.close() 595 ``` 596 597 Esta linea que se agrega luego de crear el socket provoca que el cliente intente 598 asociar el socket con el numero de puerto `5432` a la dirección IP de host, en 599 este caso se utiliza `localhost` (alias a `127.0.0.1`). 600 601 <!-- 602 El resultado de ejecutar el nuevo script tiene dos resultados los cuales 603 dependen de si el servidor se ejecuta primero o el cliente. En el primer caso, 604 el servidor se ejecuta primer asociando el socket creado a la dirección IP, esto 605 provoca un error en el cliente ya que al intentar asociar su socket a la 606 dirección IP se produce un error ya que la dirección IP ya tiene un socket 607 asociado; en el segundo caso, el cliente se ejecuta primero asociando su socket 608 a la dirección IP, esto provoca un error en el servidor ya que al intentar 609 asociar su socket a la dirección IP se produce el mismo error que en el caso 610 anterior para el cliente, error de que la dirección IP ya tiene u socket 611 asociado. 612 613 a. Una solución puede ser crear otro socket en el cliente con un nuevo puerto y 614 asociar este nuevo puerto con la linea agregada, de esta manera tanto el 615 servidor como cliente escucharían en la dirección IP utilizada. 616 --> 617 618 a. No es necesario modificar el archivo `UDPServidor.py` ya que el numero de 619 puerto es diferente al utilizado en el servidor, en caso de que sea el mismo 620 si se produce un error ya que el socket solo puede estar asociado a un solo 621 extremo de la comunicación. 622 b. Luego del cambio tanto el cliente como el servidor escuchan en la dirección 623 IP del host, siendo la única diferencia el numero de puerto, para el servidor 624 el numero de puerto que escucha es el `12000`, mientras que el cliente 625 escucha en el numero de puerto `5432`. 626 c. Antes de agregar la linea, el cliente no tenía un numero de puerto asociado, 627 simplemente enviaba los mensajes al puerto `12000` que ya estaba asociado al 628 socket del servidor. 629 630 <!-- 631 > 27. Análisis de captura de paquetes del protocolo DNS. 632 > a. Mediante el comando `ipconfig /all` obtener 633 > * Dirección IPv4 e IPv6 la placa de red o de WiFi según corresponda. 634 > * Dirección MAC 635 > * Dirección IP de la puerta de enlace predeterminada 636 > * Direcciones IP del servidor DNS 637 > 638 > b. En Wireshark, en Interface List (captura-opciones-entrada) elija la 639 > asociada a la IP y MAC registrada en a. Guardar la captura en un archivo 640 > llamado `ejercicio30.pcap` (captura-opciones-salida) 641 > c. Comience a capturar paquetes. 642 > d. Ir a www.google.com en un navegador. 643 > e. Al ver la página de Google detenga la captura de paquetes. 644 > f. Filtre paquetes DNS Si no se ve ninguno, cerrar el navegador web y 645 > enviar el comando ipconfig /flushdns. Repetir los pasos desde b. Si no 646 > se ven paquetes DNS, enviar el comando nslookup www.google.com en vez 647 > de usar el navegador. 648 > g. Busque un paquete standard query (A) google.com y complete la tabla: 649 > 650 > Número de trama: 651 > Cantidad de bytes capturados: 652 > Dirección MAC de origen: 653 > Dirección MAC registrada en a): 654 > Dirección MAC de destino: 655 > Dirección IP de origen: 656 > Dirección IP registrada en a): 657 > Dirección IP de destino: 658 > Dirección IP de la puerta de enlace predeterminada registrada en a) 659 -->
