计算机网络【自顶而下】——传输层

一、可靠数据传递的原理

可靠数据传输协议（rdt）

在下层提供的尽力而为的服务的情况下，通过本层向上层提供可靠的服务。

1、停止等待协议

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

• 下层的信道是完全可靠的
  • 没有比特出错
  • 没有分组丢失
• 发送方和接受方的FSM
  • 发送方将数据发送到下层信道
  • 接收方从下层信道接收数据

1.2、Rdt2.0 只有比特差错的信道

• 下层信道可能会出错：将分组中的比特翻转

  • 用校验和来检测比特差错

• 问题：怎样从差错中恢复：

  • 确认(ACK)：接收方显式地告诉发送方分组已被正确接收
  • 否认确认(NAK)：接收方显式地告诉发送方分组发生了差错
    • 发送方收到NAK后，发送方重传分组

• rdt2.0中的新机制：采用差错控制编码进行差错检测

  • 发送方差错机制编码、缓存
  • 接收方使用编码检错
  • 接收方的反馈：控制报文（ACK，NAK）；接收方→发送方
  • 发送方收到反馈相应的动作

  文字描述：
  发送方发送 data 过去，接收方接收到 data后，进行数据校验；
  检验么没有问题，回发送方一个ACK(确认)，在把数据进行解析后，通过曾经的接口向上层提供数据；
  如果校验不通过，回复发送方一个NAK(反向确认)；
  发送方收到NAK后，重新把原来的数据发送一遍，直至收到ACK，在继续发送后面的data。

1.3、Rdt2.1：发送方出来出错的ACK/NAK

在rdt2.0的基础上添加了一个pkt版本，可能会出现重复(只需要不向上层交付就行)，但不会出错。

rdt2.1流程：

• 发送方：
  • 在分组中加入序列号
  • 两个序列号(0，1)就足够了
    • 一次只发送一个未经确认的分组
  • 必须检测ACK/NAK是否出错(需要EDC)
  • 状态数变成了两倍
    • 必须记住当前分组的序列号为0还是1
• 接收方
  • 必须检测接收到的分组是否是重复的
    • 状态会指示希望接收到的分组的序号为0还是1
  • 注意：接收方并不知道发送方是否正确收到了其ACK/NAK
    • 没有安排确认的确认

1.4、Rdt2.2：无NAK的协议

功能同rdt2.1，但只是少了个NAK反向确认，使用ACK的(0和1序号)做确认

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

• 新的假设：下层信道可能会丢失分组（数据或ACK）
  • 会死锁
  • 机制还不够处理这种状况
    • 检验和
    • 序列号
    • ACK
    • 重传
• 方法：发送方等待ACK一段合理的时间
  • 发送端超时重传：如果到时没有收到ACK→重传
  • 问题：如果分组（或ACK）只是被延迟了：
    • 重传将会导致数据重复，但利用序列号已经可以处理这个问题
    • 接收方必须指明被正确接收的序列号
  • 需要一个倒计数定时器
    

2、流水线协议

流水线：运行发送方在未得到对方确认的情况下一次发送多个分组

• 必须增加序号的范围：用多个bit表示分组的序号
• 在发送方/接收方要有缓冲区
  • 发送方缓冲：未得到确认，可能需要重传；
  • 接收方缓存：上层用户取用数据的速率=接收到的数据速率：接收到的数据可能乱序，排序交付(可查)
• 两种通用的流水线协议：回退N步(GBN)和选择重传(SR)
  • GBN:RW=1，不可以乱序接收
  • SR：RW>1,可以乱序接收接收窗口之内的分组，但不能交付，且接收窗口不能向前滑动

2.1、滑动窗口协议

• 发送缓冲区：
  • 形式：内存中的一个区域，落入缓冲区的分组可以发送
  • 功能：用于存放已发送，但是没有得到确认的分组
  • 必要性：需要重发送时可用
• 发送缓冲区的大小：一次最多可以发送多少个未经确认的分组
  • 停止等待协议=1
  • 流水线协议>1，合理的值，不能很大，链路利用率不能超过100%
• 发送缓冲区的分组
  • 未发生的：落入发送缓冲区的分组，可以连续发送出去。
  • 已经发送出去的，等待对方确认的分组：发送缓冲区的分组只有得到确认才能删除

GBN协议和SR协议的异同

• 相同之处
  • 发送窗口>1
  • 一次能够可发送多个未经确认的分组
• 不同之处
  • GBN：接收窗口尺寸=1
    • 接收端：只能顺序接收
    • 发送方：从表现来看，一旦一个分组没有发送成功，如：0，1，2，3，4
      • 假如1未成功，2，3，4都发送出去了，要返回1再发生GBN
  • SR：接收窗口尺寸>1
    • 接收端：可以乱序接收
    • 发送端：发送0，1，2，3，4，一旦1未成功，2，3，4已发送，无需重发，选择性发送1

回退N步 GBN

选择重传 SR

二、多路复用

1、传输服务和协议

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

2、传输层 VS 网络层

• 网络层服务：主机之间的逻辑通信
• 传输层服务：进程间的逻辑通信
  • 依赖于网络层的服务
    • 延时、带宽
  • 并对网络层的服务进程增强
    • 数据丢失、顺序混乱、加密

通过Socket进行向下传递添加头数据，最终通过网卡传递到目标端，在进行解复用

3、多路复用/解复用

• 在发送方主机多路复用
  • 从多个套接字接收来自多个进程的报文，根据套接字对应的IP地址和端口号等信息对报文段用头部加以封装（该头部信息用于以后的解复用）
• 在接收方主机多路解复用
  • 根据报文段的头部信息中的IP地址和端口号接收到的报文段发给正确的套接字（和对应的应用进程）

三、无连接传输 UDP

• 尽力而为的服务报文段可能丢失
  • 丢失
  • 送到应用进程的报文段乱序
• UDP被用于：
  • 流媒体（丢失不敏感，速率敏感）

1、UDP：用户数据报协议

为什么要有UDP？

• 不建立连接（会增加延时）
• 简单：在发送端和接收端没有连接状态
• 报文段的头部很小（开销小）
• 无拥塞控制和流量控制

四、面向连接的传输TCP

1、TCP：概述

• 点对点：

  • 一个发送方，一个接收方

• 可靠的、按顺序的字节流

  • 没有边界的

• 管道化（流水线）：

  • TCP拥塞控制和流量控制设置窗口大小

• 发送和接收缓存

• 全双工数据

  • 在同一个连接中数据双向流动
  • MSS：最大报文段大小

• 面向连接

  • 在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量

• 有流量控制：

  • 发送方不会淹没接收方
    

• 序号：

  • 报文段首字节的在字节流的编号

• 确认号

  • 期望从另一方收到的下一个字节的序号
  • 累积确认

• 接收方如何处理乱序的

2、TCP的往返延时(RTT)和超时

• 怎么设置TCP超时
  • 比RTT要长
    • 但RTT是变化的
  • 太短：太早超时
    • 不必要的重传
  • 太长：对报文段丢失反应太慢，消极
• 怎样估计RTT
  • SampleRTT：测量从报文段发出到收到确认的时间
    • 如果有重传，忽略此次测量
  • SampleRTT会变化，因此估计的RTT应该会比较平滑
    • 对几个最近的测量值求平均，而不是仅用当前的SampleRTT

3、TCP：可靠数据传输

• TCP在IP不可靠范围的基础上建立的rdt
  • 管道化的报文段
    • GBN or SR
  • 累积确认（像GBN）
  • 单个重传定时器（像GBN）
  • 是否可以接受乱序的，没有规范
• 通过以下事件触发重传
  • 超时（只重发那个最早的未确认段：SR）
  • 重复的确认
    • 例子：收到了ACK50，之后又收到了3个ACK50
• 首先考虑简化的TCP发送方：
  • 忽略重复的确认
  • 忽略流量控制和拥塞控制

4、TCP连接管理

在正式交换数据之前，发送方和接收方握手建立通信关系：

• 同意建立连接（每一方都知道对方愿意建立连接）
• 同意连接参数

两次握手建立连接

• 问题：
  • 服务器会出现很多半连接
  • 接收老数据问题

5、三次握手解决：半连接和接收老数据问题

s：选择初始序号告诉服务器，服务器收到；然后告诉客户端收到了，顺带一起把服务器的初始序号告诉客户端；客户端收到服务器的初始序号后，再告诉服务器，已经收到你的初始序号

6、TCP关闭连接：

• 客户端，服务器分别关闭它自己这一侧的连接
  • 发送FIN bit=1 的TCP段
• 一旦接收到FIN，用ACK回应
  • 接到FIN，ACK可以和它自己发出FIN段一起发送
• 可以处理同时的FIN交换
• 

五、拥塞控制

1、拥塞控制原理

拥塞：

• 非正式的定义：”太多的数据需要网络传输，超过了网络的处理能力“
• 与流量控制不同
• 拥塞的表现：
  • 分组丢失（路由器缓冲区溢出）
  • 分组经历比较长的延迟（在路由器的队列中排队）
  • 最严重的还会出现网络死锁的情况，只有网络进没有网络出

2、拥塞控制方法

2种常用的拥塞控制方法：

• 端到端拥塞控制：
  • 没有来自网络的显示反馈
  • 端系统根据延迟和丢失事件推断是否有拥塞
  • TCP采用的方法

• 网络辅助的拥塞控制：ATM
  • 路由器提供给端系统以反馈信息
    • 单个bit置位，显示有拥塞（SNA,DECbit，TCP/IP ECN AIM）
    • 显示提供发送端可以采用的速率

TCP拥塞控制：

拥塞感知

发送端如何探测到拥塞？

• 某个段超时了（丢失事件）；拥塞
  • 超时时间到，某个段的确认没有来
  • 原因1：网络拥塞（某个路由器缓冲区没空间了，被丢弃）概率大
  • 原因2：出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
  • 一旦超时，就认为拥塞了，有一定误判，但是总体控制方向是对的
• 有关某个段的3次重复ACK：轻微拥塞
  • 段的第1个ack，正常，确认绿段，期待红段

速率控制方法

如何控制发送端发送的速率

• CongWin是动态的，是感知到的网络拥塞程度的函数
  • 超时或者3个重复ack，CongWin；
    • 超时时CongWin降为1Mss，进入SS阶段然后再倍增到CongWin/2（每个RTT），从而进入CA阶段
    • 3个重复ack；CongWin降为CongWin/2，CA阶段

为什么TCP是公平的？

两个竞争的TCP会话：

• 加性增加，斜率为1，吞吐量增加
• 乘性减，吞吐量比例减少
•