第三章运输层

Boumbo

已于 2022-06-28 22:38:07 修改

阅读量208

点赞数

分类专栏：计算机网络（自顶向下）文章标签： tcp/ip

于 2022-06-06 17:11:56 首次发布

本文链接：https://blog.csdn.net/Boumbo/article/details/125150579

版权

计算机网络（自顶向下）专栏收录该内容

4 篇文章 2 订阅

订阅专栏

正在更新中！

运输层位于应用层和网络层之间，是分层的网络体系结构中的重要部分
第一个关键功能：将网络层的在两个端系统之间的交付服务扩展到运行在两个不同端系统上应用层进程之间的交付服务
第二个关键功能：拥塞控制

3.1 概述和运输层服务

运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信（logic communication）
从应用程序的角度看，逻辑通信使得运行不同进程的主机好像直接相连一样（实际上两主机可能位于地球两侧）
应用进程使用运输层提供的逻辑通信功能彼此发送报文，无需考虑承载这些报文的物理基础设施，如图3-1所示

运输层协议是在端系统中而不是在路由器中实现的
发送端，运输层将从发送应用程序进程接收到的报文转换成运输层分组（运输层报文段（segment）），实现方法是将报文划分为较小的块，并为每个块加上一个运输层首部以生成运输层报文段，然后将这些报文段传递给网络层，网络层将其封装为网络层分组，并向目的地发送
接收端，网络层从数据报中提取运输层报文段，上交给运输层，运输层处理报文段后为接收方应用程序使用
因特网有两种运输层协议：TCP和UDP

3.1.1 运输层和网络层的关系

网络册提供了主机之间的逻辑通信，运输层位于网络层之上，提供了不同主机上的进程之间的逻辑通信
运输层协议只工作在端系统中
运输层协议将来自应用进程的报文移动到网络册，反过来也一样，但是对于这些报文在网络核心如何移动并不作任何规定
如图3-1所示，中间路由器既不处理也不识别运输层加在应用层报文的任何信息
运输协议能够提供的服务常常受制于底层网络层协议的服务模型
虽然底层网络协议不能提供相应的服务，运输层协议可以提供如可靠传输、安全传输等功能

3.1.2 因特网运输层概述

UDP（用户数据报协议）：为应用程序提供一种不可靠、无连接的服务
TCP（传输控制协议）：为应用程序提供一种可靠的、面向连接的服务
当设计一个网络应用程序时，该应用程序的开发人员必须指定二者之一作为应用程序的运输协议
约定：将运输层分组称为报文段（segment）
介绍一些因特网的网络层：
- 因特网网络层协议有一个名字叫IP,即网际协议
- IP为主机之间提供了逻辑通信
- IP的服务模型是尽力而为交付服务（best-effort delivery service），虽然尽最大努力，但是不做任何保证（不确保报文段的交付、不保证报文段按序交付、不保证报文段数据的完整性，因此IP被称为不可靠服务（unreliable service）
- 每个主机至少有一个IP地址
UDP和TCP提供的最基本的服务（责任）：将两个端系统间IP的交付服务扩展到运行在端系统上的两个进程之间的交付服务
将主机间交付扩展到进程间交付称为运输层的多路复用（transport-layer multiplexing）与多路分解（demultiplexing）
UDP和TCP还可以通过在其报文段首部中包括差错检查字段而提供完整性检查（进程到进程的数据交付和差错检查是两种最低限度的运输层服务，也是UDP提供的仅有的两种服务）
TCP为应用程序提供了几种附加服务：
- 可靠数据传输（reliable data transfer）：使用流量控制、序号、确认和定时器，TCP可以确保正确地、按序地将数据从发送进程交付给接收进程
- 拥塞控制（congestion control）：不严谨的说法：TCP拥塞控制防止任何一条TCP连接用过多流量来淹没通信主机之间的链路和交换设备。TCP力求为每个通过一条拥塞网络链路的连接平等地共享网络链路带宽

3.2 多路复用与多路分解

考虑如下情景：
假定你正坐在计算机前下载Web页面，同时还在运行一个FTP会话和两个Telnet会话。这样你就有4个网络应用进程在运行，即两个Telnet进程，一个FTP进程和一个HTTP进程。当你的计算机中的运输层从底层的网络层接收数据时，它需要将所接收到的数据定向到这4 个进程中的一个。
How？

套接字（socket） 作为进程从网络接受数据和向网络传递数据的门户，使得运输层实际上并没有直接将数据交付给进程，而是将数据交给了一个中间的套接字，如图3-2所示
由于接收主机不止一个套接字，因此每个套接字都有唯一的标识符，标识符格式取决于UDP还是TCP套接字
每个运输层报文段中具有几个字段，用于运输层定向到对应套接字。在接收端，运输层检查这些字段，标识出接收套接字，进而将报文段定向到该套接字
多路分解（demultiplexing）：将运输层报文段中的数据交付到正确的套接字的工作
多路复用（multiplexing）：在源主机从不同套接字收集数据块，并为每个数据块封装首部信息（用于以后分解）从而生成报文段，然后将报文段传递到网络层
运输层多路复用要求：
- 1. 套接字有唯一标识符
- 1. 每个报文段有特殊字段指示该报文所要交付到的套接字
如图3-3所示，这些特殊字段为源端口号字段（source port number field）和目的端口号字段（destination port number field）
端口号为一个16比特的数，大小为0～65535。0～1023位周知端口号（well-known port number）

1.无连接的多路复用与多路分解

假定在主机A中的一个进程具有UDP端口19157，它要发送一个应用程序数据块给位于主机B中的另一进程，该进程具有UDP端口 46428

主机A中的运输层创建一个运输层报文段，其中包括应用程序数据、源端口号(19157)、目的端口号(46428)
然后，运输层将得到的报文段传递到网络层。
网络层将该报文段封装到一个IP数据报中，并尽力而为地将报文段交付给接收主机
如果该报文段到达接收主机B,接收主机运输层就检查该报文段中的目的端口号(46428)并将该报文段交付给端口号46428所标识的套接字

注意：一个UDP套接字是由一个二元组全面标识的，该二元组包含一个目的1P地址和一个目的端口号。因此，如果两个UDP报文段有不同的源IP地址和/或源端口号，但具有相同的目的IP地址和目的端口号，那么这两个报文段将通过相同的目的套接字被定向到相同的目的进程

2.面向连接的多路复用与多路分解

TCP套接字是由一个四元组(源 IP地址，源端口号，目的IP地址，目的端口号）来标识的
当一个TCP报文段从网络到达一台主机时，该主机使用全部4 个值来将报文段定向(分解)到相应的套接字
两个具有不同源IP地址或源端口号的到达TCP报文段将被定向到两个不同的套接字
重新考虑2.7.2节TCP客户-服务器编程的例子：
- TCP服务器上的欢迎套接字在12000号端口等待来自TCP客户的连接建立请求
- TCP客户创建一个套接字并发送一个建立请求报文段
- 一条连接建立请求报文段包含目的IP地址，目的端口号 （不是欢迎端口号），源IP地址，源端口号
- 当服务器操作系统接收到目的端口为12000的入连接请求报文段后，定位正在12000端口号上等待接受连接的进程，同时创建一个新的套接字
- 新创建的连接套接字通过客户请求报文段中的源端口号，源主机IP地址，目的端口号 （不是欢迎端口号），自身的IP地址标识。所有后续到达的报文段中的四个值与新创建套接字的四个标识值匹配，则被分解到这个套接字。TCP连接完成，客户和服务器就可以相互发送数据了
服务器主机可以支持很多并行的TCP套接字，每个套接字与一个进程相联系，并由其四元组来标识每个套接字
当一个TCP报文段到达主机时，所有4个字段(源IP地址,源端口，目的IP地址，目的端口)被用来将报文段定向(分解)到相应的套接字。

3.Web服务器与TCP

考虑一台在80号端口运行Web服务器
客户向该服务器发送报文段时，所有报文段的目的端口都将为80
初始连接建立报文段和承载HTTP请求的报文段都有80的目的端口
该服务器能够根据源IP地址和源端口号来区分来自不同客户的报文段
如图3-5所示，服务器为每条连接生成一个新进程，每个这样的进程都有自己的连接套接字，通过这些套接字可以收到HTTP请求和发送HTTP响应
需要注意的是，连接套接字与进程之间并非总是有着一一对应的关系
当今的高性能Web服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程（线程可以看作是一个轻量级的子进程）
对于这样一台服务器，在任意给定的时间内都可能有(具有不同标识的)许多连接套接字连接到相同的进程
如果客户与服务器使用持续HTTP,则在整条连接持续期间，客户与服务器之间经由同一个服务器套接字交换HTTP报文
如果客户与服务器使用非持续HTTP，则对每一对请求/响应都创建一个新的TCP连接并在随后关闭，因此对每一对请求/响应创建一个新的套接字并在随后关闭
这种套接字的频繁创建和关闭会严重地影响一个繁忙的Web服务器的性能

3.3 无连接运输：UDP

运输层最低限度必须提供一种复用/分解服务，以便在网络层与正确的应用级进程之间传递数据。
UDP只是做了运输协议能够做的最少工作，除了复用/分解功能及少量的差错检测外，它几乎没有对IP增加别的东西
UDP从应用进程得到数据，附加上用于多路复用/分解服务的源和目的端口号字段，以及两个其他的小字段，然后将形成的报文段交给网络层
网络层将该运输层报文段封装到一个IP数据报中，然后尽力而为地尝试将此报文段交付给接收主机
该报文段到达接收主机，UDP使用目的端口号将报文段中的数据交付给正确的应用进程
使用UDP时，在发送报文段之前，发送方和接收方的运输层实体之间没有握手，因此称其为无连接的
为什么使用UDP，或者为什么有些情景下使用UDP而非TCP
- 实时应用通常要求最小的发送速率，不希望过分地延迟报文段的传送，且能容忍一些数据丢失，TCP服务模型并不是特别适合这些应用的需要
- 无须连接建立：TCP在开始数据传输之前要经过三次握手，UDP却不需要任何准备即可进行数据传输。因此UDP不会引入建立连接的时延。
- 无连接状态：TCP需要在端系统中维护连接状态。此连接状态包括接收和发送缓存、拥塞控制参数以及序号与确认号的参数。UDP不维护连接状态，也不跟踪这些参数
- 分组首部开销小：每个TCP报文段都有20字节的首部开销，而UDP仅有8字节的开销
使用UDP的应用是可能实现可靠数据传输的。这可通过在应用程序自身中建立可靠性机制来完成(例如，可通过增加确认与重传机制来实现）

3.3.1 UDP报文段结构

UDP报文段结构如图3-7所示
UDP首部只有4 个字段，每个字段由两个字节组成
- 通过端口号可以使目的主机将应用数据交给运行在目的端系统中的相应进程（执行分解功能）
- 长度字段指示在UDP报文段中的字节数（首部加数据）
- 接收方使用检验和来检查在该报文段中是否出现了差错

3.3.2 UDP检验和

UDP检验和提供了差错检测功能，检验和用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了改变
发送方的UDP对报文段中的所有16比特字的和进行反码¹运算，求和时遇到的任何溢出都被回卷²。得到的结果被放在UDP报文段中的检验和字段
举个例子：
假定有如下3个16比特的字：
前两个之和为：
前两个之和与第三个相加之和为：
注意到最后一次加法有溢出，它要被回卷
执行反码运算，得到最终结果：101101010011110，即检验和为101101010011110
在接收方，全部的4个16比特字(包括检验和)加在一起。如果该分组中没有引入差错，则显然在接收方处该和将是1111111111111111，若结果中某一个或者某一些比特是0，则分组中出现了差错
如果端到端数据传输服务要提供差错检测，UDP就必须在端到端基础上在运输层提供差错检测（称为端到端原则（end-end principle））

端到端原则：与在较高级别提供这些功能的代价相比，在较低级别上设置的功能可能是冗余的或几乎没有价值的

虽然UDP提供差错检测，但它对差错恢复无能为力
UDP的某种实现只是丢弃受损的报文段
其他实现是将受损的报文段交给应用程序并给出警告

3.4 可靠数据传输原理

图3-8为学习可靠数据传输的框架
为上层实体提供可靠传输服务可以抽象为一条可靠的信道进行传输
借助可靠信道，传输数据比特就不会受到损坏或丢失，而且所有数据都是按照其发送顺序进行交付
可靠数据传输协议（reliable data transfer protocol）是实现这种服务的依靠
贯穿我们讨论始终的一个假设是分组将以它们发送的次序进行交付，某些分组可能会丢失，也就是说底层信道将不会对分组重排序
因为本节研讨的理论适用于一般的计算机网络，而不只是用于因特网运输层，因此我们将使用术语分组而不用运输层的报文段

3.4.1 构造可靠数据传输协议

我们一步步研究一系列协议，最后得到一个完美的可靠的数据传输协议

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

首先考虑最简单的情况：底层信道是完全可靠的。称此协议为rdt1.0
图3-9为rdt1.0发送方和接收方的有限状态机（Finite-State Machine，FSM）
图3-9a定义了发送方的操作，图3-9b定义了接收方的操作
发送方和接收方有各自的FSM，且发送方和接收方的FSM每个都只有一个状态
FSM描述图中箭头表示协议从一个状态变迁到另一个状态
引发变迁的事件显示在表示变迁的横线上方，事件发生时所采取的动作显示在横线下方
若某事件无动作或没有就某事件采取动作，在横线上方或下方使用符号ʌ分别表示缺少动作或事件
FSM初始状态用虚线表示
rdt发送端
- 事件：由较高层应用的过程调用rdt_send(data)，接收来自较高层的数据
- 动作：产生一个包含该数据的分组(经由make_pkt (data)动作)，并将分组发送到信道中
rdt接收端
- 事件：较低层协议调用rdt_rcv( packet)事件，从底层信道接收一个分组
- 动作：从分组中取岀数据(经由extract(packet, data) 动作)，并将数据上传给较高层(通过deliver_data(data)动作)
有了完全可靠的信道，接收端就不需要提供任何反馈信息给发送方，因为不必担心出现差错
假定接收方接收数据的速率能够与发送方发送数据的速率一样快。因此，接收方没有必要请求发送方慢一点

2. 经具有比特差错信道的可靠数据传输：rdt2.0

在实际情况中，底层信道在分组的传输、传播或缓存的过程中，分组中的比特可能受损

假定所有发送的分组(虽然有些比特可能受损)将按其发送的顺序被接收
肯定确认（positive acknowledgement）：报文接收者接收到一个正确完整的分组后会向发送方发送“ok”
否定确认（negative acknowledgement）：报文接收者接收到错误或不完整的分组后向发送方发送“重发一遍”
这样的控制报文使得接收方可以让发送方知道哪些内容被正确接收了，哪些内容出现了错误需要重新发送
自动重传请求（Automatic Repeat reQuest）协议：网络中，基于上述重传机制的可靠数据传输协议
ARQ协议需要另外三种协议功能来处理存在比特差错的情况：
- 差错检测：需要一种机制，以使接收方检测到何时出现了比特差错，这样的技术可以使接收方检测并可能纠正分组中的比特差错。这样的技术要求有额外的比特，从发送方发送到接收方。这些比特将被汇集在rdt2.0数据分组的分组检验和字段中
- 接收方反馈：发送方和接收方在不同的端系统上，发送方要了解接收方情况，只能通过接收方的反馈。rdt2.0协议将从接收方向发送方回送ACK（肯定确认）与NAK（否定确认）分组
- 重传：接收方收到了有差错分组时，发送方需要重新发送该分组
如图3-10为rdt2.0的FSM，该协议采用了差错检验、肯定确认与否定确认