sin / ack número de secuencia confusión

Estaba mirando un poco de tráfico random en wireshark y me encontré con esto (usando numbers relativos seq / ack):

1. myIP -> 74.125.227.96 [SYN] seq=0 2. 74.125.227.96 -> myIP [SYN/ACK] seq=0 ack=1 3. myIP -> 74.125.227.96 [ACK] seq=1 ack=1 4. myIP -> 74.125.227.96 [ACK] seq=1 ack=1 len=14600 5. 74.125.227.96 -> myIP [ACK] seq=1 ack=2921 6. 74.125.227.96 -> myIP [ACK] seq=1 ack=5841 7. myIP -> 74.125.227.96 [ACK] seq=14601 ack=1 len=8760 8. 74.125.227.96 -> myIP [ACK] seq=1 ack=8761 9. myIP -> 74.125.227.96 [ACK] seq=23361 ack=1 len=4380 etc... 

Yo estaba usando http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers como un recurso y parece que seq = ack anterior y ack + = seq anterior + len / flags (por favor Corrígeme si estoy equivocado). Pero, ¿qué pasa con las líneas 4-7? ¿El package está siendo fragmentado o algo así? Los numbers de seq / ack no parecen agregar para mí así que ¿dónde voy mal?

2 Solutions collect form web for “sin / ack número de secuencia confusión”

Numeración de Secuencia TCP

Hay un par de cosas para recordar cuando se descodifican trazas TCP …

  1. Los numbers de secuencia de TCP son direccionales (es decir, si alguien me envía una carga útil, no aumento mi número de secuencia basado en bytes que recibí )
  2. Los numbers de secuencia TCP apuntan a la cabecera de la carga útil de un package

Sin embargo, esos puntos por sí solos no tienen en count los ACKs faltantes para los numbers 5841-14600 entre los packages 6 y 7. Mi mejor conjetura (y eso es todo lo que realmente puedo hacer en este momento) es que puede haber caído packages ACK en alguna parte entre el NIC y wireshark. Puedes ver cuando esto sucede si ves posts como este (desde una session de linux xterm o ssh) …

 19431 packets captunetworking 38863 packets received by filter 572 packets dropped by kernel <---------------- 7 packets dropped by interface <---------------- 

Soluciones a las gotas de packages de wireshark

  • Reduzca el tamaño de los packages que mira wireshark (100 bytes por package es normalmente más que suficiente)
  • Deshabilitar las búsquedas DNS y el desplazamiento de captura en vivo (la captura de búfer de disco es la más eficiente)
  • En linux puede corregir estas gotas ajustando buffers en la NIC y entre el kernel y libpcap Nota 1

    ethtool -G eth0 rx 768

    sysctl -w net.core.netdev_max_backlog=30000

  • Si estás en windows, ayuda a dar más espacio de búfer a wireshark (la opción -B CLI) cuando la llames …


Nota 1. YMMV, los ajustes de búfer son específicos para su sistema … juega con ellos hasta que no vea packages de posts eliminados

Tal vez la fragmentación. Tal vez otra session en el server. Puertos eq? Wireshark puede seleccionar todos los packages en una session tcp desde la interfaz (por seleccionar en el menu en rcm en el package)

  • Solución de problemas de pérdida de packages en pfSense + Ubiquiti UniFi (¿quizás Wireshark?)
  • ¿Cómo reorderar eficientemente packages en files PCAP basados ​​en la timestamp?
  • ¿Por qué agregar filters de captura rompe el volcado de tráfico en wireshark / windump?
  • Depuración del tráfico de networking en la máquina local de Windows
  • Wireshark, usando "Decode as", BACnet falta como una opción
  • ¿Cómo puedo filtrar packages desde un monitor de puerto?
  • Analizar las requestes HTTP a través de Wireshark?
  • Creación de keytab para la count de equipo para descifrar la captura de packages
  • Problema con WireShark (inhalación de MySQL)
  • Excesivo 'TCP Dup ACK' y 'TCP Fast Retransmission' causando problemas en la networking. ¿Qué está causando esto?
  • ¿Wireshark puede capturar la request https?
  • ISP que transmite todos los packages IP, por lo que puedo ver el tráfico de otros clientes de ISP
  • ¿cómo puedo configurar tshark para capturar URL completa uri request ip y sello de time
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.