Localice la pérdida de paquetes y la situación de paquetes de error
watch more /proc/net/devSe utiliza para ubicar la pérdida de paquetes y la situación del paquete de error, para ver el cuello de botella de la red, enfocarse en la caída (el paquete se cae) y la cantidad total de transmisión de paquetes de red, no exceda el límite superior de la red:
[root@localhost ~]# watch -n 2 more /proc/net/dev
Every 2.0s: more /proc/net/dev Fri May 1 17:16:55 2020
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 10025 130 0 0 0 0 0 0 10025 130 0 0 0 0 0 0
ens33: 759098071 569661 0 0 0 0 0 0 19335572 225551 0 0 0 0 0 0
-
El más a la izquierda representa el nombre de la interfaz, Recibir representa la recepción de paquetes y Transmitir representa el envío de paquetes;
-
bytes: Indica el número de bytes enviados y recibidos; -
packets： Indique la cantidad correcta de paquetes enviados y recibidos; -
errs: Indica la cantidad de paquetes enviados y recibidos incorrectamente; -
drop: Indica la cantidad de paquetes descartados enviados y recibidos;
Ver las direcciones pasadas por la ruta
traceroute ipPuede ver las direcciones pasadas por la ruta. A menudo se usa para contar el consumo de tiempo de la red en cada sección de enrutamiento, como por ejemplo:
[root@localhost ~]# traceroute 14.215.177.38
traceroute to 14.215.177.38 (14.215.177.38), 30 hops max, 60 byte packets
1 CD-HZTK5H2.mshome.net (192.168.137.1) 0.126 ms * *
2 * * *
3 10.250.112.3 (10.250.112.3) 12.587 ms 12.408 ms 12.317 ms
4 172.16.227.230 (172.16.227.230) 2.152 ms 2.040 ms 1.956 ms
5 172.16.227.202 (172.16.227.202) 11.884 ms 11.746 ms 12.692 ms
6 172.16.227.65 (172.16.227.65) 2.665 ms 3.143 ms 2.923 ms
7 171.223.206.217 (171.223.206.217) 2.834 ms 2.752 ms 2.654 ms
8 182.150.18.205 (182.150.18.205) 5.145 ms 5.815 ms 5.542 ms
9 110.188.6.33 (110.188.6.33) 3.514 ms 171.208.199.185 (171.208.199.185) 3.431 ms 171.208.199.181 (171.208.199.181) 10.768 ms
10 202.97.29.17 (202.97.29.17) 29.574 ms 202.97.30.146 (202.97.30.146) 32.619 ms *
11 113.96.5.126 (113.96.5.126) 36.062 ms 113.96.5.70 (113.96.5.70) 35.940 ms 113.96.4.42 (113.96.4.42) 45.859 ms
12 90.96.135.219.broad.fs.gd.dynamic.163data.com.cn (219.135.96.90) 35.680 ms 35.468 ms 35.304 ms
13 14.215.32.102 (14.215.32.102) 35.135 ms 14.215.32.110 (14.215.32.110) 35.613 ms 14.29.117.242 (14.29.117.242) 54.712 ms
14 * 14.215.32.134 (14.215.32.134) 49.518 ms 14.215.32.122 (14.215.32.122) 47.652 ms
15 * * *
...
Ver errores de red
netstat -iPuede ver los errores de red:
[root@localhost ~]# netstat -i
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
ens33 1500 570291 0 0 0 225897 0 0 0 BMRU
lo 65536 130 0 0 0 130 0 0 0 LRU
-
Iface: Nombre de la interfaz de red; -
MTU: Unidad de transmisión máxima, que limita la longitud máxima de las tramas de datos. Los diferentes tipos de red tienen un límite superior, como: Ethernet MTU es 1500; -
RX-OK: El número correcto de paquetes de datos al recibir. -
RX-ERR: El número de paquetes con errores al recibirlos. -
RX-DRP: El número de paquetes de datos descartados al recibirlos. -
RX-OVR: Al recibir, el número de paquetes de datos perdidos debido a la sobrevelocidad (en la transmisión de datos, los datos se pierden porque el dispositivo receptor no puede recibir los datos transmitidos a la velocidad de envío). -
TX-OK: El número correcto de paquetes al enviar. -
TX-ERR: El número de paquetes de datos con errores al enviar. -
TX-DRP: El número de paquetes de datos descartados durante el envío. -
TX-OVR: El número de paquetes de datos perdidos debido al exceso de velocidad durante el envío. -
Flg: Mark, B ha establecido una dirección de transmisión. L Esta interfaz es un dispositivo de bucle invertido. M recibe todos los paquetes (modo caótico). N Evite el seguimiento. O En esta interfaz, desactive ARP. P Este es un enlace punto a punto. La interfaz R se está ejecutando. La interfaz U está en estado "activo".
Tasa de retransmisión de paquetes
cat /proc/net/snmpSe utiliza para ver y analizar el volumen de paquetes de red, el tráfico, los paquetes de error y la pérdida de paquetes en 240 segundos. Por RetransSegsy OutSegstasa de retransmisión calculada tcpetr=RetransSegs/OutSegs.
[root@localhost ~]# cat /proc/net/snmp
Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates
Ip: 1 64 241708 0 0 0 0 0 238724 225517 15 0 0 0 0 0 0 0 0
Icmp: InMsgs InErrors InCsumErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps
Icmp: 149 0 0 50 99 0 0 0 0 0 0 0 0 0 147 0 147 0 0 0 0 0 0 0 0 0 0
IcmpMsg: InType3 InType11 OutType3
IcmpMsg: 50 99 147
Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts InCsumErrors
Tcp: 1 200 120000 -1 376 6 0 0 4 236711 223186 292 0 4 0
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors
Udp: 1405 438 0 1896 0 0 0
UdpLite: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors
UdpLite: 0 0 0 0 0 0 0
Tasa de retransmisión = 292 / 223186≈0,13%
-
Número promedio de nuevas conexiones TCP por segundo: obtenga el aumento de PassiveOpens en los últimos 240 segundos a través del archivo / proc / net / snmp y divídalo por 240 para obtener el aumento promedio por segundo;
-
El número de conexiones TCP de la máquina: obtenga el número de conexiones TCP a través de CurrEstab en el archivo / proc / net / snmp;
-
Datagramas UDP recibidos promedio por segundo: Obtenga el incremento de InDatagrams en los últimos 240 segundos a través del archivo / proc / net / snmp y divídalo por 240 para obtener el datagramas UDP promedio recibido por segundo;
-
Promedio de datagramas UDP enviados por segundo: obtenga el incremento de OutDatagrams en los últimos 240 segundos a través del archivo / proc / net / snmp y divídalo por 240 para obtener el promedio de datagramas UDP por segundo;
se acabó el tiempo
La mayoría de los errores de tiempo de espera se encuentran en el nivel de la aplicación, por lo que este se centra en comprender los conceptos. Los tiempos de espera se pueden dividir aproximadamente en tiempos de espera de conexión y tiempos de espera de lectura y escritura. Algunos marcos de cliente que utilizan grupos de conexiones también tienen tiempos de espera de adquisición de conexión y tiempos de espera de limpieza de conexión inactiva.
-
Tiempo de espera de lectura y escritura. readTimeout / writeTimeout, algunos marcos se denominan so_timeout o socketTimeout, ambos se refieren al tiempo de espera de lectura y escritura de datos. Tenga en cuenta que la mayoría de los tiempos de espera aquí se refieren a tiempos de espera lógicos. El tiempo de espera de soa también se refiere al tiempo de espera de lectura. Los tiempos de espera de lectura y escritura generalmente solo se establecen para el cliente;
-
Tiempo de conexión agotado. connectionTimeout, el cliente generalmente se refiere al tiempo máximo para establecer una conexión con el servidor. El connectionTimeout en el lado del servidor es un poco variado, jetty representa el tiempo de limpieza de la conexión inactiva y tomcat representa el tiempo máximo para que se mantenga la conexión;
-
otro. Incluyendo el tiempo de espera de adquisición de conexión connectionAcquireTimeout y el tiempo de espera de limpieza de conexión inactiva idleConnectionTimeout. Se utiliza principalmente para marcos de cliente o servidor que utilizan grupos de conexiones o colas.
Cuando establecemos varios tiempos de espera, debemos confirmar que intentamos mantener el tiempo de espera del cliente menor que el tiempo de espera del servidor para asegurarnos de que la conexión finaliza normalmente.
En el desarrollo real, lo que más nos importa debería ser el tiempo de espera de lectura y escritura de la interfaz.
Cómo establecer un tiempo de espera de interfaz razonable es un problema. Si el tiempo de espera de la interfaz es demasiado largo, puede ocupar demasiado la conexión tcp del servidor. Si la configuración de la interfaz es demasiado corta, el tiempo de espera de la interfaz será muy frecuente.
La interfaz del servidor obviamente reduce el rt, pero el cliente aún se agota, lo cual es otro problema. Este problema es realmente muy simple: el enlace del cliente al servidor incluye transmisión de red, colas y procesamiento del servicio. Cada enlace puede ser una causa que lleve mucho tiempo.
Desbordamiento de la cola TCP
El desbordamiento de la cola de TCP es un error de nivel relativamente bajo, que puede causar errores más superficiales, como tiempos de espera y primeros. Por lo tanto, el error está más oculto, así que hablemos de él por separado.
Como se muestra en la figura anterior, hay dos colas: cola syns (cola semi-conectada) y aceptar cola (cola completamente conectada). Apretón de manos de tres vías. Una vez que el servidor recibe la sincronización del cliente, coloca el mensaje en la cola de sincronización y responde con syn + ack al cliente. El servidor recibe la confirmación del cliente. Si la cola de aceptación no está llena en este momento, eliminará el almacenamiento temporal de la cola Syns. La información se coloca en la cola de aceptación, de lo contrario se ejecuta como lo indica tcp_abort_on_overflow.
tcp_abort_on_overflow 0 significa que si la cola de aceptación está llena durante el tercer paso del protocolo de enlace de tres vías, el servidor desecha el ack enviado por el cliente. tcp_abort_on_overflow 1 significa que si la cola de conexión completa está llena en el tercer paso, el servidor envía un primer paquete al cliente, lo que indica que el proceso de negociación y esta conexión están abolidos, lo que significa que puede haber muchos restablecimientos de conexión / restablecimiento de conexión por compañeros en el registro.
Entonces, en el desarrollo real, ¿cómo podemos localizar rápidamente el desbordamiento de la cola tcp?
-
comando netstat, ejecute netstat -s | egrep "listen | LISTEN"
Como se muestra en la figura anterior, desbordado representa el número de desbordamientos de la cola completamente conectada y sockets descartados representa el número de desbordamientos de la cola semiconectada.
-
comando ss, ejecutar ss -lnt
Como se vio arriba, Send-Q indica que el número máximo de colas completamente conectadas en el puerto de escucha en la tercera columna es 5, y la primera columna Recv-Q es cuánto se usa actualmente la cola completamente conectada.
Luego, veamos cómo establecer el tamaño de las colas completamente conectadas y semiconectadas:
El tamaño de la cola completamente conectada depende de min (backlog, somaxconn). La acumulación se transfiere cuando se crea el socket, y somaxconn es un parámetro del sistema a nivel del sistema operativo. El tamaño de la cola de semiconexión depende de max (64, / proc / sys / net / ipv4 / tcp_max_syn_backlog).
En el desarrollo diario, a menudo usamos el contenedor de servlets como servidor, por lo que a veces debemos prestar atención al tamaño de la cola de conexión del contenedor. El trabajo pendiente en tomcat se llama acceptCount, y en jetty es acceptQueueSize.
Excepción RST
El paquete RST representa un restablecimiento de la conexión y se utiliza para cerrar algunas conexiones inútiles. Por lo general, representa un cierre anormal, que es diferente de cuatro ondas de manos.
En el desarrollo real, a menudo vemos restablecimiento de conexión / restablecimiento de conexión por errores de pares, que son causados por el paquete RST.
1. El puerto no existe
Si se emite una solicitud SYN para establecer una conexión como un puerto que no existe, el servidor devolverá directamente un mensaje RST para interrumpir la conexión si encuentra que no tiene este puerto.
2. Reemplazar activamente FIN para terminar la conexión.
En términos generales, el cierre normal de la conexión debe lograrse a través de mensajes FIN, pero también podemos usar mensajes RST en lugar de FIN, lo que significa que la conexión se termina directamente. En el desarrollo real, puede establecer el valor de SO_LINGER para controlar, esto a menudo es deliberado, para omitir TIMED_WAIT, para proporcionar eficiencia interactiva y usarlo con precaución.
3. Se produce una excepción en un lado del cliente o servidor, y el lado opuesto envía un RST para informar a la conexión que se cierre.
El desbordamiento de la cola tcp mencionado anteriormente que envía paquetes RST en realidad pertenece a este tipo. Esto a menudo se debe a algunas razones, una de las partes ya no puede procesar normalmente la conexión de solicitud (por ejemplo, el programa se bloquea, la cola está llena), por lo que le dice a la otra parte que cierre la conexión.
4. El paquete TCP recibido no está en una conexión TCP conocida
Por ejemplo, si a la máquina de una parte le falta un paquete TCP debido a una red defectuosa, la otra parte cierra la conexión y luego recibe el paquete TCP faltante después de mucho tiempo, pero debido a que la conexión TCP correspondiente ya no existe, enviará un paquete RST directamente para abrir una nueva conexión.
5. Una parte no ha recibido el mensaje de confirmación de la otra parte durante mucho tiempo y envía un mensaje RST después de un cierto período de tiempo o después del número de retransmisiones.
La mayor parte de esto también está relacionado con el entorno de red. Un entorno de red deficiente puede resultar en más paquetes RST.
Dije antes que muchos mensajes RST harán que el programa informe errores. Una operación de lectura en una conexión cerrada informará un restablecimiento de la conexión, y una operación de escritura en una conexión cerrada informará un restablecimiento de la conexión por parte de un par. Por lo general, también podemos ver errores de tubería rota. Este es un error a nivel de tubería. Significa leer y escribir en una tubería cerrada. A menudo es un error continuar leyendo y escribiendo datos después de recibir un RST y reportar un error de restablecimiento de conexión. también se introduce en los comentarios del código fuente de glibc.
¿Cómo determinamos la existencia del paquete RST al solucionar problemas? Por supuesto, use el comando tcpdump para capturar paquetes y use wirehark para un análisis simple. tcpdump -i en0 tcp -w xxx.cap, en0 representa la tarjeta de red de monitoreo.
A continuación, abrimos el paquete capturado a través de Wireshark y es posible que pueda ver la siguiente figura, la roja representa el paquete RST.
TIME_WAIT 和 CLOSE_WAIT
Creo que todo el mundo sabe lo que significan TIME_WAIT y CLOSE_WAIT.
Cuando estamos en línea, podemos usar directamente el comando netstat -n | awk '/ ^ tcp / {++ S [$ NF]} END {for (a in S) print a, S [a]}' para ver el tiempo de espera Y el número de close_wait
Usar el comando ss será más rápido ss -ant | awk '{++ S [$ 1]} END {for (a in S) print a, S [a]}'
1 、 TIME_WAIT
La existencia de time_wait es para que el paquete de datos perdido sea reutilizado por la conexión subsiguiente, y la segunda es para cerrar la conexión normalmente dentro del rango de tiempo de 2MSL. De hecho, su existencia reducirá en gran medida la apariencia de los paquetes RST.
Es más probable que ocurra demasiado time_wait en escenarios con frecuentes conexiones cortas. En este caso, algunos ajustes de parámetros del kernel se pueden realizar en el lado del servidor:
# Indica que la reutilización está activada. Permitir que los sockets TIME-WAIT se reutilicen para nuevas conexiones TCP, el valor predeterminado es 0, lo que significa que está cerrado
net.ipv4.tcp_tw_reuse = 1
#Indica que la recuperación rápida de sockets TIME-WAIT en la conexión TCP está activada, el valor predeterminado es 0, lo que significa que está cerrado
net.ipv4.tcp_tw_recycle = 1
Por supuesto, no debemos olvidar el pozo del rechazo de paquetes de datos en el entorno NAT debido a marcas de tiempo incorrectas. Otra forma es cambiar tcp_max_tw_buckets. Cualquier time_wait que exceda este número será eliminado, pero esto también resultará en el informe de tiempo de espera desbordamiento de la mesa de cubos.
2 、 CLOSE_WAIT
Close_wait a menudo se debe a problemas escritos por la aplicación y el mensaje FIN no se inicia nuevamente después del ACK. La probabilidad de close_wait es incluso mayor que la de time_wait y las consecuencias son más graves. A menudo se debe a que un lugar está bloqueado y la conexión no se cierra correctamente, lo que consume gradualmente todos los hilos.
Para localizar tales problemas, es mejor usar jstack para analizar la pila de subprocesos para solucionar el problema. Aquí hay solo un ejemplo.
Los compañeros de desarrollo dijeron que CLOSE_WAIT aumentó después de que la aplicación se puso en línea, hasta que colgó. Después de que jstack encontró la pila sospechosa, la mayoría de los subprocesos se atascaron en el método countdownlatch.await. Después de enterarse de los compañeros de desarrollo, se enteraron de que varios -se utilizó el subproceso, pero no lo hizo. Capture la excepción, la excepción encontrada después de la modificación es simplemente la clase más simple que no se encuentra y que a menudo aparece después de actualizar el SDK.