NO ME PASÓ NADA HIJO DE PUTA, TE LO CREÍSTE Y YA ESTÁ MARICÓN, ESTABA RIQUÍSIMA PORQUE LAS ACEITUNAS SON VIDA Y LA MERIENDA DE LOS CAMPEONES, COMO EL BOCATA DE CHOPPED
Pero ya que estamos aquí, voy a aprovechar para contaros como funciona el protocolo TCP:
TCP, Transmission Control Protocol del inglés, es un protocolo de Telecomunicación de la Capa de Transporte, capa 4 en modelo OSI y capa 3 en el modelo TCP/IP.
Con esto ya podemos situarnos dentro del esquema y saber donde nos encontramos.
Pues bien, el objetivo de este protocolo no es otro que el de asegurar las conexiones, esto no quiere decir que vayan a ser conexiones "seguras" en el sentido de que puedan ser interceptadas o similar, la Seguridad se basa en 3 premisas, asegurar la confidencialidad, la integridad y la disponibilidad de la información.
Como podréis empezar a entender, este protocolo ayuda en la 2º parte, la de la integridad de las conexiones, e incluso si lo desarrollamos un poco más, la disponibilidad de la información, puesto que si no se dispone de todos los paquetes no se va a poder ejecutar la conexión, aunque volviendo al punto 2, no quiere decir que las conexiones siempre vayan a respetar la integridad de las mismas, sino que si no se respeta, la conexión no se puede establecer.
La seguridad de este protocolo radica en el Acuse de Recibo, para poder establecer la conexión, el Cliente solicita al Servidor, en lo que se conoce como el inicio de la conversación, una FLAG llamada SYN (Sincronización), el Servidor responde al Cliente con otra FLAG llamada SYN-ACK con lo que el Servidor quiere darnos a entender que Acepta nuestra petición y nos devuelve a nosotros una petición de Sincronización por su parte. Cuando el equipo Cliente recibe el SYN-ACK, éste responde al Servidor con un ACK aceptando así por su parte la petición de conexión, pudiendo iniciar entonces la conexión:
Y como una imagen vale más que mil palabras, otro esquema:
Ahora que tenemos la conexión "segura", vuelvo a recalcar que la seguridad de esta conexión radica en que te asegura de que los paquetes van a llegar, podemos hacer uso del servicio que vayamos a usar.
Por ejemplo, para el protocolo HTTPS, que todos conocemos, es lo que se conoce como un "protocolo orientado a conexión", por eso utiliza el protocolo TCP para realizar dicha comunicación. En el momento en el que te conectas a una web, tú solicitas al Servidor WEB, Pornhub.com, una solicitud de conexión, para pasar el rato, y tu Smartphone le hace una petición TCP al servidor, el socket sería algo así:
IP_DE_TU_SMARTPHONE:47892-pornhub.com:443
Los Socket es lo mismo que conexión, para que vayáis aprendiendo lenguaje técnico, pues bien, ese Socket intenta establecer esa comunicación, así que si utilizamos un sniffer para visualizar las conexiones, veremos esto:
Como os dije antes, tenemos una IP origen 172.X.X.X/32 y una IP destino 51.X.X.X, el puerto origen es el 63936 y como indica la flechita, se conecta al puerto 443 que está en la escucha para el servicio HTTPS en dicho servidor. He señalado la FLAG del SYN para que veáis que ese es el inicio de la comunicación y como funciona. Donde pone Seq=0 es la secuencia de la conexión, el valor es 0 porque como entenderéis es el inicio de la conexión, veremos como se modifica ese valor a lo largo de la traza cuando ésta sea aceptada con un 1, para indicar que es la primera conexión y que ahí se ha originado.
Lo siguiente entonces que veremos será la de SYN-ACK y en efecto aquí está:
Como vemos, ahora es el Servidor el Origen de la traza, puesto que la petición ahora se origina de su lado porque le está respondiendo afirmativamente al Cliente "Si, me conecto contigo" por eso aparece el ACK con un valor de "1" y el propio FLAG del ACK, y también vemos que envía su propio FLAG de SYN al Cliente para que éste lo acepte y establecer así la conexión. Si nos fijamos, como en el SYN anterior, el Seq es igual a "0" porque como hemos explicado antes, ahora le toca al cliente responder afirmativamente a la conexión, y hasta que ésta no se establezca, no se terminará y no será 1
Aquí tenemos el último paso de la conexión:
Ahora el Cliente le envía el ACK al Servidor como se ve en la FLAG, y el valor de la Secuencia se vuelve 1, por lo que ya se ha iniciado la conexión.
Ahora el Cliente podrá disfrutar del Servicio prestado, en este caso reproducción de vídeos porno.
La traza completa de la negociación se vería así:
El protocolo TLSv1.2 es el protocolo de cifrado, como HTTPS es un servicio "Securizado" la información viaja cifrada para que en caso de ser interceptada, como ha sucedido ahora, no se pueda visualizar.
Pensaréis:
"que redundante ¿no?, ¿por qué el Cliente también tiene que aceptar la solicitud del Servidor si joder, te abro la conexión porque quiero conectarme no?"
Claro que no, es necesario, hay ocasiones que el tráfico por ejemplo de ida (outbound) si está permitido, pero no el tráfico de vuelta (inbound), también puede ser que tu máquina por la configuración que le hayas dado no acepte peticiones del exterior, el caso es que pueden ocurrir múltiples situaciones que hagan que una de las partes en algún momento de la comunicación no pueda establecerla, entonces esta negociación es necesaria, con esto ambas partes reconocen que si se puede establecer una comunicación.
Aquí tenéis un ejemplo:
En este ejemplo, vemos que se ha perdido la conexión, porque el Servidor se ha intentado conectar al Cliente pero ha habido algún problema, seguramente pérdida de línea, porque la traza la he sacado en el bar mientras me tomaba unas cañas con mis amigos, y como tenía el teléfono conectado dando datos, puede ser que mucha carga de tráfico haya "tirado" por un segundo la conexión, de ahí que veamos un nuevo FLAG, el FLAG "RST", básicamente es un RESET, y que le hace es recargar la conexión para volver al intentarlo, viene de parte del Servidor, por lo que nos está pidiendo que le volvamos a enviar el ACK, porque parece que ha habido algún problema, y el paquete no ha llegado, por lo que sigue intentándolo, el nº de intentos configurados en el Servidor, Router...etc. Si os fijáis ocurre todo en la misma Secuencia, en la Secuencia 1.
Aquí quería mostraros la forma que tiene este protocolo de finalizar la conexión, pero no encuentro las trazas donde el Servidor se despide del Cliente, así que os lo imagináis que al final es igual a la del Cliente con el Servidor:
Bien, aquí vemos como desde nuestro Origen solicitamos al Destino que vamos a cerrar la conexión, por lo que enviamos el FLAG FIN, para indicar eso mismo, que vamos a finalizar la conexión, el caso es que veis en la Secuencia que es la 8532 que el ACK por parte del Cliente se ha dado, por lo que el Servidor también ha enviado su mensaje de despedida, solo que el Wireshark no lo ha pillado, o simplemente ya la hora que es no tengo la cabeza para más.
Con esto lo que tenéis que ver es que tanto para iniciar la comunicación como para cerrarla, hay un protocolo de negociación, para que tanto el Servidor como el Cliente sepan que no van a recibir más paquetes y para que no se quede la conexión abierta consumiendo recursos ni en el lado del Cliente por ejemplo, el puerto abierto, puesto que puede ser utilizado para otro servicio o incluso ser atacado.
En resumen, el flujo de comunicación para terminar una conexión TCP, en un esquema sería así:
Con el ejemplo del RST, vemos la importancia de este protocolo, que asegura que la conexión se vaya a realizar, si por ejemplo nos queremos conectar a un Servidor porque tiene una carga de memoria alta, y puede ser peligroso por la salud física del mismo, necesitaremos que la comunicación sea fiable y no se pierda ningún paquete por el camino, porque claro, que risa le daría al administrador, lanzar un comando desde su equipo y que éste no se ejecute porque la mitad de los paquetes se han perdido y el servidor no puede ejecutar la orden porque claro... imagínate que tu jefe/profesor te dice "Mañana entras a las 8 porque no hay mucho trabajo" y solo te llega "Entras a las 8 hay trabajo"... el mensaje no es el que es, de hecho sería algo más parecido a esto "Mana nra l que y uo trabaj" algo que la máquina ni por asomo podría entender. Lo mismo con la respuesta claro, los datos no serían precisos o no podrían llegar porque faltan demasiados paquetes.... la conexión necesita ser fiable.
Por contraparte está el protocolo UDP, es más rápido porque se salta la negociación, por lo que no tienes interrupciones en las comunicaciones si éstas fallan, pero eso si veo que os ha gustado el contenido y queréis saber más, lo puedo explicar en otro post.
Las imágenes de los esquemas las he sacado de Google, no os flipéis creyendo que me he puesto ha hacerlo en mi casa o en el bar, no me aburro tanto jajajaja, pero las capturas de tráfico si las he hecho con tráfico real que he generado yo, las he capturado con el Wireshark que es un Sniffer, quien no sepa lo que es también puede preguntar.
TCP, Transmission Control Protocol del inglés, es un protocolo de Telecomunicación de la Capa de Transporte, capa 4 en modelo OSI y capa 3 en el modelo TCP/IP.
Con esto ya podemos situarnos dentro del esquema y saber donde nos encontramos.
Pues bien, el objetivo de este protocolo no es otro que el de asegurar las conexiones, esto no quiere decir que vayan a ser conexiones "seguras" en el sentido de que puedan ser interceptadas o similar, la Seguridad se basa en 3 premisas, asegurar la confidencialidad, la integridad y la disponibilidad de la información.
Como podréis empezar a entender, este protocolo ayuda en la 2º parte, la de la integridad de las conexiones, e incluso si lo desarrollamos un poco más, la disponibilidad de la información, puesto que si no se dispone de todos los paquetes no se va a poder ejecutar la conexión, aunque volviendo al punto 2, no quiere decir que las conexiones siempre vayan a respetar la integridad de las mismas, sino que si no se respeta, la conexión no se puede establecer.
La seguridad de este protocolo radica en el Acuse de Recibo, para poder establecer la conexión, el Cliente solicita al Servidor, en lo que se conoce como el inicio de la conversación, una FLAG llamada SYN (Sincronización), el Servidor responde al Cliente con otra FLAG llamada SYN-ACK con lo que el Servidor quiere darnos a entender que Acepta nuestra petición y nos devuelve a nosotros una petición de Sincronización por su parte. Cuando el equipo Cliente recibe el SYN-ACK, éste responde al Servidor con un ACK aceptando así por su parte la petición de conexión, pudiendo iniciar entonces la conexión:
Y como una imagen vale más que mil palabras, otro esquema:
Ahora que tenemos la conexión "segura", vuelvo a recalcar que la seguridad de esta conexión radica en que te asegura de que los paquetes van a llegar, podemos hacer uso del servicio que vayamos a usar.
Por ejemplo, para el protocolo HTTPS, que todos conocemos, es lo que se conoce como un "protocolo orientado a conexión", por eso utiliza el protocolo TCP para realizar dicha comunicación. En el momento en el que te conectas a una web, tú solicitas al Servidor WEB, Pornhub.com, una solicitud de conexión, para pasar el rato, y tu Smartphone le hace una petición TCP al servidor, el socket sería algo así:
IP_DE_TU_SMARTPHONE:47892-pornhub.com:443
Los Socket es lo mismo que conexión, para que vayáis aprendiendo lenguaje técnico, pues bien, ese Socket intenta establecer esa comunicación, así que si utilizamos un sniffer para visualizar las conexiones, veremos esto:
Como os dije antes, tenemos una IP origen 172.X.X.X/32 y una IP destino 51.X.X.X, el puerto origen es el 63936 y como indica la flechita, se conecta al puerto 443 que está en la escucha para el servicio HTTPS en dicho servidor. He señalado la FLAG del SYN para que veáis que ese es el inicio de la comunicación y como funciona. Donde pone Seq=0 es la secuencia de la conexión, el valor es 0 porque como entenderéis es el inicio de la conexión, veremos como se modifica ese valor a lo largo de la traza cuando ésta sea aceptada con un 1, para indicar que es la primera conexión y que ahí se ha originado.
Lo siguiente entonces que veremos será la de SYN-ACK y en efecto aquí está:
Como vemos, ahora es el Servidor el Origen de la traza, puesto que la petición ahora se origina de su lado porque le está respondiendo afirmativamente al Cliente "Si, me conecto contigo" por eso aparece el ACK con un valor de "1" y el propio FLAG del ACK, y también vemos que envía su propio FLAG de SYN al Cliente para que éste lo acepte y establecer así la conexión. Si nos fijamos, como en el SYN anterior, el Seq es igual a "0" porque como hemos explicado antes, ahora le toca al cliente responder afirmativamente a la conexión, y hasta que ésta no se establezca, no se terminará y no será 1
Aquí tenemos el último paso de la conexión:
Ahora el Cliente le envía el ACK al Servidor como se ve en la FLAG, y el valor de la Secuencia se vuelve 1, por lo que ya se ha iniciado la conexión.
Ahora el Cliente podrá disfrutar del Servicio prestado, en este caso reproducción de vídeos porno.
La traza completa de la negociación se vería así:
El protocolo TLSv1.2 es el protocolo de cifrado, como HTTPS es un servicio "Securizado" la información viaja cifrada para que en caso de ser interceptada, como ha sucedido ahora, no se pueda visualizar.
Pensaréis:
"que redundante ¿no?, ¿por qué el Cliente también tiene que aceptar la solicitud del Servidor si joder, te abro la conexión porque quiero conectarme no?"
Claro que no, es necesario, hay ocasiones que el tráfico por ejemplo de ida (outbound) si está permitido, pero no el tráfico de vuelta (inbound), también puede ser que tu máquina por la configuración que le hayas dado no acepte peticiones del exterior, el caso es que pueden ocurrir múltiples situaciones que hagan que una de las partes en algún momento de la comunicación no pueda establecerla, entonces esta negociación es necesaria, con esto ambas partes reconocen que si se puede establecer una comunicación.
Aquí tenéis un ejemplo:
En este ejemplo, vemos que se ha perdido la conexión, porque el Servidor se ha intentado conectar al Cliente pero ha habido algún problema, seguramente pérdida de línea, porque la traza la he sacado en el bar mientras me tomaba unas cañas con mis amigos, y como tenía el teléfono conectado dando datos, puede ser que mucha carga de tráfico haya "tirado" por un segundo la conexión, de ahí que veamos un nuevo FLAG, el FLAG "RST", básicamente es un RESET, y que le hace es recargar la conexión para volver al intentarlo, viene de parte del Servidor, por lo que nos está pidiendo que le volvamos a enviar el ACK, porque parece que ha habido algún problema, y el paquete no ha llegado, por lo que sigue intentándolo, el nº de intentos configurados en el Servidor, Router...etc. Si os fijáis ocurre todo en la misma Secuencia, en la Secuencia 1.
Aquí quería mostraros la forma que tiene este protocolo de finalizar la conexión, pero no encuentro las trazas donde el Servidor se despide del Cliente, así que os lo imagináis que al final es igual a la del Cliente con el Servidor:
Bien, aquí vemos como desde nuestro Origen solicitamos al Destino que vamos a cerrar la conexión, por lo que enviamos el FLAG FIN, para indicar eso mismo, que vamos a finalizar la conexión, el caso es que veis en la Secuencia que es la 8532 que el ACK por parte del Cliente se ha dado, por lo que el Servidor también ha enviado su mensaje de despedida, solo que el Wireshark no lo ha pillado, o simplemente ya la hora que es no tengo la cabeza para más.
Con esto lo que tenéis que ver es que tanto para iniciar la comunicación como para cerrarla, hay un protocolo de negociación, para que tanto el Servidor como el Cliente sepan que no van a recibir más paquetes y para que no se quede la conexión abierta consumiendo recursos ni en el lado del Cliente por ejemplo, el puerto abierto, puesto que puede ser utilizado para otro servicio o incluso ser atacado.
En resumen, el flujo de comunicación para terminar una conexión TCP, en un esquema sería así:
Con el ejemplo del RST, vemos la importancia de este protocolo, que asegura que la conexión se vaya a realizar, si por ejemplo nos queremos conectar a un Servidor porque tiene una carga de memoria alta, y puede ser peligroso por la salud física del mismo, necesitaremos que la comunicación sea fiable y no se pierda ningún paquete por el camino, porque claro, que risa le daría al administrador, lanzar un comando desde su equipo y que éste no se ejecute porque la mitad de los paquetes se han perdido y el servidor no puede ejecutar la orden porque claro... imagínate que tu jefe/profesor te dice "Mañana entras a las 8 porque no hay mucho trabajo" y solo te llega "Entras a las 8 hay trabajo"... el mensaje no es el que es, de hecho sería algo más parecido a esto "Mana nra l que y uo trabaj" algo que la máquina ni por asomo podría entender. Lo mismo con la respuesta claro, los datos no serían precisos o no podrían llegar porque faltan demasiados paquetes.... la conexión necesita ser fiable.
Por contraparte está el protocolo UDP, es más rápido porque se salta la negociación, por lo que no tienes interrupciones en las comunicaciones si éstas fallan, pero eso si veo que os ha gustado el contenido y queréis saber más, lo puedo explicar en otro post.
Las imágenes de los esquemas las he sacado de Google, no os flipéis creyendo que me he puesto ha hacerlo en mi casa o en el bar, no me aburro tanto jajajaja, pero las capturas de tráfico si las he hecho con tráfico real que he generado yo, las he capturado con el Wireshark que es un Sniffer, quien no sepa lo que es también puede preguntar.
Última edición:
