计算机网络_第五章_运输层

目录:


5.1 运输层协议概述

5.1.1 进程间基于网络的通信

  • 第2~4章依次介绍了计算机网络体系结构中的物理层、数据链路层和网络层,它们共同解决了将主机通过异构网络互联起来所面临的问题,实现了主机到主机的通信
  • 然而在计算机网络中实际进行通信的真正实体,是位于通信两端主机中的进程
  • 如何为运行在不同主机上的应用进程提供直接的逻辑通信服务,就是运输层的主要任务。运输层协议又称为端到端协议。

在这里插入图片描述
图解:

网络层实现了主机到主机之间的通信,但是通信其实是主机内部的进程与进程之间的通信,AP1是进程1, AP2是进程2,运输层解决的就是不同主机之间的进程通信问题.

引出下文:在本章的学习中,运输层向应用层实体屏蔽了下面网络核心的细节(例如网络拓扑、所采用的路由选择协议等),它使应用进程看见的就好像是在两个运输层实体之间有一条端到端的逻辑通信信道。
根据应用需求的不同,因特网的运输层为应用层提供了两种不同的运输层协议,即面向连接的TCP和无连接的UDP,这两种协议就是本章要讨论的主要内容。

5.1.2 TCP/IP运输层中两个重要协议

在这里插入图片描述

图解:

应用层有的协议使用可靠传输服务,有的使用不可靠传输服务,到运输层则使用对应的支持可靠传输服务的TCP,不可靠传输服务的UDP.
  • TCP 与UDP协议概述
    在这里插入图片描述

5.1.3 运输层端口号与复用和分用

一.运输层端口号

  • 运行在计算机上的进程是使用进程标识符(Process ldentification,PID)来标识的。
    • 然而,因特网上的计算机并不是使用统一的操作系统,而不同操作系统(Windows、Linux、MacOS)又使用不同格式的进程标识符
    • 为了使运行不同操作系统的计算机的应用进程之间能够基于网络进行通信,就必须使用统一的方法对TCP/IP体系的应用进程进行标识。
  • TCPIP体系结构的运输层使用端口号来标识和区分应用层的不同应用进程。端口号的长度为16比特,取值范围是0~65535

端口号的分类:
在这里插入图片描述
图解:

熟知端口号就是已经分好的,用户拿来就用的

二.发送方的复用和接收方的分用

在这里插入图片描述
图解:

不管用的UDP还是TCP,IP数据报用的都是一样的,根据协议字段值的不同,将他们合在一个IP数据报中传输,这就是复用,分用就是传到了地方,能够把他们分开,再各回各家.

5.2 UDP协议和它与TCP协议的对比

一.数据传输

UDP直接进行数据传输.
TCP先要三报文握手,建立TCP连接,然后基于TCP连接进行数据传输,
再四报文挥手,释放TCP连接.

二.对单播、多播、广播的支持情况

在这里插入图片描述
图解:

TCP三报文握手就好像在主机之间建立了一条可靠信道,所以TCP仅支持点到点的通信

三.对应用报文的处理

在这里插入图片描述

四.数据传输可靠性的支持情况

UDP是无连接的不可靠的(适用于IP电话,视频会议等实时应用)
TCP向上层提供面向连接的可靠传输服务(适用于要求可靠传输的应用,例如文件传输)

五.UDP首部

在这里插入图片描述

图解:

UDP首部比较简单

TCP首部比较复杂,最小20字节,最大60字节,后续会详细讲解

5.3 TCP协议

5.3.1 TCP协议首部格式

跳转到我的博客:TCP首部格式_基本知识


5.3.2 TCP协议"三报文握手"建立连接和"四报文挥手"释放连接

  • TCP是面向连接的协议,它基于运输连接来传送TCP报文段。
    • TCP运输连接的建立和释放,是每一次面向连接的通信中必不可少的过程。
  • TCP运输连接有以下三个阶段:
    • 通过“三报文握手”来建立TCP连接。
    • 基于已建立的TCP连接进行可靠的数据传输。
    • 在数据传输结束后,还要通过“四报文挥手”来释放TCP连接。
一."三报文握手"建立连接
  • “三报文握手”建立TCP连接的目的在于解决以下三个主要问题:
    • 使TCP双方能够确知对方的存在
    • 使TCP双方能够协商一些参数(例如最大报文段长度、最大窗口大小、时间戳选项等)。
    • 使TCP双方能够对运输实体资源进行分配和初始化。运输实体资源包括缓存大小、各状态变量、连接表中的项目等。

在这里插入图片描述

图解:

首先是tcp客户与tcp服务器建立连接,此时tcp服务器是被动的,等待客户主动打开连接

第一步,tcp客户发送报文 SYN=1, seq=x (解释说明:SYN=1,要建立连接,seq是序号,虽然不携带数据,但是消耗序号)
第二步,服务器发送报文给用户,SYN=1 ACK=1 seq=y, ack=x+1(解释说明:SYN=1,要建立连接,ACK=1,ACK取值为1时,确认号字段有效,seq是序号,虽然不携带数据,但是消耗序号,seq的值是任意的,ack确认上一个报文的seq
第三步,客户向服务器发送,ACK=1,seq=x+1,ack=y+1 (ack确认上一个报文的seq,seq加一,是因为第一步消耗了)

注意:

  • TCP规定SYN被设置为1的报文段(例如TCP连接请求报文段和TCP连接请求确认报文段)不能携带数据,但要消耗掉一个序号。

    • 按上述规定,TCP连接请求报文段不能携带数据(即没有数据载荷),但是会消耗掉序号x。
    • 因此,TCP客户进程下一次发送的TCP报文段的数据载荷的第一个字节的序号为x+1。
  • TCP规定普通的TCP确认报文段可以携带数据,但如果不携带数据,则不消耗序号。

    • 如果该报文段不携带数据,则TCP客户进程要发送的下一个数据报文段的序号仍为x+1。
  • 采用“三报文握手”而不是“两报文握手”来建立TCP连接,是为了防止已失效的TCP连接请求报文段突然又传送到了TCP服务器进程,因而导致错误。


二."四报文挥手"释放连接

在这里插入图片描述

图解:

和三报文握手的解析过程类似

注意:

  • 处于时间等待(TIME-WAIT)状态后要经过2MSL时长,可以确保TCP服务器进程能够收到最后一个TCP确认报文段而进入关闭(CLOSED)状态
  • 另外,TCP客户进程在发送完最后一个TCP确认报文段后,再经过2MSL时长,就可以使本次连接持续时间内所产生的的所有报文段都从网络中消失。这样就可以使下一个新的TCP连接中不会出现旧连接中的报文段

保活计时器:作用
在这里插入图片描述


5.3.3 TCP流量控制

为什么要流量控制?
TCP为应用程序提供了流量控制(Flow Control)机制,以解决因发送方发送数据太快而导致接收方来不及接收,造成接收方的接收缓存溢出的问题。

流量控制的基本方法:接收方根据自己的接收能力(接收缓存的可用空间大小)控制发送方的发送速率

具体实现理解如下:
发送方给接收方发送TCP报文,当接收方,收到之后,给发送方发送确认的报文的时候,告知发送方当时的rwnd字段长度,就是接收窗口长度,根据接收窗口大小动态调整.

现在考虑一种特殊的情况,当前的rwnd=0,此时接收方向发送方发送rwnd=300,但是在发送过程中丢失了,此时,A一直等待B发送的非零窗口通知,B一直等待A发送的数据报文段,如果不采取措施,这种互相等待而形成的死锁局面将一直持续下去!

为了打破由于非零窗口通知报文段丢失而引起的双方互相等待的死锁局面,TCP为每一个连接都设有一个持续计时器

  • 只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。
  • 当持续计时器超时时,就发送一个零窗口探测报文段,仅携带1字节的数据。
  • 对方在确认这个零窗口探测报文段时,给出自己现在的接收窗口值。
  • 如果接收窗口值仍然是0,那么收到这个报文段的一方就重新启动持续计时器。
  • 如果接收窗口值不是0,那么死锁的局面就可以被打破了。

实际上TCP规定:即使接收窗口值为0,也必须接受零窗口探测报文段、确认&文段以及携带有紧急数据的报文段。


5.3.4 TCP的拥塞控制

跳转到我的博客:TCP的拥塞控制_基础知识_四种拥塞控制方法


5.3.5 TCP的可靠传输

注意:

注意: ackn,在选择重传协议与TCP协议中并不完全相同。
在选择重传协议中,ackn,表明序号到n为止的数据已正确接收,现在期望收到序号为n+1的数据。在TCP协议中,ackn,表明序号到n-1为止的数据已正确接收,现在期望收到序号为n的数据。

发送窗口的移动:
在这里插入图片描述

  • 发送窗口后沿的移动情况:
    • 不动(没有收到新的确认)
    • 前移→(收到新的确认)
  • 发送窗口前沿的移动情况:
    • 前移→(通常情况)
    • 不动
      • 情况1:没有收到新的确认,接收方通知的窗口大小也没有改变。
      • 情况2:收到了新的确认,但接收方通知的窗口缩小了,使发送窗口的前沿正好不动。
      • 向后收缩(接收方通知的窗口变小了),但是TCP非常不推荐这样做.

应该如何描述发送窗口的状态呢?换句话说,如果要编程实现滑动窗口机制,那么对于发送窗口的状态应该如何标记和维护呢?


使用三个指针P1、P2、P3分别指向相应的字节序号:

  • P1指向发送窗口内已发送但还未收到确认的第一个数据的序号。
  • P2指向发送窗口内还未发送的第一个数据的序号。
  • P3指向发送窗口前沿外的第一个数据的序号。

在这里插入图片描述

这样就可以用P1、P2和P3这三个指针来描述发送窗口的相关信息:

  • 小于P1的就是已发送并已收到确认的部分
  • 大于等于P3的就是不允许发送的部分
  • P3-P1=发送窗口尺寸
  • P2-P1=已发送但还未收到确认的字节数量
  • P3-P2=允许发送但当前还未发送的字节数量(又称为可用窗口或有效窗口)

整个过程的描述:
发送方收到来自接收方的确认后,窗口右滑,已发送且收到确认可以删除.
接收方收到来确认后,窗口右滑,已发送且确认已交付主机,可以删除.
按序接收有没到的,就产生超时重传重新传送.
在这里插入图片描述


5.3.6 TCP超时重传的选择

TCP超时重传时间RTO的选择是TCP最复杂的问题之一
在这里插入图片描述
图解:

RTT 难测量,我们无法知道确认的报文段是跟哪次的数据报文段是匹配,跟中间哪次重传的匹配?

引入加权平均往返时间RTTs:

  • 不能直接使用略大于某次测量得到的往返时间RTT样本的值作为超时重传时间RTO。
  • 但是,可以利用每次测量得到的RTT样本计算加权平均往返时间RTTs,这样可以得到比较平滑的往返时间。

RTTS1= RTT1,(RTTS1),是第一次RTT的值
新的RTTS =(1 - a)×RTTS + a×新的RTT样本
这里的a取推荐值0.125
在这里插入图片描述

解决报文段重传的测量策略
在这里插入图片描述


5.3.7 TCP的选择确认

能否设法只传送缺少的数据而不重传已经正确到达、只是未按序到达的数据呢?
答案是肯定的

解决办法:假如指针指向,指针在扩展首部的选项字段中声明
在这里插入图片描述

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

小徐要考研

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

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

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

打赏作者

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

抵扣说明:

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

余额充值