preface

Much of the content is derived from chapter 3 in Computer Networking: a Top-down Approach, 7th edition.

Various application layer protocols enable applications between different hosts to exchange information across the network. These applications take what they need and choose their own application-layer protocols to get the job done, regardless of how the data moves across the network.

The transportation layer, located between the application layer and the network layer, uses the services of the network layer to support its own work and provides services for the application layer to support the operation of the application layer.

Application layer protocol, oriented to the delivery of information between application processes. The transport layer protocol is oriented towards the delivery of information between hosts.

  • When application processes of different hosts exchange information, they load and disassemble information through application-layer protocols. In other words, they use application-layer packets to interact.
  • Packets at the application layer need to be delivered to the corresponding host based on the capabilities of the transportation layer. For processes, the transport layer services are used through sockets.
  • Finally, the application-layer message is loaded into the transport-layer message, and the transport-layer uses network layer services to move the message across the network.

Therefore, the transport layer protocol provides rules on how to extract information between hosts for the delivery of information between hosts.

Multiplexing and multiplexing

For different transport layer protocols, the host assigns well-known ports for receiving and sending packets (unless otherwise specified). For example, the default TCP port number is 80. Firstly, the packets must specify the port numbers of both hosts, that is, the source port (sending port) and the destination port (receiving port).

Source and destination port numbers, which express the purpose of multiplexing and multiplexing:

  • Multiplexing: The sender of the packet can correctly receive the data from the socket, encapsulate it into a packet, and transmit it to the network layer. This process is called multiplexing.
  • Multiplexing: The recipient, receiving a packet from the network layer, can properly disassemble and deliver it to the correct socket. This process is called multiplexing.

UDP

UDP is the User Datagram Protocol. It uses a minimum number of services to reuse and decompose data.

The features of UDP are:

  • Deliver data as quickly as possible, without more functional support.
  • Delivers data directly to the destination port without establishing a connection.
  • Stateless connections, regardless of whether the data is delivered correctly to the destination.
  • The header has low overhead and supports the least functionality with the least number of bytes.

Simply put, UDP provides almost what the network layer services provide, and provides only simple functionality to support reuse/decomposition efforts. UDP is more about sending packets in a timely manner.

If you’re watching live, you’d rather see what’s happening in real time than what’s guaranteed to happen in the past.

The design goal of UDP is not to require redundant functions, so UDP packets are as simple as possible.

  • Source port: This port is a 16-bit port used by the sender and is optional. If it is not written, it is set to 0 so that the receiver will not send a response.
  • Destination port: a 16-bit port used by the receiving end.
  • Length: The length of the entire UDP packet is 16 bits. The minimum length is 8 bytes, because the packet header occupies 8 bytes.
  • Check value: the value contains 16 bits and is used to check whether data is damaged during transmission. If damaged, discard and do not require resend.

UDP can tolerate a small amount of packet loss, especially for streaming video and real-time phone calls, and requires reliable transmission.

Implement a reliable transport protocol

More often than not, a reliable transport protocol is needed to ensure that the data gets to its destination correctly. However, the network layer protocol that provides services for the transportation layer protocol does not provide this function, and the transportation layer realizes it by itself.

FSM

Before discussing how to implement a reliable transport protocol, take a brief look at FSM(Finite-State). As a modeling tool, FSM is used to describe the state changes that an object goes through during its life cycle.

There are four elements in FSM:

  • Status: Indicates the current state. For example, the current state is 1.
  • Conditions: Also called events, when one is met, the corresponding action can be performed or the new state can be migrated to, such as conditions A and B.
  • Action: When the condition is met, the corresponding processing is performed. After the action is completed, the status quo can be maintained, such as condition C, or the status can be migrated to a new state.
  • Substate: it is opposite to the present state, and it needs to be activated after the condition is reached. If the present state is 1, and condition A is satisfied, the migration to substate 2. After the state transition is completed, the present state is 2.

FSM helps illustrate how objects can handle complex conditions and transition between states. Now, assume that you are going to implement a Z protocol and use FSM to observe how Z performs a reliable transport protocol step by step.

Z1.0: transmitted by reliable channel

At the beginning, the transport services provided by the network layer can be trusted to be reliable. The data is eventually sent in groups over the channel.

Transmitting a message over a reliable channel is simple:

  • Sender: Only needs to wait until condition A triggers, receives data from the application layer, and sends packets through the channel without changing the state.
  • Receiver: It only needs to wait until the condition Q triggers, receive the data from the channel, fetch the data, and hand it over to the application layer, and the state does not change.

Z2.0: The channel sequence is transmitted by error

Now, the transport service provided by the network layer is unreliable, and indeed it is, assuming that packets are sent and received sequentially.

Imagine, when people communicate, how do they make sure that the other person has received the information? A dictated something to B, and B said “OK” to A to indicate that he had received the information.

To handle errant transmission situations, introduce:

  • Error detection: A mechanism is required to verify that the transmitted information is error-free, and some bit capacity is required to support this feature. In this case, it is assumed that you already have the technology.
  • Retransmission: When the receiver finds a packet error, it requires the sender to retransmit the packet.
  • Receiving feedback: After receiving the packet, the receiving end verifies the packet by error detection. If the packet is correct, the receiving end replies to ACK; if the packet is incorrect, the receiving end replies to NAK.

The sender:

  • After receiving the data from the application layer, the packet is sent over the channel and waits for the reply.
  • If an ACK is received while waiting for a reply, the data from the application layer continues to be processed. If the NAK is received, the group is resended.
  • A protocol that continues to process data at the application layer only after the receiver receives the packet. The protocol that supports this behavior is also called stop-wait protocol.

The receiver:

  • After receiving the data from the channel, the device sends an ACK to the sender and sends the data to the application layer.
  • The data received from the channel was incorrectly verified, and NAK was sent to the sender.

Z2.1: Confirm that ACK and NAK semantics are correct

Z2.0 implicitly assumes that ACK and NAK will be correctly transmitted, but they are themselves subject to transmission errors, so they need to be verified. However, you cannot create new “ACK” or “NAK” to confirm them, and this way will not avoid the loss of new confirmations.

New rules need to be added:

  • If we can’t confirm the answer, we will repeat it. Similarly, if the sender is unable to determine the response from the receiver and thinks the packet was not received, it resends the packet.
  • At the receiving end, after receiving a repeated packet, it considers that the sender has not correctly received the answer for this packet and answers ACK again
  • To satisfy these two rules, you need to be able to identify the groups, so each group has a number.

Currently, the packets are sent in sequence. That is, the sender does not send the next packet until it confirms that the packets have reached the receiver. Use X and Y to represent different groups.

The sender:

  • Receives data from the application layer, sends packet X through the channel, and then waits for an ACK or NAK describing X.
  • If the NAK X is received or there is a problem with the received message, the recipient is considered to have incorrectly received the packet and resends the packet X
  • If ACK X is received, wait for more application layer data to be received
  • Receiving data from the application layer, sending packet Y over the channel, and then waiting for an ACK or NAK describing Y.
  • If NAK Y is received or there is a problem with the received message, the receiver considers that the packet has not been correctly received and resends the packet Y
  • If an ACK Y is received, the system waits to receive more application-layer data
  • Repeat the process

The receiver:

  • When waiting for group X of the channel, if the wrong group X is received, reply NAK X
  • If the correct group Y is received and owned, the sender is considered not to have received the correct reply about the group Y, and replies ACK Y
  • If the packet X is correctly received, reply ACK X and wait for the packet Y from the channel
  • When waiting for group X to group the channel, if the wrong group Y is received, reply NAK Y
  • If the correct group X is received and already owned, the sender is considered not to have received the correct reply for group X and replies ACK X
  • If packet Y is correctly received, reply ACK Y and wait for packet X from the channel
  • Repeat the process

Redundant ACK is used to solve the problem that the reply may go wrong during transmission.

Z2.2: No NAK confirmation service

Z2.1 maintains both ACK and NAK to indicate responses. Logically, unless an ACK can be confirmed, it is treated as an NAK. Therefore, it is only necessary to determine whether the received ACK is the expected ACK, and all other cases are regarded as NAKS, so that only the ACK can be used to confirm the service.

The overall situation of Z2.2 and Z2.1 is roughly the same. The difference is that the conditions that can be triggered while waiting for an ACK have changed. In the case of waiting for ACK X, the condition changes from “NAK X received, or unacknowledged reply” to “ACK Y received, or unacknowledged reply”.

Z3.0: transmission through the channel with error and packet loss

In the PROTOCOL of Z2 series, it is assumed that sending and receiving messages can always be received from each other, and then make corresponding processing. In fact, the information transmitted between each other may not reach the destination, such a situation can be called packet loss. The agreement needs to be further refined.

The sender needs a timer. If the sender does not receive a reply from the receiver after the timer timer expires, the sender considers the packet lost and retransmits the packet.

For the receiver, no other changes are required. When receiving redundant packets, the receiver considers that the sender has not received a reply.

The sender:

  • Each time the sender sends a packet, the timer is restarted. When the sender receives a correct reply, the timer is disabled
  • Conditions D and F are for processing timeout, and corresponding groups are retransmitted
  • Conditions H and Q handle the case that the packet exceeds the scheduled time but finally reaches the receiver. In this case, it is possible to receive redundant ACK, but no processing is required

The receiver:

  • No other changes are required on the basis of 2.2

Here, the key points to implement a reliable transport protocol are identified: checksum, sequence number, timer, and validation.

Z4.0 Pipeline reliable transport protocol

Although Z3.0 can ensure that the data can be transmitted to the sender, but it has a very big problem, inefficient. Z3.0 is a stop-wait protocol, that is, one packet is confirmed to have arrived correctly, the next packet is not sent. While waiting for the reply from the receiver, the sender completely stops working, resulting in low efficiency.

In a more practical way, the sender sends multiple packets concurrently, seeming to fill the packets into a pipeline, hence the technique’s name pipeline.

The transmission time of a packet is much longer than that of the sender and the receiver, so the pipeline approach will effectively improve the efficiency. Now we need to supplement the rules to satisfy the pipeline:

  • In Z3.0, only two serial numbers “X “and” Y” are supported to ensure that one group is correctly received before sending the next group. In the pipeline, more serial number ranges are needed to support validation of multiple groups.
  • The sender needs to cache a certain amount of the packet to be able to resend it; The receiver also needs some redundancy in order to correctly respond to sent and resent packets.
  • For packet loss, damage and delay processing within sequence number range, pipeline can choose go-back-n (GBN) and Selective Repeat (SR) strategies.

Z4.0 chooses N steps back to support pipeline.

In the n-step back strategy, the concept of a send window is used to control how many packets can be sent by the sending pipeline. The packet in the sender has four different states

  • Acknowledged: A group that has been sent and received an acknowledgement from the receiver
  • Sent, unacknowledged: A group that has been sent but has not received acknowledgement from the receiver
  • Processed, not sent: The group to be sent
  • Unprocessed: Data that needs to be sent at the previous level, but cannot be processed by the sender

The window has a length of N, which represents how many packets can be sent to the network at the same time. Base is the left edge of the window, and the packets smaller than base are all confirmed packets. The packets between base and Nextseqnum are all the packets waiting for confirmation by the receiver. Nextseqnum-base < N means that the sender can continue to send packets.

For the receiver, maintain a serial number X, which means that all the packets within X have been received. When a packet is correctly received, ACK X is replied. In this way, the sender knows that the sender expects the group with the serial number X+1, and then adjusts the base to X+1 and sends the group after X+1. The FSM becomes:

The sender:

  • From base, send to base+N group, then start timer, nextseqnum record to which group sent.
  • If the timeout occurs, the packet is sent from base to base+N again.
  • When you receive an unconfirmed response, do nothing.
  • When the acknowledgement reply X is received, base is updated to X+1, the group of base to base+N is sent, and the timer is started. If base= Nextseqnum, turn off the timer.

The receiver:

  • Maintain X, which represents the range of packet ordinals that have been received.
  • When the correct expected grouping is received, the data is retrieved and delivered to the upper layer, while updating X, and then ACK X is returned.
  • In other cases, just reply ACK X. When receiving packets that are out of order, the sender discards them. After receiving a reply, the sender resends the packet.

Z5.0 selects a reliable transport protocol for retransmission

Although Z4.0 can meet the pipeline by going back N steps, a big problem is that it wastes too much bandwidth, and the loss or ACK damage of a certain packet may lead to the waste of resources in retransmitting many packets. Select retransmission to transmit only the lost packets to solve the bandwidth waste problem.

To support selective retransmission, you also use the concept of Windows on the receiving end to accumulate the packets you receive, using rcV_BASE to record the left edge of the window. For the sender, the timer is enabled separately for each group. The receiver receives an out-of-order packet. If the packet is not in the window range, it caches it and returns ACK X. The receiver will update its send_base value with reference to X and take the corresponding action. The FSM becomes:

The sender:

  • Send the group, start the timer for the group, update Nextseqnum, and repeat the process if send_base + N > Nextseqnum.
  • When group X times out, the group is sent again and the timer of the group is restarted.
  • When ACK X is received, mark X as confirmed. When send_base=X, slide the window to the unconfirmed group with the minimum serial number, update send_base, and send the group under the window condition.
  • We don’t do anything else.

The receiver:

  • Receive packet X and confirm that it is correct. First, determine whether the packet is within the window range. If yes, update it as received; if no cache, cache it. When RCV_base = X, update the RCV_base sliding window to the smallest group number without cache, deliver the cache group that has slipped to the upper layer, and reply ACK X.
  • We don’t do anything else.

summary

At this point, a reliable transport protocol with basic efficiency has been implemented. The basic conditions for it are:

  • Check and: Checks whether a packet was corrupted during transmission.
  • Timer: The timer solves the problem of packet loss, ACK loss, or damage to send the packet to the receiver again to ensure that the packet is transmitted to the receiver.
  • Serial number: Identifies a packet so that multiple packets can be transmitted in the network at the same time and each packet can be identified.
  • ACK: The behavior of the receiver to inform the sender that the packet is correctly received. The methods may differ, but the purpose is the same.
  • Pipeline: Enables multiple packets to be transmitted in the network at the same time, improving efficiency.
  • Windows: Use the cumulative validation method to support pipelines. in the real world, there is a further effect.

After observing how the model of a reliable transport protocol was formed with FSM, it is now possible to understand more fully how TCP is implemented.

TCP

Transmission Control Protocol (TCP). TCP is a reliable connection-oriented transport protocol. TCP is designed to deliver data correctly between hosts, with as much efficiency as possible in both sending and receiving, and provides a variety of additional features.

TCP Packet Structure

A TCP packet contains:

  • Source port: The port of the sending port, which is used for multiplexing
  • Destination port: The port of the receiving port, which is used for multiplexing
  • Serial number: In TCP, each data byte has a serial number. The serial number indicates that the data carried in the current packet is the start position of a set of data. For example, if the current serial number is 300 and there are 100 bytes in total, the serial number of the next packet is 400
  • Confirmation number: Is the ACK number, indicating the next expected number X, which means that all data before X has been received correctly
  • Header length: Since an optional option field exists, it is used to confirm the length of the entire header
  • Reserved use: a reservation made for a possible new use in the future
  • Flag bit: contains the flag bit control function of URG, ACK, PSH, RST, SYN, and FIN. For example, the acknowledgement number is valid only when ACK is set to 1
  • Receiving window: It is used to tell the sender and receiver the size of the window, so as to adjust the rate of sending data and achieve the purpose of flow control
  • Internet checksum: Calculated and stored by the sender and used by the receiver to verify whether the packet is damaged
  • Emergency data pointer: This parameter is valid only when URG is set to 1. The offset location of critical data, a way for the sender to send urgent data to the receiver
  • Option: The optional part is used to negotiate the maximum message length between the sender and the receiver, or to act as the adjustment factor for the adjustment window
  • Data: Optional parts that carry application-layer data, or other data used for other purposes.

Establish a connection

The client initiates the connection and the server initiates the connection. TCP also uses a three-way handshake to establish a connection.

First handshake The client sends a special packet to the server. The packet does not carry any application-layer data. First, the SYN flag is set to 1, indicating the ability to establish a connection with the server. Therefore, this special packet is also called a SYN packet. Then, an initial ordinal client_ISN is randomly generated and placed in the ordinal field. Finally, it is sent out through the lower protocol.

After receiving the packet, the server uses the SYN flag to identify it as a SYN packet until the client wants to connect to it. The server then allocates caches and variables to the TCP connection to service the subsequent content. Then, the server also generates a packet that contains no data, and populates the SYN flag with position 1, the acknowledgment number with client_ISN + 1, and the serial number with its initial serial number client_ISN. Finally, the packet is sent. The packet that indicates that the connection is allowed is also called a SYNACK packet.

Third handshake After receiving a SYNACK packet, the client uses the acknowledgement number to confirm the connection and allocates cache and variables for the TCP connection. From now on, the client can start sending data to the server. Meanwhile, the connection has been established and the SYN flag is at bit 0. In the next packet, enter service_ISN + 1 in the acknowledgment number so that the server can confirm the packet that allows the connection.

After a TCP connection is established, both parties can continuously send data to each other. TCP data transmission is bidirectional, which is why both parties exchange initial sequence numbers and allocate cache variables to each other.

To send data

To observe TCP sending data, the client sends data to the server.

  • The client sends data to the server. The TCP packet is filled in the sequence number segment. For example, the first packet is filled with 0
  • After receiving the data, the server replies ACK to the client, filling in the acknowledgement number of the packet. For example, the first reply is filled with 1000
  • TCP takes a cumulative acknowledgement, the server’s ACK 4000 reply is lost, so after timeout, the client resends the data “Seq= 3000,1000 bytes of data”
  • Although the ACK 2000 packet is also lost, the ACK 3000 packet reaches the client before the timeout. Therefore, the client knows that the data before 3000 is delivered correctly and there is no need to retransmit it.

disconnect

At a certain point, the client no longer needs to transfer data to the server, so it chooses to disconnect from the server to save costs. The TCP disconnection process is also known as the four wave

  1. The client sends a special TCP packet to the server, sets FIN to 1, and specifies a client_num.
  2. After receiving the disconnection packet from the server, the server replies with an ACK with the confirmation number client_num + 1
  3. After processing its logic, the server also sends a disconnection packet to the client. FIN is set to 1 and server_num is specified
  4. After receiving the disconnection packet, the client replies to the AC with the confirmation number client_num and serial number client_num+1
  5. At this point, the connection is disconnected

In particular, the client must confirm that the server has received its ACK packet before disconnecting. However, the disconnected server no longer sends packets to the client. How can the client confirm?

Maximum Segment Lifetime (MSL) indicates the Maximum duration of any packet on the network. The packets that exceed this duration are discarded.

After sending an ACK, the client waits 2MSL, confirms that it does not receive any FIN packet from the server again, and closes the connection again. When the server does not receive an ACK from the client, it resends the FIN packet after the timeout period. After receiving the ACK, the client replies again and waits for 2MSL. This allows the client to acknowledge that the server connection is closed and to close its own connection.

The overall state transition of TCP from establishment to disconnection can be shown in the following figure, which will not be described in detail.

Flow control and congestion control

The TCP content so far has assumed that the network is perfectly smooth and that both parties can transfer content at any rate. However, the reality is that the network does not have the conditions to meet any transmission rate.

When TCP operates on a crowded network, it is expected that the packet from the sender will not be delivered to the receiver on time, or the ACK packet from the receiver will not be notified to the sender quickly. The sender considers that the packet is lost and frequently triggers packet retransmission. The same situation applies to the resent packets. Under such conditions, it is better to reduce the rate to maintain the relative efficiency than to waste bandwidth, waste terminal capacity, and become inefficient.

Furthermore, if the network is smooth, the sender can quickly send packets, but the receiver is far from urgent in processing packets. As a result, the cache of the receiver overflows, discarding the new packets that cannot be processed temporarily, and the sender resends the packets after a timeout. It is easy to imagine that the two engines can work more efficiently if their speed matches.

The flow control service is used to solve the problem of rate matching to eliminate the possibility of a cache overflow on the recipient side, and congestion control is used to solve the problem of matching the send rate to the network condition. Although the two coping methods are very similar, they are adopted for different purposes.

Flow control

Flow control service, which uses the receive window in the receiver to represent the remaining data processing capability of the receiver to achieve negotiated control.

After TCP is established, the receiving end sets up a cache to receive data and deliver it to the application layer. Once the cache overflows, new data cannot come in.

The receiver: (1) Use LastRead to indicate where the receiving application read data from the cache. (2) Use LastReceived to indicate where the receiving application received data from the sender. (3) Use BufferSize to ensure that the cache does not overflow. Lastreceived-lastread <= BufferSize RWND = BufferSize - (lastreceiver-lastread) Put RWND in the window segment for receiving TCP packets. At the sender: (1) RWND is dynamic and needs to be tracked, that is, there is also a mapping on the sender. (2) LastAck indicates the location of the data that has been confirmed to be delivered. (3) LastSend indicates the location of the data that has been sentCopy the code

In this way, both sides maintain RWND information about the size of the receiving window and continuously update the information through TCP packets, thus eliminating the impact of cache overflow.

It is important to note that when RWND =0, the receiver may no longer be able to receive an ACK from the sender, because as a rule, the sender should not send more data when there is no more processing power at the receiver. To eliminate this effect, when RWND =0, the sender will continue to send 1 byte of data so that the RWND can be updated and work can continue.

Congestion control

Congestion control is to match the transmission rate of the sender to the network condition. If the rate of the sender is higher than that provided by the network, packets may be lost, or packets may not be delivered on time, resulting in a timeout.

Now, assuming that the receiver’s cache is sufficient, that is, RWND is sufficient, the rate at which the sender sends depends on the network connectivity.

The three problems of congestion control are:

  1. How do senders control the rate at which they send packets
  2. How does the sender know about the network
  3. In what way does the sender adjust the rate

For the first problem, in the protocol model after implementing Z4.0, the concept of sending window (CWND) is used to represent the sender’s remaining ability to send packets, then, lastsend-lastack <= min(CWND, RWND). Now, just considering CWND, that is, changing CWND, can control the rate at which the sender sends.

For the second problem, a correct ACK, where the metaphorical network is open, delivers the packets on time, can speed things up. A lost packet causes the sender to receive a duplicate ACK, retransmitting the packet. A timeout also means that the group was not delivered within the expected time and needs to be retransmitted. According to this logic, when the sender has a timeout or three repeated ACKS, the network is considered congested and the rate needs to be reduced.

For the third problem, it is necessary to achieve a balance in the real network environment. If the transmission rate is adjusted too quickly, it will cause too much loss and waste bandwidth capacity. If you adjust the transmission rate too carefully, you will not make full use of the bandwidth. Therefore, the algorithm to adjust the rate has to balance the two. The TCP congestion control algorithm provides a good enough solution.

In the TCP congestion control algorithm, the sender switches between three states, constantly adjusting to fit the network.

Slow start

The sender starts with a slow start. CWND will be set to 1 MSS. MSS is the maximum data length that a packet can carry. The round trip time of a packet is RTT. The transmission rate of a packet is MSS/RTT. Ssthresh is the threshold, that is, when the CWND and SSThRESH meet a certain relationship, the sender will switch state.

  • At slow start, the sender wants to quickly improve the sending capability to send packets that reach CWND in RTT time. After each new ACK arrives, CWND = CWND + MSS, so that after each RTT time, CWND doubles. As a result, the transmission rate increases exponentially.
  • The send rate will quickly exceed the network condition and the sender will receive a duplicate ACK, dupACKcount++.
  • If a timeout occurs, you are in the process of slow start. In this case, it is not appropriate to switch to another state, dupACKccount = 0, SSthresh = CWND / 2, send the lost packet, and restart the slow startup.
  • If the value of dupACKccount is 3, the transmission rate exceeds the network status. Switch to Quick Reply and continue to adjust.
  • If CWND >= SSthRESH, the send rate has room to improve, but it is too reckless to continue doubling, switch to congestion to avoid further adjustment.

Congestion avoidance

Congestion avoidance Indicates that the rate of the sender has room to improve. However, the sender needs to take more prudent measures to improve the rate to minimize packet loss caused by the rate improvement.

  • When a new ACK is received, instead of the slow start doubling each RTT time, congestion avoidance increases by 1 MSS per RTT time, i.e., the CWND increment for each new ACK arrival is MSS * (MSS/CWND).
  • When receiving a duplicate ACK, dupACKcount++.
  • When the timeout occurs, it indicates that the network situation changes dramatically during the linear growth of the rate. Set dupACKccount = 0 and SSThresh = CWND / 2 to send the lost packets, enter the slow start state, and quickly match the rate again.
  • If dupACKccount = 3, the rate of the sender may be slightly higher than the network condition. Set SSThRESH = CWND / 2, CWND = SSHRESH + 3 * MSS to send the lost packets and enter the fast recovery state.

Fast recovery

The quick recovery state is not necessarily a state. It means to quickly adjust the judgment whether to let the sender go back to slow start to quickly locate the general situation of the network, or to re-enter congestion avoidance and carefully adjust the sending rate.

  • When a duplicate ACK is received, CWND = CWND + MSS and a new packet is sent.
  • When a new ACK is received, CWND = SSTRESH, dupACKccount = 0, enter congestion avoidance
  • On timeout, resend the lost packet with ssthRESH = CWND / 2, CWND = 1 MSS. DupACKcount = 0, restart the fast startup.

The TCP congestion control algorithm helps the sender to dynamically adapt to the network conditions and adapt quickly when the network changes dramatically by treating the three different states: slow start, congestion avoidance, and fast recovery.

conclusion

  1. From the beginning, from the multiplexing and multiplex decomposition, the most basic function of a transportation layer protocol is expounded, that is, to know where the data carried by the transportation layer protocol comes from and where to go. Services for the application layer.
  2. With THE help of UDP, this paper observed the functions that a simple transportation layer service should have, and also explained the network service that the transportation layer depends on, which cannot guarantee the reliability of data.
  3. Transportation layer sometimes needs reliable data transmission service, through the implementation model of Z protocol, it is shown that check and, ACK, serial number, timeout, send window are the basic elements of a reliable transport protocol.
  4. Finally, by looking at the implementation of TCP, it has all the characteristics of the Z protocol model and other features, such as link oriented

, flow control, congestion control, etc.

In general, transportation layer protocols specify how hosts exchange information and provide the possibility for application layer operation.

Article portals in all layers of the Internet protocol stack

Internet Protocol Stack: What are application-layer protocols doing

Internet Protocol Stack: How does the transport layer deliver data

Internet protocol stack: the data plane of the network layer

Internet protocol stack: the control plane of the network layer

Internet Protocol Stack: Link layer overview

reference

Ch.3 in computer networking: a top-down approach, 7th Ed

Interviewer, don’t ask me for three handshakes and four waves