在谈RST攻击前，必须先了解TCP：如何通过三次握手建立TCP连接、四次握手怎样把全双工的连接关闭掉、滑动窗口是怎么传输数据的、TCP的flag标志位里RST在哪些情况下出现。下面我会画一些尽量简化的图来表达清楚上述几点，之后再了解下RST攻击是怎么回事。
此前的文章中，我们介绍了 tcp 协议的基本概念和连接的建立与终止 最后，我们介绍了“经受时延的确认”，这是一种将 ACK 包与下一条数据包合并发送的策略，这样可以尽量减少发往网络的报文，以提高传输的效率，节省网络资源。 除此之外，TCP 还有很多其他算法和策略用来优化网络的使用。
本篇基于TCP确认应答机制基础上，对TCP传输效率作一个提高优化。也就是新增了流量控制和拥塞控制，下面博主将详细总结TCP的滑动窗口机制。
Internet - TCP 的封包格式：TCP 为什么要粘包和拆包？ 中提到了 TCP 利用发送字节数和接收字节数，这个二元组的唯一性保证顺序。
在我们当初学习网络编程的时候，都接触过TCP，在TCP中，对于数据传输有各种策略，比如滑动窗口、拥塞窗口机制，又比如慢启动、快速恢复、拥塞避免等。通过本文，我们将了解滑动窗口在TCP中是如何使用的。
说道TCP滑动窗口协议，相信大家都很熟悉，但是说道 Window Scaling参数或许知道的和用过的人却不多，本文我们来谈谈Window Scaling的由来
滑动窗口实现了TCP流控制。首先明确滑动窗口的范畴：TCP是双工的协议，会话的双方都可以同时接收和发送数据。TCP会话的双方都各自维护一个发送窗口和一个接收窗口。各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的发送窗口则要求取决于对端通告的接收窗口，要求相同。
想象一下这个场景：主机 A 一直向主机 B 发送数据，不考虑主机 B 的接收能力，则可能导致主机 B 的接收缓冲区满了而无法再接收数据，从而导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机 B 的接收缓冲区情况仍未好转，则会将大量的时间浪费在重传数据上，降低传送数据的效率。
TCP/IP协议是非常重要的一个知识点，也一直是面试的高频题，当面试官问你，能说说TCP协议是怎么保证可靠传输的吗，你能回答上吗？
上一篇文章中，我们看到了如何通过 wireshark 排查 TCP 重复 ACK 特别是由此引发的快速重发问题：
3）4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节），所以TCP头部最大长度是15*4=60。
对于接收端：当收到数据帧后，将窗口向前移动一个位置，并发回确认帧，若收到的数据帧落在接收窗口之外，则一律丢弃。
小到基于应用层做网络开发，大到生活中无处不在的网络。我们在享受这个便利的时候，没有人会关心它如此牢固的底层基石是如何搭建的。而这些基石中很重要的一环就是tcp协议。翻看一下“三次握手”和“四次挥手”，本以为这就是tcp了，其实不然。它仅仅解决了连接和关闭的问题，传输的问题才是tcp协议更重要，更难，更复杂的问题。回头看tcp协议的原理，会发现它为了承诺上层数据传输的“可靠”，不知要应对多少网络中复杂多变的情况。简单直白列举一下：
说到TCP流量控制和拥塞控制，不得不说一下滑动窗口，TCP流量控制和拥塞控制主要是由滑动窗口来实现的，首先什么是滑动窗口
前些日子，在分享网络编程知识文章的时候，有个网友私信给我留言了一条“能不能写一篇关于 TCP 滑动窗口原理的文章”。
最主要的功能：传输比特流。利用传输介质为数据链路层提供物理连接，实现比特流的传输。让上一层的数据链路层传送数据是尽可能屏蔽掉传输介质和物理设备的差异。
在上一篇TCP 滑动窗口原理解析文章中，我们对 TCP 的滑动窗口原理进行一次总结，也提到了流量控制和拥塞控制。
本文介绍一下Window Scaling的概念，以及配套的例子运用。转载请标明出处~~
本文是接着上篇 画图带你理清TCP协议三次握手和四次挥手 继续带你学习TCP 其他 7 大特性。
TCP协议是互联网中广泛使用的传输层协议之一，用于可靠地传输数据。其中，滑动窗口是TCP协议中用于控制流量和实现可靠传输的重要机制。本文将介绍TCP协议中滑动窗口的原理，并解释滑动窗口如何控制流量的机制。
笔者最早接触滑动窗口是滑动窗口协议，滑动窗口协议（Sliding Window Protocol），属于 TCP 协议的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。发送方和接收方分别有一个窗口大小 w1 和 w2。窗口大小可能会根据网络流量的变化而有所不同，但是在更简单的实现中它们是固定的。窗口大小必须大于零才能进行任何操作。
上一篇记录了TCP三次握手四次挥手的细节以及为什么会在TIME_WAIT状态停留时间为2MSL。
我们都知道TCP是可靠的协议，而可靠性很多时候就是来自于TCP的确认重传机制，在确认重传的基础上，就实现了滑动窗口协议，滑动窗口主要有两个作用：
很早之前写了这篇文章：你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗？看完图解就不愁了
传输层协议提供逻辑通信服务 传输层协议只需在端系统中实现 通信的真正断电并不是主机，而是主机中运行的应用进程
本节内容有点多，不过关于 TCP 的话，除了三四次握手就是可靠传输了，高频重点知识点，大家还是搞清楚比较好。
1. 在网络通信中，通信的本质实际就是两台主机上的进程在网络环境中进行通信，也就是数据的传输，而我们总说TCP/IP协议栈，这两个协议分别解决了两个重要的问题，即一台主机如何在网络环境中标定自己的唯一性，一台主机中的某个进程如何在主机内部标定自己的唯一性，实际就是通过网络层协议IP地址和传输层协议端口号port来解决这两个问题的。
昨天我们简单说了这个 HTTP 和 HTTPS 为什么说简单呢？因为就是基础的 HTTP 的协议的讲解以及 HTTPS 的安全性等，这就有读者说，为什么不说点进阶的内容呢。
滑动窗口本质上是描述接受方的TCP数据报缓冲区大小的数据，发送方根据这个数据来计算自己最多能发送多长的数据。如果发送方收到接受方的窗口大小为0的TCP数据报，那么发送方将停止发送数据，等到接受方发送窗口大小不为0的数据报的到来。 关于滑动窗口协议，还有三个术语，分别是： 窗口合拢：当窗口从左边向右边靠近的时候，这种现象发生在数据被发送和确认的时候。 窗口张开：当窗口的右边沿向右边移动的时候，这种现象发生在接受端处理了数据以后。 窗口收缩：当窗口的右边沿向左边移动的时候，这种现象不常发生。
滑动窗口协议 还可以看我的另一篇博客，有更详细的介绍：http://www.cnblogs.com/xcywt/p/8401523.html 属于TCP协议中的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。 该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发送一个分组就停下来等待确认，所以该协议可以加速数据的传输，提高网络吞吐量。 TCP利用一个滑动的窗口来告诉发送端对它所发送的数据能够提供多大的缓冲区，由16位定义，最大为65535个字节。 滑动窗口本质上是描述接收方的
在 TCP 中，当发送端的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。
窗口是操作系统开辟的一块缓存空间，发送方在收到接收方ACK应答之前，必须在缓冲区保留已发送的数据，如果按期收到确认应答，数据就可以从缓冲区移除。
SYN同步报文段，尝试和对方建立连接，JavaSocket API中，客户端new Socket内核就会发起这样的SYN请求 SYN这个标志位为1，表示是一个同步报文段 我能听见（ACK），你能听见我吗（SYN） 建立连接的过程，相当于通信双方各自给对方发送SYN，再各自给对方发送ACK中间的ACK和SYN和二为一，于是最后就是“三次握手”
TCP(Transmission Control Protocol 传输控制协议)是一种基于IP的传输层协议，TCP协议面向连接、正面确认与重传、缓冲机制、流量控制、差错控制、拥塞控制，可保证高可靠性(数据无丢失、数据无失序、数据无错误、数据无重复到达)传输层协议。
这个过程其实可以完美的解释三次握手的机制。我们知道，网络环境总是不安全的，只有至少经过这三次交互才能确认两方的发送和接受能力都没问题。我们来看一下这几步分别确定了什么：
当服务器的并发TCP连接数以十万计时，我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存，linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用，但这些配置看名字却有些互相冲突、概念模糊的感觉，如下（sysctl -a命令可以查看这些配置）： net.ipv4.tcp_rmem = 8192 87380 16777216 net.ipv4.tcp_wmem = 8192 65536
当服务器的并发TCP连接数以十万计时，我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存，linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用，但这些配置看名字却有些互相冲突、概念模糊的感觉，如下（sysctl -a命令可以查看这些配置）：
在之前的TCP中，没有使用滑动窗口，就要等待N次应答时间和N次传播时间，这两个时间加起来才是总的传输时间，这样的效率一定是很低的。也就是之前我们讨论了确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段. 这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候
原文:https://blog.csdn.net/qq_50156012/article/details/123391854
背景：假设我是一个水果店老板，你是每天需要给我补货的人，我有一个仓库是放水果的，容量是3000，这是补货的人给我发的货数量就不能大于我仓库的容量，如果今天来补了3000，假设我第二天一箱都没卖出去，那么我就需要告诉你暂停发货了，等我卖出去了，仓库能有点空闲的位置的时候，你再来补货。
前一篇「硬不硬你说了算！近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可，在此特别感谢你们的认可，大家都暖暖的。
运输层向上层【应用层】提供端到端的逻辑通信服务，即应用到应用的通信服务。只有两个主机之间的协议栈才会有传输层，网络核心部分中只用到下面的三层【网络层，数据链路层，物理层】
但是在网络中相连两端之间的介质，是复杂的，并不确保数据的可靠性交付，那么 TCP 是怎么样解决问题的？
应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。
在这个图中，我们将字节从 1至11进行标号。接收方通告的窗口称为提出的窗口（ o ff e r e d w i n d o w），它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第 3字节在内的数据，且通告窗口大小为 6。回顾第1 7章，我们知道窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
