Hey. I don’t understand what SYN and ACK mean when establishing a TCP connection. A bunch of videos revised and did not understand. Who figured it out? What is the point of these SYN and ACK (why did they come up with it at all)? Computers exchange some strange numbers, some SYN increments per unit ... Some simple example is needed, understandable for someone who does not understand networks at all.

  • We watched videos ... Did you try a book like the same Oliferov? - Vladimir Martyanov
  • Oliferov's book is generally incomprehensible. this is a handbook, not a textbook. it is generally unrealistic to learn from it, but you can only see something if you have forgotten. - Dimon

1 answer 1

They invented them with the important goal that packets transmitted via TCP may not come in the same sequence as they were sent and not in the same composition. We need a mechanism that will allow us to assemble a set of received packets in the correct sequence. And at the same time to check whether all the packages are present or someone on the way down came off the track and was lost.

This problem is solved with the help of queue numbers and confirmation numbers. Queue numbers (sequence numbers) - simply number the packets sent. This number increases with the length of the data field. Each data octet (i.e., each byte) of one packet has its own queue number. The queue number of the first octet of the data is transmitted in the TCP packet header, which is also considered to be the queue number for the packet. Confirmation Numbers — tell the other party the queue number you expect to receive from it next. They say that packets with all previous queue numbers (but not including this one) have already been received.

The initial queue number is sent by the client when the connection is established along with the SYN flag. In response, the server sends a confirmation number (received queue number + 1) and its queue number (in general, any, but using the SYN coockie mechanism built according to a certain algorithm). The server is currently informing the client that it expects a packet from it, which will have a queue number equal to the confirmation number sent. From this number the client in the future and repelled.

Then everything happens in this way - one side (side A) sends to the other (side B) packets numbered by queue numbers. The second side accepts them and reports the queue number that it expects to receive from A with the next packet. This suggests that side B received all packets whose queue number was below the transmitted confirmation number (but not equal to it) and that party B expects that in the next batch of transmitted data the numbering will start from this number.

Just in case, once again, the TCP field Номер очереди ( Порядковый номер ) means just the packet number, it is needed in order to properly assemble and detect the packets (or a duplicate). The Номер подтверждения field is used to inform the second party about which packets have already been received from it (with what sequence numbers) and contains the number expected to see in the Номер очереди field of the next received packet from the same source.

PS SYN and ACK are all flags, not numbers. They indicate that the corresponding header fields are enabled ( TCP flags )

  • Why do you have confirmation numbers? Are these package numbers? In general, they increase each time by the size of the transmitted data (ie, this is the number of the last byte received (for ACK)), which allows you to correctly collect fragments and allows you to correctly count the "window" before receiving the ACK - Mike
  • @Mike: ru.wikipedia.org/wiki/… - MANK
  • I read wikipedia. only there is not correct, or rather vaguely written. Confusion arises from the word "ordinal." Start some tcpdump and see what actually happens in a real session :) - Mike
  • Here is citforum.ru/nets/tcp/tcpspec.shtml RFC translation to TCP protocol. And there is the correct terminology, the "sequence number" is called the neutral "queue number" in paragraph 3.3. It describes in detail how it works - Mike
  • @Mike: thanks, wrong with the increment size, I'll fix it now. - MAN69