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

╰+攻爆jí腚メ 2023-10-13 15:47 104阅读 0赞

## 一、可靠数据传递的原理 ##

可靠数据传输协议（rdt）

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

![在这里插入图片描述][60c1881734cf449ea2998d43cbf55d6b.png]

### 1、停止等待协议 ###

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

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

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

*  下层信道可能会出错：将分组中的比特翻转
    
     *  用校验和来检测比特差错
 *  问题：怎样从差错中恢复：
    
     *  确认(ACK)：接收方显式地告诉发送方分组已被正确接收
     *  否认确认(NAK)：接收方显式地告诉发送方分组发生了差错
        
         *  发送方收到NAK后，发送方重传分组
 *  rdt2.0中的新机制：采用差错控制编码进行差错检测
    
     *  发送方差错机制编码、缓存
     *  接收方使用编码检错
     *  接收方的反馈：控制报文（ACK，NAK）；接收方→发送方
     *  发送方收到反馈相应的动作
    
    > **文字描述：**  
    > 发送方发送 data 过去，接收方接收到 data后，进行数据校验；  
    > 检验么没有问题，回发送方一个ACK(确认)，在把数据进行解析后，通过曾经的接口向上层提供数据；  
    > 如果校验不通过，回复发送方一个NAK(反向确认)；  
    > 发送方收到NAK后，重新把原来的数据发送一遍，直至收到ACK，在继续发送后面的data。

![在这里插入图片描述][2d6d1aed441e435a9b74c1e6a27f6e9a.png]

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

在rdt2.0的基础上添加了一个pkt版本，可能会出现重复(只需要不向上层交付就行)，但不会出错。  
![在这里插入图片描述][97629392781b4db5a4841671b4325f38.png]  
![在这里插入图片描述][659bbe100f97419da9cefc71f7897e28.png]

**rdt2.1流程：**

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

#### 1.4、Rdt2.2：无NAK的协议 ####

功能同rdt2.1，但只是少了个NAK反向确认，使用ACK的(0和1序号)做确认  
![在这里插入图片描述][584788d4c2a7414a9f7d352d138b5a58.png]

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

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

### 2、流水线协议 ###

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

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

![在这里插入图片描述][70b92e31edde429982287a880bbe78da.png]

#### 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

![在这里插入图片描述][1e114c41aca74bc0bab851b8f83a9eba.png]

#### 回退N步 GBN ####

![在这里插入图片描述][28e45147014947af874999544e2d4bd3.png]

#### 选择重传 SR ####

![在这里插入图片描述][46dde3d76aa948998e85cfcfbb7c23dc.png]

## 二、多路复用 ##

#### 1、传输服务和协议 ####

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

#### 2、传输层 VS 网络层 ####

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

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

#### 3、多路复用/解复用 ####

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

## 三、无连接传输 UDP ##

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

#### 1、UDP：用户数据报协议 ####

为什么要有UDP？

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

## 四、面向连接的传输TCP ##

#### 1、TCP：概述 ####

*  点对点：
    
     *  一个发送方，一个接收方
 *  可靠的、按顺序的字节流
    
     *  没有边界的
 *  管道化（流水线）：
    
     *  TCP拥塞控制和流量控制设置窗口大小
 *  发送和接收缓存
 *  全双工数据
    
     *  在同一个连接中数据双向流动
     *  MSS：最大报文段大小
 *  面向连接
    
     *  在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方的状态变量
 *  有流量控制：
    
     *  发送方不会淹没接收方  
        ![在这里插入图片描述][8f98f9b1cac74b27a935c15d3b684ff3.png]
 *  序号：
    
     *  报文段首字节的在字节流的编号
 *  确认号
    
     *  期望从另一方收到的下一个字节的序号
     *  累积确认
 *  接收方如何处理乱序的

#### 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发送方：
    
     *  忽略重复的确认
     *  忽略流量控制和拥塞控制

![在这里插入图片描述][ff92c4d14047454d89a9794790845aaa.png]

#### 4、TCP连接管理 ####

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

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

两次握手建立连接

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

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

s：选择初始序号告诉服务器，服务器收到；然后告诉客户端收到了，顺带一起把服务器的初始序号告诉客户端；客户端收到服务器的初始序号后，再告诉服务器，已经收到你的初始序号  
![在这里插入图片描述][e57f2bdbbfcd41ebbf2d26c1c7aae3e1.png]

**6、TCP关闭连接：**

*  客户端，服务器分别关闭它自己这一侧的连接
    
     *  发送FIN bit=1 的TCP段
 *  一旦接收到FIN，用ACK回应
    
     *  接到FIN，ACK可以和它自己发出FIN段一起发送
 *  可以处理同时的FIN交换
 *  ![在这里插入图片描述][1e35dee132814f728963cba9b3c21e56.png]

## 五、拥塞控制 ##

#### 1、拥塞控制原理 ####

拥塞：

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

#### 2、拥塞控制方法 ####

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

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

![在这里插入图片描述][3d951646c82d4e6da73eaa8406d85713.png]

*  网络辅助的拥塞控制：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阶段

![在这里插入图片描述][e3ece129aafa4edcbf3f9df0f51101d4.png]

#### 为什么TCP是公平的？ ####

两个竞争的TCP会话：

*  加性增加，斜率为1，吞吐量增加
 *  乘性减，吞吐量比例减少
 *  ![在这里插入图片描述][e44a81bdf00a4595a98d03228c70a6a2.png]

[60c1881734cf449ea2998d43cbf55d6b.png]: https://img-blog.csdnimg.cn/60c1881734cf449ea2998d43cbf55d6b.png
[2d6d1aed441e435a9b74c1e6a27f6e9a.png]: https://img-blog.csdnimg.cn/2d6d1aed441e435a9b74c1e6a27f6e9a.png
[97629392781b4db5a4841671b4325f38.png]: https://img-blog.csdnimg.cn/97629392781b4db5a4841671b4325f38.png
[659bbe100f97419da9cefc71f7897e28.png]: https://img-blog.csdnimg.cn/659bbe100f97419da9cefc71f7897e28.png
[584788d4c2a7414a9f7d352d138b5a58.png]: https://img-blog.csdnimg.cn/584788d4c2a7414a9f7d352d138b5a58.png
[059762c12aab4018b54de4e131a9f6b6.png]: https://img-blog.csdnimg.cn/059762c12aab4018b54de4e131a9f6b6.png
[70b92e31edde429982287a880bbe78da.png]: https://img-blog.csdnimg.cn/70b92e31edde429982287a880bbe78da.png
[1e114c41aca74bc0bab851b8f83a9eba.png]: https://img-blog.csdnimg.cn/1e114c41aca74bc0bab851b8f83a9eba.png
[28e45147014947af874999544e2d4bd3.png]: https://img-blog.csdnimg.cn/28e45147014947af874999544e2d4bd3.png
[46dde3d76aa948998e85cfcfbb7c23dc.png]: https://img-blog.csdnimg.cn/46dde3d76aa948998e85cfcfbb7c23dc.png
[8f98f9b1cac74b27a935c15d3b684ff3.png]: https://img-blog.csdnimg.cn/8f98f9b1cac74b27a935c15d3b684ff3.png
[ff92c4d14047454d89a9794790845aaa.png]: https://img-blog.csdnimg.cn/ff92c4d14047454d89a9794790845aaa.png
[e57f2bdbbfcd41ebbf2d26c1c7aae3e1.png]: https://img-blog.csdnimg.cn/e57f2bdbbfcd41ebbf2d26c1c7aae3e1.png
[1e35dee132814f728963cba9b3c21e56.png]: https://img-blog.csdnimg.cn/1e35dee132814f728963cba9b3c21e56.png
[3d951646c82d4e6da73eaa8406d85713.png]: https://img-blog.csdnimg.cn/3d951646c82d4e6da73eaa8406d85713.png
[e3ece129aafa4edcbf3f9df0f51101d4.png]: https://img-blog.csdnimg.cn/e3ece129aafa4edcbf3f9df0f51101d4.png
[e44a81bdf00a4595a98d03228c70a6a2.png]: https://img-blog.csdnimg.cn/e44a81bdf00a4595a98d03228c70a6a2.png