Finally, TCP, the best protocol.

Simply put, TCP fully realizes the various control functions of data transmission, packet loss can be retransmitted control, and disorder can be corrected. None of this is available in UDP.

It has been known before that UDP protocol is transmitted in the form of data packets, which may arrive early. We cannot guarantee the order of data arrival. TCP solves this problem. When a computer reads data from a TCP interface, the data is already a sequential “stream.”

The concept of flow

Overview

  • B: Point-to-point
    • One sender, one receiver
  • Reliable sequential byte stream
    • No “message boundaries”
    • UDP is oriented to packets, while TCP is oriented to data streams
  • Assembly line pipelined
    • Implementation of pipelining control mentioned earlier, TCP congestion and flow control can set window size
  • “Full duplex” data(that is, two-way transmission while sending and receiving)
    • MSS: maximum segment size
  • connection-oriented
    • Data will be sent only when the communication peer is confirmed to exist, thus controlling the waste of communication traffic
    • Handshaking between senders and receivers before data is exchanged
  • Flow control
    • The sender doesn’t overwhelm the receiver, meaning it doesn’t send too many messages at once or anything like that

Overview of TCP segments — TCP header

TCP encapsulates IP packets with segments rather than the entire text stream.

Like an IP or UDP packet, a TCP fragment is divided into a header and a payload

The name “fragment” is more of a reminder: hey, this isn’t the full text stream.

It flags up quite a bit of important information, incidentally reminding you that this layer of transport is port-based, reminding you that it is reliable and so on

The structure of the entire TCP segment is shown in the figure

  • memorize
  • Remember to pay attention to sizes, such as 16bits source port and 16bits destination port

Some explanations:

  • The number of the first byte in the entire byte stream, used to indicate the location
  • Acknowledgment number: Acknowledgements, the Cumulative ACK of the next byte to be expected to be received from the other party, as will be clear from the diagram

Q: How does the receiver handle unordered segments A: What the TCP specification doesn’t say is, – it’s up to the person who wrote the TCP code, as long as the data is delivered to the application layer

Show me the picture!!

  • In practice, more than one byte may be passed at a time, and the Ack order may jump

Self-evolving TCP timeout control — Estimation and approximation of round trip time

Origin of the problem

In reality, how to define timeout is a big problem — everyone knows it’s longer than the round trip time, but I don’t even know the RTT. This thing can change

  • If the timeout is too short, I will have to send it again and again, or even fail to receive it directly
  • It’s too long to lose in a million years

So, we need a way to estimate RTT

Estimation method of RTT [Important]

  • The value of RTT is different every time, and we need to make it more likely to be a probabilistic expected value

Jacobsen/Karel’s Algorithm EstimatedRTT=(1− A)∗EstimatedRTT+a∗SampleRTTEstimatedRTT =(1-A)*EstimatedRTT + A * SampleRTTEstimatedRTT = (1 – a) ∗ EstimatedRTT + a ∗ SampleRTT

  • So the probability is shifted by weighted A, much like machine learning
  • In the past, the impact of samples has declined exponentially
  • A = 0.125

Timeout Specifies the timeout period

After calculating RTT, we can set the timeout timeout time to EstimatedRTT + a controlled safety margin value

First, the difference between sampleRTT and EstimatedRTT is calculated as DevRTT=(1−β)∗DevRTT+β∗∣ sampleRTT −EstimatedRTT∣DevRTT =(1 -β)*DevRTT + Beta * | SampleRTT – EstimatedRTT | DevRTT = 1 – (beta) ∗ DevRTT + beta ∗ ∣ SampleRTT – EstimatedRTT ∣

Reliable TCP

We’ve done a whole section on reliable transport theory, but can we finally see how TCP actually implements it

When data is received from the application

  • Create sequence numbers for each segment
  • The number is the byte stream of the first data byte in the segment
  • 3. Send a timer (equivalent to the oldest unacked segment sent) at the TimeOutInterval just calculated before it starts

If the timeout

  • Retransmission of the segment that caused the timeout restarts the timer

For example, a segment that has not been identified before is identified

  • Mark it as confirmed
  • If there are more unconfirmed segments, start the timer and continue

Just look at the picture! (DIAGRAM of TCP retransmission scheme)

Basic can be solved easily!

Fast cotransmission scheme

Sometimes timeout is too long, and you can actually tell in advance

Segment loss is detected by repeated ACKS

  • The sender usually sends a large number of segments consecutively
  • If a packet segment is lost, it usually causes (receives) multiple duplicate ACKS

If the sender receives three redundant ACKS of the same data

  • Retransmission of the minimum ordinal segment:

The first one is normal, the back three repeat on retransmission!

The title

Last problem send window 2 can’t move right without confirmation