计算机网络——运输层 上

版权声明:原创作品转载需标明作者与地址 https://blog.csdn.net/zjuwxx/article/details/90174480

本章重点:

  1. 运输层为相互通信的应用进程提供逻辑通信
  2. 端口和套接字的意义
  3. 无连接的 UDP的特点
  4. 面向连接的 TCP的特点
  5. 在不可靠的网络上实现可靠传输的工作原理,停止等待协议和 ARQ协议
  6. TCP的滑动窗口、流量控制、拥塞控制和连接管理

目录

一、运输层协议概述

1.1进程之间的通信

1.2运输层的两个主要协议

1.3运输层的端口

二、用户数据报协议 UDP

2.1 UDP概述

2.2 UDP的首部格式

三、可靠传输的工作原理

3.1停止等待协议

3.1.1无差错情况

3.1.2出现差错

3.1.3确认丢失和确认迟到

3.1.4信道利用率

3.2连续 ARQ协议


一、运输层协议概述

1.1进程之间的通信

从通信和信息处理的角度看,运输层向它上面的应用层提供通信服务,它属于面向通信部分的最高层,也是用户功能中的最底层

从运输层的角度看,通信的端点并不是主机而是主机中的进程

真正进行通信的实体是在主机中的进程,是这台主机中的一个进程和另一台主机中的一个进程在交换数据

IP协议虽然能把分组送到目的主机,但是这个分组还停留在主机的网络层而没有交付主机中的应用进程

一个主机中经常有多个应用进程同时分别和另一个主机中的多个应用进程通信

运输层向高层用户屏蔽了下面网络核心的细节,它使应用进程看见的就像是在两个运输层实体之间有一条端到端的逻辑通信信道

当运输层采用面向连接的 TCP协议时,尽管下面的网络是不可靠的,这种逻辑信道仍相当于一条全双工的可靠信道

当运输层采用无连接的 UDP协议时,这种逻辑信道仍是一条不可靠信道

1.2运输层的两个主要协议

用户数据报协议 UDP,传输控制协议 TCP

按照 OSI术语,两个对等运输实体在通信时传送的数据单位叫运输协议数据单元 TPDU;在 TCP/IP体系中根据使用的协议是 TCP或 UDP分别叫做 TCP报文段或 UDP用户数据报

UDP在传送数据之前不需要先建立连接,远地主机的运输层在收到 UDP报文后不需要给出确认

TCP提供面向连接的服务,传送数据之前必须先建立连接,数据传送结束后要释放连接。TCP不提供广播或多播服务

1.3运输层的端口

运输层具有复用和分用的功能

复用:应用层所有的应用进程都可以通过运输层再传送到 IP层

分用:运输层从 IP层收到发送给各应用进程的数据后,必须分别交付知名的各应用进程

为了使发送方识别对方机器上的进程,需要在运输层使用协议端口号。通信的终点是应用进程,把所传送的报文交到目的主机的某个合适的目的端口,剩下的工作(最后交付目的进程)由 TCP或 UDP完成

在协议栈层间的抽象的协议端口是软件端口。硬件端口是不同硬件设备进行交互的接口,软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址

互联网上的计算机通信是采用客户-服务器方式,客户在发起通信请求时,必须先知道对方服务器的 IP地址端口号

  1. 服务器端使用的端口号:分为熟知端口号(数值0~1023)和登记端口号(数值1024~49151)
  2. 客户端使用的端口号:数值49152~65535。仅在客户进程运行时才动态选择,通信结束后,刚才已使用过的客户端口号就不复存在

二、用户数据报协议 UDP

2.1 UDP概述

用户数据报协议 UDP只是在 IP的数据报服务上增加一点功能,即服用、分用和差错检测

特点:尽最大努力交付(不保证可靠传输),面向报文,没有拥塞控制,支持一对一、一对多、多对一、多对多的交互通信,首部开销小

2.2 UDP的首部格式

当运输层从 IP 层收到 UDP 数据报时,就根据首部中的目的端口,把 UDP 数据报通过相应的端口,上交最后的终点——应用进程

如果接收方 UDP发现收到的报文中的目的端口号不正确(不存在对应于该端口号的应用进程)就丢弃该报文,并由网际控制报文协议 ICMP发送“端口不可达”差错报文给发送方

虽然在 UDP之间的通信要用到其端口号,但由于 UDP的通信是无连接的,不需要使用套接字(TCP之间的通信必须要在两个套接字之间建立连接)

IP数据报的检验和只检验 IP数据报的首部,但 UDP的检验和是把首部和数据部分一起都检验

三、可靠传输的工作原理

3.1停止等待协议

“停止等待”是每发送完一个分组就停止发送,等待对方确认。在收到确认后再发送下一个分组

3.1.1无差错情况

A 发送分组 M1,发完就暂停发送,等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送  ACK。A 在收到了对 M1 的确认后,就再发送下一个分组  M2

3.1.2出现差错

B接收 M1时检测出了差错而丢弃 M1,或者 M1在传输过程中丢失,出现这两种情况时 B都不会发送任何信息

解决方法:A只要超过了一段时间仍没有收到确认,就认为刚才发送的分组丢失了,因而重传前面发送过的分组,这就叫超时重传

注意

  • 在发送完一个分组后,必须暂时保留已发送的分组的副本,以备重发
  • 分组和确认分组都必须进行编号
  • 超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些

3.1.3确认丢失和确认迟到

1、确认丢失

B 发送的 M1 确认丢失,那么 A 设定的超时重传时间不能收到确认, A 无法知道自己发送的分组出错、丢失或者 B 发送的确认丢失了。因此 A 超时计时器到期后就要重传 M1

假定 B 收到了重传的分组 M1。这时 B 应采取两个行动

  1. 丢弃这个重复的分组 M1不向上层交付
  2. A 发送确认。不能认为已经发送过确认就不再发送,因为 A 之所以重传 M1 就表示 A 没有收到 M1 确认

2、确认迟到

传输过程中没有出现差错, B 对分组 M1 确认迟到了

A 收到重复的确认。对重复的确认的处理很简单:收下后就丢弃

B 仍然会收到重复 M1并且同样要丢弃重复 M1并重传确认分组

3.1.4信道利用率

停止等待协议的优点是简单,缺点是信道利用率太低

信道利用率:

为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输

3.2连续 ARQ协议

发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置

接收方一般采用累积确认的方式,在收到几个分组后,对按需到达的最后一个分组发送确认

优点:容易实现,即使确认丢失也不必重传

缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息

by   云烟成雨yycy

猜你喜欢

转载自blog.csdn.net/zjuwxx/article/details/90174480