分栏型网站,wordpress发消息,永久免费建个人主页,蛋糕网站建设方案目录
一、TCP协议段格式
二、确认应答
三、超时重传 TCP全称为#xff1a;传输控制协议 Transmission Control Protocol)。协议如其名#xff0c;要对数据的传输进行一个详细的控制。
一、TCP协议段格式 源 / 目的端口号#xff1a;表示数据从哪个进程来传输控制协议 Transmission Control Protocol)。协议如其名要对数据的传输进行一个详细的控制。
一、TCP协议段格式 源 / 目的端口号表示数据从哪个进程来到哪个进程去。 32位序号 / 32位确认序号后面详细讲。 4位TCP报头长度表示该TCP头部有多少个32位bit(有多少个四字节) 注意4个bit位1111 》15此处这里的单位是4字节而不是字节。所以TCP头部最大长度为15 * 4 60 保留(6位)TCP 在设定报头的时候会提前准备几个 保留位现在虽然用不到但是可以先占个位置后面一旦需要用了咱们就会把这些保留位给使用起来。后续一旦需要扩展功能使用保留位就可以实现就可以避免 TCP 的扩展引起不兼容的问题。而UDP协议长度受到 2 个字节的限制想要进行扩展发现扩展不了一旦改变这里的报头长度就会使机器发送的UDP数据报和其他机器不兼容无擦通信 6位标志位(TCP的核心部分后面也会讲到) URG紧急指针是否有效 ACK确认号是否有效 PSH提示接收端应用程序立刻从TCP缓冲区把数据读走; RST对方要求重新建立连接我们把携带RST标识的称为复位报文段 SYN请求建立连接我们把携带SYN标识的称为同步报文段 FIN通知对方本端要关闭了我们称携带FIN标识的为结束报文段 16位窗口大小后面再说。 16位校验和类似于UDP校验和但是把报头和数据载荷放在一起计算校验和.、。 16位紧急指针标识哪部分数据是紧急数据。 选项TCP 报头中的前20个字节是固定长度的后面这里包含了 “选项”optional部分“可选的” / “可有可无的”选项部分可以有也可以没有可以有一个也可以有多个。 二、确认应答 我们知道TCP协议具有可靠传输的特点而这一特点也是 TCP 安身立命的本钱初心就是解决 “可靠传输” 问题。 而网络通信过程中很复杂无法确保发送方发出去的数据100% 能够到达接收方此处的“可靠性”也只能 “退而求其次”。只要尽可能的去进行发送了发送方能够知道对方是否收到就人为是 可靠传输 了。 用来确保可靠性最核心的机制称为 “确认应答”。 在网络中发送数据可能会出现 “后发先至”的情况为什么呢一个数据包从发送方到接收方传输过程中走的路径可能不一样。第一个数据包走路线一第二个数据包走路线二有可能路线二非常畅通路线一堵车了就导致第二个数据报虽然发的迟但是能先到这就是后发先至的情况。 解决方案引入了序号和确认序号对于数据进行编号应答报文里就告诉发送方说我这次应答的是哪个数据。给第一个数据包进行编号1序号第二个数据包进行编号2序号接收方收到一条数据就进行确认序号如果确认序号为1和序号1匹配上了就接收数据不会出现后发先至的情况。 真实的 TCP 的情况要更复杂一些TCP 是面向字节流以字节为单位进行传输的描述按一条、两条的概念进行传输。实际上TCP的序号和确认序号都是以字节来进行编号的如图 同时接收方也希望应用程序读到的数据是顺序正确的顺序不对对于接收方应用程序的逻辑肯定也会有一些影响所以会有一个接收缓冲器可以认为是一个 “优先级队列”作为优先级的参考。 在TCP报头中报头里的序号只能存一个假设载荷有 1000 个字节就有 1000 个序号由于序号是连续的只需要在报头中保存第一个字节序号即可后续字节的序号都是很容易计算得到的。 确保TCP可靠性的最核心机制TCP的确认应答 确认应答中通过应答报文来反馈给发送方表示当前的数据正确收到了应答报文也叫ack报文acknowledge的缩写 三、超时重传
——确认应答的补充 发送数据的时候如果一切顺利通过应答报文就可以告诉发送方当前数据是不是收到了。但是网络可能存在 “丢包” 的情况如果数据包丢了没有到达对方那对方自然也没 ack 报文了这个情况下就需要 超时重传 TCP可靠性就是在对抗丢包期望在丢包客观存在的背景下也能够尽可能的传过去。 为啥会出现 “丢包” 的情况这个网络的 路由器 / 交换机不仅仅是给你这一次通信提供服务的还要能支持千千万万的主机之间的同期在整个网络中就可能某个 路由器 / 交换机 在某个时刻突然负载量很高短时间内可能有大量的数据包要经过这个设备转发但是要知道一台设备能够处理的数据是有限的很可能瞬间的高负载超出了这个设备能转发的数据量的极限此时多出来的部分就无了就被设备 “丢包” 了丢包情况客观存在啥时候会丢包难以预测。 超时重传就要解决丢包的问题情景如下发送方发了个数据之后要等等的时间里收到ack报文数据报在网络上传输需要时间如果等好久ack还没等到此时发送发就认为数据的传输出现丢包了当认为丢包之后就会把刚才的数据包再传输一次重传等待的过程有一个时间的阈值上限就是 超时。 如上图主机A发送数据给主机B在规定时间内B没有收到数据也就不会发送ack报文给主机A这时主机A 就会重新发送数据给 主机B。 上面的过程中是认为没有收到 ack报文 就是丢包其实这样的结论是有点小问题的丢包不一定是发的数据丢了也可能是 ack报文 丢了。数据丢了还是 ack 丢了从发送方角度来看就区分不了但都是发送方没接收到 ack。 上图是 ack报文 丢了但数据是实实在在的传输到主机B了但这种情况还要进行重传吗答案肯定是不行的试想一下发送的请求如果是扣款请求呢那这样就扣了双份的钱这就不符合逻辑的问题也很严重。 所以如上图所示数据传过来还要返回给主机A确认应答只要接收方没有收到 ack就会把发送过来的数据丢包然后主机A 再次发送数据给主机B知道主机B确认应答发送ack给主机A了。 那接收方如何判断接收到的数据是重复的呢 TCP socket 在内核中存在接收缓冲区一块内存空间发送方发来的数据是要先放到接收缓冲区中的然后应用程序调用 read / scanner.next 才能读到数据。这里的读操作其实是读接收缓冲区。 如图当数据到达接收缓冲区的时候接受方首先会先预判一下看当前缓冲区中是否已经有这个数据了或者这个数据曾经在接收缓冲区中存在过。 如果已经存在或者存在过就会直接把重复发来的数据丢弃掉就能确保应用程序调用 read / scanner.next 的时候不会出现重复数据了。毕竟当前是靠应用程序来进行“扣款” 上面是判断数据是否存在过接收方如何判断数据是否是 “重复数据” ——核心判断依据数据的序号 1、数据还在接受缓冲区里还没被read走此时就拿着新收到的数据的序号和缓冲区里的所有数据的序号对比一下看看有没有一样的有一样的就是有重复了就可以把新收到的数据丢弃了。 2、数据在接收缓冲区中已经被应用程序read走了此时新来的数据序号直接无法再接受缓冲区查找注意应用程序读取数据的时候是按照序号的先后顺序连续读取的。 先读 1~1000 1001~2000 2001~3000 一定是先读序号小的数据后读序号大的数据的可以把接收缓冲区这个队列想象成带有优先级的阻塞队列。 此时 socket api 中就可以记录上次读的最后一个字节序号是多少。比如上次读的最后一个字节的序号是 3000新收到的一个数据包的序号是 1001这个 1001 一定是之前已经读过的了。这个时候同样可以把这个新的数据包判定为 “重复的包” 直接丢弃。 上述谈到的 ack、重传、保证顺序、自动去重都是 TCP 内置的我们使用 TCP 的api 的时候只需调用一个简单的代码outputStream.write() 上述功能就能都自动生效了我们程序员需要操心的就少多了。但如果使用 UDP上述这些问题就都得好好考虑了。
超时重传的时间阈值 超时是会重传重传也不是无限的重传重传的过程也是有一定的策略的如下 1、重传次数是有上限的。重传到一定程度还没有 ack 就尝试重置连接如果重置连接后传输数据还是失败就直接放弃。 2、重传的超时时间阈值也不是固定不变的随着重传次数的增加而增大重传频率越来越低。 经历了重传之后还是丢包大概率是网络出现严重问题了。再怎么重传也是白费劲重传还有啥要重传但是可以省点力气少传两次。
举个例子 假设一次网络通信过程中丢包的概率是 10%这个数字其实已经非常夸张了实际使用网络过程中如果出现这种情况这就是非常严重的故障。 那么顺利到达的概率是 90%进行重传一次的概率10% * 10% 1%两次传输包至少有一次能到达的概率99%随着重传次数的增加包到达对方的概率也会大大增加。 如果这时候连续重传3、4次还丢包只能说明当前丢包的概率太大了远远不止 10%这个时候意味着网络已经出现非常严重的故障了再重传也意义不大所以干脆就让它少传几次省点力气因为路都断了再想从这个路上通过势必就非常难了。 例如直播app直播的延迟网络传输的的过程中就会有丢包现象才有直播延迟这一现象但也因为延迟可以给程序留有更多的 “重传时间”。 都看到这了点个赞再走吧谢谢谢谢谢
