运输层（一）

运输层 | 为运行在不同主机上的应用进程提供了逻辑通信功能

运输层服务

运输层协议在端系统中实现（不是路由器），

• 发送端：将从发送应用程序进程接收到的报文转换成运输层分组（报文段，segment），实现方法是将报文划分成较小的块，为每个块加上一个运输层首部以生成运输层报文段
• 接收端：网络层从数据报中提取运输层报文段，并向上交给运输层

运输层和网络层间区别：

网络层是主机间通信，运输层是主机进程间通信

类比案例：

运输层协议能够提供的服务受制于底层网络层协议的服务模型

因特网运输层

网络协议IP为主机间提供逻辑通信，服务模型是尽力而为交付服务（best-effort delivery service），不确保报文段的顺序交付和完整性。因此被称为不可靠服务

TCP（传输控制协议）：可靠的、面向连接

UDP（用户数据报协议）：不可靠的、无连接

多路复用（multiplexing）和多路分解（de~）

多路复用：在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息从而生成报文段

多路分解：将运输层报文段中的数据交付到正确的套接字

多路复用：

主机接收IP数据报，每个数据报携带一个传输层的报文段；主机使用IP+port传送报文段到正确套接字

port：16bits，0-65535（0-1023：周知well-known；1024-49151：registered；49152-65535：dynamic or private）

无连接的

UDP套接字：二元组（目的IP，目的端口号）

面向连接的

TCP套接字：四元组（源IP地址，源端口号，目的IP地址，目的端口号）

现在P4、P5、P6都合并为一个进程，每新建一个连接就创建一个新的线程

UDP(User Datagram Protocol)

无连接的：发送报文段前，发送方和接收方的运输层实体之间没有握手

应用：

• 流媒体应用程序
• DNS：避免了TCP的连接创建时延
• SNMP（Simple Network Management Protocol）
• RIP（Routing Information Protocol）

为什么用UDP

• 没有拥塞控制：如果用TCP，信息传输链路如果拥堵会继续重新发送直到得到接收方收到确认，不管可靠交付多长时间；而UDP不用这样，可以满足实时应用的特点
• 无需建立连接：TCP传输数据前还需要经过三次握手，UDP不需任何准备即可开始传输数据，减少了延迟
• 无连接状态：UDP不维护连接状态，支持更多的活跃用户
• 分组首部开销少：TCP 20 bytes，UDP 8 bytes

UDP报文段结构

UDP检验和（checksum）

检验UDP报文段传输过程中其中的比特是否发生改变

发送方：对所有16比特字的和进行反码运算→循环进位累加（最高位溢出右移与最低位相加）再求反码，得到的结果放入UDP检验和字段中

接收方：全部的16比特字进行相加（包括检验和），如果和=1111111111111111，可能无错误；否则出错

eg：

为什么使用检验和

• 不能保证源和目的之间的所有链路都提供差错检测
• 报文段存储时可能引入比特差错
• 差错检测作为一种保险措施（提供检测，但是对差错无能为力：丢弃受损报文段 或 交给应用程序并给出警告）

可靠数据传输原理

考虑单向数据传输，FSM：finite state machines有限状态机

rdt1.0：经完全可靠信道的可靠数据传输

底层信道完全可靠：没有比特差错、没有分组损失，接收端不需要提供反馈信息给发送方

rdt2.0：经具有比特差错信道的可靠数据传输

底层信道发生比特错误，仍假设分组会按顺序接收，检验和来检查比特错误

此时需要自动重传请求协议（ARQ，Automatic Repeat reQuest）：有误的内容重传

• 差错检测
• 接收方反馈：ACK（acknowledgement）、NAK（negative acknowledgement），若收到接收方返回的NAK，发送方重传
• 重传

在等待ACK、NAK时，不能发送新的数据分组：停等协议（stop-and-wait），如图红线所示

发送出错

rdt2.0存在致命性缺陷：ACK、NAK有可能损坏

方案：正确收到ACK则发新数据，正确收到NAK或者无法确认收到的ACK、NAK则重发老数据

如果在发送方收到不清楚的ACK或NAK时，这种方法在发送方到接收方的信道中引入了冗余分组（duplicate packet），困难在于接收方不知道发送方是否正确收到上次所发的ACK或NAK

解决：在数据分组中添加新字段，让发送方对数据分组编号

rdt2.1

sender：

receiver：

rdt2.2

无NAK可靠数据传输协议，此时两次接收到相同的ACK相当于最后一次没有接收到正确分组（NAK）

当发送方收到接收方反馈的ACK中出现冗余情况（即接收方并未收到预期编号的正确数据包，isACK()），发送方认为刚才发送的数据存在错误，则重发该数据。

sender：

receiver：

rdt3.0：经有比特差错的丢包信道的可靠数据传输

假定除了比特受损外，底层信道还会丢包，需要关注怎么检测丢包以及发生丢包后该做什么

方案：发送方传输一个数据分组，该分组或接收方对该分组的ACK发生了丢失，此时发送方都收不到接收方的响应，如果发送方愿意等待足够长时间以便确定分组已丢失，只需重传数据分组即可

为了实现基于时间的重传机制，需要一个倒计时定时器（countdown timer）

比特交替协议 alternating-bit

流水线可靠数据传输协议

rdt3.0仍是一个停等协议，发送利用率很低

方案：不以停等方式运行，允许发送方发送多个分组而无需等待确认→流水线（pipelining）技术

（停等发送）

（流水线发送）

流水线技术的影响

• 必须增加序号范围（每个输送中的分组【不重传的】必须有一个唯一的序号）
• 协议的发送方和接收方都需要缓存多个分组（发送方最低限度应当能够缓冲那些已发送但没有确认的分组）

GBN：回退N步

Go-back-N：

• 发送方发送多个分组而不需等待确认，流水线中可存在N个未被确认的数据包
• 接收方需发送累计确认（cumulative ack）：如果出现间断就不发ack
• 发送方为最早未被确认数据包维护一个定时器

发送方

N被称为窗口长度（window size），GBN协议也被称为滑动窗口协议（sliding-window protocol），存在限制是为了进行流量限制

NOTE：TCP序号是按字节流中的字节进行计数的，不是按分组计数

扩展的FSM

发送方：

• 上层的调用（invocation from above）：发送方首先查看窗口是否已满

  • 不满：创建分组并发送
  • 已满：只需将数据返回给上层
• 收到ACK：累计确认，必须正确接收序号
• 超时事件：超时则重传所有未被确认的分组

接收方：

• 丢弃所有失序分组，只需维护下一个按序节后的分组的序号

eg：

SR：选择重传

GBN一个问题是需要重传大量分组，如果窗口长度和带宽时延很大

Selective repeat：

• 发送方只需重传没有收到ACK的分组（使用计时器限时）
• 也使用和GBN相同的窗口限制未完成、未被确认的分组
• 接收方确认一个正确接收的分组而不管其是否按序（缓存失序的分组）

发送方：

• 从上层收到数据：同GBN
• 超时
• 收到ACK：若分组序号在窗口内，则发送方标记为已接收；若分组序号等于send_base，则窗口序号前移到具有最小序号的未确认分组处，窗口移动后有序号落在窗口内且未发送，则发送这些分组

接收方：

• 序号在[rcvbase, rcvbase+N-1]被正确接收：发送ACK回发送方；若该分组以前没收到过，缓存该分组；若该分组序号等于接收窗口的基序号，则该分组以及以前缓存的序号连续的分组交付给上层。然后接收窗口向前移动分组的编号向上交付这些分组
• 序号在[rcvbase-N, rcvbase-1]被正确接收：必须产生一个ACK，即使该分组是接收方以前已确认过的分组
• 其他：忽略

eg：

小结：

发展顺序：

检验和：rdt2.0

确认（ACK）：rdt2.0

否认确认：rdt2.0

序号：rdt2.1

定时器：rdt3.0

窗口、流水线：rdt3.0+