计算机网络之传输层

最新推荐文章于 2022-10-23 23:20:47 发布

月Sukii

最新推荐文章于 2022-10-23 23:20:47 发布

阅读量1.8k

点赞数 1

分类专栏：计算机网络文章标签：计算机网络

本文链接：https://blog.csdn.net/sukiki09/article/details/121607304

版权

计算机网络专栏收录该内容

3 篇文章 0 订阅

订阅专栏

UDP

特点：无连接

用于：流媒体、DNS、SNMP

rdt

rdt1.0

特点

下层的信道是完全可靠的
- 没有比特出错
- 没有分组丢失

rdt2.0

特点

下层信道可能会出错：将分组中的比特翻转
- 用校验和来检测比特差错

恢复方法

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

缺陷

不能解决ACK、NAK出错的情况

rdt2.1

特点

引入序号（0和1）机制
- 发送方在每个分组中加入序号，如果 ACK/NAK 出错，发送方重传当前分组，接收方丢弃（不发给上层）重复分组

发送方：

在分组中加入序列号
一次只发送一个未经确认的分组

rdt2.2

特点：

无NAK
接收方对最后正确接收的分组发 ACK ，以替代 NAK
- 接收方必须显式地包含被正确接收分组的序号
当收到重复的 ACK （如：再次收到 ack0 ）时，发送方与收到 NAK 采取相同的动作：重传当前分组

rdt3.0

特点：

具有比特差错和分组丢失的信道

下层信道可能会丢失分组（数据或 ACK ）

解决方法：

发送方等待 ACK 一段合理的时间
发送端超时重传：如果到时没有收到 ACK-> 重传
问题：如果分组（或 ACK ）只是被延迟了：
- 重传将会导致数据重复，但利用序列号已经可以处理这个问题
- 接收方必须指明被正确接收的序列号
需要一个倒计数定时器

滑动窗口协议

GBN协议

在这里插入图片描述

特点

超时重传
累计确认
- 分组1接收之后，分组2丢失，分组3发送之后服务器返回ack1，表示1以及1之前的分组已经成功接收，要求客户端发送分组2。当分组2成功发送并成功接收之后，客户端再重新发送发送分组3
- 客户端收到ack1,ack3,ack8表示8以及8之前的分组（0~8）成功被接收。

解析：由于收到了3号帧的确认，也就是ACK 3，那么由累计确认机制可知：0、1、2、3号帧都成功传送。因此，只有4、5、6、7号帧需要重发。所以选C.4。

SR协议

特点

具有缓存机制
- 失序的分组将会被缓存，当丢失的分组被重发且成功接收后，无需重发失序的分组，即可直接进行窗口滑动。

对比

	GBN	SR
优点	简单，所需资源少（接收方一个缓存单元）	出错时，重传一个代价小
缺点	一旦出错，回退 N 步代价大	复杂，所需要资源多（接收方多个缓存单元）

TCP（传输控制协议）

特点

点对点：一个接收方和一个发送方
可靠的、面向字节流的协议
全双工连接
可靠性
- 拥塞控制
- 流量控制
- 确认号
- 序列号
- 超时重传
- 校验和

TCP报文段

三次握手

在这里插入图片描述

为什么不用两次握手？

主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，客户端发送的第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源浪费

四次挥手

为什么最后客户端还要等待 2*MSL的时间呢?

保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。