windowsupdateagent，魔兽世界服务器负载不兼容怎么办？
1.首先需要从战网通行证这里来点击退出登录。
2.然后打开电脑的任务管理器,随便挑选一个方式打开。
3.在任务管理器中右键点击agentexe,结束这个进程。
4.最后重新启动展望客户端,点击右上方的设置按钮。
5、然后点击其中的离线模式，运行这个软件。
6、客户端会自动进行检查更新，完成以后就可以解决问题。
用爱思助手升级了ios13后面系统更新还会推送吗？
会推送的，因为爱思助手更新的系统也是官方版本，不影响后续系统更新推送。如果你不想要新系统更新推送的话只能越狱了，越狱之后有三个办法可以不推送新系统更新。以下是越狱之后不让手机推送系统更新的办法
1.删除已下载OTA更新包
找到/var/mobile/Library/Assets/com_apple_MobileAsset_SoftwareUpdate目录，删除目录下所有文件。
2.关闭OTA更新
手机上用iFile或者在电脑上用iTools、PP助手、同步助手，进入目录/System/Library/LaunchDaemons，将下面三个文件重命名（在文件名后面加上.bak）
①com.apple.mobile.softwareupdated.plist
②com.apple.OTATaskingAgent.plist
③com.apple.softwareupdateservicesd.plist
3.通用以及软件更新右侧的数字1的办法：
进入/System/Library/CoreServices这个文件夹，找到SystemVersion.plist，拷贝到电脑里，将ProductBuildVersion的数值改为9B179，再把在电脑上修改好的文件拷贝到手机里覆盖原来文件，然后重启手机，发现讨厌的数字1消失了，然后再拷贝到电脑改为原来的数值后拷贝到手机覆盖掉原来文件。
战网睡眠模式怎么解决？
许多玩家玩使命召唤时会出现战网睡眠模式，就给大家看看我是怎么处理得
1.Win+R打开”运行“，输入”%ProgramData%“
2.删除ProgramData目录下的Battle.net及Blizzard Entertainment文件夹
3.如果无法删除，打开任务管理器，结束掉Agent.exe和Battle.net.exe进程
4.关闭后先打开迅游加速器加速使命召唤16启动加速，在登陆游戏就ok了。
5.实在不行也就只能去问战网客服了。
Windows错误报告工具到底是如何联机检查解决方案的？
在 Windows 应用意外崩溃后，系统似乎会努力地寻找解决方案。但是在绝大多数情况下，这一切都是徒劳的，并不会向用户给出任何结果。即便如此，很多人还是想要知道这个无效的过程期间到底都发生了什么。好消息是，近日微软 Windows Update Agent 软件开发团队的 Mark Phaedrus，就在问答网站 Quora 上回答了这个问题。
（题图 via MSPU）
以下是 Windows 错误报告系统工作原理的简化说明：
● 程序遇到崩溃。
● Windows 错误检查机制启动，尝试获取程序崩溃当时正在做什么的重要信息。
● 基于上述信息来创建‘桶签名’（Bucket Signature），这是识别崩溃的一个简单方法。尽管无法直接判断，但若遇到两个或以上相同的内容，就能揪出是同一件事导致的崩溃。
● 若用户隐私设置允许，Windows 错误报告会将 Bucket Signature 签名信息发送给微软。
之后就是三种结果：
（1）微软未能找到特定的问题：服务器那边仅仅是记下了崩溃的签名信息，未能反馈任何后续进展。
（2）服务器接收到了大量相同的崩溃签名信息：此事微软会将 bug 报告分配给开发团队作分析，但他们可能需要更多信息来完成修复。
（3）运气很好，找到了相应问题的修复程序：那服务器会向用户机器传回一个通知 ——‘你可以怎么怎么做来解决该问题’。
但若无法简单通过安装最新的 Windows 修补程序来解决这个问题，还是去寻找 IT 管理员的帮助吧。
综上所述，若用户不提交错误日志，那微软可能永远不会知道该问题的常见程度。如果你希望微软能够尽力修复，那也请不吝提交崩溃日志信息。
WebSocket是什么原理？
首先我们看一下websocket的出现背景，我们知道http系列协议是建立在tcp上的，理论上，他是可以可以双向通信的。但是http1.1之前，服务器没有实现推送的功能。每次都是客户端请求，服务器响应。下面看一下http协议关于请求处理的发展。
http1.0的时候，一个http请求的生命周期是客户端发起请求，服务器响应，断开连接。但是我们知道tcp协议的缺点就是，三次握手需要时间，再加上慢开始等特性，每一个http请求都这样的话，效率就很低。http1.1的时候，默认开启了长连接（客户端请求中设置了keep-alive头），服务器处理一个请求后，不会立刻关闭连接，而是会等待一定的时间。如果没有请求才关闭连接。这样浏览器不仅可以在一个tcp连接中，不断地发送请求（服务器也会限制一个连接上可以处理的请求阈值），甚至可以一次发很多个请求。这就是http1.1的管道化（pipeline）技术。但是他也有个问题，因为对于基于http协议的客户端来说，虽然他可以发很多请求出去，但是当一个请求对于的回包回来时，他却无法分辨是属于哪个请求的。所以回包只能按请求顺序返回，这就引来了另一个问题-线头阻塞(Head-of-Link Blocking)。并且http1.1虽然支持长连接，但是他不支持服务端推送（push）的能力。如果服务器有数据要给客户端，也只能等着客户端来取（pull）。来到了http2.0，不仅实现了服务器推送，还使用了帧（iframe），流（stream）等技术解决了线头阻塞的问题，http2.0在一个tcp连接中，可以同时发送多个http请求，每个请求是一个流，一个流可以分成很多帧，有了标记号，服务器可以随便发送回包，客户端收到后，根据标记，重新组装就可以。以上是http协议的关于请求的一些发展，而websocket就服务端推送提供了另外一种解决方案。他本质上是在tcp协议上封装的另一种应用层协议（websocket协议）。因为他是基于tcp的，所以服务端推送自然不是什么难题。但是在实现上，他并不是直接连接一个tcp连接，然后在上面传输基于websocket协议的数据包。他涉及到一个协议升级（交换）的过程。我们看看这个过程。1 客户端发送协议升级的请求。在http请求加上下面的http头2 服务器如果支持websocket协议的话，会返回101状态码表示同意协议升级，并且支持各种配置（如果服务器不支持某些功能或版本，或告诉客户端，客户端可以再次发送协议升级的请求）。服务会返回形如下面的http头（可以参考websocket协议)。3 这样就完成了协议的升级，后续的数据通信，就是基于tcp连接之上，使用websocket协议封装的数据包。下面我们通过wireshark来了解这个过程。首先我们启动一个服务器（ip：192.168.8.226）。我们可以直接在浏览器控制台进行测试这时候，我们看看wireshark的包。首先看前面三条记录，这是tcp三次握手的数据包。这个我们都了解了，就不展示。接着看第四条记录。展开后如下。我们看到建立tcp连接后，浏览器发了一个http请求，并带上了几个websocket的数据包。接着看下面的一条。服务返回了同意升级协议或者说交换协议。从服务器代码中我们看到，在建立连接的时候我们给浏览器推送了一个get it的字符串。继续看上面的记录。这就是服务器给浏览器推送的基于websocket协议的数据包。具体每个字段什么意思，参考websocket协议就可以。继续往下看一条记录是针对服务器推送的数据包的一个tcp的ack。最后我们可以顺便看看最后三条写着keep-alive的记录。这就是之前文章里讲到的tcp层的keep-alive。因为我们一直没有数据传输，所以tcp层会间歇性地发送探测包。我们可以看看探测包的结构。有一个字节的探测数据。如果这时候我们发送一个数据包给服务器，又是怎样的呢。白色背景的三条数据，分别是浏览器发送给服务器的数据，服务器推送回来的数据。tcp的ack。我们发现，服务器给浏览器推送的时候，浏览器会发送ack，但是浏览器给服务器发送的时候，服务器貌似没有返回ack。下面我们看看为什么。首先我们看浏览器发出的包。再看看服务器给浏览器推送的数据包。我们发现服务器（tcp）推送消息的时候把ack也带上了。而不是发送两个tcp包。这就是tcp的机制。tcp不会对每个包都发ack，他会累积确认（发ack），以减少网络的包，但是他也需要保证尽快地回复ack，否则就会导致客户端触发超时重传。tcp什么时候发送确认呢？比如需要发送数据的时候，或者超过一定时间没有收到数据包，或者累积的确认数量达到阈值等。既然研究了tcp，我们不妨多研究点，我们看一下，如果这时候关闭服务器会怎样。服务器会发送一个重置包给浏览器，告诉他需要断开连接。继续，如果是浏览器自己调用close去关闭连接会怎样。我们看到websocket首先会发送一个FIN包给服务器，然后服务器也会返回一个FIN包，然后才开始真正的四次挥手过程。并且四次挥手的第一个fin包是服务器发的。我们再来看看安全版本的websocket。我们启动一个https服务器。然后在浏览器控制台执行。然后来看看wireshark。首先建立tcp连接，然后建立tls连接。后续的数据通信就可以基于加密来进行了。不再重复。后续分析tls协议的时候再分析。经过一系列的分析，我们对websocket协议应该有了更多的了解，最后再说一个关于websocket的点。我们发现如果在websocket连接上，一直不通信的话，websocket连接所维持的时间是依赖tcp实现的。因为我们发现tcp层会一直发送探测包。达到阈值之后，连接就会被断开。所以我们想维持websocket连接的话，需要自己去发送心跳包，比如ping，pong。总结：本文分析了websocket的基本原理，但不涉及协议的内容，如需了解协议的内容，可以参考rfc文档。