计算机网络笔记-3

第三章

第三章 传输层

3.1 概述和传输层服务

传输服务和协议

  • 为运行在不同主机上的应用进程提供逻辑通信
  • 传输协议运行在端系统
    • 发送方:将应用层的报文分成报文段,然后传递给网络层
    • 接受方:将报文段重组成报文,然后传递给应用层
  • 有多个传输层协议可供应用选择
    • Internet:TCP和UDP

传输层 VS 网络层

  • 网络层服务:主机之间的逻辑通信
  • 传输层服务:进程间的逻辑通信
    • 依赖于网络层的服务—延时,带宽(这些服务无法优化)
    • 并对网络层的服务进行增强—数据丢失,顺序混乱,加密

image-20230223100113960

Internet传输层协议

  • 可靠的,保序的传输:TCP
    • 多路复用,解复用
    • 拥塞控制
    • 流量控制
    • 建立连接
  • 不可靠,不保序的传输:UDP
    • 多路复用,解复用
    • 没有为尽力而为的IP服务添加更多的其他额外服务
  • 都不提供:
    • 延时保证
    • 带宽保证

3.2 多路复用和解复用

image-20230223101759285

工作原理

image-20230223101911827

无连接(UDP)多路解复用

image-20230223102027656

面向连接的解复用

image-20230223102507925

3.3 无连接传输 UDP

UDP:用户数据报协议

User Datagram Protocol [RFC 768]

  • “no frills”,”bare bones” Internet传输协议
  • “尽力而为的服务”,报文段可能丢失,送到应用进程的报文段乱序
  • 无连接:
    • UDP发送端和接收端之间没有握手
    • 每个UDP报文段都被独立地处理

UDP被用于:

  • 流媒体(丢失不敏感,速率敏感,应用可控制传输速率)
  • DNS
  • SNMP

在UDP上实现可靠传输:

  • 在应用层增加可靠性
  • 应用特定的差错恢复

image-20230223104543262

校验和:EDC,差错检验码

UDP校验和

目标:检测在被传输报文段中的差错(如比特反转)

发送方:

  • 将报文段的内容视为一个个16比特的整数,不足的补0
  • 校验和:报文段的加法和(1的补运输)
  • 发送方将校验和放在UDP的校验和字段

接受方:

  • 计算接受到的报文段的校验和
  • 检查计算出的校验和与校验和字段的内容是否相等
    • 不相等—检测到差错
    • 相等—没检测到差错,但也许有差错—残存错误

image-20230223105930147

即最高位进位要进到最低位去,最后结果取反码即为校验和

在接收方,将包括EDC在内的报文相加起来,为2^(16)-1,则通过校验

3.4 可靠数据传输(rdt)的原理

image-20230223110335755

image-20230223110955563

rdt_rcv大概是打错了,应该都是udt_rcv

image-20230223111442837

即双向传输化rdt简化成单向传输rdt,而实现单向传输中,控制信息是双向的(需要给出反馈信息)

Rdt1.0: 在可靠信道上的可靠数据传输

image-20230223111956528

同理,rdt_rcv应该是udt_rcv,此处应该是打错了

Rdt2.0: 具有比特差错的信道

image-20230223112449483

image-20230223112511642

Rdt2.1: ACK/NAK出错

image-20230223113014951

即只要发送方没有接受到正确的ACK,都会重传当前分组,如果发送方已经成功收到该分组(通过分组内的序号识别?),则将其丢弃,再次发送ACK

image-20230223113508171

image-20230223113650653

packet通过校验后,通过序号是0还是1判断是否将数据传递给上层

image-20230223114456837

image-20230223114851441

Rdt2.2: 无NAK的协议

image-20230223141345669

image-20230223141405334

image-20230223141827476

image-20230223141851812

若ack出现错误,则sender重新发送packet,此时receiver根据packet中的序号判断是否重复

image-20230223142256245

Rdt3.0 :具有比特差错和分组丢失的信道

image-20230223142902632

image-20230223143351708

要注意等待ACK状态中,接收到错误ACK后,不执行操作,直至超时后才重新发送packet

image-20230223144628186

流水线协议:提高链路利用率

超时时间不合理仍能正常工作,但会导致packet都被发送多次

image-20230223145606337

延迟时间:一个bit从发送方发出,到接受方接受所需要的时间—可以理解成车的行驶时间

带宽:每秒能发出多少个bit—可以理解为马路宽度,即每秒能发出多少辆车

由于每次发送需要等待接收方返回控制信息(ACK),就算链路的容量较大,由于每次发送的PDU较小,也无法有效利用其容量,如例子中吞吐量仅为270kbps

image-20230223150546097

即一次发送多个PDU

image-20230223151440952

通用:滑动窗口(slide window)协议

发送窗口:

image-20230223152058394

  1. 发送窗口SW=1,接受窗口RW=1: S-W(stop and wait)协议—rdt3.0
  2. 发送窗口SW>1,接受窗口RW=1: GBN(回退N步)协议—流水线协议
  3. 发送窗口SW>1,接受窗口RW>1: SR(选择重传)协议—流水线协议

image-20230223152817943

image-20230223153239779

image-20230223153811869

image-20230223154000012

image-20230223154140618

接受窗口:

image-20230223154909864

接受窗口=1,比如罩住1时,若收到非1数据,都返回ACK0,收到1时,则返回ACK1,即GBN协议,只能顺序接受(其ACK包含累计确认的含义,即前X个都成功接收了)

若接受窗口>1,比如罩住1234,若收到2,则返回ACK2(但只有收到1时,尾沿才能移动),即SR协议

image-20230223155344966

image-20230223155635506

窗口互动:

image-20230223160106595

image-20230223160402573

比如发送方一次发送1~5,一共5个PDU,2~5都成功发送,由于GBN其接受窗口大小为1,2~5都被抛弃,然后产生了4个累计确认,然后超时重发机制又使得发送窗口内PDU全被发送一遍

image-20230223160823853

假设发送了2,3,4,一共3个PDU,其中3,4都被接受到,返回ACK3和ACK4,而2超时,则超时重发机制会将2重新发送(而3,4不需要)

GBN协议和SR协议的异同

image-20230223161400568

image-20230223161759919

image-20230223163131488

image-20230223163056946

image-20230223163634823

注意返回ACK1后不会立即发送2,而是等2的计时器超时,ACK决定的是窗口的后沿位置

image-20230224175444325

image-20230224180411251

image-20230224180545223

注意上图中黑框为发送缓冲区的范围(发送后才加入发送窗口开始计时)

image-20230224180921150

3.5 面向连接的传输: TCP

TCP:概述

image-20230224181400695

  • 全双工:二者可以同时向对方发送数据
  • 物理链路中载荷大小有限,通过划定最大报文段大小,使数据分块分块后传输

TCP:报文段结构

image-20230224182042768

  • 注意序号是字节的序号,而不是前文中PDU的序号,如MSS大小为1024B,第一个MSS序号为0,则第二个MSS序号为1024,第n个MSS序号为1024*n(真实情况中,初始序号在握手时决定),而窗口大小也是以字节为单位
  • 注意接受方若向发送方发送ACK555,则表示554及之前的字节都被成功接受,需要第555个字节(注意与前文差1)

image-20230224183105558

  • 乱序到达的段既可以丢弃也可以缓存

image-20230224183327965

TCP:往返延时(RTT)和超时

image-20230225140249704

image-20230225141039317

前i个采样贡献权值为a*(1-a)^i,即呈指数下降

image-20230225141248713

TCP:可靠数据传递

image-20230225141458179

由重复确认引起的重传称为快速重传(因为还没超时)

image-20230225142912828

image-20230225143112205

image-20230225143833761

接受方的ACK行为

image-20230225144453436

image-20230225144755237

image-20230225144951125

image-20230225145145451

TCP:流量控制

image-20230225145421440

  • 通过反馈接受窗口的大小(即缓冲区的空白大小)来控制流量
  • 通过对报文段结构的学习,我们可以知道,反馈信息(窗口大小,ACK等等)是附带在数据中的(TCP的双向传输特性也支持这一点)

image-20230225150043512

image-20230225150300140

TCP:连接管理

image-20230225150639856

两次握手是否可行?

image-20230225150945256

image-20230225151455685

即双方正常创建连接,关闭连接后,该连接中由于超时导致的重复发送(可能是连接请求,可能是传输的数据)才到达服务器,第一张图中服务器”建立”了一个不存在的连接,而第二张图中服务器不仅”建立”了一个不存在的连接,甚至接受了前一个连接中的老数据作为当前连接的新数据

三次握手

image-20230225152459699

image-20230225153349475

  • 可以发现,第二次握手表示服务器是活跃的,第三次握手表示客户端是活跃的,因此延迟到达的连接请求会被服务器拒绝,无法建立
  • 而延迟到达的数据,若socket已经关闭,则服务器不接受该数据;若相同端口,IP地址的socket再次打开,由于初始序号不一致,老数据仍被拒绝
  • 有没有可能老数据的序号与此时的序号恰好一致—有,概率极小
  • 可以将初始序号同时间周期绑定在一起—仍有可能重复,概率非常非常小,几乎不可能

image-20230225153752143

连接拆除

image-20230225154139229

image-20230225154633265

  • 为什么最后客户端仍有个等待时间—为了确保ack发送到服务器(ack可能发生丢失),服务器接收到ack后就关闭连接,客户端在发送ack一段时间后,才关闭连接

3.6 拥塞控制原理

image-20230225155834350

与流量控制的差别:流量控制是”我”到”你”的问题,即单对单,而拥塞控制是整个网络的问题(多到多)

拥塞场景/代价1

image-20230225160222368

拥塞场景/代价2

image-20230225160521192

  • 传输层输出大于应用层输出

image-20230225160648117

image-20230225161100966

  • 因为拥塞,即使数据没有丢失也发生了超时,此时链路中存在多个相同的分组—浪费,同时加剧拥塞

拥塞场景/代价3

image-20230225161840238

  • 蓝色的流量经过第一个路由器过滤,当发生拥塞时,蓝色经过的第二个路由器,其吞吐量被红色占据,蓝色吞吐量几乎为0,而红色在其经过的第二个路由器,该路由器吞吐量又几乎被绿色的流量占据,故红色的吞吐量也几乎为0
  • 出现”死锁”

image-20230225162420588

拥塞控制方法

image-20230225162548691

网络辅助的拥塞控制

image-20230225163124710

信元: 53个字节,其中5个字节是头部(非常小,所以传输得很快,比bit大,比分组小)

image-20230225164602424

3.7 TCP拥塞控制

因为网络辅助的拥塞控制,给网络带来的压力较大(附加了控制信息),所以TCP采用端到端的拥塞控制

TCP拥塞控制:机制

端到端的拥塞控制机制

  • 路由器不向主机提供有关拥塞的反馈信息
    • 路由器的负担较轻
    • 符合网络核心简单的TCP/IP架构原则(将问题放在端系统解决)
  • 端系统根据自身得到的信息,判断是否发生拥塞,从而采取动作

几个问题

  • 如何检测拥塞
    • 轻微拥塞
    • 拥塞
  • 控制策略
    • 在拥塞发生时如何动作,降低速率
      • 轻微拥塞时,如何降低
      • 拥塞时,如何降低
    • 在拥塞缓解时如何动作,增加速率

TCP拥塞控制:拥塞感知

image-20230303165305564

TCP拥塞控制:速率控制方法

image-20230306124919075

image-20230306125436218

(MSS:最大报文段长度)

即发生超时时,先降为1,然后倍增到原来CongWin的1/2(每个RTT增加1倍),然后开始线性增长

若出现轻微拥塞,则直接降为CongWin的1/2,然后线性增长

TCP拥塞控制和流量控制的联合动作

image-20230306130150738

TCP拥塞控制:策略概述

  • 慢启动
  • AIMD:线性增,乘性减少
  • 超时事件后的保守策略

TCP慢启动

image-20230306130736526

image-20230306130923523

AIMD

image-20230306131203459

image-20230306131255848

image-20230306131817274

image-20230306132117204

TCP吞吐量

image-20230306132440982

TCP公平性

image-20230306132650138

每次发送拥塞,窗口大小要除2,则TCP会话之间的窗口大小之差也除2,指数级趋向于0,故每一个会话的有效带宽相同

image-20230306133430732

UDP不受拥塞控制节制—对TCP不友好