Programación de sockets. ¿Cómo implementar el reenvío de paquetes de datos? Versión en lenguaje C.

Yo tampoco lo sé... Tengo que hacer una copia... *** Aprendamos juntos~~ Para escribir un programa de red, debes usar Socket, que es conocido por todos los programadores. . Además, durante la entrevista, también le preguntaremos a la otra parte si conoce la programación de Socket. En términos generales, mucha gente dirá que la programación de Socket consiste básicamente en algunas operaciones básicas como escuchar, aceptar, enviar y escribir. Sí, es como las operaciones de archivos comunes, siempre que lo haya escrito, lo sabrá. Para la programación de redes, también debemos llamarlo TCP/IP. Parece que ya no existen otros protocolos de red. Para TCP/IP, también conocemos TCP y UDP. El primero puede garantizar la precisión y confiabilidad de los datos, mientras que el segundo permite la pérdida de datos. Finalmente, también sabemos que antes de establecer una conexión, debemos conocer la dirección IP y el número de puerto de la otra parte. Además, los programadores comunes no saben mucho y, en muchos casos, este conocimiento es suficiente. Como máximo, al escribir un programa de servicio, se utilizarán varios subprocesos para manejar el acceso simultáneo. También conocemos los siguientes hechos: 1. Un número de puerto específico no puede ser utilizado por múltiples programas. Por ejemplo, si IIS ocupa el puerto 80, Apache no puede utilizar también el puerto 80. 2. Muchos firewalls solo permiten que los paquetes pasen a través de puertos de destino específicos. 3. Después de que el programa de servicio escuche un determinado puerto y acepte una solicitud de conexión, generará un nuevo socket para procesar la solicitud. Entonces surge una pregunta que me ha desconcertado durante mucho tiempo. Si se crea un socket y se vincula al puerto 80, ¿significa que el socket ocupa el puerto 80? Si es así, cuando acepta una solicitud, ¿qué puerto utiliza el nuevo socket (siempre pensé que el sistema le asignaría un número de puerto libre de forma predeterminada)? Si es un puerto inactivo, no debe ser el puerto 80, por lo que el puerto de destino de futuros paquetes TCP no será el 80; ¡el firewall definitivamente impedirá que pase! De hecho, podemos ver que el firewall no bloquea dichas conexiones, y este es el método de manejo y solicitud de conexión más común. Lo que no entiendo es por qué el firewall no bloquea dichas conexiones. ¿Cómo determina qué conexión se genera debido al puerto connet80? ¿Hay alguna marca especial en el paquete TCP? ¿O el firewall recuerda algo? Más tarde, estudié detenidamente los principios de la pila de protocolos TCP/IP y obtuve una comprensión más profunda de muchos conceptos. Por ejemplo, TCP y UDP pertenecen a la capa de transporte y ambos se basan en la capa IP (capa de red). La capa IP es la principal responsable de la transmisión de paquetes de datos entre nodos (de extremo a extremo). El nodo aquí es un dispositivo de red, como una computadora. Debido a que la capa IP solo es responsable de enviar datos a los nodos y no puede distinguir entre las diferentes aplicaciones anteriores, los protocolos TCP y UDP les agregan información del puerto, y el puerto identifica una aplicación en un nodo. Además de agregar información del puerto, el protocolo UPD básicamente no procesa ningún dato en la capa IP. El protocolo TCP también agrega controles de transmisión más complejos, como ventanas deslizantes de transmisión de datos (Slice Window) y mecanismos de confirmación de recepción y reenvío para lograr una transmisión confiable de datos. No importa qué tipo de flujo de datos TCP estable vea la capa de aplicación, lo que se transmite a continuación son paquetes de datos IP uno por uno, y los datos deben ser reorganizados mediante el protocolo TCP. Por lo tanto, tengo motivos para sospechar que el firewall no tiene suficiente información para determinar más información sobre el paquete TCP, excepto la dirección IP y el número de puerto. Además, también hemos visto que los llamados puertos se utilizan para distinguir diferentes aplicaciones para que diferentes paquetes IP puedan reenviarse correctamente cuando llegan. TCP/IP es solo una pila de protocolos, al igual que el mecanismo operativo de un sistema operativo. Debe implementarse de manera concreta y al mismo tiempo proporcionar una interfaz de operación externa. Así como el sistema operativo proporciona interfaces de programación estándar, como la interfaz de programación Win32, TCP/IP también debe proporcionar interfaces de programación externas. Esta es la interfaz de programación Socket, ¡así que eso es lo que es! En la interfaz de programación de Socket, el diseñador propuso un concepto muy importante, es decir, socket.

Este socket es muy similar a un identificador de archivo. De hecho, en el sistema BSD, se almacena en la misma tabla de identificadores de proceso que el identificador de archivo. Este zócalo es en realidad un número de serie que indica su posición en la tabla de manijas. Hemos visto esto mucho, como identificadores de archivos, identificadores de ventanas, etc. Estos identificadores en realidad representan ciertos objetos específicos en el sistema y se usan como parámetros en varias funciones para operar en objetos específicos; esto es en realidad un problema con el lenguaje C++. Este identificador es en realidad este puntero, que en realidad es. el puntero del objeto. Ahora sabemos que los sockets no están necesariamente relacionados con TCP/IP. Cuando se diseñó la interfaz de programación Socket, se esperaba que también pudiera adaptarse a otros protocolos de red. Por lo tanto, la aparición del socket solo facilita el uso de la pila de protocolos TCP/IP. Abstrae TCP/IP y forma varias interfaces de funciones básicas. Como crear, escuchar, aceptar, conectar, leer y escribir, etc. Ahora entendemos que si un programa crea