Мне было интересно, есть ли какая-то конкретная причина для увеличения порядкового номера ACK вместо подтверждения полученного порядкового номера. Почему RFC так спроектировал?
Actual:
[SYN] SEQ=100
[SYN, ACK] Seq=300 Ack=101
[ACK] Seq=101 Ack=301
Why not:
[SYN] Seq=100
[SYN/ACK] Seq=300 Ack=100
[ACK] Seq=101 Ack=300
Естественно, имеет смысл подтвердить только что полученный порядковый номер вместо порядкового номера, который вы получили + 1?
В TCP протокол отслеживает то, что было отправлено, используя порядковый номер. Фактически это счетчик всего отправленного +1.
Подробнее о https://tools.ietf.org/html/rfc793#section-3.3
ACK увеличивается на 1, потому что пакет несет SYN, он не пустой. SYN способствуют увеличению SEG.LEN, как объяснено в RFC:
SEG.LEN = количество октетов, занятых данными в сегменте (считая SYN и FIN)
Если бы пакет был пустым и без SYN / FIN, счетчик не увеличивался бы.
Это также предусмотрено в RFC, где говорится, что следующий номер последовательности для отправки должен быть больше или равно чем тот, который указан в ACK:
Новое подтверждение (называемое "приемлемым подтверждением") - это подтверждение, для которого выполняется следующее неравенство:
SND.UNA < SEG.ACK =< SND.NXT
где SND.UNA - это самый старый неподтвержденный порядковый номер, а SND.NXT - это следующий порядковый номер для отправки.
Увеличивая seq. номер пакет, по сути, спрашивает другую сторону: «Я ожидаю, что вы сейчас отправите мне первый байт данных»