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

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

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