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计时器。
拥塞控制
拥塞控制四种算法
-
慢开始
-
拥塞避免
-
快重传
-
快恢复
慢开始
假设当前发送方拥塞窗口cwnd的值为1,而发送窗口swnd等于拥塞窗口cwnd,因此发送方当前只能发送一个数据报文段(拥塞窗口cwnd的值是几,就能发送几个数据报文段),接收方收到该数据报文段后,给发送方回复一个确认报文段,发送方收到该确认报文后,将拥塞窗口的值变为原来窗口的2倍
拥塞避免
当cwnd>ssthresh 时,采用拥塞避免算法,每次收到ack后将发送窗口增加1,直到发生丢包。此时更新ssthresh=ssthresh/2,cwnd=1,重新采用慢开始算法,直到cwnd>ssthresh时继续采用拥塞避免算法