专业微网站电话号码,做软件难吗,ps做 网站标准尺寸,阿坝州网站制作前言
TCP/IP五层协议是互联网中的主流模型#xff0c;为网络通信提供了一个稳固的框架。
主要包含了应用层#xff0c;传输层#xff0c;网络层#xff0c;数据链路层#xff0c;物理层。
本篇主要介绍传输层的TCP协议的核心机制 一. 确认应答#xff08;ack#xf…前言
TCP/IP五层协议是互联网中的主流模型为网络通信提供了一个稳固的框架。
主要包含了应用层传输层网络层数据链路层物理层。
本篇主要介绍传输层的TCP协议的核心机制 一. 确认应答ack
TCP最核心的机制为可靠传输但可靠传输并不是保证100%的成功而是尽可能的使数据能到达对方可靠性的保证有两个重要机制 1.能感知到对方是否接收到数据 2.如果发现对方没有收到就要进行重发 其中通过确认应答机制来感知对方是否收到。
所谓的“感知对方是否收到”是靠对方的通知。
应答报文acknowledge缩写为ack 网络传输中存在着后发先至的情况当发送多个消息时上诉机制可能可能产生问题例如 甲向乙提出两问题乙回答时可能发送后发先至的情况变成了乙不同意一起吃饭却同意做女朋友此时就产生了歧义。
此时可以给传输的数据添加编号通过编号可以区分出数据的先后顺序。 TCP是面向字节流的实际上的编号是按照字节来编号的。
按照字节编号这样的机制就是TCP的序号
在应答报文中针对之前收到的数据进行对应编号称为TCP的确认序号
其中确认序号是接收方收到的数据最后一个字节序号的下一个序号如上图数据最后一个字节序号是1000ack则返回10001也就是1001作为确认序号
确认序号前的数据全部都已经被接收方接收
如果数据在发送过程中发生后发先至后面的数据比前面的数据先一步到达此时接收方read就会进入阻塞等待直到读取到开头发送的数据确报发送方write的顺序和接收方read的顺序相同时才会解除阻塞。 二.超时重传
网络传输中并不是一帆风顺常常会发生丢包情况
产生丢包的原因有多种 1.数据传输过程中发生了bit翻转收到这个数据的接收方计算校验和对不上此时会直接丢弃该数据包。 2.数据传输到某一节点节点负载太高了网络高峰期后续传输过来的数据可能直接被节点丢弃掉 TCP需要通过应答报文来区分数据是否丢包收到应答报文(ack)就说明数据没有丢包没收到应答报文就说明数据丢包了。
丢包是难以预测的TCP再强大也难以完全避免丢包能做的只有在感应到数据丢包时重新发一次
但数据在网络传输是需要消耗时间的“没收到应答报文”可能只是暂时没收到等一会可能就收到了也有可能是确实丢失永远收不到了。
超时重传机制通过设定一个“时间限制”如果在这个时间限制内没有收到ack则视为数据丢包随后重传文件 如果数据成功发送但ack丢包由于发送方无法识别对方有没有收到数据到达限制时间后也会进行重新发送此时接收方又收到了一份相同的数据TCP会进行去重确保不会read到同样的数据。 超时重传的时间不是固定不变的而是动态变化的。
发送方第一次重传超时时间是t1如果仍然没有ack则会进行第二次重传超时时间为t2
通常情况下t2t1,每重传一次超时时间的间隔就会变大反复重传多次后都没有顺利到达TCP不会尝试重传会先进行复位连接发送一个一个特殊的数据包复位报文如果网络这会恢复了复位报文会重置连接使通信可以继续运行如果网络存在严重问题复位报文也没得到回应此时TCP就会单方面放弃连接连接也就无了。
确认应答和超时重传相互补充共同构建了TCP的可靠传输机制 三.连接管理★★★重点
1.建立连接三次握手 三次握手是客户端与服务器建立连接的过程前面提到过连接的实质是双方保存着对方的信息
如上图所示A请求保存B的信息B接收到后返回ACK然好B请求保存A的信息A收到后返回ACK其中syn和ack可以同时发送于是将这两步合并成一步这就是三次握手。 三次握手要解决说什么问题意义所在 1.投石问路初步验证通信链路是否畅通可靠传输的前提条件 2.确认通信双方各自的发送能力与接收能力是否都正常 3.让通信双方在通信前对通信过程中需要用到的一些关键参数进行协商TCP通信时的起始数据序号就是通过三次握手协商确定的 上诉约定的意义在于避免“前朝的剑斩今朝的官”
假如A和B在传输数据时数据包传输的慢突然A和B断开了连接过了一会A和B又重新建立了连接虽然还是A和B两个主机连接但可能是不同的应用程序此时上一个没到达的数据包可能这时才到达A和B已经是新的连接了。
针对这样“迟到”的数据包应当直接丢弃掉。
那么如何区分数据包是否是前朝的
可以给每个连接都协商不同的起始序号如果发现收到的数据和起始序号以及和最近收到的序号差距很大则为“迟到”的数据包 2.断开连接四次挥手
断开连接就是通信双方各种把对端的信息删除掉优雅的
前面介绍“超时重传”时提到单方面释放连接则是没那么优雅的进行断开连接会造成资源浪费 通信双方各种给对方发送“FIN”各自给对方返回“ACK”
三次握手的三次是因为中间的syn与ack进行了合并
对于四次挥手来说中间ACK和FIN不一定能够合并。
原因是四次挥手ACK是内核控制的但FIN的触发则是通过应用程序调用close
这中间存在着时间间隔
3.TCP的状态 1LISTEN状态
服务器进入的状态表示已经绑定好端口服务器初始化完毕准备连接客户端
2ESTABLISHED
客户端和服务器都保存好了对方的信息可以传输后续数据业务三次握手后
3CLOSE_WAIT
被动断开连接的一方进入的状态等待代码执行close方法
如果发现服务器端存在大量CLOSE_WAIT状态的TCP连接说明服务器代码可能存在问题应检查代码是否有close操作
4TIME_WAIT
主动断开连接的一方进入的状态此处的TIME_WAIT按照时间等待达到一定时间后连接也就释放了。
为何不直接释放连接而是要等待一段时间 TCP在传输的过程中任何一个数据都有可能丢包
此处的等待就是以防最后一个ACK丢包如果最后一个ACK丢包则会重传FIN 能够重发一次ACK的前提是A这边的连接不能释放如果释放就无法返回数据
保留一段时间没有收到重传的FIN则说明刚才的ACK应该是收到了就可以释放连接
TIME_WAIT持续时间通常为2MSL
四.滑动窗口
1.概述
提起滑动窗口学过算法的同学应该知道算法思想中也有滑动窗口其实算法中的“滑动窗口”正是借鉴自TCP的滑动窗口
为什么TCP要滑动窗口 TCP希望能在可靠传输的基础上也能有不错的效率为此引入滑动窗口。
此处的提高效率只是“亡羊补牢”使传输的效率损失尽可能降低效率低于UDP 按照以上方式无滑动窗口A每次发送一个数据给B都得等待B的ack才能发下一个这种方式的低效的。
改进方案则是把“发一个等一个”改成“发送一批等待一批”把多次等待ack的时间合并成一次这样等待的时间少了效率也就提高了。
批量发送的数据越多效率越高此时把批量发送数据且不需要等待的数据的量称为窗口大小。 以下图为例主机A批量发送数据包后当收到第一个ack后就会立即发送下一条数据窗口向右移动 2.丢包问题
情况一
数据包抵达ACK丢包如图 此时不需要做任何处理批量发数据ACK丢失也只是丢失其中的一部分不可能全丢了
通过确认序号可以判定前面的数据都收到了接下来要发送的数据就从确认序号这里往后发
情况二
发送方数据丢包 如图确认序号会在收到后面的数据包时反复返回丢失段数据包的序号提醒发送方进行重发发送方识别出哪个数据包丢失后针对这个数据包进行重传其他顺利到达的数据包无需重传这就是“快速重传”
快速重传可以视为滑动窗口下搭配的超时重传。 五.流量控制
滑动窗口窗口的大小对于传输数据的性能是直接相关的
窗口的大小不能无限的大通信是双方的事情发送方发送的快了也得确保接收方能够处理的来。
发送方与接收方之间有着一个接收缓冲区用于存放发送方发送的数据本质为阻塞队列
如果发送速度特别快接收方处理接收速度比较慢就会使接收缓冲区充满此时发送方强行发送数据则会丢包这就需要让接收方的处理能力反向制约发送方的发送速度。 可以通过“定量”的方式来实现制约 如果空闲空间越大则可以认为应用程序处理速度比较快就可以让发送方发送的快一些设置一个更大的窗口大小。
如果空闲空间小则可以认为应用程序处理速度比较慢就可以让发送方发送的慢一些设置一个更小的窗口大小shu
TCP接收方接收到数据的时候就会把接收缓冲区剩余空间大小通过ACK数据包反馈给对方例如 流量控制并不是TCP独有的机制其他的协议可能也会涉及流量控制 六.拥塞控制
拥塞控制与流量控制是有关联的也是“踩刹车”
虽然TCP有了滑动窗⼝这个⼤杀器,能够⾼效可靠的发送⼤量的数据.但是如果在刚开始阶段就发送⼤量的数据,仍然可能引发问题。
因为⽹络上有很多的计算机,可能当前的⽹络状态就已经⽐较拥堵.在不清楚当前⽹络状态下,贸然发送⼤量的数据,是很有可能引起雪上加霜的。
如下图有一个节点本身负载已经很高如果A依旧快速发送数据包这个节点可能就直接丢包了 但由于中间节点数量多每次传输数据走的路径还不一样哪一个节点负载高难以精确的发现
那么要怎么衡量节点的负载来控制发送速度
拥塞控制中把中间传输的节点视为一个整体不关注具体的实现细节。
通过做实验的方式找到一个合适的发送速度面多加水水多加面 例如1.先按照一个比较小的速度发送数据数据非常畅通没有丢包说明网络传输数据整体比较畅通就可以加快发送速度 2.增大到一定的速度后发现丢包了说明网络上可能存在拥塞就减慢发送速度 3.减速到一定速度后发现不丢包了则又开始增加数据发送速度 ........ 如此反复 拥塞控制的窗口是动态变化的需根据实际情况来调整 拥塞控制和流量控制都是踩刹车这两个机制会同时起作用最终实际发送发送窗口的大小取决于上述两个机制得到的方式窗口的较小值。
流量控制与拥塞控制都是对TCP可靠传输的补充 七.延时应答
延时应答的目的是为了提高效率尽可能降低可靠传输带来的性能影响。
发送方发送数据时接收接收后不着急马上返回ack而是数据发送一定数量或可以按照一定时间后再返回ack。 八.捎带应答
捎带应答是再延时应答的基础上提高效率的机制
把返回的业务数据和ack合二为一减少包的数量提高效率。
正常情况下发送方和接收方数据发送为“一问一答”ack和发送数据业务之间存在着时间间隔无法合并。
但是ack有着延时应答可以将ack发送的时间往后拖这一拖可能赶上发送数据业务的时间于是发送数据业务时可以把ack也一起带上。 四次挥手中FIN和ACK无法合并也是因为两个数据包之间存在着时间间隔。
但如果此时触发延时应答ACK等待FIN发送时捎带发送那么四次挥手也能够变成三次挥手 九.面向字节流
TCP协议传输时是通过字节流传输的前文已经介绍过这里主要介绍面向字节流所产生的粘包问题。
什么是粘包问题 以图为例当A向主机发送数据时数据到达接收缓冲区
当应用程序读取接收缓冲区时有各种读法如aaabbbccc等但“aaa”“bbb”“ccc”才是正确的读法如不为这样的读法应用程序读取的数据包与原数据包有所偏差会产生不同的结果。
粘包问题就是应用层数据包在TCP缓冲区中连城一片粘在一起。
应如何解决粘包问题
方案一
关键在于明确每个数据包的边界可通过分隔符来区分包和包的边界。
方案二 约定每个应用层数据包的长度利用数据包开头的两个/四个字节来定义长度 十.异常处理
在遇到一些异常情况时TCP协议有着解决问题的方案
1进程崩溃
在Java中表现为抛出异常但没人catch最终异常到了JVM里进程直接崩溃
在这过程中操作系统会进行善后会关闭文件描述表里对应的文件socket文件也会触发正常的关闭流程四次挥手
2主机关机正常流程
操作系统会关闭掉所有的进程关闭的过程中同样会进行四次挥手。
此时有两种情况
a当四次挥手快时四次挥手结束后主机关机
b当四次挥手慢时可能每来得及挥完就关机了如图 此时B应没收到ACK就会触发超时重传可能会重传很多次但达到上限后只能单方面主动放弃连接 3主机掉电拔电源
分为两种情况
a发送方掉电 此时B会发送探测报文若A有ACK说明A没有掉。
如果多次发送探测报文没有回复则认为A掉了
探测报文是周期性发送的同时这个报文也是探测对方“生死”的也被称为“心跳包” b接收方掉电 此时B就不会发送ACK给A了A会触发超时重传重传的数据也没有响应多次后会重置连接重置连接没有响应后A会单方面断开连接 4网线断开
和主机掉电非常相似 站在A的视角ACK收不到超时重传重置连接最后单方面放弃连接
站在B的视角探测报文没有回复最后单方面放弃连接 TCP不只有10个机制本篇只是提到较为核心的机制
以上便是全部内容如有不对欢迎指正
