cse205w4_transportlayer

运输层协议为运行在不同主机上的应用进程提供了逻辑通信（logic communication）功能应用程序使用运输层提供的逻辑通信功能彼此发送报文，而无需考虑承载这些报文的物理基础设施的细节。

运输层协议是在端系统中而不是在网络路由器中实现的：

• 在发送方：运输层将接收到的来自发送应用进程的报文转换成运输层分组，用因特网术语称其为运输层报文段（segment）。可能的方法是，将应用报文划分为较小的块，并为每块加上一个运输层首部来创建运输层报文段。然后，运输层将这些报文段传递给网络层，网路层将其封装成网络层分组（一个数据报）并向目的地发送。
• 在接收方： 网络层从数据报中提取运输层报文段，并将该报文段向上交给运输层。运输层则处理接收到的报文段，使得接收方应用进程可应用该报文段中的数据。

网络应用程序可以使用多种运输层协议如TCP和UDP

在协议栈中，运输层刚好位于网络层之上。
运输层为运行在不同主机上的进程之间提供了逻辑通信，而网络层则提供了主机之间的逻辑通信。
运输层协议所能提供的服务也受到了底层网络层协议的服务模型的限制。如果网络层协议不能为两主机之间发送的运输层报文段提供时延和带宽保证，那么运输层协议也不能为两进程之间发送的报文提供时延和带宽保证。
然而，即使底层网络协议在网络层不提供相应服务，运输层协议也能提供某些服务。一个例子是运输层协议提供可靠性，一个是提供机密性。

UDP和TCP最基本的任务是，将两个端系统间IP的交付服务扩展为运行在两个端系统上的进程之间的交付服务。将主机间交付扩展到进程间交付，称为运输层的多路复用和多路分解。

• TCP（传输控制协议），它为调用它的应用程序提供了一种可靠的、面向连接的服务
  TCP为应用程序提供了几种附加服务

1. 它提供可靠数据传输（reliable data transfer），通过使用流量控制、序号、确认和定时器等技术，TCP确保正确地、按序地将数据从发送进程交付给接收进程。这样，TCP就将两个端系统间不可靠的IP服务转换成了一种可靠的进程间数据传输服务。
2. TCP还提供拥塞控制（congestion control）
   不严格地说，TCP拥塞控制防止任何一条TCP连接用过多流量来淹没通信主机之间的链路和交换设备。
   从原理上讲，TCP允许TCP连接通过一条拥塞的网络链路，平等地共享网络链路带宽。

• UDP（用户数据报协议），它为调用它的应用程序提供了一种不可靠、无连接的服务

1. UDP流量是不可调节的，使用UDP传输的应用程序可以根据其需要以任何速率发送数据

多路复用与多路分解服务是所有计算机网络都需要的。
多路分解（demultiplexing）：将运输层报文段中的数据交付到正确的套接字的工作。
多路复用（multiplexing）：从源主机的不同套接字中收集数据块，并为每个数据块封装上首部信息（这将在多路分解时用到）从而生成报文段，然后将报文段传递到网络层的工作。
多路复用的要求：

1. 套接字有唯一标示符
2. 每个报文段有特殊字段来指示该报文段所要交付的套接字，这些特殊字段是源端口号字段（source port number filed）和目的端口号字段（destination port number）。

端口号是一个16比特的数字，其大小在0～65535之间。0Q～1023范围的端口号称为周知端口号（well-known port number），是受严格限制的，它们会被保留给诸如HTTP（端口号80）和FTP（端口号21）之类的周知应用层协议。

运输层多路分解的过程：主机上的每个套接字被分配一个端口号，当报文段到达主机时，运输层检查报文段中的目的端口号，并将其定向到相应的套接字。然后报文段中的数据通过套接字进入所连接的进程。。

1. 无连接的多路复用与多路分解（UDP）
   应用程序的客户机端让运输层自动地（并且透明地）分配端口号，而服务器端则分配一个特定的端口号。
   一个UDP套接字是由一个包含目的IP地址和目的端口号的二组来全面标识的。如果两个UDP报文段有不同的源IP地址和/或源端口号，但具有相同的IP地址和目的端口号，那么这两个报文段将通过相同的目的套接字定向到相同的目的进程。
2. 面向连接的多路复用与多路分解
   TCP套接字和UDP套接字之间的一个细微差别是，TCP套接字是由一个四元组（源IP地址，源端口号，目的IP地址，目的端口号）来标识的。
   当一个TCP报文从网络到达一台主机时，主机使用全部4个值来将报文段定向（多路分解）到相应的套接字。
   与UDP不同的是，两个具有不同源IP地址或端口号的到达的TCP报文段将被定向到两个不同的套接字，除非TCP携带了初始创建连接的请求。
   服务器主机可同时支持很多TCP套接字，每个套接字与一个进程相联系，并由其四元组来标识每个套接字。当一个TCP报文段到达主机时，所有4个字段用来定向（多路分解）报文段到相应的套接字。

1. UDP从应用进程得到数据，附加上多路复用/多路分解服务所需的源端口号和目的端口号字段，及两个其他的小字段，然后将形成的报文段交给网络层。
2. 网络层将该运输层报文段封装到一个IP数据报中，然后尽力而为地将此报文段交付给接收主机。
3. 如果该报文段到达主机，则UDP使用目的端口号来将报文段中的数据交付给正确的应用进程

使用UDP时，在发送报文段之前，发送方和接收方的运输层实体之间没有进行握手，正因如此，UDP被称为无连接的
UDP被使用于DNS连接和流媒体中

UDP的特性：

1. 应用层能更好地控制将要发送的数据和发送时间：
2. 无需建立连接：UDP无需任何准备即可进行数据传输，因此UDP不会引入建立连接的时延。
3. 无连接状态：TCP需要在端系统中维护连接状态。
4. 分组首部开销小：每个TCP报文段都有20字节的首部开销，而UDP仅有8字节的首部开销。

发送方的UDP对报文段中的所有16比特字的和进行反码运算，求和时遇到的任何溢出都被回卷。得到的结果放在UDP报文段中的检验和字段

通过rdt_send()函数，可以调用数据传输协议的发送方。它将要发送的数据交付给接收方的上层。在接收方，当分组从信道的接收段抵达时，将调用rdt_rcv()。当rdt协议想要向较高层交付数据时，通过调用deliver_data()完成。

通过有限状态机（finite-state machine，FSM）来表示发送方和接收方的操作。
FSM描述图中各个标志的作用：

当发送方在wait-for-ACK-or-NAK状态时，它不能从上层获取数据，因为这种行为，类似于rdt2.0的协议被称为停等（stop-and-wait)协议

rdt2.0的缺陷：ACK或NAK分组受损，冗余分组（duplicate packet）的困难在于接收方不知道它上次所发送的ACK或NAK是否被发送方正确地收到。
解决该问题的方法：在数据分组中添加一新字段，让发送方对其数据分组编号，即将发送的数据分组的序号（sequence number）放在该字段。于是，接收方只需要检查序号即可确定收到的分组是否是一次重传。

协议rdt2.1使用了从接收方到发送方的肯定确认和否定确认。当接收到失序的分组时，接收方对所接受的分组发送一个肯定确认。如果收到受损的分组，接收方将发送一个否定确认。如果不发送NAK，而是发送一个对上次正确接收的分组的ACK，我们也能实现与NAK一样的效果。
发送方接收到对同一分组的两个ACK（即接收冗余ACK，duplicate ACK）后，就知道接收方没有正确接收到跟在被确认两次的分组后面的分组。

rdt2.2是在具有比特差错信道上实现的一个无NAK的可靠数据协议。
rdt2.1和rdt2.2之间的细微变化在于，接收方必须包括由一个ACK报文确认的分组序号（这可以通过在接收方FSM中，包括make_pkt()中的参数ACK，0或ACK，1来实现），发送方必须检查接收到的ACK报文中所确认的分组序号。

现在假定除了比特受损外，底层信道还会丢包。
我们让发送方负责检测和恢复丢包。假定发送方传输一个数据分组，或者该分组或者接收方对该分组的ACK发生了丢失。在这两种情况下，发送方都收不到应当到来的接收方的响应。如果发送方愿意等待足够长的时间以便确定分组已丢失，则只需重传该数据分组即可。
因此，实际中发送方采取的方法是“明智地”选择一个时间值，以判定确认不能确保但可能已经发生了丢包。如果在这个时间值内没有收到ACK，则重传分组。注意到如果一个分组经历了一个特别大的时延，发送方可能会重传该分组，即使该数据分组或ACK都没有丢失。这就是发送方到接收方的信道中引入了冗余数据分组（duplicate data packet）的可能性。幸运的是，rdt2.2协议已经有足够的功能（即序号）来处理冗余分组情况。
为了实现基于时间的重传机制，需要一个到计数定时器（countdown timer），在一个给定的时间过期后，可中断发送方。
因此，发送方需要能做到：1】每次发送一个分组（即第一次分组和重传分组）时，便启动一个定时器。2】响应定时器中断（采取适当的动作）。3】终止定时器。
因为分组序号在0和1之间交替，因此rdt3.0有时被称为比特交替协议（alternating-bit protocol）。

rdt3.0的性能问题的核心在于它是一个停等协议。
假设两个端系统之间的光速往返传播时延（RTT）大约为30ms。假定彼此通过一条传输速率为$R = 1 Gbps(10^9 bps)的信道相连。包括首部字段和数据的分组长$L = 1000$字节（8000比特），实际发送一个分组到$1Gbps$链路中所需时间是：

$$t_{trans} = frac{L}{R} = frac{8000bit/packet}{10^9bit/s} = 8 mu s$$

如果发送方在$t = 0$时刻开始发送分组，则在$t = L/R = 8mu s$后，最后1比特数据进入发送方信道。该分组经过15ms跨美国的旅行后到达接收方，该分组在时刻$t = RTT/2 + L/R = 15.008ms$时到达接收方。为了简化起见，假设ACK分组很小（以便我们可以忽略其发送时间）。接收方收到一个数据分组的最后1比特后立即发送ACK，ACK在时刻$t = RTT + L/R =30.008ms时到达发送方。此时，发送方可以发送下一个报文。
因此在30.008ms内，发送方的发送只用了0.008ms。定义发送方（或信道）的利用率（utilization)为：发送方实际忙着将发送比特送进信道的时间与发送时间之比。

$$U_{sender} = frac{L/R}{RTT+L/R} = frac{0.008}{30.008} = 0.00027$$

解决这种特殊的性能问题的一个简单方法是：不使用停等方式运行，允许发送方发送多个分组而无需等待确认。因为从发送方向接收方传输的众多分组可以被看成是填充到一条流水线中，故这种技术被称为流水线（pipelining）。流水线技术可对可靠数据传输协议带来如下影响：

1. 必须增加序号范围，因为每个传输的分组（不算重传的）必须有一个唯一的序号，而且也许有多个在传输中未确认的分组。
2. 协议的发送方和接收方也许必须缓存多个分组。发送方最低限度应当能缓冲那些已发送但没有确认的分组。
3. 所需序号范围和对缓冲的要求取决于数据传输协议处理丢失、损坏及过度延时分组的方式。解决流水线的差错恢复有两种基本方法：回退N步（Go-Back-N)和选择重传(selective repeat)

1、什么叫做将两个端系统间IP的交付服务扩展为运行在两个端系统上的进程之间的交付服务？
2】rdt传送的是什么？
3】rdt2.1和rdt2.2的区别