TCP协议是互联网中广泛使用的传输层协议之一，用于可靠地传输数据。其中，滑动窗口是TCP协议中用于控制流量和实现可靠传输的重要机制。本文将介绍TCP协议中滑动窗口的原理，并解释滑动窗口如何控制流量的机制。
"停止-等待" 协议 弊端 : 信道利用率低 , 发送完一帧后等待 , 这个时候信道完全是空闲的 ;
发送方 发送数据 速率高 , 接收方 接收数据 能力差 , 造成传输出错 , 数据链路层 的 负责进行流量控制的工作 ;
昨天我们简单说了这个 HTTP 和 HTTPS 为什么说简单呢？因为就是基础的 HTTP 的协议的讲解以及 HTTPS 的安全性等，这就有读者说，为什么不说点进阶的内容呢。
滑动窗口在计算机科学领域中我认为有两层概念，一种是计算机网络中的滑动窗口协议，另一种则是滑动窗口算法,他们在计算机科学领域都有非常广泛的应用，接下来我将用一篇文章来讲述滑动窗口协议和滑动窗口算法在计算机网络和软件编程领域的应用场景和原理，开始表演~
在面向帧的自动重传请求系统中，当待确认帧的数量增加时，有可能超出缓冲存储空间而造成过载。
注：最后有面试挑战，看看自己掌握了吗 文章目录 链路层 流量控制 和传输层的流量控制区别 停止-等待协议 为什么要有停止等待协议 无差错情况 滑动窗口协议 后退N帧协议GBN 选择重传协议SR 可靠传输 流量控制 🍃博主昵称：一拳必胜客 特别鸣谢：木芯工作室 、Ivan from Russia ---- 链路层 流量控制 较高发送速度和较低接受能力的不匹配 流量控制也是数据链路层的一项重要工作 和传输层的流量控制区别 传输层—端到端流量控制-------接收端发送给一个窗口公告 链路层-----
写这篇文章前，我有些肺腑之言想感谢一下我的微信好友“风大”。 是他给了我信心，原来没有很难的技术，只要你肯努力总能赶上其他人。 后来关注他的博客后，发现他尽然觉得弄懂hashmap的 最好办法是自己实现一个hashmap。一开始我也是不懂为什么要这样，后来发现读懂hashmap之后，再自己实现的时候，刚好可以读懂hashmap中那些设计巧妙的地方，发现自己与大师的差距。最后我也总结了一个学习方法： 先弄懂一个技术怎么样，再考虑如果是自己去设计会是什么样子，一开始就算是抄，抄多了你就会自己写了。 之前写过一个springMVC的小轮子，后来看spring事务机制的时候 ，又写了一个TransactionManage。 这些东西就像高冷的美女，只有你征服她时，你才能感受到她平凡而又不普通的一面。
写这篇文章前，我有些肺腑之言想感谢一下我的微信好友“风大”。 是他给了我信心，原来没有很难的技术，只要你肯努力总能赶上其他人。 后来关注他的博客后，发现他尽然觉得弄懂hashmap的 最好办法是自己实现一个hashmap。一开始我也是不懂为什么要这样，后来发现读懂hashmap之后，再自己实现的时候，刚好可以读懂hashmap中那些设计巧妙的地方，发现自己与大师的差距。最后我也总结了一个学习方法： 先弄懂一个技术怎么样，再考虑如果是自己去设计会是什么样子，一开始就算是抄，抄多了你就会自己写了
Internet - TCP 的封包格式：TCP 为什么要粘包和拆包？ 中提到了 TCP 利用发送字节数和接收字节数，这个二元组的唯一性保证顺序。
笔者最早接触滑动窗口是滑动窗口协议，滑动窗口协议（Sliding Window Protocol），属于 TCP 协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。发送方和接收方分别有一个窗口大小 w1 和 w2。窗口大小可能会根据网络流量的变化而有所不同，但是在更简单的实现中它们是固定的。窗口大小必须大于零才能进行任何操作。
上一篇文章中，我们看到了如何通过 wireshark 排查 TCP 重复 ACK 特别是由此引发的快速重发问题：
流量控制涉及对链路上帧的发送速率的控制，以使接收方有足够的缓冲空间来接受每一个帧。例如，在面向帧的自动重传请求系统中，当待确认帧的数量增加时，有可能超出缓冲存储空间而造成过载。流量控制的基本方法是由接收方控制发送方发送数据的速率，常见的方式有两种：停止-等待协议和滑动窗口协议。
滑动窗口协议（Sliding Window Protocol），属于TCP协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。
我们知道tcp协议是可靠传输的协议，而tcp的可靠传输与滑动窗口协议密不可分，那么今天罗师傅就和大家一起探讨一下tcp的滑动窗口，tcp的滑动窗口到底是怎么回事？
我们刷leetcode的时候，经常会遇到滑动窗口类型题目。滑动窗口问题非常经典，也很有技巧性，一般大厂也喜欢问。今天跟大家一起来学习滑动窗口的套路，文章如果有不正确的地方，欢迎大家指出哈，感谢感谢~
ISO（国际标准化组织）曾提出一个 OSI 七层模型。将网络的协议划分为 7 个层，从低到高排序是：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。但是这个模型仅停留在理论阶段。因为该模型过于庞大、复杂，以至于无法被广泛应用。
在谈RST攻击前，必须先了解TCP：如何通过三次握手建立TCP连接、四次握手怎样把全双工的连接关闭掉、滑动窗口是怎么传输数据的、TCP的flag标志位里RST在哪些情况下出现。下面我会画一些尽量简化的图来表达清楚上述几点，之后再了解下RST攻击是怎么回事。
在这个图中，我们将字节从 1至11进行标号。接收方通告的窗口称为提出的窗口（ o ff e r e d w i n d o w），它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第 3字节在内的数据，且通告窗口大小为 6。回顾第1 7章，我们知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。
HTTP协议 如何区分无状态协议和状态协议 判断的依据是否存在客户端信息 无状态协议(不保存)：UDP、Http 有状态协议（保持）：TCP、FTP Http协议状态码 示网页服务器HTTP响应状态的3位数字代码 2xx:表示请求成功 3xx:重定向 4xx:请求出错 5xx:服务器故障 短连接和长连接 长连接：数据过程中，保持TCP连接不断开。等待在同域名下继续用这个 通道传输数据。 短连接： 浏览器和服务器每进行一次 HTTP 操作，就建立一次连接，任 务结束就中断连接。 http1.1默认使用长连
今天我们来总结学习一下TCP发送报文的相关知识，主要包括发送报文的步骤，MSS，滑动窗口和Nagle算法。
TCP作为一个传输层协议，最核心的能力是传输。传输需要保证可靠性，还需要控制流速，这两个核心能力均由滑动窗口提供。
传输层协议提供逻辑通信服务 传输层协议只需在端系统中实现 通信的真正断电并不是主机，而是主机中运行的应用进程
帧协议 ( GBN ) 弊端 : 累计确认 机制 , 导致的批量重传 , 这些重传的帧 , 可能已经传输成功 , 就是因为之前的帧出错 , 导致传输成功的帧被丢弃 ;
我们都知道tcp的传输是可靠的，那么你知道tcp是如何实现数据的可靠传输的吗？今天就和大家一起探讨一下tcp是如何实现数据可靠传输的。
前些日子，在分享网络编程知识文章的时候，有个网友私信给我留言了一条“能不能写一篇关于 TCP 滑动窗口原理的文章”。
运输层向上层【应用层】提供端到端的逻辑通信服务，即应用到应用的通信服务。只有两个主机之间的协议栈才会有传输层，网络核心部分中只用到下面的三层【网络层，数据链路层，物理层】
TCP协议作为一个可靠的面向流的传输协议，其可靠性是由流量控制和滑动窗口协议保证。
当发送者向接收者发包后，如果过了一段时间(超时时间)依然没有收到消息，就当做本次包丢失，需要重新补发。
对于接收端：当收到数据帧后，将窗口向前移动一个位置，并发回确认帧，若收到的数据帧落在接收窗口之外，则一律丢弃。
想象一下这个场景：主机 A 一直向主机 B 发送数据，不考虑主机 B 的接收能力，则可能导致主机 B 的接收缓冲区满了而无法再接收数据，从而导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机 B 的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。
可靠数据传输对于应用层、传输层、链路层都很重要，是网络领域的Top10问题。 对于传输层来说，由于相邻的网络层是不可靠的，所以要在传输层实现可靠数据传输（rdt）就比较复杂。 那么我们来了，究竟怎样才是可靠？
互联网发展至今已经高度发达，而对于互联网应用（尤其即时通讯技术这一块）的开发者来说，网络编程是基础中的基础，只有更好地理解相关基础知识，对于应用层的开发才能做到游刃有余。
1、计数器算法 计数器算法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开 始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter，具体算法的示意图如下：
滑动窗口，收到前面的确认消息，滑动窗口向前移动，把滑动窗口内的未发送消息发送出去：
为了使传输层提供可靠的数据传输服务，基于不可靠信道实现可靠数据传输需要采取以下措施：
发送窗口大于1，接收窗口等于1。出错时重传帧数多，适用于信道质量好，出错率少的情况。
我记得之前在群里看到，有位读者字节一面的时候被问到：「如何基于 UDP 协议实现可靠传输？」
最近有个朋友的APP需要在国外搭建一个直播服务器，因为他们的主播在韩国(主播主要是记者)，而观众主要在国内，叫我帮忙给他们开发一个直播服务器。
学习 TCP 协议，首先第一个要了解当然是 TCP 连接是如何建立的，下面给大家介绍一下三次握手和四次挥手的过程以及为什么要这样设计。
随着Http协议发展的20年间，从物理带宽、CPU、内存，到软件都有了很大的提升，而原来的协议也具有了很大的局限性：
这篇文章的内容写于2016年左右，最近在整理材料时翻出来，还是能感觉到当时对于性能测试的热爱，现在都好久没做性能测试了。来看看当年的个人是如何定位问题的吧，也许对于现在做性能测试的同学能带来一些启示。
滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。
说道TCP滑动窗口协议，相信大家都很熟悉，但是说道 Window Scaling参数或许知道的和用过的人却不多，本文我们来谈谈Window Scaling的由来
tcp作为四层中可靠到传输协议，为上层协议提供了字节流的可靠到传输，之所以能做到可靠主要因为以下几点：
本文是接着上篇 画图带你理清TCP协议三次握手和四次挥手 继续带你学习TCP 其他 7 大特性。
AIMD ：Additive Increase Multiplicative Decrease 加性增，乘性减
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
