目录
7.12.1 Remote Procedure Calls（远程程序调用）
7.12.2 RTP – Streaming and VOIP（流媒体和网络电话）
7.8 运输层和网络层的关系
在协议栈中，运输层刚好位于网络层之上。
网络层提供了主机之间的逻辑通信。
运输层为运行在不同主机上的进程之间提供了逻辑通信。
这种差别虽然细微但很重要。我们用一个家庭类比来帮助分析这种差别。
有两个家庭，位于两个，每家有12个孩子。两个家庭的孩子互相写信。每一个家庭有个孩子（A和B）负责收发邮件，并将这些信件交到每天到家门口来的邮政服务的邮车上。当信件到达另一个家庭时，A和B也负责将信件分发到她的兄弟姐妹手上。
邮政服务为两个家庭间提供逻辑通信。
A和B为堂兄弟姐妹之间提供了逻辑通信。从堂兄弟姐妹们的角度来看，A和B就是邮件服务，尽管他们只是端到端交付过程的一部分（即端系统部分）。
在解释运输层和网络层之间的关系时，这个家庭的例子是一个非常好的类比：
应用层报文
信封上的字符
进程
主机（又称为端系统）
运输层协议
网络层协议
运输层协议只工作在端系统中：
在端系统中，运输层协议将来自应用进程的报文移动到网络边缘（即网络层）。
运输层协议不涉及报文在网络核心移动的规定。
中间路由器既不处理也不识别运输层加在应用层报文的任何信息。
计算机网络中可以安排多种运输层协议，每种协议为应用程序提供不同的服务模型。
运输协议能够提供的服务常常受制于底层网络层协议的服务模型。
如果网络层协议无法为主机之间发送的运输层报文段提供时延或带宽保证的话，运输层协议也就无法为进程之间发送的应用程序报文提供时延或带宽保证。
即使底层网络协议不能在网络层提供相应的服务，运输层协议也能提供某些服务。例如：
- 即使底层网络协议是不可靠的，也就是说网络层协议会使分组丢失、篡改和冗余，运输协议也能为应用程序提供可靠的数据传输服务。
- 即使网络层不能保证运输层报文段的机密性，运输协议也能使用加密来确保应用程序报文不被入侵者读取。
传输层寻址：
- 在应用层和传输层都需要对要连接的远程进程进行规范。
- 传输层的寻址通常使用端口号（如端口80）。
- 完整的地址是一个5元组（源IP地址，源端口，目标IP地址，目标端口，协议）。
7.9 因特网运输层概述
因特网为应用层提供了两种截然不同的可用运输层协议：
UDP（用户数据报协议）：它为调用它的应用程序提供了一种不可靠、无连接的服务。
TCP（传输控制协议）：它为调用它的应用程序提供了一种可靠的、面向连接的服务。
我们将运输层分组称为报文段（segment）。
因特网网络层协议有一个名字叫IP，即网际协议。IP为主机之间提供了逻辑通信。
IP 的服务模型是尽力而为交付服务（best-effort delivery service）：
- 它不确保报文段的交付；
- 不保证报文段的按序交付；
- 不保证报文段中数据的完整性。
由于这些原因，IP 被称为不可靠服务（unreliable service）。每台主机至少有一个网络层地址，即所谓的IP地址。
我们总结一下UDP和TCP所提供的服务模型：
UDP和TCP最基本的责任是：
将两个端系统间IP的交付服务扩展为运行在端系统上的两个进程之间的交付服务。
将主机间交付扩展到进程间交付被称为运输层的多路复用（transport-layer multiplexing）与多路分解（demultiplexing）。
提供完整性检查：
UDP和TCP还可以通过在其报文段首部中包括差错检查字段而提供完整性检查。
两种最低限度的运输层服务：
进程到进程的数据交付和差错检查是两种最低限度的运输层服务，也是UDP所能提供的仅有的两种服务。
TCP为应用程序提供了几种附加服务。首先，它提供可靠数据传输（reliabledata transfer）。 通过使用流量控制、序号、确认和定时器，TCP确保正确地、按序地将数据从发送进程交付给接收进程。这样，TCP就将两个端系统间的不可靠IP服务转换成了一种进程间的可靠数据传输服务。
TCP还提供拥塞控制（conges-tion control）。拥塞控制与其说是一种提供给调用它的应用程序的服务，不如说是一种提供给整个因特网的服务，这是一种带来通用好处的服务。
7.10 多路复用与多路分解
多路复用与多路分解服务是所有计算机网络都需要的。
假定你正坐在计算机前下载Web页面，同时还在运行一个FTP会话和两个Telnet会话。这样你就有4个网络应用进程在运行，即两个Telnet进程，一个FTP进程和一个HTTP进程。当你的计算机中的运输层从底层的网络层接收数据时，它需要将所接收到的数据定向到这4个进程中的一个。现在我们来研究这是怎样完成的。
一个进程（作为网络应用的一部分）有一个或多个套接字（socket），它相当于从网络向进程传递数据和从进程向网络传递数据的门户。因此，如下图所示，在接收主机中的运输层实际上并没有直接将数据交付给进程，而是将数据交给了一个中间的套接字。由于在任一时刻，在接收主机上可能有不止一个套接字，所以每个套接字都有唯一的标识符。 标识符的格式取决于它是UDP还是TCP套接字，我们将很快对它们进行讨论。
接收主机怎样将一个到达的运输层报文段定向到适当的套接字？
为此目的，每个运输层报文段中具有几个字段。在接收端，运输层检查这些字段，标识出接收套接字，进而将报文段定向到该套接字。
多路分解（demultiplexing）：
将运输层报文段中的数据交付到正确的套接字的工作称为多路分解。
多路复用（multiplexing）：
在源主机从不同套接字中收集数据块，并为每个数据块封装上首部信息（这将在以后用于分解）从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用。
当B从邮递员处收到一批信件，并通过查看收信人名字而将信件亲手交付给他的兄弟姐妹们时，他执行的就是一个分解操作。当A从兄弟姐妹们那里收集信件并将它们交给邮递员时，她执行的就是一个多路复用操作。
运输层多路复用与多路分解在主机中是怎样工作的？
运输层多路复用要求：
- 套接字有唯一标识符;
- 每个报文段有特殊字段来指示该报文段所要交付到的套接字。
如图所示，这些特殊字段是源端口号字段（source port number field）和目的端口号字段（ destination port number feld）。
端口号是一个16比特的数，其大小在0 ~ 65535之间。0 ~ 1023范围的端口号称为周知端口号（ well-known portnumber），是受限制的，这是指它们保留给诸如HTTP（它使用端口号80）和FTP （它使用端口号21）之类的周知应用层协议来使用。当我们开发一个新的应用程序时( 如在2.7节中开发的一个应用程序)，必须为其分配一个端口号。
7.11 无连接运输：UDP
假如设计一个不提供不必要服务的最简化的运输层协议，你也许会首先考虑使用一个无所事事的运输层协议。但是运输层有最低限度的服务：必须提供一种复用/分解服务，以便在网络层与正确的应用级进程之间传递数据。
- 由[RFC768]定义的UDP只是做了运输协议能够做的最少工作。除了复用/分解功能及少量的差错检测外，它几乎没有对IP增加别的东西，使用UDP的应用程序差不多就是直接与IP打交道。
- UDP从应用进程得到数据，附加上用于多路复用/分解服务的源和目的端口号字段，以及两个其他的小字段，然后将形成的报文段交给网络层。
- 网络层将该运输层报文段封装到一个IP数据报中，然后尽力而为地尝试将此报文段交付给接收主机。
- 如果该报文段到达接收主机，UDP使用目的端口号将报文段中的数据交付给正确的应用进程。
- 使用UDP时，在发送报文段之前，发送方和接收方的运输层实体之间没有握手。正因为如此，UDP被称为是无连接的。
使用UDP的应用层协议的例子——DNS
- 当一台主机中的DNS应用程序想要进行一次查询时，它构造了一个DNS查询报文并将其交给UDP。
- 无须执行任何与运行在目的端系统中的UDP实体之间的握手，主机端的UDP为此报文添加首部字段，然后将形成的报文段交给网络层。
- 网络层将此UDP报文段封装进一个IP数据报中，然后将其发送给一个名字服务器。在查询主机中的DNS应用程序则等待对该查询的响应。
- 如果它没有收到响应（可能是由于底层网络丢失了查询或响应），则要么试图向另一个名字服务器发送该查询，要么通知调用的应用程序它不能获得响应。
为什么应用开发人员宁愿在UDP之上构建应用，而不选择在TCP上构建应用？既然TCP提供了可靠数据传输服务，而UDP不能提供，那么TCP是否总是首选的呢？答案是否定的，因为有许多应用更适合用UDP，原因主要以下几点：
关于何时、发送什么数据的应用层控制更为精细。采用UDP时，只要应用进程将数据传递给UDP，UDP就会将此数据打包进UDP报文段并立即将其传递给网络层。在另一方面，TCP有一个拥塞控制机制，以便当源和目的主机间的一条或多条链路变得极度拥塞时来遏制运输层TCP发送方。TCP仍将继续重新发送数据报文段直到目的主机收到此报文并加以确认，而不管可靠交付需要用多长时间。因为实时应用通常要求最小的发送速率，不希望过分地延迟报文段的传送，且能容忍一些数据丢失，TCP服务模型并不是特别适合这些应用的需要。如后面所讨论的，这些应用可以使用UDP，并作为应用的一部分来实现所需的、超出UDP的不提供不必要的报文段交付服务之外的额外功能。
无需连接建立。如我们后面所讨论的，TCP在开始数据传输之前要经过三次握手。UDP却不需要任何准备即可进行数据传输。因此UDP不会引入建立连接的时延。这可能是DNS运行在UDP之上而不是运行在TCP之上的主要原因（如果运行在TCP上，则DNS会慢得多）。HTTP使用TCP而不是UDP，因为对于具有文本数据的Web网页来说，可靠性是至关重要的。HTTP中的TCP连接建立时延对于与下载Web文档相关的时延来说是一个重要因素。
无连接状态。TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数以及序号与确认号的参数。要实现TCP的可靠数据传输服务并提供拥塞控制，这些状态信息是必要的。在另一方面，UDP不维护连接状态，也不跟踪这些参数。因此，某些专门用于某种特定应用的服务器当应用程序运行在UDP之上而不是运行在TCP上时，一般都能支持更多的活跃客户。
分组首部开销小。每个TCP报文段都有20字节的首部开销，而UDP仅有8字节的开销。
下图列出了流行的因特网应用及其所使用的运输协议：
如我们所期望的那样，电子邮件、远程终端访问、Web 及文件传输都运行在TCP之上。因为所有这些应用都需要TCP的可靠数据传输服务。无论如何，有很多重要的应用是运行在UDP上而不是TCP上。UDP被用于RIP路由选择表的更新。因为这些更新被周期性地发送（通常每5分钟一次），更新的丟失能被最近的更新所替代，因此丟包、过期的更新是无用的。UDP也用于承载网络管理数据。在这种场合下，UDP要优于TCP，因为网络管理应用程序通常必须在该网络处于重压状态时运行，而正是在这个时候可靠的、拥塞受控的数据传输难以实现。此外，如我们前面所述，DNS运行在UDP之上，从而避免了TCP的连接创建时延。
如上图所示，UDP和TCP现在都用于多媒体应用，如因特网电话、实时视频会议、流式存储音频与视频。我们刚说过，既然所有这些应用都能容忍少量的分组丢失，因此可靠数据传输对于这些应用的成功并不是至关重要的。此外，TCP的拥塞控制会导致如因特网电话、视频会议之类的实时应用性能变得很差。由于这些原因，多媒体应用开发人员通常将这些应用运行在UDP之上而不是TCP之上。
然而，TCP被越来越多地应用于流式多媒体传输中。约75%的按需和实况流式多媒体使用了TCP。当分组丢包率低时，并且为了安全原因，某些机构阻塞UDP流量，对于流式媒体传输来说，TCP变得越来越有吸引力了。
虽然目前通常这样做，但在UDP之上运行多媒体应用是有争议的。如我们前面所述，UDP没有拥塞控制。但是，需要拥塞控制来预防网络进入一种拥塞状态，此时只能做很少的有用工作。如果每个人都启动流式高比特率视频而不使用任何拥塞控制的话，就会使路由器中有大量的分组溢出，以至于几乎没有UDP分组能成功地通过源到目的的路径传输。况且，由无控制的UDP发送方引入的高丢包率将引起TCP发送方（ 如我们将看到的那样，TCP遇到拥塞将减小它们的发送速率）大大地减小它们的速率。因此，UDP中缺乏拥塞控制能够导致UDP发送方和接收方之间的高丢包率，并挤垮了TCP会话，这是一个潜在的严重问题。很多研究人员已提出了一些新机制，以促使所有的数据源（包括UDP源）执行自适应的拥塞控制。
注意，使用UDP的应用是可以实现可靠数据传输的。这可通过在应用程序自身中建立可靠性机制来完成（例如，可通过增加确认与重传机制来实现）。但这并不是无足轻重的任务，它会使应用开发人员长时间地忙于调试。无论如何，将可靠性直接构建于应用程序中可以使其“左右逢源”。也就是说应用进程可以进行可靠通信，而无需受制于由TCP拥塞控制机制而无需受制于传输速率限制。
7.11.1 UDP报文段结构
UDP报文段结构如图所示：
数据字段：
应用层数据占用UDP报文段的数据字段。例如，对于DNS应用，数据字段要么包含一个查询报文，要么包含一个响应报文。对于流式音频应用，音频抽样数据填充到数据字段。
UDP首部只有4个字段，每个字段由两个字节组成。
端口号：
通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程（即执行分解功能）。
长度字段：
长度字段指示了在UDP报文段中的字节数（首部加数据）。因为数据字段的长度在一个UDP段中不同于在另一个段中，故需要一个明确的长度。
检验和：
接收方使用检验和来检查在该报文段中是否出现了差错。实际上，计算检验和时，除了UDP报文段以外还包括了IP首部的一些字段。
7.12 UDP的应用
7.12.1 Remote Procedure Calls（远程程序调用）
RPC 远程程序调用：
- 允许在远程服务器上调用程序，就像它们在客户机上一样。
- 对程序员隐藏了网络方面的问题。
RPC并不是一个单一的协议/API。存在几十个变体。
它是如何抽象地工作的：
- 机器A上的客户进程调用机器B上的程序。
- A机器上的进程被暂停，而程序的执行在B机器上进行。
- 机器B将结果回复给机器A，然后继续处理。
为了隐藏网络，客户端和服务器必须被绑定到各自的存根（stubs）上：
- 客户端存根在客户端地址空间中运行。
- 服务器存根在服务器地址空间中运行。
从客户端和服务器进程的角度看，所有的调用都是本地的
参数可以被传递和返回：
- 装载（Marshalling）——将内存中的数据结构转换为可以存储或传输的形式。
- 卸载（Unmarshalling）——将存储或传输的数据转换为内存中的数据结构。
概念上很简单，但存在许多挑战：
- 不能轻易传递指针，客户端和服务器处于不同的地址空间中。有可能在每个地址空间中集合和取消集合基础值并创建一个指针，对复杂的数据结构不起作用。
- 像C这样的弱类型语言会带来问题，例如，未知的数组大小。
- 无法推断参数类型。
- 全局变量不能共享。
UDP可以是RPC的一个好选择，但是需要一些额外的脚手架：
- 如果没有收到回复，在超时后重新发送，这里回复就构成对请求的确认。
- 处理需要跨多个 UDP 段拆分的大参数大小
但是如果操作是非幂等的，必须谨慎使用UDP。例如，增加银行余额，而TCP可用于非幂等交换的操作。
7.12.2 RTP – Streaming and VOIP（流媒体和网络电话）
实时传输协议（Real-Time Transport Protocol，RTP）。
RTP是在哪一层？
- 在用户空间运行，使用来自传输层的UDP -> 应用层
- 为应用程序提供服务的通用协议 -> 传输层
- (都不是表现层！)
RTP将几个流复用为单一的UDP段流。
UDP示例使用——实时协议在协议栈中的位置：
RTP Header
- 有效载荷类型：使用的编码（MP3等）——每次都可能不同。
- 序列号：在每个数据包上增加的计数器。
- 时间戳：相对于流的开始，源控制的时间戳 。
7.12.3 实时传输控制协议（RTCP）
RTP的控制协议
- 处理反馈、同步和用户界面
对源的反馈
- 延迟、抖动、带宽、拥堵
- 编码器用于自适应编码以适应网络条件
- 在组播设置中，反馈被限制在媒体带宽的小百分比内
同步化
- 不同的流使用不同的时钟/有不同的漂移。
用户界面
- 命名来源以显示谁在进行电话会议
(另一个网络模型：控制平面是一个与数据平面堆栈平行的堆栈）。
RTP再现：
- 抖动——数据包延迟的变化
- 在接收器处有缓冲器来对付它
- 数据包8到达的太晚，可以等待或跳过，这取决于应用。
- 缓冲区的大小也与应用有关（VOIP=小缓冲区）
258
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
