REDES Y COMUNICACIONES – 05-04-2023

51
Son aplicaciones que utilizamos como usuarios, las aplicaciones de red se le llaman a programas que corren en la
computadora pero para su funcionamiento necesitan tener si o si algún tipo de conectividad para llevar a cabo su tarea.
Ejemplo si envió un mail y la computadora no tiene conectividad a la red no serviría de nada. Entonces una aplicación de
red es una aplicación que requiere de la red para llevar a cabo su normal funcionamiento.

Acá tenemos que las aplicaciones tanto las que utilizamos nosotros como las que nos dan los servicios como puede ser
un servidor u otro cliente en una p2p, corren en los sistemas clientes, ósea las aplicaciones de red corren en las maquinas
donde tenemos un cliente/usuario sentado utilizándola, NO CORREN aplicaciones de red en los dispositivos que arman la
red como por ejemplo los routers, y los switches.

52
En el grafico tenemos: que es un host donde tenemos una aplicación de red, pero en estos equipos que son

routers que forman toda la malla que sería la red por la cual estamos circulando con la información, y no
tenemos una pantalla donde hay un usuario o cliente trabajando, obviamente estas rutas van a tener un tipo de forma
para poder acceder para configurarlo, pero aquí no vamos a correr un Ej. navegador, ejecutar un programa, ejecutar un
juego de red, ni similares, PORQUE justamente las aplicaciones de red van a correr justamente van a correr en los sistemas

terminales o lo que llamamos host ya sean pc, servidores, celulares (también corren aplicaciones de red) o
dispositivos móviles. Y los dispositivos de red van a correr software específico que nos va a hacer posible que estos equipos
sepan cómo hacer para comunicar, cuando queremos ir de un dispositivo a otro, los routers van a tener algún tipo de
código que nos va a encaminar la comunicación para que llegue de un extremo a otro.

Si vemos la imagen vemos los diferentes modelos, cliente: tenemos el modelo completo las 5 capas (física, enlace, red,
transporte y aplicación), pero en los routers el modelo que tenemos es (física, enlace, red, faltaría transporte y aplicación),
porque no hay software de aplicación no implementa esas dos capas porque no hay software de aplicación y transporte
en un router y el switch es aún más básico tiene solo 2 capas (física y de enlace) por que el switch trabaja a nivel de la red
de internet.

53
Habíamos dicho el servidor iba a ser una computadora que va a estar siempre encendida / prendida, y va a estar
siempre prendida porque va a estar siempre disponible esperando que alguien le haga algún pedido de servicio, (la
dirección I.P. es un número que identifica a cada uno de los dispositivos dentro de toda la red del mundo, es un numero
único en el mundo, es como la dirección de una casa, el IP no cambia.). El número del IP del servidor no cambia para poder
ubicarlo para solicitar servicios, y cuando queremos hacer algo que necesite atender mucha cantidad de clientes Ej. gmail,
existen lo que se llaman las GRANJAS donde tendríamos muchos servidores que están dando el mismo servicio y que se
reparten la carga entre ellos para poder dar un servicio con un tiempo de respuesta razonables esa granja puede ser que
este toda en un solo lugar o incluso distribuidos físicamente en el mundo.

54
Habíamos visto también la arquitectura Peer to Peer P2P, en la cual no había servidores definidos sino que todas las
maquinas tenían el mismo nivel jerárquico y trabajan cada una pidiendo o dando una respuesta de forma indistinta, son
como si fueran clientes y servidores al mismo tiempo, pero lo que cambiaba mucho podíamos tener diferentes IP, que el
IP vaya cambiando (en el caso del servidor si le afecta que le cambien el IP), las maquinas podían estar encendidas o
apagadas (on/off) (en el caso de los servidores era necesario que este 24hs prendidos). Esto es más escalable que un
servidor, pero es mucho más difícil de gestionar, porque cada máquina hace lo que quiere, no hay una gestión hecha de
forma centralizada.

Después tenemos el caso de los híbridos que busca utilizar los beneficios de los 2. Que podría ser el caso de la mensajería
instantánea: Email, los mensajes van de usuario a usuario, no pasa por un servidor, eso utiliza el modelo p2p pero cuando
nosotros queremos saber si el usuario está conectado o desconectado donde está ubicado y eso, el usuario cuando se
conecta al sistema se registran esos datos en un servidor, (eso sería centralizado en un server). Entonces todos podemos
conectarnos al server para conocer el estado de todos nuestros contactos (conectado/desconectado/mensaje de estado
en whatssap) todo eso se solicita al servidor, pero cuando se realiza una comunicación se hace entre pares p2p. Los
sistemas híbridos tratan de tomar todas las ventajas de ambos sistemas.

55
Retomando un poco el proceso de cómo se comunican (como corre dentro del Windows/Linux) como se comunica un
proceso con otro dentro de una máquina, para hacer la comparativa de cómo nos vamos a comunicar con procesos que
están en distintas maquinas. Si nosotros tenemos varios procesos corriendo en una computadora Ej. Si tenemos 2
procesos, un proceso es un programa básicamente, es decir 2 programas ejecutándose, se utiliza un SISTEMA que se llama
IPC (Intra Process Comunication) Comunicación entre procesos (dentro de una misma maquina: no requiere conexión a
internet), esto es algo que implementa básicamente el sistema operativo, el sistema operativo define de qué manera un
proceso puede mandar un mensaje a otro proceso dentro de la misma máquina.

Si el Proceso A se quiere Conectar con el Proceso B, ya no tiene forma de hacerlo directamente a través del sistema
operativo (como si podía cuando los procesos se encuentran dentro de la misma maquina), vamos a tener 2 sistemas
operativos y una red en el medio, la manera de a utilizar es enviando a través de la red algún tipo de mensaje.

Ahora veremos que tiene que suceder dentro de toda la red para que pueda ir desde un punto hacia el otro.

Proceso-Cliente: proceso cliente es quien inicia la comunicación, es el que envía el mensaje. Enviara el mensaje cuando
lo necesite. Ej. Usuario hace click en un link.

Proceso-Servidor: es quien va a recibir un mensaje y mandara un mensaje de respuesta. Siempre estará esperando un
mensaje. Ej. Recibe mensaje de que el usuario requiere la página web, y responde el mensaje mostrando la página web.

56
La forma en que se comunican esos 2 procesos, vamos a tener el servidor, el cliente donde vamos a tener un proceso de
cada lado, del lado del cliente y del lado del servidor, y ese proceso va a definir un SOCKET (significa enchufe) y vendría a
ser el punto de conexión de los procesos, entonces lo que se hace, a través de la red / internet se conectaran los diferentes
SOCKET /enchufes como (como si fuera un enchufe que conecta los 2 tomacorrientes), y de esta manera nos permite que
el proceso A envié un mensaje al proceso B a través de la conexión (red/internet) y ese mensaje llegue y también la
respuesta vuelva, por lo tanto la conexión puede ser bidireccional.

Todo lo que sucede en la parte “gris” al proceso no le interesa, el proceso se desentiende el PROCESO TRANSMISOR confía
en la estructura de transporte, para que lleve los mensajes al otro extremo y viceversa.

El SOCKET esta implementado en la capa de TRANSPORTE. El SOCKET está definido por el N°IP (aplica protocolo IP) y otro
N° de Puerto (aplica protocolo TCP/UDP), ese par de números se los denomina SOCKET y nos va a identificar el punto de
conexión de un determinado proceso dentro de un host.

57
Para que un proceso reciba un mensaje y poder identificarlo el IP es la dirección única en todo el mundo, para cada
dispositivo va a tener una dirección, y va a ser una dirección de 32 bits, vamos a necesitar también el Puerto de
conexión que nos permitirá identificar el proceso que queremos generar el SOCKET o conexión.

Socket A = N°IP + N° Puerto Proceso A. el número de IP va a ser siempre el mismo el cual identifica a la maquina en el
mundo, y lo que ira cambiando es el número de puerto que identificara los diferentes procesos dentro de una misma
máquina. El IP identifica el HOST / Terminal y el proceso dentro de ese Hosto o terminal lo indicara el N° de Puerto. Existen
algunos números de puertos que son Estandar Ej. HTTP web – N° puerto 80. HTTPs – N° puerto 443.

Como hacemos para bajar esto a la realidad ?

58
Tenemos algunos comandos en el sistema operativo, que nos permitirán ver un poco lo que estuvimos viendo. En Linux
y Windows tenemos el mando NETSTAT estadísticas red.

59
En la imagen se puede ver Socket de Dirección Local vinculado a Socket de Dirección Destino y el estado si está establecida.

Primer columna: Protocolo: nos va a decir que protocolo se está utilizando para la conexión. TCP / UDP.

Segunda columna: Local Address: Dirección Local: es el socket de mi máquina.

Tercer columna: Foreing Address: Dirección Destino: es el socket de conexión destino.

Cuarta columna: State: Estado: El estado de la conexión de los socket. Dentro de los cuales se puede observar:

- LISTENING: son procesos que está escuchando, esperando una comunicación, esperando que algún proceso
remoto le solicite algún tipo de servicio
- ESTABLISHED: son los procesos que se encuentran con una conexión establecida.
- Cualquier otro estado va a ser un estado de cierre, las conexiones no se cierran instantáneamente y se procesó
de cierre pude tener diferentes etapas TIME_WAIT – CLOSE_WAIT – OTROS.

En el caso de las UDP como no tenemos conexión a un socket destino se expondrá con la siguiente nomenclatura: “*:*” y
no tiene una conexión o estado de conexión.

Opciones que pueden salir entre otras:

La siguiente connotación indica que hace referencia a cualquier número de IP:

60
Lo que tiene que definir un protocolo para poder para poder tener algún tipo de utilidad y que se entienda un equipo con
el otro,

- Primero es que tipo de mensajes vamos a intercambiar, porque un protocolo lo que hace es que 2 procesos se
comuniquen, y para comunicarse tienen que saber qué tipo de mensajes pueden mandar y que tipo de mensaje
van a responder, ante un determinado mensaje de solicitud o pedido. Hay que ponerse de acuerdo para identificar
cada tipo de mensaje si es de respuesta o pedido.
- Segundo: vamos a tener que ponernos de acuerdo para definir la sintaxis, el formato de cada mensaje, ejemplo
si queremos solicitar una página web, vamos a enviarle la palabra pedido-direccionWeb-xxx-xxx-xxx, datos
necesarios, toda esa definición de que campos vamos a tener, si serán campos numéricos, con texto, todos los
parámetros y sintaxis de los mensajes. Puede ser sintaxis entendible para humanos o codificado. La sintaxis es el
formato.
- Tercero: definir la semántica, que es la semántica es definir cada uno de los campos que definimos en la sintaxis,
Ej. el primer campo me indicara que tipo de pedido es, según el capo se definirá el archivo a solicitar o a devolver.
Eso sería la información que se encuentra contenida en los campos. La sintaxis es el formato, la semántica es el
significado.
- Cuarto: definir las reglas de cuando los procesos se envían y responden los mensajes, que mensaje se enviara
primero, que mensaje será el que responda, cuando quiero determinada cosa como tengo que pedirlo, y que
mensaje mando, y si tengo un error que mensaje mando, etc.

Todo esto es lo que se encuentra definido dentro de un protocolo y dentro de RFCs. Y para que se definen esos RFCs
que son de dominio público, para que cualquiera pueda hacer un software que sea interoperable con software que hace
otra persona. Ej. Nosotros podemos hacer un navegador web, pero nosotros debemos cumplir lo que se encuentra
definido en el RFCs para que cuando pidamos algo a otro servidor web que programo otra persona, ese servidor web
pueda entender que se le está pidiendo y que nos devuelva lo que nosotros le solicitamos. Si no seguimos las reglas le
vamos a mandar un mensaje que el servidor web no va a entender por qué no cumple la sintaxis, porque el mensaje no
está enviado en el orden correcto, o porque no le mando el mensaje con la palabra que corresponde por lo que no va a
entender. Todo esto se define en los RFCs que son las definiciones de los protocolos. Cada protocolo va a tener un RFCs
asociado.

61
Servicios de la capa de transporte que requiere una aplicación:

Servicios Confiables: no tiene perdida de datos pera determinado tipos de aplicaciones donde necesita una transferencia
100% confiable. Algunas aplicaciones requieren un determinado ancho de banda para que no se corte: Tasa de datos.
Otras necesitan que no haya retardo: Servicios sin Retardo. Estas cuestiones son las que me van a definir qué tipo de
servicio voy a requerir en función de la aplicación que estemos programando.

Esta es una tabla que nos indica cada aplicación que nos permite y que es lo que no nos permite, si queremos por ejemplo
navegar, no me va a permitir perdidas por que la pagina me va a tener que traer la página correctamente pero si tenemos

62
ancho de banda lo manejamos porque tardara uno poco más o un poco menos en bajar y no es importante tanto el tiempo
a diferencia si se trata de un juego que el retardo puede afectar a las prestaciones del mismo, estos toleran algún tipo de
fallas, requiere ancho de banda para coordinar a los jugadores en el juego pero es muy sensible al tiempo ya que se puede
perder por demoras en el tiempo. Ver el resto de los ejemplos en la tabla.

Esta pregunta ya la habíamos contestado en clases anteriores, hay streaming que puede ir por cualquiera de los
protocolos. Porque algunos tipos de protocolos permiten ir por cualquiera de los dos. La telefonía internet es típica de
protocolo UDP. Otro opción son las VPN también pueden ser TCP/UDP.

Entonces tener un protocolo que no nos da un tipo de seguridad ni confiabilidad puede ser que sea mejor o peor en
función de la aplicación que queramos.

63
Las páginas WEB uno las ve como algo armado pero en realidad son un montón de objetos que se encuentran
compaginados para armar lo que nosotros conocemos como una pagina Web. Tiene un encabezado, tiene un cuerpo,
tiene un pie de página, tiene dentro del cuerpo una estructura de divisiones: una parte como texto otra como gráficos, se
puede cargar algún tipo de video, audio, o cualquier otro tipo de contenido. La idea es que cuando queremos ver una
pagina web la vamos a tener que de alguna manera solicitar al servidor donde esa pagina se encuentra alojada entonces
una de las consas que tenemos que conocer es lo que se llama URL que sus siglas son Universal Resource Locator: que
seria la forma de ubicar ese objeto de forma universa en todo el mundo y la conocemos como la DIRECCION DE LA PAGINA
WEB:

Va a tener el protocolo “http” + (Socket = el nombre de la maquina (N°IP) y el puerto (N°Puerto Proceso)) + la página
que en definitiva va a ser un archivo que vamos a tener el archivo base que vendría a ser el archivo HTML (hoy tenemos
otras tecnologías pero en definitiva lo que viaja termina siendo un archivo HTML) y ese archivo HTML en definitiva va a

64
ser código HTML y en algún lugar va a tener algún tipo de referencia Ej. Hacia una imagen, o un archivo de audio, o
cualquier otro (código, etc).

Entonces cuando queremos cargar una página lo que vamos a hacer es a través de la dirección URL es solicitar esa página,
cuando la solicitamos vamos a obtener el archivo base html y ese archivo después nos va a contener referencias a otros
archivos que son también componentes de la misma página, que luego tendré que buscar esos archivos individuales para
que nos muestre la pagina completa.

Si colocamos la URL: “http: ryc.upso.edu.ar” que va a ser el servidor que vamos a utilizar para realizar las practicas

Si podemos observar se cargó con la pagina el archivo HTML. Como nosotros no le indicamos nada en la URL nos trae por
defecto el archivo básico que se encuentra predefinido en el servidor. Si nosotros indicaríamos “http:ryc.upso.edu.ar:80”
(este es el socket destino: luego dentro del socket – luego dentro del socket destino tendremos un “camino o nombre
de ruta para buscar lo que necesitemos solicitar”) en definitiva nos tendría que traer lo mismo por que como nosotros
no le pusimos ningún puerto en la dirección nos trae el 80 que es por defecto (http).

Una vez que nos conectamos al socket destino o URL lo que se van a utilizar son las normas HTTP para establecer la
comunicación solicitar y enviar mensajes para que el servidor entiende lo que estamos solicitando y también pueda dar
respuesta a la solicitud.

Los clientes WINDOWS / MACOS/ LINUX (Proceso Cliente) le van a pedir a un servidor que también podrá ser WINDOWS
/ MACOS / LINUX (Procesos Servidor), entonces le vamos a hacer un requerimiento al server/servidor por medio del
protocolo http y vamos a recibir una respuesta mediante protocolo http – el protocolo va más allá del sistema operativo.

65
Para obtener páginas web obviamente vamos a necesitar TCP: Servicios Orientados a la Conexión el cliente va a iniciar la
conexión al puerto N° 80 del servidor, el servidor va a aceptar la conexión y a partir que se establece esa comunicación /
llamada, vamos a poder intercambiar mensajes http entre el cliente – servidor, cuando ya no tenemos más mensajes que
intercambiar vamos a tener el cierre de la conexión.

El servidor web no guarda estados, significa que todos los pedidos y respuestas entre el cliente – servidor son
considerados independientes entre sí, porque no guarda el estado, cada pedido es individual, porque para mantener el
estado es muy complejo y requiere de muchos recursos y ello no es algo fundamental para intercambiar objetos. Ósea
http no guarda el estado de las conexiones. Cada pedido será independiente de los anteriores y solo el cliente sabrá lo
que está solicitando, el servidor no. Ósea el servidor no guarda que relacion puede existir entre un pedido y otro de un
determinado usuario si corresponden o no a la misma página, etc, por ello sin independientes entre sí.

Vamos a tener 2 tipos de mensajes que dijimos que vamos a tener que definir en el protocolo http. 1- Como hacemos el
Pedido?; 2- Como damos la Respuesta?. Como es la sintaxis para definir el Pedido/Respuesta, en el caso de http utiliza
mensajes en ASCII (es decir que será posible tener un entendimiento o lectura de dicho mensaje): Ejemplo Formato de
pedido:

66
Primero tendremos una palabra que nos indicara que tipo de pedido es y será la que nos permitirá diferencia saber que
es lo que nosotros queremos solicitarle al servidor:

GET Solicitar una página.

HEAD Solicitar el encabezado de una página. No la página completa
PUT Permite subir algún tipo de información al servidor.
Delete Borrar.
POST Postear.

Si todo lo colocamos en un formato grafico quedaría:

67
Los métodos que vamos a utilizar son:

- GET: solicita una página web

- POST: mandamos información para que nos devuelva otra página web con otra información.
- HEAD: solicitamos que nos devuelva toda la información de la página pero solo el encabezado.
- PUT: comandos de http/1.1: sube archivos.
- DELETE: comandos de http/1.1: eliminar un archivo del servidor

Como tenemos un mensaje de requerimiento también vamos a tener un mensaje de RESPUESTA:

68
Comienza con la versión de HTTP que se utiliza para esa respuesta, un código de ESTADO y un texto que va a ser una
síntesis del código de estado, si la página viene todo bien nos enviara el CODIGO DE ESTADO: 200 que nos indicara que la
respuesta se pudo enviar correctamente y sin problemas. Luego se muestran líneas de información relacionada a la
respuesta y según lo que se haya solicitada vendrá con información relacionada a imágenes, html páginas web, etc.

En general todos los 400 son problemas en el requerimiento.

En general todos los 500 son errores del server, no del requerimiento sino del servidor.

En general todos los 300 son errores de ubicación del objeto, de redirección.

Todos estos códigos se encuentran definidos en el RFCs

69
La forma más simple es a través del navegador (pero en ese caso el navegador haría todo el trabajo y nosotros no
estaríamos haciendo nada), para probarlo vamos a utilizar TELNET (WINDOWS): Para habilitarlo debemos:

Luego para ingresar al servidor debemos indicarle en la línea de comandos el SOCKET como indica la filmina:

Luego al ingresar al servidor queda a la espera de la consulta: SI ingresamos cualquier tecla que no se relacione con el
protocolo HTTP no dará un error y nos desconectara del host / servidor:

70
La dificultad que tiene TELNET de WINDOWS es que no se ven los caracteres al momento de escribir la sintaxis: si le
indicamos: telnet ryc.upso.edu.ar 80, GET / HTTP/1.0 Le estamos solicitando el GET – RAIZ:

Si nosotros ingresamos por el navegador este código html lo veriamos de la siguiente forma:

Ahora si le indicamos al navegador ingresar a la página inicial: ryc.upso.edu.ar/inicial.htm

71
Ahora si le indicamos telnet ryc.upso.edu.ar 80 – GET /inicial.htm HTTP/1.0:

En este caso como solo solicitamos el archivo inicial.htm nos trae ese código, pero no nos trae las imágenes por que no
es algo que hayamos solicitado. Si queremos la imagen le indicamos: telnet ryc.upso.edu.ar 80 – GET /image002.jpg
HTTP/1.0: nos manda la imagen codigicada como se encuentra en el servidor.

72
En el SOCKET podemos en vez de utilizar el dominio podríamos utilizar el N° IP del servidor. Si queremos saber el N° IP
del Servidor utilizamos ping ryc.upso.edu.ar

73
 PARACTICA CON JUAN DESAGUES.

https://netacad.com/es/courses/packet-tracer

Instalamos: Packet Tracer 8.2.1 Windows 64 bits

74
NOTAS: los módulos se encuentran prendidos, y debemos apagarlos para incorporarlos al grafico. El router viene
prendido por defecto:

Como tanto la computadora como la notebook tenían puerto de red no le agregamos ningún componente:

75
Tenemos los diferentes tipos de cables: usamos la opción automática.

76