rst是什么指令？

复位键，车上的rst是英文reset的简写，指的是复位键的意思。

当系统出现死机、程序错乱或者需要恢复出厂设置的时候，可以使用复位键恢复出厂设置，使系统正常运行。rst通常不是按键，需要谨慎使用，而是有个小孔，用类似牙签的物品伸进回去触摸开关，解决系统除硬件损坏以外的问题。产生复位的一种常见情况是当连接请求到达时，目的端口没有进程正在监听。对于UDP，当一个数据报到达目的端口时，该端口没在使用，它将产生一个ICMP端口不可达的信息，而TCP则使用复位。

汽车GPS导航系统由两部分组成，一部分由安装在汽车上的GPS接收机和显示设备组成，另一部分由计算机控制中心组成，两部分通过定位卫星进行联系。汽车导航具有GPS全球卫星定位系统功能，让您在驾驶汽车时随时随地知晓自己的确切位置。

英特尔RST也就是英特尔快速存储技术，是一个基于 Windows的应用程序。该程序为配备 SATA 磁盘的台式机、移动电脑和服务器平台系统提供更高的性能和可靠性。当使用一个或多个 SATA 磁盘时，您可因性能提高及耗电降低而获益。使用多个磁盘时，可增强对磁盘故障时数据丢失的保护。

这个东西没啥用。。不用管他

至于卸载，win7的话,就进入"控制面板"-"程序和功能"里可以看到"英特尔R快速存储技术"这一项,选择卸载即可

当TIME_WAIT超过linux系统tw数量的阀值(可用数量不会大于65535)，系统会把多余的time-wait socket 删除掉，并且显示警告信息，如果是NAT网络环境又存在大量访问，会产生各种连接不稳定断开的情况，从而影响了服务的稳定性。

一、状态的产生

要解决TIME_WAIT状态过多的问题，先来研究下TIME_WAIT状态的产生，下面是TCP连接断开时的四次挥手状态转换图，说明一点，途中显示的是客户端主动断开连接，tcp连接也可以由服务器端主动断开连接。我们先来描述一下断开的状态：

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命,RFC规定一个MSL为2min，linux中一般设置为30s）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

可以看到TIME_WAIT状态产生是在tcp连接主动关闭的一端产生的正常tcp状态，超过两个MSL之后，就会关闭，释放占用的端口。基于以上的分析我们可以推断，在我们的应用中产生大量TIME_WAIT状态的根本原因是频繁创建断开连接TCP连接。要解决TIME_WATIT状态过多的问题，就要分析我们的应用把频繁创建的短连接改为长连接。

二、常见的短连接产生的场景

1服务连接服务

后台业务服务器，通常需要调用redis、mysql以及其他http服务和grpc服务，在服务相互调用中，如果使用的是短连接，高并发时就会产生大量TIME_WAIT，如何解决呢？一般情况下，redis等客户端会有连接池，我们要做的是设置好相关的连接服用参数，一般会有连接数、连接重用时间、连接空闲数等。所以在应用中通过设置合理的连接池参数可以避免TIME_WAIT状态过多的问题：

1检查http连接池

2检查grpc连接池

3检查redis连接池

4检查mysql连接池

我们来查看一个mysql连接池配置信息，最大连接数100，最大空闲连接数10，测试的并发数50，产生的效果如下：

可以看到TIME_WAIT状态快速上升，我们查看redis客户端的连接情况：

{MaxOpenConnections:100 OpenConnections:1 InUse:0 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:0 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:17 InUse:15 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:48 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:44 Idle:7 WaitCount:0 WaitDuration:0s MaxIdleClosed:82 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:90 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:49 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:126 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:49 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:131 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:49 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:181 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:51 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:233 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:51 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:240 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:46 InUse:38 Idle:8 WaitCount:0 WaitDuration:0s MaxIdleClosed:296 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:313 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:363 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:51 InUse:50 Idle:1 WaitCount:0 WaitDuration:0s MaxIdleClosed:409 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:50 InUse:48 Idle:2 WaitCount:0 WaitDuration:0s MaxIdleClosed:438 MaxLifetimeClosed:0}

{MaxOpenConnections:100 OpenConnections:49 InUse:49 Idle:0 WaitCount:0 WaitDuration:0s MaxIdleClosed:494 MaxLifetimeClosed:0}

分析发现MaxIdleClosed数据持续上升，此为mysql客户端连接池配置不合理产生大量TIME_WAIT状态的例子

2网络抖动

      网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接。同样网络情况不好并且无TIME_WAIT等待，关闭连接后无新连接，当接收到被动方重传或延迟的FIN包后，会给被动方回一个RST包，可能会影响被动方其它的服务连接。

网络抖动问题比较好排查，直接使用ping命令可以观察到。

有三个条件可以产生RST包：

1 建立连接的SYN到达某端口，但是该端口上没有正在监听的服务

如：IP为192168133的主机上并没有开启WEB服务（端口号为0x50），这时我们通过IE去访问192168133，通过Wireshark抓包，可以看到，对此SYN包的回复为RST。说明此服务器（即IP192168133）是存在的，不过其上并没有运行WEB Server(如apache)的程序

2 TCP想取消一个已有连接

基于什么样的情况才会取消一个已有的连接？

3 TCP接收到了一个根本不存在的的连接上的分节

我们知道，TCP在数据传输前，要通过三路握手(three-way handshake)建立连接，即连接建立起后，服务器和客户端都有一个关于此连接的描述，具体形式表现为套接口对，如果收到的某TCP分节，根据源 IP，源tcp port number，及目的IP，目的tcp port number在本地（指服务器或客户端）找不到相应的套接口对，TCP则认为在一个不存在的连接上收到了分节，说明此连接已错，要求重新建立连接，于是发出了RST的TCP包！

建立一条新的TCP连接时，甚至是在发送任意数据之前，TCP软件之间会交换一系列的IP分组，对连接的有关参数进行沟通，如果连接只用来传送少量数据，这些交换过程就会严重降低HTTP的性能

TCP连接三次握手：

另 参考 here ：

TCP的三次握手是怎么进行的：

之后，一个TCP连接建立，开始通讯。

SYN：同步标志

同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把 TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

ACK：确认标志

确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端[系统]已经成功接收所有数据。

RST：复位标志

复位标志有效。用于复位相应的TCP连接。

URG：紧急标志紧急(The urgent pointer) 标志有效。紧急标志置位，PSH：推标志该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。

FIN：结束标志

带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

TCP的几个状态对于我们分析所起的作用

在TCP层，有个FLAGS字段，这个字段有以下几个标识：SYN, FIN, ACK, PSH, RST, URG其中，对于我们日常的分析有用的就是前面的五个字段。它们的含义是：SYN表示建立连接，FIN表示关闭连接，ACK表示响应，PSH表示有 DATA数据传输，RST表示连接重置。其中，ACK是可能与SYN，FIN等同时使用的，比如SYN和ACK可能同时为1，它表示的就是建立连接之后的响应，如果只是单个的一个SYN，它表示的只是建立连接。

TCP的几次握手就是通过这样的ACK表现出来的。但SYN与FIN是不会同时为1的，因为前者表示的是建立连接，而后者表示的是断开连接。RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。一般地，当出现FIN包或RST包时，我们便认为客户端与服务器端断开了连接；而当出现SYN和SYN＋ACK包时，我们认为客户端与服务器建立了一个连接。PSH为1的情况，一般只出现在 DATA内容不为0的包中，也就是说PSH为1表示的是有真正的TCP数据包内容被传递。TCP的连接建立和连接关闭，都是通过请求－响应的模式完成的。

从本节开始，我们开始学习最重要的传输层。传输层位于OSI七层模型的第四层（从下往上）。顾名思义，传输层的作用是实现应用程序间的通信。网络层的作用是保证数据在不同数据链路上传输的可达性，至于如何传输则是由传输层负责。

常见的传输层协议主要有 TCP和UDP 协议。

UDP协议最大的特点就是简单，UDP首部如图：

和UDP首部相比，TCP首部要复杂的多。解析这个首部的时间也会相应的增加，这也是TCP连接的效率低于UDP的原因之一。

TCP是面向有连接的协议，连接在每次通信前被建立，通信结束后被关闭。了解连接建立和关闭的过程通常是考察的重点。连接的建立和关闭可以用一张图来表示：

通常情况下我们认为客户端首先发起连接请求。

1发送端发送一个SYN=1，ACK=0标志的数据包给接收端，请求进行连接，这是第一次握手；

2接收端收到请求并且允许连接的话，就会发送一个SYN=1，ACK=1标志的数据包给发送端，告诉它，可以通讯了，并且让发送端发送一个确认数据包，这是第二次握手；

3最后，发送端发送一个SYN=0，ACK=1的数据包给接收端，告诉它连接已被确认，这就是第三次握手。之后，一个TCP连接建立，开始通讯。

SYN：同步标志

同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

ACK：确认标志

确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

RST：复位标志

复位标志有效。用于复位相应的TCP连接。

URG：紧急标志

紧急(The urgent pointer) 标志有效。紧急标志置位，

PSH：推标志

该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。

FIN：结束标志

带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据

根据一般思路，我们认为第三次是多余的，TCP协议为什么还要增加第三次的握手呢？

这是因为在网络请求的时候，我们应该时刻记住“网络是不安全的，数据包是可能丢失的”。假设没有第三次确认，客户端向服务端发送了SYN包，请求建立连接。由于网络原因，服务器没有及时收到这个包，于是客户端重新发送了SYN包。正常建立了连接。此时超时的那个确认包到达了服务端，如果是两次握手此连接就建立了，服务端就建立了一个空连接，白白浪费资源。如果是三次，客户端判断这个确认包是无效的，就丢弃了。

三次握手实际其实解决了第二步丢包问题。那么第三步的ACK包丢失了，TCP协议是如何处理的呢？

按照TCP协议处理丢包问题的一般方法，服务器会重新向客户端发送确认包，知道ACK确认为止。但实际上这种做法有可能遭到SYN泛洪攻击。所谓的泛洪攻击，是指发送方伪造多个IP地址，模拟三次握手的过程。当服务器返回ACK后，攻击方故意不确认，从而使服务器不断重发ACK。由于服务器长时间处于半连接状态，最后消耗过多的CUP和内存资源导致死机。

所以服务端采用的是这种方法，发送RST数据包，进入close状态，这个RST数据包中的TCP首部中的控制位中的RST位被置为1。这表示连接信息全部被初始化，原有的TCP通信不能继续。客户端如果还想建立TCP连接，需要从第一步握手重新开始。

（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。

（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。

（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。

（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。