ACK номер ожидаемого ОКТЕТА к принятию, а не номер ПАКЕТА! Драма в стихах
Дорогой LOR, я сидел ни кого не трогал читал книгу Network Programming with Go
от Adam Woodbeck, раздел №2, а именно Socket Level Programming. Потом
переводил параграф на русский язык, писал поэму на тему параграфа и отсылал
своему другу с прозвищем «Маэстро Алгоритм» - получал в ответ порцию отборных
матов и продолжал дальше.
И тут перечивая свою очередную поэму, и сверясь с книгой я обнаружил страшное. Автор гонит. Читаем:
Страинца 48, Acknowleging Receipt Packages by Using Their Sequnce Number.
For example, if a sender transmits
a bunch of packets with sequence numbers up through 100 but then receives
an ACK from the receiver with sequence number 90, the sender knows it
needs to retransmit packets from sequence numbers 91 to 100.
-
Sequence Number - это номер следующий сущности готовой к принятию, если ACK Sequence Number = 90 - это значит 89 сущностей успешно принято, готовы принимать 90 сущность. ACK Sequence Number = (Success + 1) где Success это номер того, чего успешно приняли. Следовательно если из 100 отправленных, пришел ACK Seq Num = 90 то успешно пришло 89, и надо переотправлять с 90 по 100; - 11 пакетов.
-
Cущность то не пакет, а БАЙТ. БАЙТ - 8 битов - ОКТЕТ.
Что делать, господа присяжные заседатели? Коммандовать парадом продолжаю я, но таких косяков я ожидал от лоровцев, но ни как от писателя букв на бумаге в книге.
Теперь ссылки найденные системой Grok.com:
https://datatracker.ietf.org/doc/html/rfc9293#section-3.4-1
3.4. Sequence Numbers
A fundamental notion in the design is that every octet of data sent over a TCP connection has a sequence number.
Обратите внимание на изящество, байт звется ОКТЕТОМ, так как Байт он быавет разный.
https://datatracker.ietf.org/doc/html/rfc9293?referrer=grok.com#section-3.1-6.8.2
Acknowledgment Number:
32 bits
If the ACK control bit is set, this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established, this is always sent.
Все равно я респектую Adam Woodbeck - книга хорошая. И заставляет задуматься, в принцпе для Go дела нет, все эти механизмы котроля передачи скрыты в реализации. И предоставляется просто интерфейс. Тем не мене ACK - это номер октета, а ни какого не пакета. И вообще TCP это «стриминговая» передча данных, реализуемая в модели не пакетов, а потока сохраняющего последовательнсть окетов.
P.S.
Внимательно вчитываясь в RFC9293, я пришел к выводу, что SNI и ACK похожи на указатели в Си. Или на шаклу линейки: первый сантиметр начинается с 0, а уже с 1 сантиметра начинается 2 сантиметр. Также SNI - указывает ту точку на которой остановились, если 0 - зачит будтем передавать 1 ОКТЕТ. Хотя я оконательно запутался, понятно, что это байты, и понятн что есть два поля в TCP Header которые указывают начиная с какого байта передаем, и какой байт уже приняли. А дальше надо детально разбираться. Сути это не меняет.
У каждго из узлов передачи есть свои числа, и говорить они могут одновремено. Дел полно двигаемся дальше. Adam Woodbeck - правильный пацан, кент в уважухе.
P.P.S.
Стараюсь разбираться: ISN - это то с чего начали (при утановленом SYN флаге, грубо говоря «от балды»). SEQ (Sequence Number) - это поле указывающие какой октет мы сейчас передаем. ACK (Aknowledge Number) - поле которое говорит какой ОКТЕТ мы готовы принять следующим.
- SYN, ACK - флаги.
- ISN - первое число, случайное.
- Sequence Number, Aknowledgment Number - это 32 битные поля в TCP Header в IP пакете.
SEQ_num - Начало какой байт начали передовать. ACK_num - какйо байт ждем, ждем 10 байт (9 приняли), или ждем 20 (19 приняли).
- https://datatracker.ietf.org/doc/html/rfc9293#section-3.4-1
- https://www.flamingbytes.com/blog/tcp-3-way-handshake-syn-syn-ack-ack/
- https://networkengineering.stackexchange.com/questions/61221/is-there-any-limit-role-for-syn-initial-number-and-seq-number-of-tcp-three-w
- https://hpbn.co/building-blocks-of-tcp/#three-way-handshake
P.P.P.S.
Важно добавить, SEQ_num и ACK_num указывают номера ОКТЕТОВ для TCP сегментов передаваемого и ожидаемого. SEQ_num - указывает байт с которого начинается TCP сегмент, а TCP сегмент икапсулирован в IP пакет.
И это механизмы для формирования непрерывного последовательного потока данных - дублирования потерянных сегментов.
P.P.P.P.S.
Протокол TCP предоставляет услуги поточной передачи данных, через объект Сокет. Последовательность данный при передачи реализована, через механизм сегментов которые содержат порядковые номера ОКТЕТОВ.
Существует два поля при помощи который получатель и отправитель регулируют последовательно отправки и получения сегментов, дублируя - если придется потерянные сегменты данных. Это 32битные поля SEQ_num и ACK_num. SEQ_num это информация от передающей стороны указывающая с какого порядкового номера ОКТЕТА (байта) начинается текущий сегмент. ACK_num это 32 битное поле которое заполняет принимающая сторона указывая какой следующий номер ОКТЕТА она готова принять: Если номер 100, значит 99 уже успешно принято.
Важно что сервер и клиент имеют два независимых друг от друга потока передачи данных и для каждого потока есть свои ACK_num, SEQ_num значения.
В чем я еще путаюсь так это в 0 байте-октете. Но это сути не меняет, а является низкоуровневой реализаций, 0-indexed или 1-indexed - не суть важно так как первое значение SEQ_num заполняется псевдослучайным образом и называется ISN: Initial Sequential Number вестимо.
TCP сегмент данный инкапсулирован в IP пакет и описывается так называемым TCP Header - который содержит флаги и вышеописанные поля SEQ_num и ACK_num - для реализации бесперебойного и последовательного потока данных.
P.P.P.P.P.S.
- Схема протоколов и интерфейсов в Сетевом Компьютерном взаимодействии - Эта схема из книги Олиферов.
- IP пакет с инкапсулированным TCP сегментом
- TCP Header
Дополнение: книга про TCP/IP которую я нашел по поиску картинок в Google. Подозрительно похожа на TCP/IP Illustrated от Kevin R. Fall, W. Richard Stevens - не факт, не проверял.
