计算机网络—运输层

注:本博客是基于谢希仁的《计算机网络》第七版编写,主要是为了自己考研,准备专业课

本章思维导图:

在这里插入图片描述

1.运输层协议概述

运输层功能:负责向两个主机中进程之间的通信提供通用的数据传输服务

1.进程间的通信

  1. 概述:
    从通信和提供服务的角度看,运输层向它上面的应用层提供通信服务,属于面向通信部分的最高层,用户功能中的最底层

    (只有位于网络边缘部分的主机的协议栈才有运输层,而网络核心部分中的路由器在转发时只用到下三层的功能)

  2. 通信:
    真正进行通信的实体是在主机中的进程,是一台主机中的进程和另一台主机中的进程在交换数据,严格来讲,两台主机进行通信就是两台主机中的应用进程互相通信,即端到端的通信

  3. 运输层的作用范围:
    在这里插入图片描述

  4. 网络层与运输层的区别:网络层为主机之间提供逻辑通信,运输层为应用进程之间提供端到端的逻辑通信

  5. 基于端口的复用和分用功能:

    1. 复用:在发送方不同的应用进程都可以使用同一个运输层协议传送数据
    2. 分用:接收方的运输层在剥去报文的首部后能把这些数据正确交付目的应用进程

两种不同的运输协议

  1. 当运输层采用TCP协议时,尽管下面的网络是不可靠的(只提供尽最大努力服务),但这种逻辑通信信道就相当于一条全双工的可靠信道

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

2.运输层的两个主要协议

两个主要协议:

  1. 用户数据报协议UDP(User Datagram Protocol)
  2. 传输控制协议TCP(Transmission Control Protocol)

两种协议在协议栈中的位置
在这里插入图片描述
UDP:

  1. 在传送数据之前不需要先建立连接,远地主机收到UDP报文后,不需要给出确认,UDP不提供可靠交付,但某些情况却是最有效的工作方式
  2. 运输协议数据单元(两个对等运输实体在通信时传送的数据单元):UDP用户数据报

TCP:

  1. 提供面向连接的服务,在传送数据前先建立连接,数据传送结束后要释放连接;TCP不提供广播或多播服务;TCP提供可靠的、面向连接的运输服务,因此增加了很多开销
  2. 运输协议数据单元:TCP报文段

3.运输层的端口

  1. 作用:把特定主机上运行的进程作为互联网上通信的终点不可行,因为进程的创建和撤销是动态的,因此使用协议端口号作为识别的终点,而不需要知道具体进程

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

两种端口区别:

  1. 硬件端口:不同硬件设备进行交互的接口(物理)
  2. 软件端口:应用层的各种协议进程与运输实体进行层间交互的一种地址,此处的端口都是指软件端口(逻辑)

端口的表示:用16位的端口号来标志一个端口
(端口号只具有本地意义,只标志本计算机应用层中各进程和运输层交互时的层间接口,不同主机的端口号可以相同)

端口号的分类

  1. 服务器端口号:

    1. 熟知端口号:0~1023,这些端口号被指派给TCP/IP最重要的以下应用程序,让所有用户都知道
      在这里插入图片描述
    2. 登记端口号:1024~49151,为没有熟知端口号的应用程序使用
  2. 客户端端口号:49152~65535,仅在客户进程运行时才动态选择,又叫短暂端口号

2. 用户数据报协议UDP

1. UDP概述:
UDP的主要特点:(考点)

  1. UDP是无连接的

  2. UDP使用尽最大努力交付

  3. UDP是面向报文的
    在这里插入图片描述

  4. UDP没有拥塞控制

  5. UDP支持一对一、一对多、多对一和多对多的交互通信

  6. UDP的首部开销小:只有8字节,比TCP的20字节首部短

2.UDP的首部格式:
在这里插入图片描述

  1. 伪首部:只在计算校验和时使用,不参与数据传输
  2. 源端口:源端口号(在需要对方回信时选用,不需要时用全0)
  3. 目的端口:目的端口号(在终点交付报文时必须使用)
  4. 长度:UDP用户数据报的长度,最小值是8(仅有首部)
  5. 校验和:检测整个UDP用户数据报在传输过程中是否有错。有就丢弃

计算UDP校验和:与IP首部检验相似,但UDP的检验和 检验首部和数据部分,而IP只检验首部,如图所示
在这里插入图片描述
上式参考:二进制反码求和过程

3.传输控制协议TCP概述

1. TCP的主要特点:(考点)

  1. TCP是面向连接的运输层协议

  2. TCP提供可靠交付的服务:保证数据无差错、不丢失、不重复、按序到达

  3. TCP只支持点对点通信

  4. TCP提供全双工通信:允许通信双方任何时候都能发送数据

  5. 面向字节流(但传输过程采用报文段形式)
    在这里插入图片描述

             TCP连接是一条虚连接(逻辑连接),并不是真正的物理连接
    

2. TCP的连接:

套接字:套接字socket=(IP地址:端口号)
IP地址拼接上端口号,例如(192.168.1.1:80)

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

TCP连接::={socket1,socket2} = {(IP1:port1),(IP2:port2)}

TCP连接的端点不是进程,而是套接字

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

4.可靠传输的工作原理:

1.停止等待协议: (自动重传请求ARQ)

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

  1. 无差错情况:
    在这里插入图片描述

  2. 出现差错:
    在这里插入图片描述
    A只要超过一段时间没收到确认,就默认发送的分组丢失而重传之前的分组,这就叫做超时重传,需要设置一个超时计时器

    注意:

    1. A发送完一个分组后,必须暂时保留已发送分组的副本,以便需要重发,只有在收到相应确认后才删除

    2. 分组和确认都需要编号,才能明确哪个分组收到确认,哪个没收到

    3. 超时计时器的重传时间应比数据在分组传输的平均往返时间更长一些

  3. 确认丢失和确认迟到:

    确认丢失:
    在这里插入图片描述
    确认迟到:
    在这里插入图片描述

2.连续ARQ协议:(考点)

  1. 发送方维持发送窗口,位于发送窗口内的分组都可以连续发送出去,而不需要等待对方确认,极大的提高信道利用率

  2. 工作原理:
    在这里插入图片描述
    ARQ规定,发送方每收到一个确认,就把发送窗口滑动一个分组位置,接收方采用累积确认方式,在收到几个分组后,对按序到达的最后一个分组发送确认

    优点:容易实现,确认丢失也不必重传(如第5个分组的确认丢失,但发送方正确收到第8个分组的确认,表明前8个分组已正确收到)

    缺点:不能向发送方反映出接收方已经正确收到的所有分组信息(即不能反映出未按序到达的信息)

    ⚠️Go-back-N(回退N):表示需要再退回来重传已发送的N个分组,例发送方发送了前5个分组,而中间的第3个分组丢失,接收方只能对前2个分组发出确认,发送方将要重新发送后面三个分组

5.TCP报文段的首部格式

首部格式:P217—各字段信息
在这里插入图片描述

⚠️最大报文段MSS(Maximum Segment Size):每一个TCP报文段中的数据字段的最大长度,默认值为536B;而数据字段的长度加上TCP首部才等于整个TCP报文段的长度

6.TCP可靠传输的实现

1.以字节为单位的滑动窗口:
在这里插入图片描述
根据B给出的窗口值,A构造自己的发送窗口

  1. 发送窗口表示:在没有收到B的确认时,A可以连续把窗口内的数据都发送出去
  2. 发送窗口中的序号表示允许发送的序号,窗口越大,发送方就可以在收到对方确认前连续发送更多的数据,因此可能获得更高的传输效率
  3. 收到新的确认后发送窗口前沿向前移动,没有收到新的确认或收到新的确认但对方通知的窗口缩小了,会使发送窗口前沿不动
  4. TCP的缓存和窗口的关系:
    在这里插入图片描述
    1. 发送缓存存放:(可发送的最大数据量)
      发送应用程序发送给发送方TCP准备发送的数据

      TCP已发送出但尚未收到确认的数据

    2. 接收方缓存存放:(可接收的最大数据量)
      按序到达的、但尚未被接受应用程序读取的数据

      未按序到达的数据

2. 超时重传时间的选择:(了解)

  1. 加权平均往返时间RTTs:
    新的RTTs=(1-a)(旧的RTTs)+a(新的RTT样本)

  2. 超时重传时间RTO:
    RTO=RTTs+4*RTTd

  3. RTT的偏差的加权平均值RTTd:
    新的RTTd=(1-b)(旧的RTTd)+b|RTTs-新的RTT样本| 其中b=0.25

  4. Karn算法:(了解即可)
    为了解决—如何判定此确认报文段是对先发送的报文段的确认,还是对后来重传的报文段的确认,从而影响RTO的数值

    在计算加权平均RTTs时,只要报文段重传了,就不采用其往返时间样本,这样得出的加权平均RTTs和RTO就较准确

3.选择确认SACK:

工作原理:

  1. 接收方在接受对方发送过来的数据字节流的序号不连续,结构就形成了一些不连续的字节块,如果这些字节的序号都在接受窗口内,接收方就先收下这些数据,但要把这些信息告诉发送方,使发送方不再重复发送这些已收到的数据
    在这里插入图片描述

左边界为闭,右边界为开;左边界指向字节块第一个字节序号,右边界指向字节块最后一个序号+1

7.TCP的流量控制(一对一)

⚠️流量控制是指点对点通信量的控制,是个端到端的问题(接受端控制发送端)

1.利用滑动窗口实现流量控制:

  1. 流量控制:让发送方发送速率不要太快,让接收方来得及接收
  2. 滑动窗口的单位:字节
  3. 滑动窗口流量控制流程:
    开始时rwnd=400,每个报文段长100字节
    在这里插入图片描述
  4. 持续计时器:解决盲等死锁。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器,若计时器到期,就发送一个零窗口探测报文段(一个字节),而对方就在确认这个报文段时给出了现在的窗口值,若窗口值仍是零,那么收到报文的一方就重新设置持续计时器,若不是零,那么死锁就被打破

2.TCP的传输效率: (非重点)

  1. Nagle算法:

    1. 若发送应用进程要把发送的数据逐个字节地送到TCP发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文发送出去,同时继续对后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段
  2. 糊涂窗口综合征:接收缓存每次只能释放出1字节空间,然后把窗口设为1,向发送方发送确认,发送方又发来1字节数据,接收方发回确认,仍将窗口设为1字节,这样会使网络效率降低

    1. 解决方法:让接收方等待一段时间,使得接收缓存有足够空间容纳一个最大的报文段,或等接收缓存中有一半空闲空间。此时再发送确认报文

8.TCP的拥塞控制(一对多,全局控制)

⚠️拥塞控制是防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载,是一个全局性的过程。

1.拥塞控制的一般原理: (了解即可)

  1. 开环控制:就是在设计网络时事先将有关发生拥塞的因素考虑周到,力求网络在工作时不发生拥塞,一旦整个系统运行起来,就不再中途进行修改

  2. 闭环控制:基于反馈回路概念;检测网络系统以便检测到拥塞在何时、何处发生;把拥塞发生的信息传送到可采取行动的地方;调整网络系统的运行以解决出现的问题

2.TCP的拥塞控制方法
拥塞控制算法:

  1. 慢开始
  2. 拥塞避免
  3. 快重传
  4. 快恢复

慢开始和拥塞避免:

  1. 拥塞窗口:大小取决于网络的拥塞程度,并且动态的变化,发送方让自己的发送窗口等于拥塞窗口

    发送窗口=min{拥塞窗口,接受窗口}

  2. 判断拥塞的依据:出现了超时

  3. 发送方控制拥塞窗口的原则:

    只要没有出现拥塞,拥塞窗口就可以再增大一些,以便把更多分组发送出去,提高网络利用率;

    只要发生拥塞,就把拥塞窗口减小一些,以减少注入到网络种的分组数,以缓解网络出现的拥塞

慢开始算法:

  1. 算法思路:由小到大逐渐增大拥塞窗口数值

  2. 初始拥塞窗口:初始拥塞窗口设置为1至2个发送方的最大报文段的数值

  3. 拥塞窗口的控制:在每收到一个对新报文段的确认后,可以把拥塞窗口增加多一个SMSS(发送方最大报文段)的数值,即拥塞窗口cwnd每次的增加量 = min(N,SMSS),N是原先未被确认、现在被刚收到的确认报文确认的字节数

  4. 算法流程:
    在这里插入图片描述
    每经过一个传输轮次,拥塞窗口cwnd就加倍

  5. 传输轮次:一个传输轮次所经历的时间就是往返时间RTT;即发送n个报文段并受到n个报文段确认总共经历的时间

  6. 传输轮次更加强调:把拥塞窗口所允许发送的报文段都连续发送出去,并收到对已发送的最后一个字节的确认

  7. 慢开始:不是指cwnd的增长速度慢,而是在TCP开始发送报文段时先把cwnd设置为1,然后再逐步增大cwnd

  8. 慢开始门限:防止拥塞窗口增长过大引起网络拥塞

  9. 用法:

    1. 当cwnd<ssthresh时,使用慢开始算法

    2. 当cwnd>ssthresh时,停止使用慢开始而改用拥塞避免算法

    3. 当cwnd=ssthresh时,既可用慢开始,也可用拥塞避免

拥塞避免算法:

  1. 算法思路:让拥塞窗口缓慢的增大,每经过一个RTT就把发送方的拥塞窗口+1,而不是像慢开始加倍增长
  2. 拥塞避免特点:加法增大,拥塞窗口按线性规律缓慢增长,比慢开始的拥塞窗口增长速率慢得多
  3. 拥塞避免不能完全避免拥塞,只是控制拥塞窗口按线性规律增长,使网络不易出现拥塞

快重传算法

  1. 特点:可以让发送方尽早知道发生了个别报文段的丢失
  2. 算法思路:要求接收方不等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认
  3. 算法启动:发送方只要一连收到3个重复确认,就立即进行重传(即快重传)
  4. 算法流程:
    在这里插入图片描述

快恢复算法

  1. 发送方只是丢失个别报文,不启动慢开始而用快恢复算法,发送方调整门限值ssthresh=cwnd/2,同时设置拥塞窗口cwnd=ssthresh,并开始执行拥塞避免算法

典型拥塞控制流程图:
在这里插入图片描述
发送方窗口的上限值:发送方的发送窗口一定不能超过对方给出的接收方窗口值rwnd;上限值应取接收方窗口和拥塞窗口这两个变量中较小的一个,即发送方窗口的上限值= min(rwnd,cwnd)

9.TCP的运输连接管理

运输连接的三个阶段:连接建立、数据传送、连接释放

客户-服务器方式:TCP连接建立采用客户服务器方式,主动发起连接建立的应用叫客户,而被动等待连接建立的应用进程叫服务器

1.TCP的连接建立(重点看懂图片流程)

三报文握手:
在这里插入图片描述
流程:

  1. 最初两端TCP进程都处于关闭状态,开始时B的TCP服务器进程先创建传输控制块TCB,准备接受客户进程的连接请求,然后进入收听状态;
  2. A的TCP客户进程也先创建TCB,然后打算建立TCP连接时,向B发送连接请求报文,这时首部中同步位SYN=1、确认ACK=0,同时选择一个初始序号seq=x(TCP规定,SYN报文段不能携带数据,但要消耗一个序号),这时TCP客户进程进入同步已发送状态;
  3. B收到连接请求报文后,若同意建立连接,则向A发送确认。在确认报文中将SYN位和ACK位都置1,确认号时ACK=x+1,同时也为自己选择一个初始序号seq=y(这个报文段也不能携带数据,但同样消耗一个序号),这时TCP服务器进程进入同步收到状态
  4. TCP客户进程收到B的确认后,还要向B给出确认。确认报文的ACK=1、同步位SYN=0,确认号ack=y+1,而自己的序号seq=x+1。(TCP规定,ACK报文段可以携带数据,但如果不携带数据则不消耗序号,这种情况,下一个数据报文段序号仍是seq=x+1)。这时TCP连接已经建立,A进入已建立连接状态
  5. B收到A的确认后,也进入已建立连接状态

2.TCP连接的释放:

四报文握手
在这里插入图片描述
流程:

  1. 起始时A和B都处于已建立连接状态

  2. A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接,A把连接释放报文段首部的终止控制位FIN置1,序号seq=u,它等于前面已传送过的数据的最后一个字节的序号+1。这时A进入终止等待状态。(FIN报文段即使不携带数据,也消耗一个序号)

  3. B收到连接释放报文后发出确认,确认号是ack=u+1,而这个报文自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号+1。然后B进入关闭等待状态,TCP服务器进程通知高层应用进程,因而从A到B这个方向的连接就释放了,这时的TCP连接处于半关闭状态,即A已经没有数据要发送了,但B若发送数据,A仍要接受

  4. A收到来自B的确认后,进入终止等待-2状态,等待B发送的连接释放报文段

  5. 若B已经没有要向A发送的数据,应用进程就通知TCP释放连接,此时B发出的连接释放报文段FIN=1,假定现在B的序号为w,B还必须重复上次已发送过的确认号ack=u+1,此时B进入最后确认状态,等待A的确认

  6. A在收到B的链接释放报文后,必须对此发出确认,在确认报文段中把ACK置1,确认号ack=w+1,而自己的序号时seq=u+1,然后进入时间等待状态。此时TCP连接还没有释放,必须经过时间等待计时器设置的时间2MSL后,A才进入关闭状态。

A等待2MSL时间的原因

  1. 保证A发送的最后一个ACK报文段能够到达B,若不能,则在2MSL时间段内可以重传

  2. 防止已失效的连接请求报文段出现在下一次新的连接中

⚠️TCP还设有保活计时器:解决当客户已主动与服务器建立TCP连接,但客户端主机出现故障,不能完成第三次握手,故服务器可以关闭本次连接

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值