fondo
Recientemente, existe un escenario comercial que requiere que el servidor (denominado S) y el cliente (denominado C) diseñen un conjunto de protocolos de comunicación basados en UDP; se requiere tolerar una cierta tasa de pérdida de paquetes bajo la premisa de ser lo más rápido posible, para que pueda estudiarse y entenderse en profundidad. La comunicación y la práctica UDP, durante el período de desarrollo y depuración, me he encontrado con cuatro situaciones de error: no hay respuesta al paquete UDP enviado por el lado C, no respuesta a la respuesta de host inalcanzable, respuesta de puerto inalcanzable y ninguna respuesta al paquete UDP enviado por el lado C nuevamente, que es diferente de la conexión y depuración anteriores. Después de un estudio cuidadoso, esta vez tengo la curiosidad de descubrir el causas de diferentes errores y el principio de notificación de errores, y finalmente tener una mejor comprensión de ICMP, un protocolo familiar y desconocido.
Problema de error y análisis de causa.
Para aclarar el problema de manera más clara y conveniente, el orden del problema y la escena del problema se procesan artísticamente a continuación: no es consistente con la situación real. Después de todo, el problema real no aparecerá uno por uno. en un orden razonable, pero a menudo se mezclan múltiples problemas para formar un llamado error que gradualmente se vuelve encantador ==!
No hay respuesta al paquete UDP enviado por el C-end
sudo hping -2 -k -s 3000 -p 9999 test.demoabc.com -d 2 # hping参数含义：-2表示UDP模式, -s表示源端口固定3000, -p表示目的端口9999, test.demoabc.com为目的主机, -d 2表示数据包payload为2字节
HPING test.demoabc.com (en0 119.x.x.100): udp mode set, 28 headers + 2 data bytes
^C
--- test.demoabc.com hping statistic ---
11 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Como se indicó anteriormente, se enviaron 11 paquetes UDP a test.demoabc.com:9999 usando hping, pero no se recibió respuesta y el proceso de escucha en S no recibió ninguno de los 11 paquetes UDP. posible pérdida de paquetes, es teóricamente imposible que estos 11 paquetes pierdan el 100% de los paquetes cuando la calidad del enlace de red es normal. Después de pensarlo un poco, rápidamente me di cuenta de que debería ser porque el firewall no abre el puerto UDP, por lo que el firewall no reenviará el paquete UDP al proceso S que está escuchando el puerto 9999, ni devolverá el paquete a la terminal C. , pero descartarlo directamente.
Solución: simplemente abra el puerto correspondiente de UDP en el firewall.
Host inalcanzable
Después de que el firewall liberó el puerto, se ajustó la depuración conjunta de autocomprobación de los paquetes C y S enviados y devueltos, por lo que se entregó al cliente. Como resultado, el cliente informó que había un problema con el envío del paquete UDP, y el host de destino de ping informaría Host Unreachable, lo cual es extraño. La autocomprobación se ha ajustado y el proceso de monitoreo ya se está ejecutando y puede recibir los paquetes UDP enviados por el comando hping. ¿Por qué hay un problema con el cliente?
Eche un vistazo más de cerca: Bueno, el host del lado C está mal escrito: cuando el nombre de dominio de prueba no se ha configurado antes, le di directamente al lado C una IP de red pública para probar rápidamente, pero debido a varias razones, yo terminó usando otro servidor El servidor correspondiente a la antigua IP se recicla, por lo que el ping del cliente informará Host Unreachable.
El comando ping probablemente tenga este efecto:
ping 119.x.x.90
PING 119.x.x.90 (119.x.x.90) 56(84) bytes of data.
From 192.168.0.105 icmp_seq=1 Destination Host Unreachable
From 192.168.0.105 icmp_seq=2 Destination Host Unreachable
From 192.168.0.105 icmp_seq=3 Destination Host Unreachable
From 192.168.0.105 icmp_seq=4 Destination Host Unreachable
From 192.168.0.105 icmp_seq=5 Destination Host Unreachable
^C
--- 119.x.x.90 ping statistics ---
8 packets transmitted, 0 received, +5 errors, 100% packet loss, time 7167ms
Solución: el cliente puede cambiar a la solicitud de host correcta.
Puerto inalcanzable
Después de resolver el problema de host inalcanzable del resultado de ping anterior, el cliente indicó que el ping está bien, pero la comunicación UDP aún informa el error de puerto inalcanzable, que es realmente extraño todos los días, especialmente hoy, continúe investigando.
Bueno, después de la investigación, el puerto UDP del cliente está mal escrito. En pocas palabras, la dirección de conexión del cliente es test.demoabc.com:9999, pero el nombre de dominio utilizado por el cliente es test.demoabc.com, pero el puerto es Se utiliza el puerto HTTP predeterminado 80. El puerto TCP 80 está realmente escuchando nginx, pero el puerto UDP 80 no está monitoreado por ningún proceso, por lo que conducirá a Puerto inalcanzable, que probablemente sea similar a la siguiente solicitud de hping
sudo hping -2 -k -s 3000 -p 80 test.demoabc.com -d 2
HPING test.demoabc.com (en0 119.x.x.100): udp mode set, 28 headers + 2 data bytes
ICMP Port Unreachable from ip=119.x.x.100 name=test.demoabc.com
ICMP Port Unreachable from ip=119.x.x.100 name=test.demoabc.com
ICMP Port Unreachable from ip=119.x.x.100 name=test.demoabc.com
ICMP Port Unreachable from ip=119.x.x.100 name=test.demoabc.com
ICMP Port Unreachable from ip=119.x.x.100 name=test.demoabc.com
ICMP Port Unreachable from ip=119.x.x.100 name=test.demoabc.com
^C
--- test.demoabc.com hping statistic ---
6 packets tramitted, 6 packets received, 0% packet loss
Solución: el cliente puede cambiar a la solicitud de host+puerto correcta.
No hay respuesta cuando el UDP del lado C envía un paquete nuevamente
Después de resolver los tres problemas anteriores, la comunicación UDP entre el cliente y el servidor finalmente se conecta y puede continuar desarrollando la lógica de seguimiento felizmente.Como resultado, un día el cliente informó repentinamente que el cliente envió paquetes normalmente, pero no recibió ningún paquete devuelto. De hecho, es un resultado similar para probar con hping nuevamente. Los resultados de hping son los siguientes:
sudo hping -2 -k -s 3000 -p 9999 test.demoabc.com -d 2
HPING test.demoabc.com (en0 119.x.x.100): udp mode set, 28 headers + 2 data bytes
^C
--- test.demoabc.com hping statistic ---
19 packets tramitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Parece que no hay diferencia con el problema causado por el cortafuegos al principio, pero revisé las reglas del cortafuegos para confirmar que no hay problema.Utilizar tcpdump para capturar el paquete también confirmó que se recibió el paquete UDP del lado C , y finalmente agregó UDP al código del servidor. Imprimir el registro del contenido original directamente después del paquete también puede confirmar que los datos se han entregado al proceso de monitoreo, pero ¿por qué el extremo C no puede recibir ninguna respuesta?
Piense detenidamente en el principio de UDP. UDP en sí no tiene conexión y no es confiable. A diferencia de TCP, el protocolo garantiza que cada paquete se entregará. El protocolo en sí mismo también garantizará que haya un paquete de retorno de acuse de recibo, por lo que, en teoría, si el S termina recibe el paquete UDP del extremo C, pero no responde, el extremo C que envía el paquete en realidad no sabe que se está enviando el paquete de datos. ¿Se perdió silenciosamente en el camino, fue rechazado por el firewall de destino y descartado? , o finalmente recibido por S sin ninguna respuesta.
Se ha confirmado que la configuración del cortafuegos es correcta, la captura de paquetes tcpdump y los registros comerciales también han verificado que el proceso de monitoreo ha recibido el paquete de datos del lado C, entonces el problema puede estar solo en la lógica del paquete de retorno del lado S al lado C, el código es para probar Hay un paquete de retorno fijo para el envío del paquete del lado C, y el lado S enviará un paquete de latido al lado C en un intervalo fijo de 1 s. normal en los últimos días, ya sea la autocomprobación o el uso del lado C. Ahora, de repente, no funciona. Basado en una rica experiencia en errores: se infiere que los cambios recientes en el código comercial han causado errores: una explicación muy razonable, verifique cuidadosamente que el servidor no haya cambiado el código en el futuro cercano, pero habrá algunas condiciones anormales en el código para juzgar la lógica de devolución por adelantado, agregue un registro de error detallado en el lugar correspondiente y vuelva a probar, y finalmente se revela la verdad: el protocolo de serialización utilizado por el cliente es incorrecto y los datos binarios generados por la serialización del El último cambio en el lado C se analizará incorrectamente en el lado S, por lo tanto, regrese por adelantado y no lo dejará. -La ip/puerto final que llega con éxito al proceso de devolución del paquete del extremo S se agregará a la lista del extremo C activo de S, y el paquete de latido se enviará aquí, porque todos los datos en el extremo C son incorrectos y devuelto por adelantado y no se unió a la lista de terminales C activos, no se enviará el paquete de latidos. La razón por la que usé la prueba hping antes era normal pero ahora falla también porque no agregué la lógica de analizar errores y regresar por adelantado al principio, sino simplemente verificar la conectividad de enviar y devolver paquetes. es esta lógica de análisis y verificación de devoluciones Por supuesto, si usa hping en las mismas circunstancias, no podrá recibir el paquete de respuesta.
Solución: corrija el código de serialización incorrecto en el lado C y agregue un registro de errores más completo y detallado en el lado S para facilitar una solución de problemas posterior y más rápida.
Mayor comprensión de ICMP
En este punto, se han explicado los cuatro problemas encontrados por la depuración conjunta de la comunicación UDP, y parece que se puede terminar todo el blog, pero parece que ICMP en el título no se ha mencionado en absoluto hasta ahora.
Para los amigos que tienen una cierta base y experiencia en redes, deben tener en cuenta que, aunque el nombre de ICMP no se ha mencionado antes, el uso de ICMP en sí mismo se ha mencionado muchas veces.De la respuesta a Host Unreachable ejecutada por el comando ping , hping El comando y la respuesta Port Unreachable del paquete UDP enviado por el terminal C dependen en realidad del protocolo ICMP.
Pero para los amigos con una base de red débil, esto no es tan obvio. De hecho, incluyéndome a mí, nunca he vinculado directamente la respuesta de error de Inalcanzable con ICMP; en otras palabras, he aprendido ICMP en clase. Sé que su nombre completo es el Protocolo de mensajes de control de Internet, y probablemente sepa que el comando ping está relacionado con ICMP, pero va más allá: ¿qué hace exactamente ICMP? ¿Bajo qué escenarios habrá una respuesta ICMP? ¿Por qué a veces la respuesta es Host inalcanzable, a veces Puerto inalcanzable y, a veces, tiempo de espera sin respuesta? ¿Qué capa del protocolo es ICMP? ¿Cuál es la relación entre UDP, TCP e ICMP?
Ya hay mucha información en Internet para una introducción ICMP más detallada. Aquí describiré brevemente mi comprensión de los problemas anteriores; corríjame si hay errores u omisiones. Los amigos que deseen obtener más información recomiendan leer las 20 ilustraciones de codificación de Kobayashi: trabajo de ping El principio es muy bueno tanto con imágenes como con textos.
¿Qué hace exactamente ICMP?
Como su nombre lo indica, ICMP es un protocolo utilizado para controlar la transmisión de paquetes y se divide principalmente en dos tipos: paquetes de consulta y paquetes de error.
¿Bajo qué escenarios responderá ICMP?
Primero puede pensar en un problema: cuando el host de origen envía un paquete IP, un paquete UDP o un paquete TCP al host de destino, si sucede algo durante el proceso de entrega y se descarta, por ejemplo, si el host de destino se apaga, ¿Cómo puede saber el host de origen? Si no hay un mecanismo responsable de notificar al host de origen, es posible que el host de origen tenga que esperar hasta que se agote el tiempo de espera. Este es un escenario de uso del mecanismo de notificación ICMP. El nodo enviará una notificación de mensaje ICMP al host de origen mientras descarta el paquete de datos. Informar explícitamente a su host de destino que es inalcanzable.
El comando ping, de uso muy común, se implementa en función del mensaje de consulta. El mensaje de consulta se puede usar para probar si el enlace al host de destino es accesible. Cuando el host de destino recibe el mensaje de consulta, responderá un mensaje de respuesta a la fuente. host de forma predeterminada, a menos que el host de destino esté deshabilitado en el host, y todos deben estar familiarizados con el uso del comando ping en la prueba simple de demora de red y la detección de fallas de conectividad de enlace.
El tipo de mensaje de error es la información de error específica que el nodo de error devuelve al host de origen cuando se produce un error durante la entrega del paquete de datos de IP al host de destino. Si llega el paquete de datos, se notificará al host de origen sobre el host. Inalcanzable. Por ejemplo, el host de origen envía un paquete UDP al puerto 9999 del host de destino, pero se cuelga el proceso de escucha en el puerto 9999. El host de destino encuentra que el paquete UDP ha sido recibido pero no hay un proceso de entrega. el host de origen será notificado del puerto inalcanzable.
¿Por qué a veces la respuesta es Host inalcanzable, a veces Puerto inalcanzable y, a veces, tiempo de espera sin respuesta?
Si finalmente se determina que el paquete de datos no se puede entregar al nodo que solo se puede descartar (tal vez un enrutador intermedio, el host final, etc.) y no se prohíbe la respuesta del mensaje ICMP correspondiente, enviará una respuesta inalcanzable a el host de origen. En pocas palabras, si el host de destino encuentra directamente Si no se entrega, responderá Host inalcanzable. Si se entregó al host de destino, pero el host de destino encuentra que se trata de un paquete TCP o UDP de capa de transporte pero no puede encontrar el proceso de recepción del puerto correspondiente, la respuesta es Port Unreachable. Y si el nodo prohíbe la respuesta del mensaje ICMP correspondiente, entonces el nodo simplemente descarta los paquetes de datos que no se pueden entregar y no habrá ninguna operación de respuesta. En este momento, el host de origen solo puede juzgar el tiempo de espera si espera más de un cierto período. de tiempo.
¿Qué protocolo de capa es ICMP?
ICMP en sí mismo es un protocolo de capa de red.
¿Cuál es la relación entre UDP, TCP e ICMP?
Tanto UDP como TCP son protocolos de capa de transporte, que no están directamente relacionados con ICMP en la capa de Red. Sin embargo, cuando los paquetes UDP y TCP tienen problemas en el proceso de llegar al host de destino, como Host Unreachable, Port Unreachable y rechazo de fragmentación, se bloquean. Al descartar, el nodo enviará un mensaje ICMP al host de origen para ayudar al host de origen a comprender la causa de la falla para su posterior procesamiento. Otros incluyen Mensaje de redirección que solicita al remitente de datos una mejor ruta y Fuente Quench Mensaje que alivia la congestión.
Resumir
Personalmente, practiqué la programación de red basada en UDP, que se puede decir que probó y purificó el conocimiento de UDP que se había memorizado principalmente antes, y realmente profundizó mi comprensión. Al mismo tiempo, tengo una comprensión mucho más intuitiva de lo aparentemente familiar pero Protocolo ICMP desconocido. , En profundidad y más aprendizaje. Lo real es: lo que obtienes en el papel es superficial, y nunca sabes que tienes que hacerlo tú mismo. Comparte con todos.
Indique la fuente de la reimpresión, la dirección original: https://www.cnblogs.com/AcAc-t/p/udp_message_and_icmp.html