前面讲过套接字是应用程序进程和运输层协议之间的接口。在发送端的应用程序将报文推进该套接字。在该套接字的另一侧，运输层协议负责使该报文进入接收进程的套接字。

        包括因特网在内的很多网络提供了不止一种运输层协议。当开发一个应用时，必须选择一种可用的运输层协议。如何做出这种选择呢?最可能的方式是，通过研究这些可用的运输层协议所提供的服务、选择一个最能为你的应用需求提供恰当服务的协议。

        一个运输层协议能够为调用它的应用程序提供什么样的服务呢?大体能够从四个方面对应用程序服务要求进行分类:可靠数据传输、吞吐量、定时和安全性。

        

1.可靠数据传输

       分组在计算机网络中可能丢失。例如，分组能够使路由器中的缓存溢出，或者当分组中的某些比特损坏后可能被丢弃。像电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等这样的应用，数据丢失可能会造成灾难性的后果(在后一种情况下，无论对银行或对顾客都是如此!)。因此，为了支持这些应用，必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输(reliable data transfer)。运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。

        当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能不能够到达接收进程。这可能能被容忍丢失的应用(loss-tolerant application)所接受，最值得注意的是多媒体应用，如交谈式音频/视频，它们能够承受一定量的数据丢失。在这些多媒体应用中，丢失的数据引起播放的音频/视频出现小干扰，而不是致命的损伤。

2.吞吐量

        可用吞吐量，在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。因为其他会话将共享沿着该网络路径的带宽，并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动。这些观察导致另一种自然的服务，即运输层协议能够以某种特定的速率提供确保的可用吞吐量。使用这种服务，该应用程序能够请求r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是为至少r比特/秒。这样的确保吞吐量的服务将对许多应用程序有吸引力。例如，如果因特网电话应用程序对语音以32kbps的速率进行编码那么它也必须以这个速率向网络发送数据，并向接收应用程序交付数据。如果运输协议不能提供这种吞吐量，该应用程序或以较低速率进行编码(并且接收足够的吞吐量以维持这种较低的编码速率)，或它可能必须放弃发送，这是因为对于这种因特网电话应用而言，接收所需吞吐量的一半是几乎没有或根本没有用处的。具有吞吐量要求的应用程序被称为带宽敏感的应用(bandwidh-sensitive application)。许多当前的多媒体应用是带宽敏感的，尽管某些多媒体应用程序可能采用自适应编码技术对数字语音或视频以与当前可用带宽相匹配的速率进行编码。

        带宽敏感的应用具有特定的吞吐量要求，而弹性应用(elastic application)能够根据情况或多或少地利用可供使用的吞吐量。电子邮件、文件传输以及Web传送都属于弹性应用。当然，吞吐量是越多越好。

3.定时

        运输层协议也能提供定时保证。如同具有吞吐量保证那样，定时保证能够以多种形式实现。一个保证的例子如:发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。这种服务将对交互式实时应用程序有吸引力，如因特网电话、虚拟环境电话会议和多方游戏，所有这些服务为了有效性而要求数据交付有严格的时间限制。

        对于非实时的应用，较低的时延总比较高的时延好，但对端到端的时延没有严格的约束。

4.安全性

        最后，运输协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。这种服务将在发送和接收进程之间提供机密性，以防该数据以某种方式在这两个进程之间被观察到。运输协议还能提供除了机密性以外的其他安全性服务、包括数据完整性和端点鉴别。