计算机网络-自顶向下方法与Internet特色笔记之三(上)

第三章 传输层

3.1 传输层服务和规范

      在协议栈中，传输层位于网络层之上，传输层协议为不同主机上运行的进程提供逻辑通信，而网络层为

不同主机提供逻辑通信。

      因特网应用层可以使用两种不同的传输层协议。

      一种是DUP协议，它为调用进程提供一种不可靠的、无连接的服务。

      一种是TCP协议，它未调用进程提供一种可靠地、面向连接的服务。

      当设计一个网络进程时，应用程序开发者必须在创建套接字的时候指定这两种协议中的一种。

      网络层协议，即IP协议，提供主机之间的逻辑通信。IP服务模型是一个尽力传送服务，这就意味着IP协

议尽它最大的努力在通信主机之间传送数据段，但是却不提供任何保证。特别是，它不能保证数据段传输的

安全性，不能保证数据段的传送顺序，不能保证数据段传输的数据完整性。基于这些原因，IP被称为不可靠

服务。

3.2 应用程序的多路复用和多路分解

      在目的主机上，传输层直接从网络层接收数据段。

      传输层的职责是将这些数据段中的数据传送给该主机上运行的相应的进程。

      每一个传输层的数据段都有一个特定的字段，用于标识这些数据段的数据是发送到哪个进程的。

      将传输层数据段中的数据分送到正确的应用进程的工作称为多路分解。

      从源主机的不同应用进程中收集数据，并将数据添加上头部信息封装起来，构成数据段，并将这些数据

段传递给网络层的工作称为多路复用。

      UDP和TCP通过在数据段的头部信息中加入两个特定的字段--源端口号和目的端口号字段，来完成多路

分解和多路复用的工作。

      端口号是一个16比特的数，范围从0--65535。

      从0到1023的端口号被称为通用端口号，其使用时有限制的。

      当我们开发一个新的应用进程，我们必须给该应用进程分配一个端口号。

      当一个目标主机从网络接收数据，三元组(源IP地址，源端口号，目的端口号)可以用来将数据分配给相应

的进程。

3.3 无连接服务UDP

      UDP协议除了多路复用/多路分解和极少的错误检测外，它没有砸IP之上加入任何东西。事实上，如果应用

程序开发者选择UDP而不是TCP，那么这个应用程序几乎就是直接和IP层进行对话。

      UDP直接从应用进程得到消息，为了多路复用/多路分解服务将源端口号和目的端口号加上，再加入两个小

的字段--长度和校验和，最后把得到的数据传递给网络层。

      如果使用UDP，那么在传送数据之前，发送方和接收方不需要进行握手，正式由于这个原因，UDP被称为

无连接的。

UDP和TCP的比较：

      1、UDP 是无连接的。TCP在开始传送数据前，会经过一个三次握手的过程。UDP在执行任务之前，不进行

任何准备活动，这样，在建立连接的时候，DUP不会带人任何延迟。

      2、TCP在终端系统之间一直保持连接，这个连接状态是指接收和发送缓冲区、拥塞控制参数以及顺序和确认

号码参数。UDP不保持连接状态，也不跟踪这些参数。由于这个原因，当应用进程运行于UDP而不是TCP上时，

一个用来执行某个应用程序的服务器可以支持更多的处于活动状态的客户。

      3、TCP 的每一个数据段中有20个字节的头部信息，UDP只有8个字节的头部信息。

      4、UDP不用对发送速率进行管理。当连接变得拥挤时，TCP会使用其拥塞机制来对发送进行限制。

      5、TCP 不能用于多点传送。UDP可以用于多点传送。

      使用UDP为应用程序提供可靠的数据传输服务是可能的。这可以通过将可靠性机制建立在应用程序

上来做到。例如，在应用层程序中加入确认和重传机制，当前很多程序都做到了这点--它们运行在UDP

上，但它们将确认和重传机制建立在应用程序之上，以减少数据包的丢失。

UDP数据报结构：

长度以字节为单位，包括UDP数据报的头部。

3.4 可靠数据传输的原理

      TCP是在不可靠的IP层传输协议上实现的可靠的数据传输协议。

      在一个计算机网络上，可靠数据传输协议是建立在自动重复请求(Automatic Repeat Request, ARQ）协议

基础上的。

      在ARQ协议中，基本上需要三种额外的协议功能来处理比特错误的出现：

      1、错误检测--校验和

      2、接收方反馈--由于发送方和接收方通常运行于不同的终端系统上，那么发送方得知接收方接收情况(一个分组        

是否正确到达)的唯一方法就是让接收方提供给发送方明确的反馈。消息叙述场景中的肯定确认ACK和否定确认NAK

就是这些反馈的例子。

      3、重传--发送方会重新传输一个分组到接收方。

      发送方在它的分组中加入了一个存放分组顺序的字段。接收方只要检查这个顺序号就可以知道接收到的分组是否

是发送方重传的数据。

      现在的协议必须额外关系两件事情：怎样检测分组的丢失以及发生丢失事件时如何补救。计算校验和、顺序编号、

ACK分组和重发机制可以解决第二个问题，但是要处理第一个问题还需要加入一个新的机制。

      假设发送方发送了一个分组，它或者是要发送的数据，或者接收方对分组的确认，但是这个分组丢失了。在这

两种情况下，发送方都不会等待到接收方的应答。在实际应用中，要解决这个问题，就要使发送方选择一个适当长

度的时间作为上限来判断分组是否丢失。如果在这个时间范围内还没有收到ACK,该分组就会被重发。需要注意的是，

如果一个分组的传送经历了一个特别长的延迟的时间，那么尽管该分组和它的ACK都没有丢失，发送方也会将分组

重发。

      从发送方的角度看，重发可以解决一切问题。发送方无法知道是分组丢失了，还是ACK丢失了，或者是分组和

ACK的传输经历了过长的延迟时间。在所有这些情况下，发送方采取的动作都是一样的--重发。为了实现一个基于

重发的机制，这里引入了一个倒计数计时器，来实现在经历过一定时间后对发送方的提醒功能。发送方需要：

      1、在每传送一个分组之后将计时器重置

      2、当计时器到达一定时间后采取相应，进行相应的操作

      3、停止计时器

      由于发送方产生的重复分组和数据或ACK分组的丢失现象的存在，使得发送方对所接收到的ACK的处理变得

复杂。当接收到一个ACK时，发送方如何知道它是与最近发送的分组相对性，还是是一个延迟到达的与以前发送

的分组相对应的呢？在ACK中加入确认字段就可以解决这个问题。当接收方产生一个ACK时，它将把被确认的分

组的顺序号拷贝到自己的确认字段中。发送方通过检查确认字段的内容，就可以知道被确认的分组的顺序号了。

      数据传输协议的关键元素：校验和、顺序号、计时器和肯定/否定确认分组(ACK/NAK)。

      为了提高可靠数据传输协议的效率，采用流水线可靠数据传输协议：运行发送方在没有接收到确认之前，可以

发送多个分组。

      流水线技术队可靠数据传输协议会产生如下几个影响：

      1、顺序号的上限必须增加。因为每一个发送了(而不是重发)的分组都必须有唯一的顺序号，而且可能同时存在

多个已经发送了但还没有得到确认的分组。

      2、协议的发送方和接收方必须能缓存多个分组。至少，发送方必须能缓存它已经发送了但还没有收到确认的

分组。接收方同时也需缓存已经正确接收到的分组。

      所需要的顺序号的上限和对缓冲区的要求取决于数据传输协议对分组丢失、损坏和超长延时作出相应的方式。

这里，可以确定两个能恢复流水线中的错误的基本方法：第N个分组重发和选择性重复。

第N个分组重发：

      在第N个分组重发(Go-Back-N,GBN)协议中，发送方允许发送多个分组而不用等待确认，但是个数不能超过流水

线中可以有的未确认的分组的顺序号的上限。

 

      如上图，base为最早发送的未收到确认的分组，nextseqnum为最小的未使用的顺序号，也就是要发送的下

一个分组的顺序号。如图，顺序号可以被分为四个部分：在【0，base-1】范围内的顺序号对应于已经发送并且

已经收到确认的分组；【base，nextseqnum-1】范围内的顺序号对应于已经发送但是还没有收到确认的分组；

【nextseqnum，base+N-1】范围内的顺序号对应于从上层到达的、马上就可以发送的分组；大于base+N-1

范围内的顺序号对应的分组必须等到流水线中的分组得到确认之后才能发送。

      如图所示，允许发送但还未收到确认的分组构成了一个大小为N的窗口。正如协议中所做的操作，该窗口沿着

顺序号空间内滑动。由于这个原因，N通常指窗口的大小，GBN协议也被称为滑动窗口协议。

      实际上，分组的顺序号是装载在分组头部中的一个固定的字段内的。因为字段标识的顺序号大小是有限的，

所以有关它的计算必须使用取余的数学运算。

      GNB发送方必须对3件事作出响应：

      1、上层调用  当上层调用发送函数时，发送方首先检测窗口是否已经满了，也就是检测是否已经存在N个还

未确认的分组。

      2、在我们的GBN协议中，顺序号为n的分组的确认被认为是累积确认。它意味着所有顺序号小于n的分组都

已经为接收方正确接收。

      3、超时事件   如果发生了超时事件，发送方将重发那些已经发送但还未收到确认的分组。

      GBN的接收方的动作也很简单。如果顺序号为n的分组被正确地并且按顺序地接收了，接收方发送一个编号为

n的ACK并且将该分组中的数据上传到上层。在所有其他情况下，接收方会将该分组忽略掉，并且重发一个最后一次

按顺序正确到达的分组的ACK。注意，由于分组是一个一个被送到上层的，如果分组k被接收并上传，那么表示所有

顺序号小于k的分组也被接收并上传了。这样，GBN自然会选择累积确认方式。

      接收方必须将数据按顺序上传给上层。假设现在正在等待分组n，但是到来的确实分组n+1，由于数据必须按

顺序上传，那么接收方就可以先将分组n+1放到缓冲区，等到分组n到来并上传之后，在执行分组n+1的上传。但是，

如果分组n丢失了，按照GBN发送方的重传规则，最终分组n和分组n+1都将被重新发送。这样的话，接收方就

可以简单的忽略掉分组n+1而不用将它放到缓冲区了。

选择性重复协议SR：

      我们知道流水线技术有第N个分组重复GBN协议和选择性修复SR协议。

      选择性重复SR协议通过采用让发送方猜测接收方错误接收(丢失或损坏)的分组并重发这些分组的工作方式，来

避免不必要的重发工作。

      SR的接收方不管接收到的分组是否是有序的，只要是正确的，就都将给出确认。无序的分组在中间缺少的分组

被接收之前，都被送入缓冲区存放。当这些缺省的分组到来之后，这些分组将成批次按顺序传送给上层。

      1、从上层接收数据。从上层接收数据后，SR发送方检查下一个可用的分组顺序号。如果顺序号在发送方窗口

内，数据将被打包发送；否则，就将数据存入缓冲区或者送还给上层以便以后发送。就如GBN中所做的那样。

      2、超时。计时器在此用来防止分组的丢失。当然，每个分组必须哟逻辑计时器，因为每个分组都将在超时后

单独重发。一个硬件计时器可以用来模拟多个逻辑计时器的操作。

      3、接收到ACK。如果接收到了一个ACK，那么SR发送方就砸该分组上做标记，表明其确认已经接收到了，前提

条件就是它在窗口之内。如果该分组的顺序号等于send-base,那么窗口的下限将向前移动到具有最小顺序号的、未经

确认的分组上。如果窗口移动了并且有未经发送的分组进入窗口，那么这些分组便被发送。

      1、顺序号在【rcv_base,rev_base+N-1】范围内的分组被正确的接收了。在这种情况下，接收到的分组在

接收方串口中落下，并且一个选择性的ACK分组被返回给发送方。如果该分组不是上一次被接收的，它将被送

如缓冲区。如果该分组的序号等于接收方窗口的下限rcv_base,那么该分组和以前放入缓冲区的具有连续顺序号

的分组一起被送入上层。接收方窗口向前移动。移动的格数与发送给上层的分组的个数相等。

      2、顺序号在【rcv_base-N,rev_base-1】区间内的分组被接收了。在这种情况下，尽管是接收以前的曾经

确认过的分组，还是要给它产生一个ACK。

      3、否则，就将该分组忽略。

 

      TCP协议时GBN协议和SR协议的混合体。