--- reliable transmission of the transport layer

  • Mentioned front link layer, when it is mentioned unreliable, an error for error detection only, error detection is the MAC frame. Talked about the network layer when a best effort delivery, does not guarantee reliable transmission. Lower are trying to avoid this problem, but the problem is inescapable after all, the ultimate reliable handed down falls to the transport layer.

Reliable transmission of TCP

A completely idealized reliable transmission

  • Assumption 1: links are ideal transmission channel, the transmitted data is neither the error, is not lost.
  • Assumption 2: the sender regardless of how fast data transmission rate, the receiver is always enough time to accept and promptly turned host (flow control problems).
  • But in fact these two assumptions are impossible to realize.

Second, stop and wait protocol ARQ

  • "Stop waiting for" is finish each send a packet to stop sending, wait for confirmation of the other party (not confirm that 重传). After receiving the acknowledgment packet at a transmission
  • Double full duplex communication, i.e., the sender is the receiver. (Herein for convenience discussions, we only consider the transmission data A and transmission data B receiving acknowledgment Therefore A叫做发送方,B叫做接收方)
  • After the transmission data B to A, B when the received data is found after the error detection is wrong, the data will be discarded. After A waiting period of time will resend the data (retransmission timeout, this time set in the back will say how).
  • 错误的几种可能:
    1. The transmitted data is lost or late
    2. Data transmitted wrong
    3. B sends back the acknowledgment is lost or late
    4. acknowledgment is lost
    5. The results are the same four cases, A and so on as long a period of time confiscated acknowledgment frame to B will timeout retransmission
  • Using the acknowledgment and retransmission mechanism called 自动重传ARQ, meaning that B does not need to request retransmission of A, A retransmission is automatically performed.
  • 优点: Simple
  • 缺点: Low channel utilization

Channel utilization:
Here Insert Picture Description

  • Where T D is a transport delay. A lot of time is spent waiting on, so the channel utilization is very low.
  • Question: Why is T D / total time? ? ? ?

Second, the transmission lines continuous ARQ protocol ----

Here Insert Picture Description

  • To solve the problem ARQ channel utilization
  • A transmission pipeline is to send only a plurality of consecutively transmitted packets, a packet transmission is not necessary to wait for each other's acknowledgment. Greatly improve the channel utilization.
working principle

Here Insert Picture Description

  • 窗口The recipient is bound to the sender, the sender constraints of how many packets can only send
    -
Cumulative confirmed
  • The recipient generally use 累计确认methods that do not have one by sending an acknowledgment of the received packet, but rather 按序列到达的最后一个分组发送确认, it means this: all packets until the packets are correctly received.
  • 优点: Easy to implement in a timely manner to confirm the loss of late do not have retransmission
  • 缺点:Not reflect all the information packets have been correctly received by the recipient to the sender (for example, the sender has sent 100 packets, except for the first three groups, other groups have successfully reached the recipient, then the recipient only tell send two packets arrive at the front side (confirmation number is 3, represents the next number is expected to receive a packet 3), it can not reflect the success behind 97 packets arrive, so the sender will mistakenly believe that only the first two groups arrived, so they resend packets 3-100, very wasteful.) (of course, this problem can be 选择确认SACKsolved)
    • Back-N-Go ( 回退N), indicates the need has been passed back retransmitted packets transmitted over the N (3-100)
  • 修正方案:选择确认SACK:
    • The receiver receives a series of discrete number of bytes, it sends back an acknowledgment tells the receiver the discontinuous and continuous fast block boundary information.
    • An optional part of the TCP header plus ' 允许SACK' option, and both sides must be agreed well in advance
    • Since the length of the header portion of the selectable portion 40 bytes at most, while indicating a 4-byte boundary will be spent (number range is 4 bytes), a block of eight bytes will be spent, and therefore can only indicate 4-byte boundary information blocks (not the whole takes up 40 bytes).

Concrete realization TCP reliable transport

  • Each end of a TCP connection must be provided with two windows - a 发送窗口and a 接收窗口(because it is full duplex). Two ports often changes dynamically
  • Using TCP reliable transport mechanism 字节的序号is controlled. All numbers are based on TCP does not based on message field
  • Round-trip time RTT TCP connection is not fixed. Need to use specific algorithms to produce the most reasonable estimate of retransmission time.
    Here Insert Picture Description
    First, the transmit buffer
  • The sender of the application process a stream of bytes written to TCP transmit buffer
  • Usually only a portion of the transmission window of the sender
  • Sent first saved but did not receive, it is possible retransmission (purple section)
    Here Insert Picture Description

Second, the receive buffer

  • Application of the process of the receiving side read the byte stream from the TCP receive buffer
  • Received byte may be omitted (purple color) from the cache
    Here Insert Picture Description
    three, three points should be emphasized
  1. A window is not always transmitted and received as large as the window B (because there is a certain time lag, lag is not as big as not ye ????)
  2. TCP flags does not specify how the data reaches the number of errant process. Usually the first to arrive in the store to wait indeed byte cache.
  3. TCP requires the receiver must have a 累计确认function (NOTE: determining accumulated prone Go-Back-N), which can reduce the transmission overhead

Fourth, the receiver sends an acknowledgment

  • Recipient may send an acknowledgment when appropriate, may be when they have data to send, the piggyback acknowledgment sent along the way. But also need to pay attention to two things:
    1. The recipient should not be unduly delayed send an acknowledgment, the sender would otherwise result in unnecessary retransmission. (Not too late a confirmation, the sender has transmitted all transmission window, the receiver will wait before retransmission data.)
    2. Piggybacking actually does not happen often, because most applications rarely transmit data simultaneously in both directions

Fifth, the timeout retransmission time RTO how to choose
Here Insert Picture Description

Published 22 original articles · won praise 0 · Views 133

Guess you like

Origin blog.csdn.net/weixin_42649617/article/details/105020578