计算机网络笔记5-运输层

第5章 运输层在这里插入图片描述

主要内容

  1. 介绍运输层协议的特点

  2. 进程之间的通信和端口等重要概念

  3. 讲述比较简单的UDP协议

  4. 讨论较为复杂但非常重要的TCP协议

4.1. 可靠传输的工作原理,包括停止等待协议和ARQ协议.

4.2. 讲述TCP报文段的首部格式

4.3. 讨论TCP的三个重要问题: 滑动窗口,流量控制 和 拥塞控制机制.

4.4. 介绍TCP的连接管理.

运输层 是整个网络体系结构中的关键层次之一

  1. 运输层为相互通信的应用进程提供逻辑通信.

  2. 端口和套接字的意义.

  3. 无连接的UDP的特点.

  4. 面向连接的TCP的特点.

  5. 在不可靠的网络上实现可靠传输的工作原理,停止等待协议和ARQ协议.

  6. TCP的滑动窗口,流量控制,拥塞控制和连接管理.

运输层协议概述

进程之间的通信

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

当网络的边缘部分中的两台主机使用网络的核心部分的功能进行端到端的通信时,只有主机的协议栈才有运输层,而网络核心部分中的路由器在转发分组时都只用到下三层的功能.

通信的真正端点并不是主机而是主机中的进程.

端到端的通信 是应用进程之间的通信.

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

这表明运输层有一个很重要的功能——复用 (multiplexing)和分用 (demultiplexing).

  • 复用: 指在发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然需要加上适当的首部)

  • 分用: 指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程

逻辑通信

运输层提供应用进程间的逻辑通信.

运输层的两个主要协议

TCP/IP运输层的两个主要协议都是互联网的正式标准,即:

  1. 用户数据报协议 UDP(User Datagram Protocol)

  2. 传输控制协议 TCP(Transmission Control Protocol)

TCP和UDP

两个对等运输实体在通信时传送的数据单位叫做运输协议数据单元TPDU(Transport Protocol Data Unit).

但在TCP/IP体系中,则根据所使用的协议是TCP或UDP,分别称之为TCP报文段 (segment)UDP用户数据报.

UDP在传送数据之前不需要先建立连接.

远地主机的运输层在收到UDP报文后,不需要给出任何确认.

虽然UDP不提供可靠交付,但在某些情况下UDP却是一种最有效的工作方式.

TCP则提供面向连接的服务.

在传送数据之前必须先建立连接,数据传送结束后要释放连接.

TCP不提供广播或多播服务.由于TCP要提供可靠的,面向连接的运输服务,因此不可避免地增加了许多的开销,如确认,流量控制,计时器以及连接管理等.

这不仅使协议数据单元的首部增大很多,还要占用许多的处理机资源.

使用UDP和TCP协议的各种应用和应用层协议

应用 应用层协议 运输层协议
名字转换 DNS(域名系统) UDP
文件传送 TFTP(简单文件传送协议) UDP
路由选择协议 RIP(路由信息协议) UDP
IP地址配置 DHCP(动态主机配置协议) UDP
网络管理 SNMP(简单网络管理协议) UDP
远程文件服务器 NFS(网络文件系统) UDP
IP电话 专用协议 UDP
流式多媒体通信 专用协议 UDP
多播 IGMP(网际组管理协议) UDP
电子邮件 SMTP(简单邮件传送协议) TCP
远程终端接入 TELNET(远程终端协议) TCP
万维网 HTTP(超文本传送协议) TCP
文件传送 FTP(文件传送协议) TCP

运输层的端口

应用层所有的应用进程都可以通过运输层再传送到IP层(网络层),这就是复用.

运输层从IP层收到发送给各应用进程的数据后,必须分别交付指明的各应用进程,这就是分用.

虽然通信的终点是应用进程,但只要把所传送的报文交到目的主机的某个合适的目的端口,剩下的工作(即最后交付目的进程)就由TCP或UDP来完成.

UDP和TCP的首部格式中,都有源端口 和目的端口 这两个重要字段.

当运输层收到IP层交上来的运输层报文时,就能够根据其首部中的目的端口号把数据交付应用层的目的应用进程.

TCP/IP的运输层用一个16位端口号 来标志一个端口.

它只是为了标志本计算机 应用层中的各个进程在和运输层交互时的层间接口.

16位的端口号可允许有65535个不同的端口号

这个数目对一个计算机来说是足够用的.

两个计算机中的进程要互相通信,不仅必须知道对方的IP地址(为了找到对方的计算机),而且要知道对方的端口号(为了找到对方计算机中的应用进程).

(1)服务器端使用的端口号 这里又分为两类,最重要的一类叫做熟知端口号 (well-known port number)或系统端口号,数值为0~1023.

IANA把这些端口号指派给了TCP/IP最重要的一些应用程序,让所有的用户都知道.当一种新的应用程序出现后,IANA必须为它指派一个熟知端口,否则互联网上的其他应用进程就无法和它进行通信.

另一类叫做登记端口 号,数值为1024~49151.这类端口号是为没有熟知端口号的应用程序使用的.使用这类端口号必须在IANA按照规定的手续登记,以防止重复.

(2)客户端使用的端口号 数值为49152~65535.由于这类端口号仅在客户进程运行时才动态选择,因此又叫做短暂端口号

(3)这类端口号留给客户进程选择暂时使用.当服务器进程收到客户进程的报文时,就知道了客户进程所使用的端口号,因而可以把数据发送给客户进程.通信结束后,刚才已使用过的客户端口号就不复存在,这个端口号就可以供其他客户进程使用.

用户数据报协议UDP

UDP概述

用户数据报协议UDP只在IP的数据报服务之上增加了很少一点的功能,这就是复用和分用的功能以及差错检测的功能.

UDP的主要特点是:

(1)UDP是无连接的,即发送数据之前不需要建立连接(当然,发送数据结束时也没有连接可释放),因此减少了开销和发送数据之前的时延.

(2)UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表(这里面有许多参数).

(3)UDP是面向报文的.发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层.UDP对应用层交下来的报文,既不合并,也不拆分,而是保留这些报文的边界.这就是说,应用层交给UDP多长的报文,UDP就照样发送,即一次发送一个报文.在接收方的UDP,对IP层交上来的UDP用户数据报,在去除首部后就原封不动地交付上层的应用进程.也就是说,UDP一次交付一个完整的报文.因此,应用程序必须选择合适大小的报文.若报文太长,UDP把它交给IP层后,IP层在传送时可能要进行分片,这会降低IP层的效率.反之,若报文太短,UDP把它交给IP层后,会使IP数据报的首部的相对长度太大,这也降低了IP层的效率.

(4)UDP没有拥塞控制,因此网络出现的拥塞不会使源主机的发送速率降低.这对某些实时应用是很重要的.很多的实时应用(如IP电话,实时视频会议等)要求源主机以恒定的速率发送数据,并且允许在网络发生拥塞时丢失一些数据,但却不允许数据有太大的时延.UDP正好适合这种要求.

(5)UDP支持一对一,一对多,多对一和多对多的交互通信.

(6)UDP的首部开销小,只有8个字节,比TCP的20个字节的首部要短.

虽然某些实时应用需要使用没有拥塞控制的UDP,但当很多的源主机同时都向网络发送高速率的实时视频流时,网络就有可能发生拥塞,结果大家都无法正常接收.因此,不使用拥塞控制功能的UDP有可能会引起网络产生严重的拥塞问题.

还有一些使用UDP的实时应用,需要对UDP的不可靠的传输进行适当的改进,以减少数据的丢失.在这种情况下,应用进程本身可以在不影响应用的实时性的前提下,增加一些提高可靠性的措施,如采用前向纠错或重传已丢失的报文.

UDP的首部格式

用户数据报UDP有两个字段:数据字段和首部字段.首部字段很简单,只有8个字节

由四个字段组成,每个字段的长度都是两个字节.各字段意义如下:

(1)源端口 源端口号.在需要对方回信时选用.不需要时可用全0.

(2)目的端口 目的端口号.这在终点交付报文时必须使用.

(3)长度 UDP用户数据报的长度,其最小值是8(仅有首部).

(4)检验和 检测UDP用户数据报在传输中是否有错.有错就丢弃.

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

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

传输控制协议TCP概述

TCP最主要的特点

  1. TCP是面向连接的运输层协议.应用程序在使用TCP协议之前,必须先建立TCP连接.在传送数据完毕后,必须释放已经建立的TCP连接.

  2. 每一条TCP连接只能有两个端点(endpoint),每一条TCP连接只能是点对点的(一对一).

  3. TCP提供可靠交付 的服务.通过TCP连接传送的数据,无差错,不丢失,不重复,并且按序到达.

  4. TCP提供全双工通信.TCP允许通信双方的应用进程在任何时候都能发送数据.TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双向通信的数据.在发送时,应用程序在把数据传送给TCP的缓存后,就可以做自己的事,而TCP在合适的时候把数据发送出去.在接收时,TCP把收到的数据放入缓存,上层的应用进程在合适的时候读取缓存中的数据.

  5. 面向字节流.TCP中的"流"(stream)指的是流入到进程或从进程流出的字节序列.

面向字节流

虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流.

TCP并不知道所传送的字节流的含义.TCP不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系.

(例如,发送方应用程序交给发送方的TCP共10个数据块,但接收方的TCP可能只用了4个数据块就把收到的字节流交付上层的应用程序).

但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样.

当然,接收方的应用程序必须有能力识别收到的字节流,把它还原成有意义的应用层数据.

TCP连接是一条虚连接(也就是逻辑连接),而不是一条真正的物理连接.

TCP报文段先要传送到IP层,加上IP首部后,再传送到数据链路层.再加上数据链路层的首部和尾部后,才离开主机发送到物理链路.

TCP和UDP在发送报文时所采用的方式完全不同.TCP并不关心应用进程一次把多长的报文发送到TCP的缓存中,而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节(UDP发送的报文长度是应用进程给出的).

如果应用进程传送到TCP缓存的数据块太长,TCP就可以把它划分短一些再传送.

如果应用进程一次只发来一个字节,TCP也可以等待积累有足够多的字节后再构成报文段发送出去.

TCP的连接

TCP把连接 作为最基本的抽象.

TCP的许多特性都与TCP是面向连接的这个基本特性有关.

每一条TCP连接有两个端点.那么,TCP连接的端点是什么呢?不是主机,不是主机的IP地址,不是应用进程,也不是运输层的协议端口.

TCP连接的端点叫做套接字(socket)或插口.

IP地址 + 端口号 即构成了套接字.

套接字的表示方法是在点分十进制的IP地址后面写上端口号,中间用冒号或逗号隔开.

例如,若IP地址是192.3.4.5而端口号是80,那么得到的套接字就是(192.3.4.5:80).

每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定.

即:

IP1 和 IP2 分别是两个端点主机的IP地址,而 port1 和 port2 分别是两个端点主机中的端口号.

TCP连接的两个套接字就是 socket1 和 socket2.

TCP连接的端点是个很抽象的套接字,即(IP地址 : 端口号).

同一个IP地址可以有多个不同的TCP连接,而同一个端口号也可以出现在多个不同的TCP连接中.

socket的多种含义

随着互联网的不断发展以及网络技术的进步,同一个名词socket却可表示多种不同的意思.例如:

  1. 允许应用程序访问连网协议的应用编程接口API (Application Programming Interface),即运输层和应用层之间的一种接口,称为socket API,并简称为socket.

  2. 在socket API中使用的一个函数名 也叫做socket.

  3. 调用socket函数的端点 称为socket,如"创建一个数据报socket.

  4. 调用socket函数时,其返回值 称为socket描述符,可简称为socket.

  5. 在操作系统内核中连网协议的Berkeley实现,称为socket实现.

可靠传输的工作原理

TCP发送的报文段是交给IP层传送的.但IP层只能提供尽最大努力服务,也就是说,TCP下面的网络所提供的是不可靠的传输.因此,TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠.

理想的传输条件有以下两个特点:

  1. 传输信道不产生差错.

  2. 不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据.

在这样的理想传输条件下,不需要采取任何措施就能够实现可靠传输.

然而实际的网络都不具备以上两个理想条件.

但我们可以使用一些可靠传输协议,当出现差错时让发送方重传出现差错的数据,同时在接收方来不及处理收到的数据时,及时告诉发送方适当降低发送数据的速度.

这样一来,本来不可靠的传输信道就能够实现可靠传输了.

停止等待协议

全双工通信的双方既是发送方也是接收方.

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

1.无差错情况

A发送分组M1,发完就暂停发送,等待B的确认.B收到了M1 就向A发送确认.A在收到了对M1 的确认后,就再发送下一个分组M2.同样,在收到B对M2 的确认后,再发送M3.

2.出现差错

可靠传输协议是这样设计的:A只要超过了一段时间仍然没有收到确认,就认为刚才发送的分组丢失了,因而重传前面发送过的分组.这就叫做超时重传.

要实现超时重传,就要在每发送完一个分组时设置一个超时计时器.如果在超时计时器到期之前收到了对方的确认,就撤销已设置的超时计时器.

这里应注意以下三点.

第一,A在发送完一个分组后,必须暂时保留已发送的分组的副本 (在发生超时重传时使用).只有在收到相应的确认后才能清除暂时保留的分组副本.

第二,分组和确认分组都必须进行编号.这样才能明确是哪一个发送出去的分组收到了确认,而哪一个分组还没有收到确认.

第三,超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些.

3.确认丢失和确认迟到

B所发送的对M1 的确认丢失了.A在设定的超时重传时间内没有收到确认,并无法知道是自己发送的分组出错,丢失,或者是B发送的确认丢失了.

因此A在超时计时器到期后就要重传M1.

现在应注意B的动作.假定B又收到了重传的分组M1.这时应采取两个行动.

第一,丢弃这个重复的分组 M1,不向上层交付.

第二,向A发送确认.不能认为已经发送过确认就不再发送,因为A之所以重传M1 就表示A没有收到对M1 的确认.

也是一种可能出现的情况.传输过程中没有出现差错,但B对分组M1 的确认迟到了.A会收到重复的确认.对重复的确认的处理很简单:收下后就丢弃.B仍然会收到重复的M1,并且同样要丢弃重复的M1,并重传确认分组.

通常A最终总是可以收到对所有发出的分组的确认.如果A不断重传分组但总是收不到确认,就说明通信线路太差,不能进行通信.

使用上述的 确认 和 重传机制,我们就可以在不可靠的传输网络上实现可靠的通信.

像上述的这种可靠传输协议常称为 自动重传请求 ARQ(Automatic Repeat reQuest).意思是重传的请求是自动进行的.接收方不需要请求发送方重传某个出错的分组.

信道利用率

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

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

流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认.

这样可使信道上一直有数据不间断地在传送.显然,这种传输方式可以获得很高的信道利用率.

连续ARQ协议

滑动窗口协议比较复杂,是TCP协议的精髓所在.

这里先给出连续ARQ协议最基本的概念,但不涉及许多细节问题.详细的滑动窗口协议将在后面讨论.

表示发送方维持的发送窗口,它的意义是:位于发送窗口内的5个分组都可连续发送出去,而不需要等待对方的确认.这样,信道利用率就提高了.

分组发送是按照分组序号从小到大发送的.

连续ARQ协议规定,发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置.

接收方一般都是采用累积确认 的方式.这就是说,接收方不必对收到的分组逐个发送确认,而是在收到几个分组后,对按序到达的最后一个分组发送确认,这就表示:到这个分组为止的所有分组都已正确收到了.

累积确认有优点也有缺点.优点是:容易实现,即使确认丢失也不必重传.但缺点是不能向发送方反映出接收方已经正确收到的所有分组的信息.

TCP报文段的首部格式

TCP虽然是面向字节流的,但TCP传送的数据单元却是报文段.

一个TCP报文段分为首部和数据两部分,而TCP的全部功能都体现在它首部中各字段的作用.

因此,只有弄清TCP首部各字段的作用才能掌握TCP的工作原理.

TCP报文段首部的前20个字节是固定的,后面有4n 字节是根据需要而增加的选项(n 是整数).因此TCP首部的最小长度是20字节.

TCP的连接释放

数据传输结束后,通信的双方都可释放连接.

现在A和B都处于ESTABLISHED状态

A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接.

A把连接释放报文段首部的终止控制位FIN置1,其序号seq=u,它等于前面已传送过的数据的最后一个字节的序号加1.

这时A进入FIN-WAIT-1(终止等待1)状态,等待B的确认.

请注意,TCP规定,FIN报文段即使不携带数据,它也消耗掉一个序号.

B收到连接释放报文段后即发出确认,确认号是ack=u+1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1.

然后B就进入CLOSE-WAIT(关闭等待)状态.

TCP服务器进程这时应通知高层应用进程,因而从A到B这个方向的连接就释放了,这时的TCP连接处于半关闭 (half-close)状态,即A已经没有数据要发送了,但B若发送数据,A仍要接收.

也就是说,从B到A这个方向的连接并未关闭,这个状态可能会持续一段时间.

A收到来自B的确认后,就进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段.

若B已经没有要向A发送的数据,其应用进程就通知TCP释放连接.

这时B发出的连接释放报文段必须使FIN=1.

现假定B的序号为w(在半关闭状态B可能又发送了一些数据).B还必须重复上次已发送过的确认号ack=u+1.这时B就进入LAST-ACK(最后确认)状态,等待A的确认.

A在收到B的连接释放报文段后,必须对此发出确认.在确认报文段中把ACK置1,确认号ack=w+1,而自己的序号是seq=u+1(根据TCP标准,前面发送过的FIN报文段要消耗一个序号).

然后进入到TIME-WAIT(时间等待)状态.

请注意,现在TCP连接还没有释放掉.必须经过时间等待计时器 (TIME-WAIT timer)设置的时间2MSL后,A才进入到CLOSED状态.

时间MSL叫做最长报文段寿命.

因此,从A进入到TIME-WAIT状态后,要经过4分钟才能进入到CLOSED状态,才能开始建立下一个新的连接.

当A撤销相应的传输控制块TCB后,就结束了这次的TCP连接.

因此,从A进入到TIME-WAIT状态后,要经过4分钟才能进入到CLOSED状态,才能开始建立下一个新的连接.

当A撤销相应的传输控制块TCB后,就结束了这次的TCP连接.

TCP的有限状态机

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

FlyingZCC

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值