1.运输层为运行在不同主机上的应用进程之间提供了逻辑通信(logic communication)。?

2.网络层提供了主机之间的逻辑通信。

3.运输层协议能够提供的服务往往受限于底层网络层协议；运输层能否为进程间应用层报文提供时延或带宽保证，取决于网络层能否为主机间运输层报文提供时延或带宽保证。

4.运输层分组称为"报文段"；网络层为"数据报"

多路复用与分解???

1.多路复用：源主机从不同套接字收集数据块，并为每个数据块封装上首部信息从而生成报文段，将报文段传递到网络层。

2.多路分解：在接收端，运输层检查某几个字段，标识出接收套接字，进而将报文段定向到套接字。?

3.UDP 套接字由一个二元组全面识别(目的 IP 地址，目的端口号)；当两项全部相同，则通过相同的目的套接字被定向到相同的进程；即使源 IP 地址和源端口号都不相同，也会通过相同的套接字。

4.TCP 套接字由一个四元组全面识别(源 IP 地址，源端口号，目的 IP 地址，目的端口号)；当四项全部相同，才通过相同的目的套接字被定向到相同的进程；源 IP 地址或源端口号不相同都会通过不同的套接字(相同进程不同线程)，除非 TCP 携带了初始创建连接的请求。

无连接运输：UDP

描述?

不提供不必要服务的运输层协议，仅提供复用/分解服务(网络层与正确的应用级进程之间传递数据)以及少量的差错检测。?

特点?

1.无连接：不需要三次握手，不会引入建立连接的时延。

2.无连接状态：TCP 连接状态包括接收/发送缓存、拥塞控制参数、序列号、确认号；UDP 不维持连接状态也不追踪这些参数；某些应用程序运行在 UDP 上，支持更多活跃用户。

3.应用层控制数据发送：UDP 收到数据就会打包进 UDP 报文段并立即传递给网络层。

4.不可靠数据传输：不保证报文将到达接收进程，报文可能乱序到达。

5.分组首部开销小：TCP 20 字节，UDP 8 字节。

报文结构?

1.源端口号：2 字节

2.目的端口号：2 字节

3.长度：字节数(首部 + 数据)。2 字节

4.检验和：接收方使用检验和来检查报文段中是否出现差错。2 字节

5.应用数据(报文)：?如 DNS 应用，查询报文或响应报文。

检验和?

步骤

1.将前三个字段相加求和。

2.将和取反码与检验和相加，若结果为：1111111111111111，则没有引入差错。

出现差错处理?

1.对差错无恢复能力。

2.丢弃受损报文段或将受损报文段交给应用程序并给出警告。?

提供检验和原因?

1.不能保证源和目的之间的所有链路都提供差错检测。

2.报文段存储在某台路由器的内存中时，也可能引入比特差错。

3.端到端原则(end-end principle)：某种功能(此时为差错检测)必须基于端到端时间，"与在较高级别提供这些功能的代价相比，在较低级上设置的功能可能是冗余的或几乎没有价值的。"?

可靠数据传输原理

构造可靠数据传输协议?

经完全可靠信道：rdt1.0

1.不会出现差错

2.不会丢失分组?

经具有比特差错的信道：rdt2.0?

? ? 1.差错检测。

? ? 2.接收方反馈：肯定确认 ACK(positiv acknowledge)/否定确认 NAK(negative acknowledge)。

? ? 3.重传：接收方收到有差错的分组时，发送方收到 NAK，将重传该分组。?

如上为自动重传(Automatic Repeat reQuest)协议。

发送方等待 ACK/NAK 时，只有接收到 ACK 并离开该状态，才能继续从上层获取数据；等停(stop-and-wait)协议。?

经具有比特差错的信道：rdt2.1

? ? 1.考虑到 ACK 或者 NAK 分组受损的可能性。

? ? 2.分组中添加一个新字段：分组的序号。

? ? 3.对于等停协议，只需要 1 比特序号(模 2 运算)；接收方与最近的一个分组序号进行比较，来判断是重传分组或是新分组。

rdt2.1：接收方对受损分组发送 NAK，对失序分组发送 ACK。

经具有比特差错的信道：rdt2.2?

?

rdt2.2：无 NAK 的可靠数据传输协议，接收方必须包括由一个 ACK 报文所确认的分组序号；发送方检查 ACK 所确认的分组序号，接下来发送与该序号不同的新分组。

经具有比特差的丢包信道：rdt3.0

1.每次发送一个分组时，便启动一个定时器(包括重传)。

2.超时，响应定时器中断，重传分组。

3.分组被成功接收，终止定时器。

rdt3.0 运作情况?

1.分组丢失与 ACK 丢失都将导致超时，重发分组。

2.定时器设置不合理，可能出现过早超时；会出现冗余分组与冗余 ACK，接收端会检查 ACK 所确认的分组序号，若与最近一次相同(冗余 ACK)，则不予处理。?

3.分组序号在 0 和 1 之间交替，因此 rdt3.0 有时被称为比特交替(alternating-bit)协议。

流水线可靠数据传输协议

定义?

1.停等协议，需要收到对当前分组的 ACK 时，才能发送下一个分组；性能极差。

2.流水线(pipelining)技术，允许连续发送多个分组，无需等待确认；利用率能提升数倍。

回退 N 步

1.回退 N 步(GBN)，滑动窗口协议(sliding-window protocol)。

2.N：窗口长度。

3.base：基序号(最早未确认分组)；该分组得到确认后，窗口向前滑动。

4.nextseqnum：下一个序号(最小未使用序号)；<?base + N。

?

?1.上层调用 rdt_send：发送方先检查窗口是否已满即是否已有 N 个已发送但未被确认的分组；未满时，产生一个分组并将其发送，更新相应的变量。

2.收到一个 ACK：对序号为 n 的分组的确认采取累计确认(cumulative acknowledge)，表明序号为 n 及以前的分组都已被正确接收。

3.超时：发送方将重传已发送但未被确认的分组；即 base 以及往后的分组(回退 N 步)。

4.接收方按序接收：收到序号为 n 的分组，假如最近按序接收的分组为 n - 1，则为分组 n 发送一个 ACK 并交付给上层，设置下一个按序接收的分组为 n + 1；否则，丢弃分组 n，并为最近按序接受的分组重新发送 ACK。

选择重传

1.选择重传(SR)；发送方只重传丢失或受损的分组。

2.每个分组都拥有自己的逻辑计时器，为了超时发生，只发送一个分组。

3.失序分组将被缓存；直到更小的分组都被接收(从 rcv_base 开始连续的)，此时将一批分组上交给上层；接收窗口向前滑动。

4.[rcv_base - N，rcv_base - 1] 内的分组被正确收到，必须产生一个 ACK；因为之前对序号在 [rcv_base - N，rcv_base - 1] 的确认 ACK 可能丢失，此次为重传，接收端收不到确认，则会一直重传并且窗口也无法向前滑动。