Во-первых, есть два набора пар порядковых номеров и номеров подтверждения, по одному набору для каждой стороны диалога. Порядковый номер — это текущий номер отправителя, а номер подтверждения — это представление получателя о «следующем ожидаемом порядковом номере» от отправителя. Как правило, они работают так...
Предположения: начальный порядковый номер HostA — 100, начальный порядковый номер HostB — 200 (эти числа случайны, и их начальные значения не имеют никакого значения, но они устанавливаются во время трехэтапного рукопожатия TCP).
Сценарий: HostA отправляет 1000 байт полезной нагрузки TCP на HostB:
Seq # Ack # TCP Payload (bytes) Next Seq #
----- ----- ------------------- ----------
100 200 1000 1100
Здесь предполагается, что начальный порядковый номер HostA равен 100, и, поскольку мы предполагаем, что он отправляет 1000 байт полезной нагрузки TCP, мы вычисляем следующий ожидаемый порядковый номер как 100 + 1000 = 1100. Это ACK #, который мы ищем. for от HostB, что укажет HostA, что HostB получил все 1000 байт полезной нагрузки и ожидает, что следующий сегмент TCP от HostA будет иметь порядковый номер 1100.
HostB подтверждает получение вышеуказанного TCP-сегмента от HostA:
Seq # Ack # TCP Payload (bytes) Next Seq #
----- ----- ------------------- ----------
200 1100 0 200
Это набор порядковых номеров и номеров подтверждений HostB. Обратите внимание, что этот набор полностью независим от набора HostA. Здесь HostB подтвердил HostA получение всех 1000 байтов данных, которые отправитель отправил в предыдущем пакете, отправив HostA ACK # 1100 (начальный порядковый номер 100 плюс дополнительные 1000 байтов полезной нагрузки). Собственный порядковый номер HostB 200 не играет роли в этой передаче данных, за исключением того, что указывает HostA, что никакие данные не были отправлены HostB в обратном направлении обратно к HostA.
Если бы HostB НЕ получил этот сегмент от HostA, то ACK HostB в конечном итоге отправил бы обратно HostA, а ACK # был бы только 100, поэтому HostA знал бы, что HostB не получил сегмент, содержащий 1000 байтов. полезной нагрузки и, следовательно, должен ретранслировать ее.
Надеюсь, это поможет?
Дополнительную информацию и дополнительные сведения см. в RFC 793.
person
Christopher Maynard
schedule
13.10.2017