notas de estudio de tcp wireshark

El tiempo de vida es un buen indicador del número de saltos que ha experimentado un mensaje.
La identificación es un buen indicador de la fuente del mensaje. (Identificación = 0 siempre enviará identificación = 0).

Confirmación de retraso TCP: retraso entre el mensaje y el reconocimiento, de modo que el reconocimiento puede enviarse junto con el siguiente mensaje. Ahorra ancho de banda pero causa un retraso adicional entre el mensaje y el reconocimiento. Especialmente si faltan algunos mensajes debido a la congestión de la red, el reconocimiento retrasado puede causar un retraso innecesario entre el reenvío de cada mensaje, especialmente para ventanas pequeñas
. TCP_QUICKACK puede desactivar el reconocimiento de retraso.

Reconocimiento selectivo de TCP. (SACK) puede ser una mitigación del problema de demora de confirmación causada por la pérdida y reenvío de mensajes tcp. Con el reconocimiento selectivo de TCP, solo faltan los mensajes entre el rango ACK y SACK y deben reenviarse, y pueden reenviarse simultáneamente sin esperar el reconocimiento previo. Este mecanismo reduce en gran medida el tráfico generado y mejora el tiempo de respuesta.


Cliente de protocolo de enlace TCP : SYN seq = x
servidor: SYN seq = y, ack = x + 1
cliente: seq = x + 1, ack = y + 1
wirehark utiliza números de secuencia relativos para hacer que la visualización sea más fácil de leer
falla al protocolo de enlace:
servidor rechazado : (tcp.flags.reset == 1) && (tcp.seq == 1) luego siga la
pérdida de paquetes del flujo TCP : (tcp.flags.syn == 1) && (tcp.analysis.retransmission) luego siga la
sincronización del flujo TCP ataque de inundación: envíe una gran cantidad de solicitudes de sincronización con una dirección de origen falsa, la respuesta del servidor nunca recibirá un reconocimiento, dejará la conexión medio abierta y eventualmente causará el agotamiento de los recursos.
El análisis de wireshark -> información de expertos -> los chats mostrarán los números totales de sincronización

No todos los paquetes tcp resultan en un ack, ack puede ser flojo. el cliente puede enviar 1,2,3,4,5 servidor ack 4 implica que se reciben todos 1-4.
El cliente puede enviar mensajes adicionales antes de recibir un reconocimiento siempre que la ventana deslizante no esté llena.
TCP es bueno para transmitir una gran cantidad de datos, para una pequeña porción de datos, incurre en un costo adicional de apretón de manos.

estadísticas -> resumen (mostrar velocidad de transmisión)
estadísticas -> gráfico de flujo TCP -> gráfico de secuencia TCP (mostrar cambio de velocidad)

Síndrome de ventana tonta y algoritmo nagle: para paquetes pequeños, si los datos anteriores no se registran oportunamente, guarde en caché los datos hasta alcanzar el tamaño máximo de segmento y envíelos juntos. (combinar el algoritmo nagle y el retardo de confirmación puede causar una transmisión lenta)

La secuencia de verificación de trama (FCS) se utiliza para verificar la secuencia incorrecta. netstat -i se puede usar para mostrar el error fcs.

TCP cerrar
cliente: FIN seq = x, ack = y
servidor: seq = y, ack = x + 1
servidor: FIN seq = y, ack = x + 1
cliente: seq = x + 1, ack = y +1
con retraso ack, podría combinar el mensaje 2, 3 y convertirse en
cliente: FIN seq = x, ack = y
servidor: FIN seq = y, ack = x + 1
cliente: seq = x + 1, ack = y + 1

Solicitado por wireshark
Tamaño del paquete limitado durante la captura (paquete demasiado grande). se puede configurar con tcpdump -s tamaño de paquete
Tcp segmento anterior no capturado . generalmente: siguiente paquete seq = paquete anterior seq + paquete len. Si el siguiente paquete seq> anterior paquete seq + paquete len, significa que faltan algunos paquetes. compruebe para verificar si se trata de pérdida de paquetes o falta de captura por wireshark. Si el paquete es más grande que MTU, se descartará.
Tcp acket segmento invisible . Solo se captura un acuse de recibo pero no el mensaje original, generalmente ocurre al comienzo de la captura.
Tcp fuera de servicio . si la siguiente secuencia de paquetes es menor que la secuencia de paquetes anterior + longitud. Un amplio rango de desorden puede causar demasiados ataques duplicados y causar retransmisión.
Tcp dup ack . Si falta un paquete en el medio de la secuencia, haga que se repita varias veces
la retransmisión rápida Tcp . > = 3 tcp dup ack dispara tcp retransmisión rápida
Tcp retransmisión . Falta el último paquete de una secuencia, y ningún paquete adicional desencadena dup ack. el remitente espera el tiempo de espera y desencadena la retransmisión de tcp
Tcp zerowindow . (win = 0) El búfer receptor del lado del receptor está lleno.
Tcp ventana llena . datos en transmisión sin ack> = tamaño de la ventana anunciada por el receptor (implica que el remitente no puede enviar más datos)
Se excedió el tiempo de reensamblaje del fragmento . el paquete de fragmentos no se puede ensamblar correctamente

Bytes en vuelo = seq + len - reconocimiento
para detectar la congestión de la red, primero detectar la retransmisión en Wirehark, encontrar el paquete original, calcular bytes en vuelo. Obtenga algunas muestras, luego conocerá el umbral de congestión de la red.

LSO (descarga de segmento grande)
A veces, no podemos obtener el paquete original para una retransmisión, esto puede deberse a LSO, si el tamaño de los datos de transmisión es mayor que MSS, en lugar de datos de segmentos de capa TCP, datos de segmentos de tarjeta de red directamente.

la transmisión lenta de datos puede deberse al tamaño de la ventana de recepción pequeña o al tamaño de la ventana de congestión. Inicio lento cwnd: valor bajo y aumento rápido, evitación de congestión: cada RTT solo aumenta un MSS. Los bytes en vuelo del último paquete en la ventana de envío representan cwnd. cada ack puede aumentar cwnd en 1 MSS, la baja frecuencia de ack puede causar un lento incremento de cwnd.

El fragmento UDP perdido puede causar que se exceda el tiempo de reensamblado. Para TCP, solo se necesita reenviar el fragmento perdido, pero no todos los fragmentos.

La fragmentación ocurre cuando el tamaño de los datos> MTU (generalmente 1500) - tamaño del encabezado (20)
No es fácil detectar la MTU más pequeña a lo largo de la ruta, diferentes MTU pueden causar refragmentación o descarte de paquetes.

ID + offset se usa para reensamblar el fragmento, el último fragmento contiene un indicador (más fragmentos = 0)

TCP usa MSS, que es MTU - encabezado IP - encabezado TCP - opciones TCP, UDP no tiene el concepto de MSS.
El protocolo de enlace TCP intercambia MSS, para que el cliente pueda usar el MSS correcto para evitar la fragmentación.
No fragmentar la bandera hará que se descarte el paquete si es inferior a MTU

la pérdida de paquetes causada por el firewall generalmente comienza con
la congestión de la red de comunicación porque la pérdida de paquetes se recuperará después de que en algún momento
verifique el tamaño del paquete, el paquete grande puede ser un indicador de un problema de MTU.
ping -f -l [tamaño] se puede usar para detectar la MTU más pequeña.

El protocolo de enlace TCP puede enviar una escala de ventana, de modo que puede exceder el límite impuesto por el tamaño de la ventana del cabezal tcp.

Secuestro de HTTP: replicar la solicitud http en el enrutador y enviar una respuesta http falsa antes de una respuesta verdadera. Personajes clave: 1. TTL de respuesta diferente. 2. interrupción de la identificación. 3. diferencia de tamaño de la ventana.

Http 1.1 limita el número de conexiones simultáneas al servidor a 2. El
uso de múltiples servidores http aumenta el número de solicitudes simultáneas, a costa del inicio lento de tcp cwnd. Un protocolo ideal: sin apretón de manos, sin inicio lento, admite multiplexación

Retransmisión TCP:
tshark -n -q -r <nombre de archivo> -z io, stat, 0, tcp.analysis.retransmission, "tcp.analysis.retransmission e ip.src = <IP_A>", "tcp.analysis.retransmission e ip.src = <IP_B> "

wirshark -> preparar un filtro -> seleccionado (generar la expresión tshark)
http://www.wireshark.org/doc/main-pages/tshark.html

retraso de transmisión largo -> aumentar el tamaño de la ventana
tasa de pérdida de paquetes alta -> usar la escala de la ventana tcp, eliminar la limitación de la ventana de envío en el tamaño de la ventana de recepción
ralentizar la velocidad de envío cuando el retraso de la transmisión aumenta el
tamaño de la ventana de ajuste para diferentes conexiones para lograr el
uso prioritario reconocimiento selectivo
mejorar cnwd lento tamaño de inicio (4MSS predeterminado) (la retransmisión debido al tiempo de espera también se restablecerá al tamaño de inicio predeterminado de cnwd)
use marcas de tiempo tcp

Supongo que te gusta

Origin blog.51cto.com/shadowisper/2487689
Recomendado
Clasificación