惠州企业网站建设选哪家,购物网站用那个软件做,标书制作注意事项,ps做网站字号大小日升时奋斗#xff0c;日落时自省 目录
1、确认应答
1.1、序号编辑
2、超时重传
3、连接管理
3.1、三次握手
3.2、四次挥手
4、滑动窗口
5、流量控制
6、拥塞控制
7、延时应答
8、捎带应答
9、面向字节流
10、异常情况 TCP协议#xff1a;
特点#xff1a;有… 日升时奋斗日落时自省 目录
1、确认应答
1.1、序号编辑
2、超时重传
3、连接管理
3.1、三次握手
3.2、四次挥手
4、滑动窗口
5、流量控制
6、拥塞控制
7、延时应答
8、捎带应答
9、面向字节流
10、异常情况 TCP协议
特点有连接的、可靠传输、面向字节流、全双工
可靠性传输是TCP内部的机制和编码关系不大咱们感知的不是很清楚
TCP详细图解 1首部长度 4位首部长度一个TCP报头长度是可变的不是像UDP一样固定8个字节
因此首部长度就描述了TCP报头具有多长另外选项之前的部分是固定长度20字节
首部长度 - 20字节 得到的就是选项部分的长度
20字节表示的就是 源端口号目的端口号序号确定序号窗口大小验证和紧急指针首部长度的大框框
首部长度解释4bit位
注重要提示 首部长度的单位 不是字节 是4字节
举例针对选项和首部长度的联系
如果首部长度值为5 表示整个TCP的报头长度是20字节相当于没有选项
选项首部长度-20字节20-200
如果首部长度值为10表示整个TCP的报头长度是40字节
选项首部长度-20字节40-2020字节
TCP报文TCP报头首部TCP载荷
首部包含了选项及以上 载荷就是数据
2保留位
保留resevered位顾名思义 占个位置起来先不用进行程序开发的时候其中一个重点考虑的事情就是可扩展性。有些功能可能暂时不需要但不代表以后不会再开发。
此处TCP的保留6位也是为了以后的扩展考虑的对于网络协议来说扩展升级是一件成本极高的事情这里以UDP提一下这方面的弊端UDP报文长度是2字节因此一个包最大64kb现在能不能把UDP协议升级一下让UDP能够支持更大的长度比如把报头长度使用4字节表示此情况理论上可以但是修改后的操作系统如何让全世界能够进行更新升级升级设备涉及广泛 计算机、路由器、手机等等都需要不是技术问题而是使用问题很难做到替代当前所有的设备
“保留位”的引入此时升级操作就会成本低不少如果后续TCP引入了一些新的功能就可以使用这些保留位字段
注对于TCP本来的报头结构的影响是比较小的老的设备即使不升级也能兼容
3选项
option选项optional可选的可有可无的此处的选项相当于对这个TCP报文的一些属性进行解释说明的
TCP内部的工作机制
TCP 可靠传输 是怎样做到可靠的
可靠传输不是说一定能把消息发给接收方因为这个可靠跟网线没有关系物理设备都断了那就不可能发过去了
此处是尽可能把数据传输过去同时如果还是传输不过去至少能知道
1、确认应答
提示实现可靠传输的最核心机制 TCP进行可靠性传输最主要就是靠这个确认应答机制
其实简单化就是 A 给 B 发了个消息B收到之后就会返回一个 应答报文ACK此时A收到应答之后就知道了刚才发的数据已经顺利到达B了
更加复杂的情况 很明显此处这里的应答就错乱的表达意思出现歧义
总结网络“后发先至”现象客观存在无法避免因此应答报文到达的顺序也是可能发生变动的。此时就需要考虑如何规避这种顺序错乱带来歧义
如何解决上述“后发先至” 看的出来以上出现问题的原因在于顺序上出错办法很简单给传输的数据和应答报文都进行编号。 引入序号以后此时就不怕顺序乱了及时顺序乱了序号就是最好判断方法
1.1、序号编辑
那序号是怎样编号的当然不是以上编辑的序号不是按照“一条两条”这样的方式来编号的...TCP是面向字节流的TCP的序号也是按照字节编号的 TCP的字节的序号是依次累加的这个依次累加的过程对于后一条数据说起始字节的序号就是上一个数据的最后一个字节的序号每个TCP数据报报头填写的序号只需要写TCP数据的头一个字节的序号即可。
TCP知道了头一个字节的序号再根据TCP报文长度可以知道每个字节的序号确认序号的取值是收到的数据的最后一个字节的序号1 总述 1TCP可靠传输能力最主要就是通过确认应答机制来保证的 2通过应答报文就可以让发送方清楚的知道传输是否成功 3引入了序号和确认序号针对多组数据进行详细的区分 2、超时重传
讨论确认应答的时候只是讨论了顺利传输的情况同样会产生问题丢包
丢包涉及到两种情况
1发的数据丢了
2返回的ACK丢了
发送方看到的结果就是没有收到ACK区分不了是哪种情况都是丢包的情况针对丢包TCP是要处理的因为丢包是一个概率性事件而且通常情况下丢包概率已经很小了重新发一下这个数据报其实还是很大的概率成功传输这里下面在做详细解释
TCP直接引入重传机制
在丢包的时候就要重新再发一次同样的数据到底当前这个传输是丢包了还是ACK走的慢还没有被接收到
此处TCP就直接引入了一个时间阈值发送方发了一个数据之后就会等待ACK此时开始计时。如果在时间阈值之内也没有收到ACK无论是否ACK是在路上还是彻底丢了都视为是丢包了
超时重传超过一定时间还没响应就重新传输
这个超时时间具体是多少ms 这个时间可以配置并且不同系统上面的默认值可能存在差别 以上带有重复数据或者操作关键时候可能会带来重大影响但是针对以上重复数据或者操作带来的影响
TCP对于这种重复数据的传输是有特殊处理去重TCP存在一个“接收缓冲区”这样的存储空间接收方操作系统内核里的一段内存每个TCP的socket对象都有一个接收缓冲区发送缓冲区
主机B 收到的 主机A的数据
其实是B的网卡读取到数据了然后把这个数据放到B的对应的socket的接收缓冲区中此处更像是一个优先级队列根据数据序号TCP很容易识别当前接收缓冲区里的这两条数据是否是重复的
自己本有这个功能如果重复了则把后来的这份数据就直接丢弃了保证了应该程序调用read读取到的数据一定是不重复的
TCP使用这个接收缓冲区对收到的数据进行重新排序使应用程序read到的数据是保证有序的与发送顺序一致
总结由于去重和重新排序机制的存在发送方只要发现ACK没有按时到达就会重传数据即使重复了即使顺序乱了接收方会处理好的
相应问题
超时重传次数重传的数据是否存在再次丢包有可能所以可能会重传N次此处的N不是无限的重传不会一直进行重传几次还没有结果其实也就没有必要了可能此时的网络出现问题了
举例
传输丢包概率假设为5% 第二次传输丢包的概率5%*5%0.25%
第三次还丢包的话可想而知 0.25%*5% 等于的数字是何等的小连续丢包能丢几次呀概率实在太小了所以多次丢包大可能是网络出现问题了因为正常丢包不会太多次
因此重新传输到一定次数的时候就不会再继续重传会认为网络故障接下来TCP会尝试重置连接网络重连如果重置还是失败了彻底断开连接
注超时重传次数可以配置
重传的时候第一次重传和第二次重传超时时间间隔并不一样执行重传时间上不是均匀的一般情况重传的次数越大超时时间间隔就越大因为超时重传次数越多重传成功的概率就越小此时重传的太快也是浪费资源不如多等等总结超时时间变大重传的频率降低
总述
1可靠传输是TCP最核心的部分TCP的可靠传输就是通过 确认应答 超时重传 两者都是具体体现共同支撑整体的TCP可靠性
2其中确认应答描述的是传输顺利的情况
3超时重传描述的是传输出现问题的情况
3、连接管理
连接管理涉及到建立连接和断开连接
那连接Connection又是什么如何做到连接的
以结婚类比大体上结婚还是要有法律认可的结婚手段才是连接法定结婚就是领证领取的结婚证两个人一人一份内容相同但是针对两个人各自关注点不同
男方认为了连接上了就是 这个结婚证上写 我老婆是这个女人
女方认为了连接上了就是 这个结婚证上写 我老公是这个男人
这就是建立连接完成了
TCP 建立连接 断开连接针对实际上来说离婚就是断开连接
此处A和B把自己存储的连接信息数据结构删除连接就是断开了
3.1、三次握手
建立连接三次握手
通信双方各自要记录对方的信息彼此之间要相互认同图解 上面看着也可以叫做“四次握手” 也能叫“三次握手”
只要不合并就可以叫做“四次握手”针对这个就有两个问题
为啥中间这两次要合并不合并可以吗
合并原因是封装分用 每次都要封装分用都是要消耗成本的所以必须合并降低封装分用的成本
再问两次握手行不行
答案针对计算机肯定不行图解 总结三次握手本质上是“四次”交互为了降低封装分用的成本必须进行合并操作通信双方各自要向对方发起一个“建立连接”的请求同时再各自向对方回应一个ACK。
三次握手另外一个重要作用验证通信双方各自的发送能力和接收能力是否正常同时也一定程度的保证了TCP传输的可靠性起到的不是关键作用辅助作用
此处再举一个实例 三次握手的意义
1让通信双方各自建立双方的“认同”
2验证通信双方各自的发送能力和接收能力是否可行
3在握手过程中双方来协商一些重要的参数
以上都是简单以实例表现出出握手以上实例每次的握手是一次通信同时也是一种协议 3.2、四次挥手
四次挥手就是断开连接“挥手”和“握手”都只是形象的叫法都是客户端服务器的数据交互
四次挥手和三次握手非常类似都是通信双方各自向对方发起一个断开连接的请求同时再各自给对方一个回应 以上是举例理解四次挥手 下面详细解析 TIME_WAIT保持连接不断开那能保持多久约定一个时间为 2MSL 如果经历了2MSL时间还是没有收到 重传的FIN 就认为这个ACK就正常到达了认为对方没有重传FIN 2MSL 指的是互联网上两个节点之间数据传输消耗的最大时间约定俗成MSL具体的准数是多少一般情况下是60s秒
针对以上解释对四次挥手可能有点迷离
四次挥手要做的事情这里简短的比喻一下 1A发送 FIN
2B发送ACK
3B发送FIN
4A发送ACK
仅仅以上四次交互构成四次挥手最后一个ACK没有丢包的情况下
4、滑动窗口
TCP依存可靠性所以传输效率就降低了很多比不上UDP无可靠性可靠性和传输效率本身是相互矛盾的TCP也有一些其他方法来补救传输效率但是补救后仍然不及UDP只是为了减少传输效率上针对TCP的影响
滑动窗口的本质就是降低了确认应答等待ACK消耗的时间
缩短渠道批量发送批量等待把多份等待时间合并成了一份 滑动窗口基本理解就是如上图解析但是有数据传输就有可能会丢包以下解释丢包情况 5、流量控制
这是一种干预发送的窗口大小的机制
滑动窗口窗口越大传输效率就越高一份时间等的ACK就越多当然窗口不能是无限大
1完全不等ACK可靠性能否保障画上问号
2窗口太大也会消耗大量的系统资源
3发送速度太快接收方处理不过来发了也白发
接收方的处理能力就是一个很重要的约束依据发送方法的速度不能超出接收方的处理能力
流量控制要做的工作就是这个根据接收方的处理能力协调发送方的发送速度
那既然接收方的处理能决定发送的速度如何探测接收处理能力
直接看接收方接收缓冲区的剩余大小 6、拥塞控制
流量控制和拥塞控制共同决定发送方的窗口大小是多少
流量控制针对的是接收方的处理能力
拥塞控制描述传输过程中的中间节点的处理能力
发送方按照滑动窗口的方式发送此时“窗口大小”描述了发送速率 拥塞窗口和流量控制的窗口共同决定了发送方实际的发送窗口拥塞窗口和流量控制窗口的较小值
7、延时应答
同样也是提升效率的机制也是在滑动窗口的基础之上
滑动窗口的关键让窗口大小在有限的范围之内扩大一点传输速度就快一点
因此要做的是在接收方能够处理的前提下尽可能的把把窗口大小放大一点
延时收到数据之后不是立即返回ACK 而是稍微等会再返回
等待的时间里接收方的应用程序将接受缓冲区的数据给消费一下此时剩余的空间会更大 8、捎带应答
也是提高效率的方式在延时应答的基础上引入的捎带应答
服务器客户端程序最典型的模型就是“一回一答” 此处举例解释捎带应答 9、面向字节流
面向字节流 引入问题粘包问题 重点针对解决方法
1约定好分隔符
2约定每个包的长度
两个任选其中一个就可以了
10、异常情况
异常情况不可抗拒因素
(1)进程关闭的情况
1进程崩溃了
进程没了对应的PCB就没了对应的文件描述符表就释放了相当于socket.close()
此时内核会继续完成四次挥手此时其实仍然是一个正常断开的流程
2主机关机按照正常流程关机
主机正常关机要先杀进程然后才正式关机杀死进程的过程中也就是和上面一样触发四次挥手
2进程来不及关闭
1主机掉电
2网络断开
假设是接收方掉电了断网
显然是来不及挥手发送方仍然在继续发数据发完数据要等待ACK都断电了ACK是真的等不到了超时重传再怎么重传也收不到ACK重传几次还没有应答尝试重置TCP连接显然这个重置也会失败最终面临的就是放弃连接
假设是发送方掉电了断网
接收方发现没数据了没数据是发送方挂了还是发送方要组织下语言稍等会再发
接收方不知道现在发送方的特殊情况 那先等
接收方需要周期性的给发送方发送一个消息确认下对方是否还工作正常
周期性发送消息心跳包确认通信双方是处在正常的工作状态
1心跳是周期性的
2如果心跳结束那就是没了
