Назад | Перейти на главную страницу

путаница с порядковым номером syn / ack

Я просматривал случайный трафик в wirehark и наткнулся на это (с использованием относительных чисел 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...

Я использовал http://packetlife.net/blog/2010/jun/7/understanding-tcp-sequence-acknowledgment-numbers в качестве ресурса, и похоже, что seq = previous ack и ack + = previous seq + len / flags (пожалуйста, поправьте меня, если я ошибаюсь). Но что происходит в строках 4-7? Пакет фрагментирован или что-то в этом роде? Кажется, что числа seq / ack не складываются для меня, так что где я ошибаюсь?

Нумерация последовательностей TCP

При декодировании трассировок TCP следует помнить о нескольких вещах ...

  1. Порядковые номера TCP являются направленными (т.е. если кто-то отправляет мне полезную нагрузку, я не увеличиваю свой порядковый номер на основе байтов, которые я получили)
  2. Порядковые номера TCP указывают на заголовок полезной нагрузки пакета

Однако сами по себе эти точки не учитывают недостающие ACK для порядковых номеров 5841-14600 между пакетами 6 и 7. Мое лучшее предположение (и это все, что я действительно могу сделать на данный момент) заключается в том, что вы могли сбросить пакеты ACK где-то в между сетевой картой и wirehark. Вы можете сказать, когда это произойдет, если увидите подобные сообщения (из сеанса linux xterm или ssh) ...

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

Решения для отбрасывания пакетов wirehark

  • Уменьшите размер пакетов, на которые смотрит wirehark (100 байт на пакет обычно более чем достаточно)
  • Отключите поиск DNS и прокрутку записи в реальном времени (наиболее эффективен захват буфера диска)

  • В Linux вы можете исправить эти падения, настроив буферы на сетевой карте и между ядром и libpcap.Примечание 1...

    ethtool -G eth0 rx 768

    sysctl -w net.core.netdev_max_backlog=30000

  • Если вы находитесь в Windows, это помогает предоставить wirehark больше буферного пространства (опция -B CLI), когда вы его вызываете ...

Примечание 1. YMMV, настройки буфера специфичны для вашей системы ... поиграйте с ними, пока не увидите сообщения о сброшенных пакетах.

Может фрагментация. Может быть, еще один сеанс с сервером. Порты эк? Wireshark может выбрать все пакеты в сеансе tcp из интерфейса (выбрав в меню rcm на пакете)