做网站的素材,郑州大旗网站制作公司,华为云网站建设,什么是seo?阿华代码#xff0c;不是逆风#xff0c;就是我疯 你们的点赞收藏是我前进最大的动力#xff01;#xff01; 希望本文内容能够帮助到你#xff01;#xff01; 目录
一#xff1a;断开连接的本质
二#xff1a;四次挥手
1#xff1a;FIN
2#xff1a;过程梳理
… 阿华代码不是逆风就是我疯 你们的点赞收藏是我前进最大的动力 希望本文内容能够帮助到你 目录
一断开连接的本质
二四次挥手
1FIN
2过程梳理
3能合二为一吗
三“三次握手”和“四次挥手”异同
1相同点
2不同点
四TCP连接状态转换
1TCP状态转换图
2LISTED
3ESTABLISHED状态
4CLOSE_WAIT面试高频
1过程梳理
2作用
5TIME_WAIT面试高频
1过程梳理
2作用
五滑动窗口
1批量传输
2滑动窗口
3ack丢包
4数据丢包
1快速重传
注意点①
注意点②
2优点
3总结
六流量控制
1缓存区上限
2窗口动态变化 一断开连接的本质
通过上一篇文章的学习我们知道“三次握手”的目的和本质就是让通信双方能够保存对端的信息当信息这个数据量过大的时候就要引用数据结构。
那么断开连接的本质就是把对端的信息从数据结构中进行删除释放掉。
二四次挥手
1FIN 同样我们先认识一下TCP数据报包中6个标志符中的FIN——结束报文段 单词为finish结束——缩写为FIN 在之前的学习中我们调用通过ServerSocket类调用close方法就会触发FIN这里的FIN也是在内核中完成。 同样如果我们结束一个进程也会触发FIN【JavaEE】——TCP回显服务器万字长文超详细-CSDN博客 2过程梳理
引入与“三次握手”中“一定是客户端先主动”不同“四次挥手”中服务器和客户端两者谁都可以先主动分手像极了爱情~这里我们用“客户端先主动”充当例子 1客户端发起FIN结束报文段 2服务器ACK应答并且也发起FIN结束报文段 3客户端ACK应答 3能合二为一吗
引入在上述图解步骤下服务器和客户端各自给对方发起FIN并再给对方返回ACK“四次挥手”后代表着通信双方“和平分手”。那么这里的②③步骤是否也能“合并”呢
答案是可以合并但是不能100%的合并——“如合~”
如果②③两者发送的时间间隔很长那么就不能合并
三“三次握手”和“四次挥手”异同 1相同点 都是需要有一端先发起SYN/FIN然后对端在返回ACK 传输顺序syn/ack/syn/ack fin/ack/fin/ack 2不同点 三次握手中中间两次一定能够合并四次挥手中中间来那个词不一定能够合并 三次握手中一定是客户端先主动四次挥手中谁先主动都可以 四TCP连接状态转换
引入在TCP的连接中数据结构会保存两端的信息在这里面就有一个属性叫做“状态”操作系统可以根据状态的不同决定应该对连接做什么
1TCP状态转换图 铁铁们看到这个图脑壳都大了吧俺也是这里我们只介绍几个比较重要的状态即可
2LISTED listed译为已登录的表示服务器这边已经建立好了ServerSocket并且绑定好了端口号随时准备接收客户端的连接 步骤一我们先启动服务器代码在之前TCP回显服务器那一篇文章直接复制粘贴即可 【JavaEE】——TCP回显服务器万字长文超详细-CSDN博客 步骤二打开命令窗口输入netstat -ano 步骤三服务器加上限制条件我们看9090这个在代码里选择连接的端口 3ESTABLISHED状态
注established译为已建立的
表示客户端和服务器已经建立完毕三次握手完了 步骤四客户端和服务器连接进入ESTABLISHED 注这里双方进入时间差极小肉眼是看不出来先后顺序的除非精确查看日志里的时间戳 4CLOSE_WAIT面试高频 close_wait译为关闭等待——谁被断开连接谁进入close_wait状态 1过程梳理 看图客户端发起FIN断开连接四次挥手服务器收到后发送ACK应答报文后进入close_wait状态。 这个状态是比较难观察到的因为服务器发送ACK和FIN的时间间隔极短即关闭socket文件的时间极短此时close_wait - last_ack 状态的切换非常快。 2作用 阻塞等待客户端数据请求 注如果发现服务器或者客户端出现大量的CLOSE_WAIT意味着很可能是socket没有关闭出bug了。 5TIME_WAIT面试高频 谁主动断开连接谁进入TIME_WAIT状态 1过程梳理 服务器返回给客户端ASK和FIN客户端收到返回ASK应答后进入TIME_WAIT状态 2作用 如果最后一个ACK丢包了服务器迟迟收不到ACK就会重传一个FIN客户端收到后也会相应重传一个ACK。 而TIME_WAIT就为这个过程留下充足的时间这个等待的时间不是无休止的等待连机器都不会无限制的等待更何况爱情呢~最多2MSLMSL是系统内核的配置项 五滑动窗口
引入之前我们简单了解一次数据传输所经历的过程。
我们可以发现一个问题发一个数据就要等一个ack这样的效率是不足以满足现在“信息爆炸”的现状的。
所以我们引出批量传输这个概念
1批量传输
顾名思义——先发一个数据不等ack了下一个数据接着发连续发了好多个ack之后使用同一份时间来等待ack
好处减少了总的等待的时间内下面这张图能非常形象的表现出来 2滑动窗口 3ack丢包
看图—— 1001的ack应答丢包了但是2001这个ack没有丢包主机A收到②这个ack后就知道主机B2001之前的数据都收到了所以①号ack丢包问题不大这种情况无需处理对于TCP传输的可靠性没有影响。
4数据丢包 1快速重传 注意点① 看上图主机A发送的1001~2000这个数据丢包了但是2001后面的数据还在发送此时主机B就会对2001后面的数据返回ack多次强调下一个数据是1001服务器收到三次这个ack之后就知道1001~2000这个数据丢包了就会重传有点超时重传的感脚~ 注意点② 主机B收到1001~2000这个丢包的数据后直接会跳到索要7001这个数据包了而不是2001~。 这是因为TCP有一个接受缓冲区你可以想象成一个队列 2优点
上述重传的过程整体效率非常高做到了“针对性”的丢包重传不必重新发送这种重传叫做“快速重传”
3总结 ①“确认应答”、“超时重传”、“滑动窗口”、“快速重传”这四种机制并不冲突可以同时存在。 ②短时间发送了很多数据窗口才滑的起来 ③判定丢包的标准是连续有多个ack索要同一个数据普通传输判定标准是ack超时没有到达 六流量控制
引入上述滑动窗口可以提高数据的传输效率窗口越大更多数据复用同一块时间效率就更高那么问题来了窗口越大越好吗显然不行
1缓存区上限
数据到达接收方是先暂时存储在缓冲区当中等到一定的数量后接受方在一次性拿(read)出来。
试想发送方如果一下子发送数据太快导致接收方的缓冲区装不下了就会导致丢包这时在重传也没用了因为已经返回ack了
2窗口动态变化
与其等待接收方缓存区满了不如提前感知到就减慢发送数据的速度下面有请我们的老朋友 16位窗口大小就能很好的动态控制窗口的大小通过这个字段来给发送方反馈发送速度很明显这个字段对于发送方的报文中没有意义只有ack报文中才有意义
注这个16位并不是实际上的大小——在TCP报头中有一个参数叫做窗口扩展因子 实际窗口大小 16位窗口大小* 2^窗口扩展因子
