Computer network top-down approach Chapter 3 - Transport Layer (Transport Layer) .1

3.1 Overview and transport layer services

　　The transport layer protocol between application processes running on different hosts to provide a logical communication (logic communication) function.

　　3.1.1 Relationship transport layer and network layer

　　The network layer provides a logical communication between hosts, the transport layer provides a logical communication processes on different hosts running.

　　3.1.2 Overview of Internet transport layer

　　Provide TCP (Transmission Control Protocol) on the Internet and UDP (User Datagram Protocol) in two

 3.2 multiplexing and demultiplexing

　　 A process has one or more sockets (socket), which corresponds to the data transfer process from the network and transfer data from the process to the gateway network.

• The receiving end will be delivered in the transport layer data segments to correct socket (ie a different process) work called demultiplexer (demultiplexing).
• Collected from a different source host socket data blocks, and encapsulate the header information for each data block to generate a segment, and then pass the segments to the network layer, all of this work is called multiplexing with (multiplexing).

　　1. No multiplexer connected to the demultiplexing

　　In the transport layer, connectionless network transmission is achieved by UDP, a UDP socket is a tuple containing a destination IP address and destination port number to fully identified.

　　The host receives a destination port number of the UDP segment examination section, the guide section and bind UDP Socket port number, and UDP packets so if two different segments of the source IP address / port number, there is the same destination port number, then the two segments will be directed to the same socket purpose process through the same purpose.

　　2. The connection-oriented multiplexing and demultiplexing

　　The transport network layer is often used for connection-oriented transport TCP, but there is a slight difference between UDP and TCP socket socket, a TCP socket is a four-tuple (source IP address, source port number, destination IP address, destination port number) to identify the. When a TCP segment from the network reaches a host, the host uses all four values ​​to the segment orientation, i.e. the demultiplexer to the appropriate socket.

　　Unlike UDP is a TCP segment having two different sources or source IP port number will be redirected to reach two different sockets.

 

　　 3.Web server with TCP

 

　　Today's high-performance Web servers typically use only one process, but the connection to create a new thread with a new socket connection for each new customer.

 

3.3 Connectionless Transport: UDP

　　UDP advantage

•  Better application layer retransmission control data to be transmitted and the transmission time.
•  No need to establish a connection.
•  No connection state.
•  Packet header overhead small.

　　3.3.1 UDP segment structure

　　

　　UDP segment structure is defined in RFC 768, UDP header only four fields, each field consisting of two bytes.　　

• Source port number: this port to the socket (client) application program corresponding to the server side can use this port number to send data to the client.
• Destination port number: a socket application process on the server corresponding to the port number, such as port 80 of the HTTP server.
• Length: indicates the total length of the UDP packet header and data portion of the segment, in bytes, i.e., header + data.
• And testing: provide error detection, i.e., when the test for determining UDP segment from the source to the destination, wherein if the changed bit.

 　　3.3.2 UDP checksum

• sender
  • The contents of paragraph regarded as 16-bit integer
  • Checksum calculation: and, added to the bit value of the intake and later, all integers obtained bitwise negation, to obtain a checksum
  • The checksum sender and the checksum field into
• receiver
  • And testing, and the remaining segment of the checksum field is calculated by comparing obtained.
  • If not equal, then check out the error, but if there may be an equal mistake.

3.4 reliable data transmission principle

　　3.4.1 configured reliable data transfer protocol

　　1. fully reliable data transmission via a reliable channel: rdt 1.0

　　Finite state machine (FSM) may represent a mathematical model of the behavior of a finite number of states and the transition and operation or the like between these states, the following figure means that a finite state machine sender and recipient, the bottom of the channel is completely reliable, the sender and a receiver with respective FSM, each have only one state FSM.

　　(Illustration: arrow FSM indicates a protocol description changes from one state to another state changes caused by events displayed above the horizontal line, the motion used when an event occurs in an initial state displayed below the horizontal line with .FSM. a dotted line.)

　　

• Since the channel is reliable, the receiver does not need to provide any feedback to the sender
• Assumed rate as fast recipient receives data rate to transmit data to the sender, the receiver does not need to ask the sender to send a little slower.

　　2. Reliable data transmission via a channel with bit errors: rdt2.0

　　Rdt 2.0 below shows the finite state machine described in FIG., The data transmission protocol (Automatic Repeat Request protocol) using the error detection, acknowledgment and negative acknowledgment.

　　

• In the transmitting end an initial state on the left , the transmitting end from a higher layer protocol is awaiting data passed down. When the trigger  rdt_send(data) event:
  • Through  sndpkt = make_pkt(data, checksum) a packet containing a data to be sent and with a checksum generated
  • Then by the packet  udt_send(sndpkt) is sent to the channel
• After performing the above-described two actions, the transmitting side changes the status is "waiting to receive the receiving end of the ACK or NAK packet." I.e., into the right shape state, then there will be different according to different programs in response to changes of the receiving end:
  • If an ACK packet is received ( rdt_rcv(rcvpkt) && isACK(rcvpkt)), then the sender knows the most recent packet has been received correctly, so protocol returns the left state, continues to wait for the next time of transmission by the higher layer data transmission request down
  • If you receive a NAK packet ( rdt_rcv(rcvpkt) && isNAK(rcvpkt)), then the sender knows the packet received by the receiver is damaged, so the call  udt_send(sndpkt) to resend the packet, then the state of the same, continue to wait to receive the receiving end of an ACK or NAK packet.

　　In the above protocol, when the sender is waiting for an ACK or NAK state, it can not obtain more data from the upper layer. Such a protocol is called the sub- stop and so protocol (the wait-and-STOP) .

• Receiving end rdt 2.0 is still only one state. State transition depends on whether the packet is received damaged, there are two ways:
  • If the received packet is damaged, that is  rdt_rcv(rcvpkt) && corrupt(rcvpkt), NAK packet is returned
  • If the packet is received intact, i.e.  rdt_rcv(rcvpkt) && notcorrupt(rcvpkt), an ACK packet is returned
• After this process still return to their state, continues to wait for the next time a packet received and processed from the bottom.

　　3.经具有比特差错的丢包信道的可靠数据传输 rdt 3.0

　　在现实的网络环境中，除了比特受损外，底层信道还会丢包；有很多可能的方法可以解决丢包问题，这里我们让发送方负责检测和恢复丢包工作。

　　假定发送端传输一个数据分组，该分组发生丢失 或者 接收端对该分组的 ACK 发生了丢失。在这两种情况下，发送端都收不到应当到来的接收端的响应。所以，如果发送端愿意等待足够长的时间以确定该分组缺失已丢失，则它只需要重传该数据分组即可。

　　从发送端的观点来看，重传是一个万能灵药。为了实现基于时间的重传机制，需要一个倒数计时器 (countdown timer)，在一个给定的时间量过期之后，可中断发送方。发送方需要做到：1）每次发送一个分组（包括第一次分组和重传分组）时，就启动一个定时器；2）相应定时器中断；3）终止定时器。

　　下图是rdt 3.0的发送方FSM，该协议运行在可能发生出错和丢失的信道上。

 

 

　　rdt 2.2 协议中的接收端有限状态机描述图仍然适用于 rdt 3.0 协议，下面我仍然用文字来简要描述一下上图中的发送端发送分组流程：

• 首先由较高层触发 rdt_send(data) 事件，通过 sndpkt = make_pkt(0, data, checksum) 产生一个序号为 0，包含待发送数据且带有校验和的分组，接着通过 udt_send(sndpkt) 将其发送到信道中并启动定时器，然后状态变迁为“等待接收接收端的 ACK 0”
• 当发送端在“等待接收接收端的 ACK 0”的时候：
  • 如果收到了受损的分组（即 corrupt(rcvpkt)）或者收到了 ACK 1（即 isACK(rcvpkt, 1)，也就是收到了自己发送的上一个分组的 ACK），则直接忽略
  • 如果定时器时间到，则由 udt_send(sndpkt) 重新发送该分组并重新启动定时器
  • 如果收到了完好的分组且 ACK 为 0，那么发送端知道接收端已经成功接收了刚才发送的序号为 0 的分组，直接停止定时器，此时发送端状态变迁到等待较高层传下来的数据发送请求
• 注意在继续等待从较高层传下来的数据发送请求的过程中，如果收到了任何分组数据包，都直接忽略，因为它们一定是冗余的

　　3.4.2 流水线可靠数据传输协议

　　停等协议可能会限制底层网络硬件所提供的能力

　　解决方法是：不使用停止等待方式，运行发送方发送多个分组而无需等待确认。由于许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，因此这种技术被称为流水线 (pipelining)。当然，流水线会增加协议的复杂度：

• 　必须增加序号范围

　　因为信道中的分组要有一个唯一的序号，会有多个分组在信道中未被确认。

• 协议的发送方和接收方必须缓存多个分组

　　发送方至少应该缓存已经发送却还没有被确认的分组。接受方也许应该缓存已经正确接收的分组。

• 所需的序号范围和对缓存大小的要求取决于协议如何处理丢失、损坏及延时大的分组

　　解决流水线差错错误的两种基本思路：回退N步和选择重传。

　　3.4.3 回退N步

  　　GBN 协议被称为滑动窗口协议 (silding-window protocol)

　　3.4.4 选择重传

 　　选择重传协议让发送方仅重传那些它怀疑在接收方出错的分组，避免了不需要的重传。

 

参考:

https://www.cnblogs.com/hithongming/p/9379397.html

https://www.cnblogs.com/oxspirt/p/6496434.html

https://www.cnblogs.com/huahuahu/p/liu-shui-xian-ke-kao-shu-ju-chuan-shu-xie-yi.html