Обоснование ACK и SEQ?

Я не уверен, считают ли люди это очевидным, но у меня есть два вопроса:

  1. Почему во время трехэтапного рукопожатия ACK = SEQ + 1, т.е. почему я ACKing для следующего байта, который я ожидаю от отправителя?
  2. После рукопожатия мой ACK = SEQ + len. Чем это отличается от рукопожатия? Почему бы не просто ACK для следующего байта, которого я ожидаю (так же, как во время рукопожатия)?

Я знаю, что, должно быть, где-то упустил основной момент. Может ли кто-нибудь прояснить это?


networking tcp network-programming network-protocols
person Legend    schedule 01.03.2010    source источник

Ответы (3)


arrow_upward
6
arrow_downward

Это связано с тем, что первый байт пространства порядкового номера соответствует флагу SYN, а не байту данных. (Флаг FIN в конце также занимает байт пространства порядкового номера.)

person Matthew Slattery    schedule 01.03.2010

arrow_upward
3
arrow_downward

Во время рукопожатия вы синхронизируетесь. Порядковый номер — это известные данные. После синхронизации длина данных — это известные данные, а также полезный псевдослучайный верификатор. Отправитель знает, сколько он отправил, и если вы ответите, он предполагает, что вы его получили. Это проще, чем ответить, скажем, контрольной суммой или хэшем данных, и обычно этого достаточно.

person No Refunds No Returns    schedule 01.03.2010
comment
Понятно... Кажется, я понял твою мысль о рукопожатии. Но опять же, почему бы просто не ответить ACK = SYN, просто чтобы сказать «Хорошо». Я получил ваш номер SYN? А во-вторых, мой второй вопрос касался того же самого... На самом деле я не предлагал добавить контрольную сумму или хеш... Из вашего ответа кажется, что где-то присутствует понятие безопасности, но я все еще пытаюсь понять, где... - person Legend; 01.03.2010
comment
нет - это просто проверка. После того, как отправитель/получатель синхронизировался, им нужен способ положительно подтвердить получение сообщения. AOK заключается в том, что получатель получил столько байтов, сколько отправил отправитель. Что-то известно обеим сторонам. Это не безопасность. Это больше похоже на бит четности, хотя это неточная аналогия. Зачем навязывать счетчик сообщений протоколу? Это не добавляет ценности, только накладные расходы. - person No Refunds No Returns; 02.03.2010

arrow_upward
0
arrow_downward

Флаги SYN и FIN вызывают увеличение порядкового номера потока на единицу. Таким образом

SYN (seq x) -------------->
                           <--- SYNACK (ack x+1, seq y)
ACK (seq x+1, ack y+1) --->

Это ваше трехстороннее рукопожатие. Это сделано так, потому что SYN и FIN требуют подтверждения получения. Таким образом, все могут быть на одной странице в течение всего времени соединения.

Теоретически любой пакет в части TWHS может иметь полезную нагрузку, но если какой-либо из пакетов с установленным флагом SYN имеет полезную нагрузку, противоположная сторона должна подтвердить как данные, так и флаг.

person jdizzle    schedule 08.03.2010