网站有哪些功能,网站开发前端简历,自己做网站和外包,seo网站优化做什么目录 TCP的“可靠性”#xff08;上#xff09;确认应答#xff08;可靠性传输的基础#xff09;超时重传连接管理#xff08;三次握手#xff0c;四次挥手#xff09; TCP的“可靠性”#xff08;上#xff09;
想必大家都或多或少的听说过TCP的特性#xff1a;有连… 目录 TCP的“可靠性”上确认应答可靠性传输的基础超时重传连接管理三次握手四次挥手 TCP的“可靠性”上
想必大家都或多或少的听说过TCP的特性有连接可靠传输面向字节流全双工
本文重点讲讲TCP的“可靠性”
网络通信过程是复杂的无法确保发送方发送出去的数据100%能够到达接收放。
此处可靠性只能“退而求其次”只要尽可能的去进行发送了发送方能够指定对方是否收到就认为是可靠传输了。 网上很多帖子说”TCP的可靠性是因为三次握手四次挥手“ 这个说法是很不准确的因为三次握手四次挥手只有初次建立连接的时候才会但是可靠性是整个过程都可靠那靠的什么呢 用来确保可靠性最核心的机制称为“确认应答”
确认应答可靠性传输的基础
确认应答就是句句有回应 比如银角大王每次像金角大王发出请求金角大王都有响应 但是上述的时序有些过于理想了实际上网络传输过程中经常会出现“后发先至”情况 为什么网络中会出现“后发先至”情况呢 一个数据包从发送方到接收方过程中走的路线可能不一样 第一个数据包走路线一第二个数据包走路线二 有可能路线二非常通畅路线一堵车了第二个数据包虽然发的迟但是能先到 如果出现后发先至的情况再去理解这里的含义就会出现问题了 为了解决上述问题引入了序号和确认序号对于数据进行编号应答报文里就告诉发送方说我这次应答的是哪个数据 这只是简化版本的模型真实的TCP的情况要更复杂一些。 TCP是面向字节流的以字节为单位进行传输的没有“一条两条”的概念 实际上TCP的序号和确认序号都是以字节来进行编号的 应答报文中的确认序号是按照发送过去的最后一个字节的序号再加上1来进行设定的 超时重传
超时重传是确认应答的补充
如果一切顺利通过应答报文就可以告诉发送方当前数据是不是成功收到
但是网络上可能存在“丢包”情况。如果数据包丢了没有到达对方对方自然也没有ack报文了。
这个情况下就需要超时重传了 TCP可靠性就是在对抗丢包期望在丢包客观存在的背景下也能够尽可能的把包传过去 发送方发了个数据之后要等 等的时间里收到了ack数据报在网络上传输需要时间 如果等了好久ack还没等到此时发送方就认为数据的传输出现丢包了 当认为丢包之后就会把刚才的数据包再传输一次重传 等待的过程有一个时间的阈值上线就是超时 为啥会存在“丢包” 网络中的路由器/交换机不仅仅是给你这一次通信提供服务还要能支持千千万万的主机之间的通信 整个网络中就可能存在某个路由器/交换机某个时刻突然负载量很高短时间内可能有大量的数据包要几个这个设备转发。这个时候如果瞬间的高负载超出了这个设备能转发的数据量的极限多出来的部分就无了就被设备丢包了。 当然没收到ack不一定就是丢包了也可能是数据到达了ack丢了 所以这里要分情况讨论
1.丢包了数据包丢了
这种情况接收方本身没有收到数据此时你重传理所应当没有任何问题
2.ack丢了
数据已经被接收方B接收了但是B返回的ack丢了
此时发送到再传输一次同一份数据B就会收到两次 试想一下如果发的请求是扣款请求呢这是肯定不行的 TCP socket再内存中存在接收缓冲区一块内存空间
发送方发来的数据是要首先放到接收方缓冲区中然后应用程序调用read/sanner.next才能读到数据这里的读操作其实是读接收缓冲区。
【缓冲区的应对方案】 1去重
当数据到达接收缓冲区的时候接收方首先会判断一下看当前缓冲区是否已经有这个数据了或者这个数据曾经在接收缓冲区中存在过
如果已经存在或者存在过就直接把重复发来的数据就丢弃了
就能确保不会出现重复数据了 接收方如何判定这个数据是否是 “重复数据” 核心判定依据【数据的序号】 数据还在接受缓冲区里还没被 read 走。 此时就拿着新收到的数据的序号和缓冲区中的所有数据的序号对一下看看有没有一样的。有一样的就是重复了就可以把新收到的数据丢弃了。数据在接受缓冲区中已经被应用程序给 read 走了此时新来的数据序号直接无法再接受缓冲区查到 注意应用程序读取数据的时候是按照序号的先后顺序连续读取的 先读 1 - 1000 1001 - 2000 2001 - 3000 一定是先读序号小的数据后读序号大的数据的可以把接收缓冲区这个队列想象成带有优先级的阻塞队列 此时socket api 中就可以记录上次读的最后一个字节的序号是多少 比如上次读的最后一个字节的序号是 3000 新收到一个数据包的序号是 1001这个 1001 一定是之前已经读过的了这个时候同样可以把这个新的数据包判定为 “重复的包” 直接丢弃了。 上述谈到的ack重传保证顺序自动去重都是 TCP 内置的。使用 TCP 的 api 的时候outputStream.write () 只需要调用一个这样的简单代码上述功能就都自动生效了程序员需要操的心就少多了。 如果使用 UDP上述这些问题就都得好好考虑考虑。 超时是会重传但不是无限的重传有一定的策略的
重传次数是有上限的。重传到一定程度还没有 ack就尝试重置连接如果重置也失败就直接放弃连接。重传的超时时间阈值也不是固定不变的随着重传次数的增加而增大重传频率越来越低
连接管理三次握手四次挥手
后续内容在我的下一篇文章中有讲到【TCP的“可靠性”下——三次握手四次挥手】
建立连接 客户端执行 socketnew Socket(serberIp,serverPort)这个操作就是在建立连接
上述只是调用 socket API 真正连接建立的过程是在操作系统内核完成的 建立连接三次握手
此处的连接是“虚拟的抽象的”连接目的是让通信双方都能保存对方的相关信息
断开连接四次挥手
断开连接的本质目的就是为了把对端的信息从数据结构中给删除掉 / 释放掉。
