青岛建站模板厂家,微信云开发小程序,关键词全网搜索工具,网站建设微商城目录 考研大纲
1.传输层概述
端口号
有连接/无连接传输
可靠/不可靠传输
2.UDP协议
2.1 udp数据报
2.2 udp检验
3.TCP协议
3.1 TCP协议的框架梳理
3.2 TCP报文段****
3.3 三次握手与四次挥手
三次握手
四次挥手
3.4 可靠传输与流量控制
流量控制#xff1a;滑动…目录 考研大纲
1.传输层概述
端口号
有连接/无连接传输
可靠/不可靠传输
2.UDP协议
2.1 udp数据报
2.2 udp检验
3.TCP协议
3.1 TCP协议的框架梳理
3.2 TCP报文段****
3.3 三次握手与四次挥手
三次握手
四次挥手
3.4 可靠传输与流量控制
流量控制滑动窗口机制
可靠传输确认机制超时重传与快重传机制
3.5 拥塞控制
拥塞控制介绍
慢开始和拥塞避免算法
快重传与快恢复算法 考研大纲 1.传输层概述 端口号 有连接/无连接传输 可靠/不可靠传输 2.UDP协议
UDP是无连接不可靠的不支持拥塞控制适用于即时性的场景如直播等
UDP接收的是应用层完整的报文因此说udp是面向报文的
2.1 udp数据报 UDP数据报理论最大长度为65535B但受限于IP数据报的长度所以实际上最大不能超过65515B UDP数据报示例 总结 2.2 udp检验
首先介绍一个校验方法。发送方取每16bit数据的二进制进行相加注意“高位回卷”加完的结果取反得到同样二进制数的16bit检验和。把原数据和检验和一起发送。那么接收方判断数据是否正确就是同样进行原数据每16bit相加最后和校验和相加如果全为1代表正确。 介绍完上面的校验方式那么就来看看udp校验其实也是这样的方式。
发送方 接收方 真题 3.TCP协议
3.1 TCP协议的框架梳理 三次握手四次挥手的整体流程 TCP有最大段长限制同时TCP可以分段而不像UDP要求传输完整报文因此TCP也称面向字节流 3.2 TCP报文段****
都是重点
ACK只有在握手阶段的第一次握手为0之后的全为1. 起始序号不一定从0开始如下图可以从500开始 确认号ack-seq按照教材定义表示期望接收的下一个序列号是多少
确认后示例如下图当接收方已经成功接受了1号和2号这2个报文段那么他可以返回的ack-seq 2500表示2500之前的字节都成功接收了期望接收的下一个序列号从2500开始。 数据偏移其实就是TCP首部的长度跟IP数据报的首部是一样的回忆一下418首总偏ip数据报的首部也是X 4B。 SYN只有在握手1和握手2时 1表示请求连接和连接接受
FIN只有在挥手1和挥手3时 1表示数据发送完毕要求释放连接 示例 窗口字段 示例例如主机B的TCP协议给进程2分配的接收缓冲区为2500B现在他已经接收了1和2这两个报文段了剩500B那么返回的rcvwnd500 校验和字段 选项字段和MSS 3.3 三次握手与四次挥手 三次握手 三次握手中的字段变化 注意下边左右连接的区别主要是在握手3握手3是可以不携带数据的 真题题目求的是握手2服务端要发送的TCP段的值SYN 1在握手1和2中所以这里是SYN 1ACK只在握手1里为0所以这里ACK 1seq是服务器自己设置要发送的起始字节随便都可以的这里不能用来判断ack 11220111221这里能确定。所以选c 三次握手中TCP状态变化 三次握手中连接耗时 四次挥手
字段的变化 tcp状态变化 连接耗时计算 真题就是上图算连接耗时客户端进入close的时间 1倍RTT 2MSL 50 1600 1650服务器进入close的时间 1.5倍RTT 75。 3.4 可靠传输与流量控制
可靠传输在数据链路层也有二者有很多相似之处。数据链路层是以帧为单位进行重传确认而TCP是以TCP段进行重传确认。流量控制同样在数据链路层也有也是滑动窗口机制。 流量控制滑动窗口机制 确认号与接收窗口的大小会在TCP首部中。 发送窗口不能超过自己的发送缓冲区也不能大于对方的接受窗口。 扩展一个端口可以建立多个TCP连接 可靠传输确认机制超时重传与快重传机制
可靠传输依靠确认机制和重传机制实现确认机制就是接收方返回ACK段。重传机制有超时重传与快重传这二者的差别在于接收方是返回确认ACK段的时机因为确认机制返回ACK的时机是“推迟确认”快重传会让确认机制变为“立即确认”。 累计确认 捎带确认 超时重传场景
情况1客户端发出的报文段丢失 情况2服务器返回的ACK段丢失 快重传机制
下面是推迟确认下的重传的场景当发送方连续发送的4个报文段中有报文段丢了那么由于推迟确认最后发送方要重发一堆的报文段这会导致浪费毕竟只是丢失了其中某个报文段没必要重传一堆报文段。 推迟后发送一个ACK如下 发送方接收到ACK后调整自己的窗口可以看到232425已经在之前发送了而且他们的计时器还没超时所以这时候是得等待超时才能重发的。 而快重传就是来解决这种问题每收到一个报文段就立即返回确认。如果发送方收到三个冗余确认号相同的ACK就立即重传对应的报文段。按照图示应当是收到13个确认后相同的ACK。 真题 3.5 拥塞控制
拥塞控制介绍
考题中假设接收方采用的确认机制都是“立即确认”。 引发超时重传--因为默认考题中的接收方采用的是“立即确认”那么发出的报文未能按时收到ACK就表明网络拥塞严重了。
引发快重传--接收方“立即确认”能够按时发送冗余ACK给发送方说明发送方有报文丢失但网络情况没那么严重因为发送方还能按时收到多个冗余ACK触发快重传。 上图中发送窗口的上限制 看做等于 拥塞窗口也就是默认接收窗口一直大于拥塞窗口的情况。
慢开始和拥塞避免算法 按照上图和下图理解很透彻。
慢开始阶段拥塞窗口即发送窗口是指数型增长当到达阈值后每次只能1。当发生超时重传网络拥塞严重就恢复慢开始拥塞窗口重置为1同时将阈值设为 此前的窗口值/2。如此反复。 真题
注意发送窗口 min拥塞窗口接收窗口题目中的乙的16KB接收缓存就是接收窗口不被取走意味着接收窗口只会越来越小。 快重传与快恢复算法
我们说快重传是网络不那么拥塞的情况。快重传触发时阈值与拥塞窗口相等等于发生时的拥塞窗口的一半因此同样触发了拥塞避免一次只能加1个拥塞窗口。注意拥塞窗口最小要大于等于2。
