Write in front: Here is Wang’s growth journal, a college student, who wants to share his study notes in his spare time to record his growth track and help those who may need it. Welcome to pay attention and leave a message.

0. Import -TCP Overview

  1. TCP is a reliable, connection-oriented transport protocol for the Internet transport layer, as opposed to UDP, which is unreliable. Read this blog post. – Oh, I wish I had come here.

  2. TCP relies on a number of basic principles, including error detection, retransmission, cumulative acknowledgements, timers, and header fields for ordinals and acknowledgements.

  3. History of TCP

  • ARPAnet, the precursor to the Internet, was just one of many packet-switched networks that began to grow rapidly in the early 1970s. These networks have their own protocols and do not communicate with each other.
  • Two researchers, Vinton Cerf and Robert Kahn, recognized the importance of interconnecting these networks and invented the TCP/IP protocol for communication networks

1. Establish the TCP connection and transfer data

  • In TCP, a connection must be established between two application processes before data can be sent between them (sending segments of packets to each other initializes the many TCP state variables associated with a TCP connection – the “handshake” phase)

  • In a TCP connection, the state of the connection remains entirely between the two end systems. So for the network elements (routers and link-layer switches) between the two end systems, they do not see the connection and they do not maintain the connection state.

  • Data flows in both directions over a TCP connection. This is called a full-duplex service, which can transmit data in both directions.

TCP connection establishment process

  • First, we define that the process that initiates the connection is called the client process and the other process is called the server process
  • The client process notifies the client transport layer that it wants to establish a connection with a process on the server
    • The customer first sends a special TCP packet segment
    • The server responds with another special TCP segment
    • Finally, the customer responds with a third special message segment

After the TCP connection is established

  • Once a TCP connection is established between two systems, two application processes can send data to each other

    • The client process passes the data flow through a socket (the gate of the process). Once the data passes through the gate, it is controlled by the TCP running in the client
    • TCP directs this data to the connection’s send buffer, one of the caches set up at the beginning of the three-way handshake.

  • From time to time TCP will then fetch a piece of data from the send cache

    • The amount of data retrieved is limited by the Maximum Segmenl Size (MSS)

    • MSS is usually set based on the Maximum link-layer frame length (known as the Maximum Transmission Unit (MTU)) that is initially determined to be sent by the local sending host. This MSS is set up to ensure that a TCP packet segment (when encapsulated in an IP datagram) plus the TCP/IP header length (typically 40 bytes) will fit into a single link layer frame. Both Ethernet and PPP link layer protocols have a 1500 byte MTU, so a typical VALUE for MSS is 1460 bytes.

      • Maximum Transmission Unit (MTU) indicates the Maximum size of the data service Unit that can be accepted by the sender and the size of the payload that can be accepted by the sender.
      • Is the maximum length of a packet or frame, usually in bytes. If the MTU is too large, the router will reject the packet forwarding because it cannot process too large packets. If it is too small, since the protocol must put a header on the packet (or frame), the actual amount of data transferred will be too small to be worthwhile. Most operating systems provide the user with a default value that is generally appropriate for the user.

    • When TCP sends a large file, such as an image on a Web page, TCP typically divides the file into chunks of MSS size (except at most 32 bits, which are usually smaller than MSS).

    • MSS refers to the maximum length of the application layer data in a packet segment rather than the maximum length of the TCP packet segment including the TCP header.

  • TCP Assigns a TCP header to each client data to form multiple TCP segments. These segments are sent down to the network layer

  • legend

2. TCP packet segment structure

  • A TCP packet segment consists of a header field and a data field

  • Structure legend

The first field

  1. The source port number

  2. Destination port number

Both of these port numbers are used for multiplexing and multiplexing, which means that a segment of a message is delivered to a specified socket. See my previous post on multiplexing and multiplexing.

  1. Validation and fields

It is used to detect whether there is a bit error in the data in the packet segment during transmission. For details, see my previous blog post. – Oh, I wish I had come here earlier. Under the fourth subheading of this blog post, there is a discussion about why checksums come into being and how they are calculated.

  1. 32 bit sequence number field

    • The ordinal number depends on the byte stream being transmitted, not the message segment being transmitted

    • Serial Numbers restricted by MMS (maximum message length), for example, there is now a 50, 000 bytes of the file transfer, MMS is 1000 bytes, TCP will be divided into 50 message segment, one of the first message section assumes that the initial sequence number is 0 (but not necessarily is 0, is randomly selected a tens of prevent message segment number repeat with other programs), The sequence number of the second packet segment is 1000 (0+MMS * 1), and that of the third packet segment is 2000

    • The choice of serial number is usually determined by both parties during connection determination and can be randomly selected

    • legend

  1. A. 32 bit Acknowledgment Number field

    • Due to TCP’s full-duplex feature, both end systems send data (packet segments) to each other.

    • Assume that host A fills the confirmation number of the packet segment with N

      • Cumulative acknowledgement: A has received all bytes numbered (n-1) and before
      • A expects to receive the packet segment N from B next
      • There is only one acknowledgment number, the first missing byte in the stream (or the one after the last acknowledged byte)

  2. Receive Window field (16 bits)

  3. 4 bits header length field

  4. Optional and variable-length options field

    • Maximum packet segment length (MSS) negotiated between sender and receiver

    • Or used as a window regulator in high-speed network environments.

  5. 6 bit fLag field

Telnet: A case study of serial numbers and confirmation numbers

  1. Telnet profile

    • Suppose host A initiates A Telnet session with host B.
    • Each character of the user key is sent to the remote host; The remote host sends back a copy of each character to the customer and displays these characters on the Telnet user’s screen.
    • This “echo back” is used to ensure that characters sent by the TelneL user have been received by the remote host and processed at the remote site.
    • Thus, each character travels twice across the network between the time the user hits the key and the time the character is displayed on the user’s screen.

  2. The illustration

  1. The first packet segment

    • The serial number is 42

      • When establishing A connection, the initial serial number of host A is set to 42. Therefore, the sequence number of the first packet sent by host A is 42

    • The confirmation number is 79

      • When establishing A connection, both parties determine that the initial serial number of host B is 79. Therefore, the first confirmation number sent by host A is 79, indicating that it expects to receive A packet segment with serial number 79 from HOST B

    • The data field is character C

      • Transmitted character

  2. Second message segment

    • The serial number is 79

      • When the connection is established, the initial serial number of host B is 79. Therefore, the serial number of the first packet sent by host B is 79

    • The confirmation number is 43

    • 1. Packet segments (bytes) with sequence number 42 or earlier have been received.

      • 2. You want to receive the packet segment 43 from A

    • The data field is character C

      • The echo characters

  3. The third packet segment

    • The serial number for 43

      • Indicates that the sequence number of the packet segment sent by A is 43

    • The confirmation number is 80

      • Packet segments (bytes) with serial number 79 and before (not before here) have been received
      • Next, he wants to receive the segment with the number 80 from B (that is, the segment is missing, but he still needs to fill in a number).

3. Round-trip time estimation and timeout

  1. Estimate the round trip time

    • Round-trip Time (RTT) is SampleRTT. In TCP, the RTT is measured only once at a certain Time, not all packet segments, and the retransmitted packet segments are not measured

    • Due to the changes of router and end system, the SampleRTT we measured obviously fluctuates, which is atypical. We need to take the average value of SampleRTT

    • Every time a new SampleRTT is obtained, EstimatedRTT is updated with the following formula

    • EstImatedRTT = (1 -α).estimateDRtt +α.samplertt

      • Exponential Weighted Moving Average (EWMA)
      • The word “exponential” in EWMA appears to mean that the weight of a given SampleRTT decays exponentially during the update process.

    • It can be seen that the new EstimatedRTT value is a weighted combination of the previous EstimatedRTT value and the new SampleRTT value.

    • The reference value of α given in [RFC 6298] is α=0.125 (i.e. 1/8)

  2. Calculation of round-trip deviation

    • Measure the change in RTT,DevRTT represents the RTT deviation
    • Formula: DevRTT = (1 -β).devrtt +β. I SampleRTT – EstimatedRTT I
    • The recommended value for beta is 0.25

  3. Set and manage the timeout interval for retransmission

    • Obviously, our timeout interval should be larger than our EstimatedRTT, but it should not be too large so as not to cause too much delay
    • Formula :TimeoutInterval =EstimatedRTT+4 * DevRTT

Reliable data transmission

  1. Let’s start with a highly simplified version that only uses timeout to recover missing segments.

    1.1 First let’s look at three major events related to sending and retransmitting

    • Event 1: Receive data from the upper-layer application

      • Receive the data
      • Encapsulate a packet segment
      • Give the serial number
      • To the IP layer
      • Timer start

    • Event 2: The timer timed out

      • Timed timeout retransmission indicates the corresponding packet segment

      • And then restart the timer

    • Event 3: An ACK was received

      • Case 1: Received sequence number equal to sendBase

        • Cumulative confirmation

        • If there is an unconfirmed packet segment, restart the timer

      • Case 2: The received sequence number is greater than SendBase

        • The cumulative confirmation

        • If there is an unconfirmed packet segment, restart the timer

    1.2 But this can also lead to some interesting situations. Consider the following scenario:

    • The acknowledgement packet sent by the receiver does not arrive until the timeout interval expires. As a result, the sender does not receive the acknowledgement packet due to the timeout interval

    • The confirmation packet sent by the receiver is lost, and the sender fails to receive the confirmation packet due to timeout

    1.3 Double the timeout interval

    • For retransmitted datagrams, each timeout is doubled
    • Of course, it is normal to start the timer due to receiving data from the upper layer and receiving ACK from the most recent EstimaledRTT and DevRTT values.
    • This is a limited form of congestion control

  2. Now let’s move on to a more comprehensive description – the time-out mechanism plus redundant validation techniques

    • For timeout retransmission, the problem may be that the timeout period is too long, which increases the end-to-end delay

    • Therefore, the technology of sending redundant ACKS is adopted

      • The repeated ACK of a packet segment (the last acknowledged byte) indicates that subsequent packets may have been lost
      • Allows the receiver not to discard the out-of-order packet segment
      • Generally, after receiving three redundant ACKS,TCPP performs fast retransmission, that is, immediately sends the lost packet segment

    • Four situations that the receiver will encounter

      • It is expected that the packet with the serial number N reaches the -ack delay of up to 500ms. The packet waits for whether the next packet segment arrives within the time. If no, the ACK for N is sent

      • The sequential segment with the desired sequence number arrives, and another sequential segment waits for ACK transmission – in the first case, an ACK is sent directly to acknowledge both sequential segments

      • An out-of-order packet segment larger than the expected sequence number arrives, and the interval is detected. – Send redundant ACKS immediately

      • A message segment that can partially or completely fill the interval between receiving data arrives – sends the maximum acknowledgement ACK immediately

  3. Does TCP select N step back or retransmission ‘? (See my previous post on pipelining protocols, Backstepping and retransmission if you are still confused about backstepping N steps and retransmission options)

  • Is TCP GBN or SR?

  • The TCP sender only needs to maintain the minimum ordinal number of bytes that have been sent but not acknowledged (SendBase) and the ordinal number of the next byte to be sent (NextSeqNum). In this sense, TCP looks more like a GBN-style protocol.

  • But TCP has some differences from GBN

    • Many TCP implementations cache properly received but out of order segments [Stevens 1994 J.

  • One proposed modification of TCP is the so-called Selective Acknowledgment [RFC 2018J], which allows TCP receivers to selectively acknowledge out-of-order segments rather than cumulative acknowledgment of the last properly received ordered segment. When used in conjunction with selective retransmission (i.e., jump retransmission of segments that have been selectively acknowledged by the recipient), TCP looks a lot like our regular SR protocol.

  • Thus, TCP’s error-recovery mechanism may best be classified as a hybrid of GBN and SR protocols.

5. Flow control

Source of traffic control service

  • We talked about TCP and each host set the receive cache when they set up a connection
  • When the TCP connection receives the correct, ordered bytes, the data is placed in the receive cache
  • The application process can read data from the cache, but not necessarily as soon as it arrives
  • A receive cache overflow occurs if the process reads data faster than it sends it
  • A flow-control service is a service that TCP provides to its application to eliminate the possibility of a sender overrunning the receiver’s cache

What is flow control service

  • The flow control service is essentially a speed matching service that matches the sending rate of the sender with the reading rate of the receiver application
  • It is different from congestion control, which is caused by network congestion

Implementation of flow control services

  • TCP provides flow control by having the sender maintain a variable called the Receive window, which is used to give the sender an indication of how much cache space the receiver has available

  • For example implementation

    • The receive window is used to give the sender an indication of how much cache space the receiver has available

    • Host B receives RcvBuffer

    • Define variables

      • LastByteRead

        • The number of the last byte of the data stream read from the cache by the application process on host B.

      • LastByteRcvd

        • The number of the last byte of the data stream that arrived from the network and was sent to host B to receive the cache towel.

      • “LasLByteRcvd – LastByteRead ~ RcvBuffer” must obviously hold

    • The receiving window is represented by RWND

    • The receiving window RWND must be met

      • RWND = RcvBuffer – [LastByteRcvd – LastßyteRead]

  • legend

  • Think about a problem

    • Assume that host B’s receive cache is full, such that RWND =0. After announcing RWND =0 to host A, it is assumed that host B has no data to send to host A. At this point, think about what happens.
    • Because the application process on host B clears the cache, TCP does not send A new packet segment with the new RWND value to host A.
    • In fact, TCP sends A segment to host A only when it has data or acknowledgment to send. In this way, host A cannot know that host B’s receive cache has new space, that is, host A is blocked and cannot send any more data!
    • To solve this problem, the TCP specification requires that when host B’s receive window is 0, host A continues to send A one-byte packet segment. These segments will be acknowledged by the recipient. Eventually the cache will begin to clear and the acknowledgement message will contain a non-zero RWND value.

6. TCP connection management

TCP connection establishment – three-way handshake

  • The first step

    • The client TCP sends a special TCP packet to the server TCP without application-layer data
    • The SYN bit at the head of the packet is set to 1, so the packet is called a SYN packet segment
    • The customer randomly selects an initial serial number to be placed in the serial number field of this paragraph
    • The packet segment is encapsulated in an IP packet and sent to the server

  • The second step

    • After receiving a SYN packet from the client, the server TCP allocates the TCP cache and variables to the TCP and sends an acknowledgement packet to the client.
    • The SYN flag of the permit packet is set to 1
    • The confirmation number of the permit message is set to the customer’s initial number +1
    • The permit message carries the initial serial number selected by the server itself
    • This acknowledgement packet is also called a SYNACK segment.

  • The third step

    • After receiving the SYNACK packet from the server, the client allocates cache and variables to the TCP and sends the SYNACK acknowledgement packet to the server
    • Acknowledgement Packet The acknowledgement number is the initial number selected by the server
    • The SYN flag is set to 0 because a connection has been established
    • This packet can carry application-layer data

  • legend

  • The reason for three handshakes

    • Make sure both sides are ready

Removal of TCP connections – Four waves of the hand

  1. An overview of the
    • At the end of the connection, resources (caches and variables) in the host are released
    • The customer sends a special packet. The FIN of the packet is set to 1
    • After receiving a FIN packet, the service sends an acknowledgement packet
    • The server continues to send its own data
    • The server sends its own FIN packets to the client (in this case, FIN packets follow the rule of timeout interval! , so it may be sent multiple times)
    • After receiving the PACKET, the customer sends the FIN ACK packet back to the server
    • The server closes the connection after receiving the ACK
    • Note that connection closure can also be initiated by the server
  2. legend

  1. SYN flood attack

    • In a SYN flood attack, the attacker sends a large number of SYN packets without replying to SYNACK packets, causing the server to allocate resources for these SYN packets to establish a large number of semi-connections.

    • To respond

      • An effective defense system exists :SYN cookies

      • Normal process, half connection queue is not full

        • The front-end service receives a SYN(SEq_A) and checks whether the queue is full. If the queue is not full, the front-end service puts the SYN(SEQ_B)+ACK(Seq_A +1) in the half-connected queue.
        • The client replies with an ACK(seq_B +1), and the server receives an ACK from the client to check whether there is a SYN in the semi-connection queue. If there is a connection, the server places the SYN in the connection completion queue

      • SYN Foold attack. Half-connection queue is full

        • After receiving the SYN, determine whether the half-connection queue is full and whether Syncookie is enabled, and proceed with the following processing according to Syncookie
        • It hashes the received SYN, encrypts the key fields into seQ of the server’s response to the SYN, sends ACK+SYN to the client (seQ =hash, the key value), and discards the SYN.
        • If the client is normal the client will respond to the server with the SYN(SEQ) ACK(seq+1)
        • When the server receives an ACK(SEq +1), it checks whether the SYN corresponding to the ACK exists in the half-connection queue. If not, it continues to check whether Syncookie is enabled. If yes, it checks whether SEQ is a legitimate cookie. Continue with the operation.

All see here, brothers, sisters, uncles and aunts give a thumbs-up to Xiao Wang, close a note and leave a message, and grow up with Xiao Wang, your attention is the biggest support for me.

If there are any inaccuracies or omissions above, or if you have a better comment, let me know in the comments below – I’ll do my best to answer them.