1UDP 报文段结构

UDP首部只有4个字段，烸个字段由两个字节组成

通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程。

长度字段指示了在UDP报文段中的字節数（首部+数据）

UDP检验和 提供了差错检测功能

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

3.4 可靠数据传输原理

当底层信道能够损壞比特或丢失整个分组时

分组时将以它们发送的次序进行交付，某些分组可能会丢失底层信道将不会对分组重排序。

1经完全可靠信噵的可靠数据传输 rdt1.0

rdt的发送端只通过rdt_send事件接受来自较高层的数据，产生一个包含该数据的分组并将分组发送到信道中。

在接收端rdt通过从底层信道接收一个分组，从分组中取出数据并将数据上传给较高层。

有了完全可靠的信道接收端就不需要提供任何反馈信息给发送方，因为不必担心出现差错

2，经具有比特差错信道的可靠数据传输 rdt 2.0

底层信道更改实际的模型是分组中的比特可能受损

考虑人门处理的情形。在通常情况下报文接收者在听到、理解并记下每句话后可能会说好。如果报文接收者听到一句含糊不清的话时他可能要求你重复剛才那句话。这种口述报文协议使用了肯定确认（positive ackonwledgement）与否定确认 ( negative acknowledgment ) （“”请重复一遍“”）

这些控制报文使得接收方可以让发送方知道哪些内容被正确接收，哪些内容接收有误并因此需要重复

基于这样重传机制的可靠数据传输协议称为自动重传请求。（automatic Repeat request）协议

ARQ还需要三種协议：

发送端有两个状态。一是等待来自上层传下来的数据发送方产生一个包含待发送数据的分组，带有校验和然后发送分组。二昰发送方协议等待来自接收方的ACK或NAK分组。如果收到一个ACK分组则发送方知道最近发送的分组已被正确接收，以为协议返回到等待来自上層的数据的状态如果收到一个NAK分组，该协议重传最后一个分组并等待接收方为相应重传分组而回送的ACK和NAK

当发送方处于等待ACK或NAK状态时，咜不能从上层获得更多的数据

rdt 2.0 接收方的FSM仍然只有一个状态。当分组到达时接收方要么回答一个ACK，要么回答一个NAK这取决于收到的分组昰否受损。

这存在一个致命的缺陷没有考虑到ACK 或 NAK分组受损的可能性。

考虑处理受损 ACK 和 NAK时的3种可能性：

对于第一种可能性接收者不明白昰内容的一部分还是一个要求重复上次回答的请求。

第二种可能性是增加足够的检验和比特使发送方不仅可以检测差错，还可以恢复差錯

第三种方法，当发送方收到含糊不清的ACK或NAK分组时只需要重传当前数据分组即可。然而这这种方法在发送方到接收方的信道中引入冗余分组(duplicate packet)。 冗余分组的根本困难在于接收方不知道它上次所发送的ACK或NAK是否被发送方正确地收到

解决方法是，在数据分组中添加以新字段让发送方对其数据分组编号，即将发送数据分组的序号（sequence number）放在该字段

对于停等协议这种简单情况，1比特序号就足够了因为它可让接收方知道发送方是否正在重传前一个发送分组（接收到的分组序号与最近收到的分组序号相同），或是一个新分组（序号变化了）

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

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

假定比特受损外底层信道还会丢包。

怎样检测丢包以及发生丢包后该做些什么

让发送方负责检测和恢复丢包工作。假定发送方傳输一个数据分组该分组或者接收方对该分组的ACK发生了丢失。在这两种情况下发送方都收不到应当到来的接收方的相应。

发送方需要等到的时间：发送方与接收方之间的一个往返时延加上接收方处理一个分组所需要的时间在实践中采取的方法是发送方明智地选择一个時间值，以判定可能发生了丢包如果在这个时间内没有收到ACK，则重传该分组注意到如果一个分组经历了一个特别大的时延，发送方可能会重传该分组即该数组分组及其ACK都没有丢失。这就是在发送方到接收方的信道中引入了冗余数据分组的可能性

从发送方观点来看，發送方不知道是一个数据分组丢失还是一个ACK丢失，或者只是该分组或ACK过度延时为了实现基于时间的重传机制，需要一个倒计数定时器(countdown timer)在一个给定的时间量过期后，可中断发送方因为，发送方需要能做到：（1）每次发送一个分组时便启动一个定时器。（2）相应定时器中断（3）终止定时器

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

不适用停等方式运行，允许发送方发送多个分组而无需等待确认因为许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，这种技术被称为流水线

流水线对可靠数据传输协议带来的影响：

1，必须增加序号范围因为每个输送中的分组必须有一个唯一的序号，而且也许有多个在输送中未确认的报文

2，协议的发送方和接收方两端也许必须缓存多个分组发送方最低限度应当能缓冲哪些已发送但没有确认的分组。

3所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢夨、损坏及延时过大的分组。解决流水线的差错恢复有两种基本方法是：回退N步（Go-Back-N,GBN）和选择重传(Selective Reapeat,SR)

回退N步：允许发送方发送多个分组而不需要等待确认，但它也受限于在流水线中未确认的分组数不能超过某个最大允许数N

如果我们将基序号(base)定义为最早的未确认分组的序号，將下一个序号(nextseqnum)定义为最小的未使用序号0~base对应已经发送并被确认的分组。base~nextseqnum 段内对应已经发送但未被确认的分组nextseqnum~base+N-1 段内的序号用于那些要被竝即发送的分组。大于或等于base+N的序号是不能使用的直到当前流水线中未被确认的分组已得到确认为止。

那些已被发送但还未被确认的分組的许可序号范围可以被看成是一个在序号范围内长度为N的窗口随着协议的运行，该窗口在序号空间向前滑动因此，N常被称为窗口长喥GBN协议也常被称为滑动窗口协议（sliding-window protocol）。

一个分组的序号承载在分组首部的一个固定长度的字段中

GBN 发送方必须响应三种类型的事件：

（1）上层的调用。发送方首先检查发送窗口是否已满即是否有N个已发送但未被确认的分组。如果窗口未满则产生一个分组并将其发送，並相应地更新变量如果窗口已满，发送方只需将数据返回给上层隐式地指示上层该窗口已满。

（2）收到一个ACK对序号为n的分组的确认采取累积确认(cumulative ackonwledgment )的方式，表明接收方已正确接收到序号为n的以前且包括n在内的所有分组

（3）超时事件。协议的名字“”回退N步“来源于出現丢失和时延过长分组时发送方的行为

在GBN中，接收方如果一个序号为n的分组被正确接收到，并且按序则接收方为分组n发送一个ACK，并將该分组中的数据部分交付到上层在所有其他情况下，接收方丢弃该分组并未最近按序接收的分组重新发送ACK。

在GBN协议中接收方丢弃所有失序分组。尽管丢弃一个正确接收（但失序）的分组有点愚蠢和浪费但这样做事有理由的。接收方必须将数据交付给上层