运输层
3.1 概述和运输层服务
运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信功能,应用进程使用运输层提供的逻辑通信功能彼此发送报文,而无须考虑承载这些报文的 物理基础设施的细节。
运输层协议是在端系统中而不是在路由器中实现的。在发送端,运输 层将从发送应用程序进程接收到的报文转换成运输层分组(运输层报文段),实现的方法(可能)是将应用报文划分为较小的块,并为每块 加上一个运输层首部以生成运输层报文段,然后在发送端运输层把这些段传递给网络层,网络层把其封装成数据报并向目的地发送。路由器只检查其网络层字段,不检查封装在该数据 报的运输层报文段的字段。在接收端,网络层从数据报中提取运输层报文段,并将该报文 段向上交给运输层。运输层则处理接收到的报文段,使该报文段中的数据为接收应用进程使用。
网络层提供了主机之间的逻辑通信,而运输层为运行在不同主机上的进程之间提供了逻辑通信
运输层基础功能(UDP具有):
- 进程到进程的数据交付
- 差错检查
但UDP并不可靠
运输层额外功能(TCP具有):
- 可靠数据传输: 流量控制、序号、确认和定时器
- 拥塞控制: TCP力求为每个通过一条拥塞网络链路的连接平等地共享网络链路带宽
3.2 多路复用和多路分解
- 多路分解: 将运输层报文段中的数据交付到正确的套接字的工作
- 多路复用: 在源主机从不同套接字中收集数据块,并为每个数据块封装上首部信息(这将在以后用于分解)从而生成报文段,然后将报文段传递到网络层的这些工作
多路复用要求:
- 套接字有唯一标识符;
- 每个报文段有特殊字段来指示该报文段所要交付到的套接字
- 0 ~ 1023范围的端口号称为周知端口号(SSH 22, FTP 21, HTTP 80)
- 开发一个新的应用程序时必须为其分配一个端口号
3.2.1 无连接的多路复用与多路分解
- 主机A中的运输层创建一个运输层报文段,其中包括应用程序数据、源端口号(19157)、目的端口号(46428)和两个其他值
- 运输层将得到的报文段传递到网络层。网络层将该报文段封装到一个IP数据报中,并尽力而为地将报文段交付给接收主机
- 如果该报文段到达接收主机B,接收主机运输层就检查该报文段中的目的端口号(46428)并将该报文段交付给端口号46428所标识的套接字
- 不同套接字如果目的端口相同会被定位到相同进程
3.2.2 向连接的多路复用与多路分解
TCP套接字是由一个四元组(源1P地址, 源端口号,目的IP地址,目的端口号)来标识的。
- TCP服务器应用程序有一个“欢迎套接字”,它在12000号端口上等待来自TCP客
户(见图2-27)的连接建立请求。 - TCP客户使用下面的代码创建一个套接字并发送一个连接建立请求报文段
- 一条连接建立请求只不过是一个目的端口号为12000, TCP首部的特定“连接建立位”置位的TCP报文段(在3.5节进行讨论)。这个报文段也包含一个由客户选
择的源端口号 - 当运行服务器进程的计算机的主机操作系统接收到具有目的端口 12000的入连接请求报文段后,它就定位服务器进程,该进程正在端口号12000等待接受连接。
该服务器进程则创建一个新的套接字 - 该服务器的运输层还注意到连接请求报文段中的下列4个值:①该报文段中的源
端口号;②源主机IP地址;③该报文段中的目的端口号;④自身的IP地址,所有后续到达的报文段,如果它们的源端口号、源主机IP地址、目的端口号和目的IP地址都与这4个值匹配,则被分解到这个套接字。随着TCP连接完成,客户和服务器便可相互发送数据了。
3.2.3 Web服务器与TCP
在web应用中需要注意:
- 连接套接字与进程之间并非总是有着一一对应的关系,对于这样一台服务器,在任意给定的时间内都可能有(具有不同标识的)许多连接套接字连接到相同的进程,每个套接字对应一个线程
- 如果客户与服务器使用持续HTTP,则在整条连接持续期间,客户与服务器之间经由同一个服务器套接字交换HTTP报文;如果客户与服务器使用非持续HTTP,则对
每一对请求/响应都创建一个新的TCP连接并在随后关闭,因此对每一对请求/响应创建一个新的套接字并在随后关闭
3.3 无连接运输:UDP
- 定义: 用户数据协议,使用UDP时,在发送报文段之前,发送方和接收方的运输层实体之间没有握手。正因为如此,UDP被称为是无连接的。
- 例子: DNS
- 为什么使用UDP:
- 适用于报文发送时延短、能忍耐部分数据丢失的应用
- 无需建立连接
- 无连接状态,能支持更多的活跃用户
- 分组首部开销小
4. UDP缺点:
缺乏拥塞控制能够导致UDP发送方和接收方之间的高丢包率
3.3.1 UDP报文段结构
3.3.2 UDP检验和
- 发送方的UDP对报文段中的所有16比特字的和进行反码运算, 求和时遇到的任何溢出都被回卷。
- 在接收方,全部的4个16比特字(包括检验和)加在一起。如果该分组中 没有引入差错,则显然在接收方处该和将是llllllllllllllllo如果这些比特之一是0, 那么我们就知道该分组中已经出现了差错。
- UDP提供差错检测,但它对差错恢复无能为力
3.4 可靠数据传输
3.4.1 构造可靠数据传输协议
3.4.1.1 经完全可靠信道的可靠数据传输:rdt1.0
- rdt的发送端只通过rdt_send(data)事件接受来自较高层的数据,产生一个包含该数据 的分组(经由make_pkt(data)动作),并将分组发送到信道中,rch_send( data)事 件是由较高层应用的过程调用产生的
- 在接收端,rdt通过rdt_rcv( packet)事件从底层信道接收一个分组,从分组中取出数据 (经由extract (packet, data)动作),并将数据上传给较高层,,rdt_rcv( packet)事件是由较低层协议的过程调用产生的(例如,rdt_rcv())
3.4.1.2 经具有比特差错信道的可靠数据传输:rdt2.0
ABQ: 自动重传请求
- 差错检测:集在MO.O数据分组的分组检验和字段中加入额外比特来差错检测
- 接收方反馈: 肯定确认(ACK)1,否定确认(NAK)0
- 重传
如何解决接收方反馈错误: 是在数据分组中添加一新字段,让发送方对其数据分组编号,即将发送数 据分组的序号(sequence number)放在该字段
3.4.1.3 经具有比特差错的丢包信道的可靠数据传输:rdt3.0
3.4.2 流水线可靠数据传输协议
rdt3.0采用停等协议,发送方虽然链路速度快但是吞吐量很小,解决方法是不以停等方式运行,允许发送方发送多个分组而无须等待确认,这种方式被称为流水线
特点:
- 必须增加序号范围
- 协议的发送方和接收方两端也许不得不缓存多个分组
- 所需序号范围和对缓冲的要求取决于数据传输协议如何处理丢失、损坏及延时过
大的分组
3.4.4 回退N步
解决流水线的差错恢复有两种基本方法是: 退N步 (Go- Back- N,
GBN)和选择重传