502Badgateway有什么错误?

简单来说502是报错类型代码badgateway错误的网关，一般原因是连接超时，我们向服务器发送请求，由于服务器当前连接太多，导致服务器方面无法给予正常的响应，从而产生这类报错。

处理方式为刷新页面，重新发出链接请求。有两个方法：

基本刷新：就是点击刷新或者使用F5快捷键。

基本刷新只是从本地的硬盘重新拿取数据到浏览器，并不重新向服务器发出请求。

大部分用户很多时候都是这样刷新的，遇到502报错的就没有任何效果。　

2.从服务器刷新：重新直接点击想要浏览的网页链接，会发现刚才还是显示502badgetway的页面现在又可以正常浏览了。

当你点击你想要浏览的网页链接的时候，是会从服务器重新下载数据的。

解决方法就是从服务器上刷新：快捷键ctrl+F5，这样就是重新向服务器发送请求了。如果服务器能正常给予你响应你就可以看到页面了。

（1）SSL： 安全套接层

（2）TLS：传输层安全

（3）工作流程：服务器认证阶段：1） 客户端 向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；2）服务器根据客户的信息确定是否需要生成新的主 密钥 ，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的 公开密钥加密 后传给服务器；4）服务器回复该主密钥，并返回给客户一个用主 密钥认证 的信息，以此让 客户认证 服务器。

简述：客户端向服务器发送一个信息并建立新的会话连接，服务器根据客户端发来的信息判断是否需要加密，如果需要加密，就发给客户端一些生成主密钥的信息（例如一些铁），客户端收到这些信息（铁）生成主密钥（锁），并用服务器的公开密钥加密后发给服务器，服务器根据客户端发回的主密钥（锁），生成一个主密钥认证的信息（钥匙）

Http协议运行在TCP之上，明文传输，客户端与服务器端都无法验证对方的身份；Https是身披SSL(Secure Socket Layer)外壳的Http，运行于SSL上，SSL运行于TCP之上，是添加了加密和认证机制的HTTP。二者之间存在如下不同：

端口不同：Http与Http使用不同的连接方式，用的端口也不一样，前者是80，后者是443；

资源消耗：和HTTP通信相比，Https通信会由于加减密处理消耗更多的CPU和内存资源；

开销：Https通信需要证书，而证书一般需要向认证机构购买；

Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

1. 建立TCP连接：TCP/IP协议，一般端号是80

2. Web浏览器向Web服务器发送请求命令

3. Web浏览器发送请求头信息 ：浏览器发送一空白行来通知服务器，它已经结束了该头信息的发送。

4. Web服务器应答

5. Web服务器发送应答头信息

6. Web服务器向浏览器发送数据：会发送一个空白行来表示头信息的发送到此为结束

第三次握手的必要性： 防止已失效的请求报文段突然又传送到了服务端而造成连接的误判。假如客户端发出连接请求A，由于网络原因，服务端并没有收到A，于是客户端又发送了连接请求B，并建立了连接，完成通信，断开连接。这时候，服务端突然又收到了A，于是看作是一次新的连接请求，进行第二次握手，由于不存在第三次握手，所以这时已经建立了TCP连接。但实际上客户端并没有发起连接，所以不会传递数据，那么这条连接就会变成一条死连接。

第四次挥手的必要性： 为保证单向通信的可行性，所以多一次握手。

1）主动断开方发送FIN时，被动断开方要回复ACK，意思是“我收到你的FIN了”；

2）主动断开方发送FIN并不意味着立即关闭TCP连接，而是告诉对方自己没有更多的数据要发送了，只有当对方发完自己的数据再发送FIN后，才意味着关闭TCP连接；

3）被动断开方收到FIN并回复ACK后，此时TCP处于“半关闭”状态，为保证被动断开方可以继续发送数据，所以第二个FIN并不会伴随ACK发送，所以比连接时多一个报文段。

TCP是传输控制协议，提供的是面向连接、可靠的字节流服务。通信双方彼此交换数据前，必须先通过三次握手协议建立连接，之后才能传输数据。TCP提供超时重传，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。UDP是用户数据报协议，是一个简单的面向无连接的协议。UDP不提供可靠的服务。在数据数据前不用建立连接故而传输速度很快。UDP主要用户流媒体传输，IP电话等对数据可靠性要求不是很高的场合。

长轮询，WebSockets和服务器发送事件是Web浏览器和Web服务器之类的客户端之间的常用通信协议。 首先，让我们开始了解标准HTTP Web请求的样子。 以下是常规HTTP请求的一系列事件：

客户端打开连接并从服务器请求数据。

服务器计算响应。

服务器在打开的请求上将响应发送回客户端。

轮询是绝大多数AJAX应用程序使用的标准技术。 基本思想是客户端反复轮询（或请求）服务器以获取数据。 客户端发出请求并等待服务器响应数据。 如果没有可用数据，则返回空响应。

客户端使用常规HTTP打开连接并从服务器请求数据。

所请求的网页以规则的间隔（例如，0.5秒）向服务器发送请求。

服务器计算响应并将其发回，就像常规HTTP流量一样。

客户端定期重复上述三个步骤以从服务器获取更新。

轮询问题是客户端必须不断向服务器询问任何新数据。 结果，许多响应都是空的，从而产生HTTP开销。

长轮训是传统轮询技术的一种变体，允许服务器在数据可用时将信息推送到客户端。使用长轮询，客户端从正常轮询中请求来自服务器的信息，但期望服务器可能不会立即响应。这就是为什么这种技术有时被称为“HANGING GET”。

如果服务器没有可用于客户端的任何数据，则服务器保留请求并等待直到某些数据可用，而不是发送空响应。

数据可用后，将向客户端发送完整响应。然后，客户端立即从服务器重新请求信息，以便服务器几乎总是有一个可用的等待请求，它可以用来传递数据以响应事件。

使用HTTP Long-Polling的应用程序的基本生命周期如下：

客户端使用常规HTTP发出初始请求，然后等待响应。

服务器会延迟响应，直到更新可用，或者直到发生超时。

当更新可用时，服务器会向客户端发送完整响应。

客户端通常在接收到响应时立即发送新的长轮询请求，或者在暂停之后发送新的长轮询请求以允许可接受的等待时间段。

每个Long-Poll请求都有一个超时。由于超时，客户端必须在连接关闭后定期重新连接。

WebSocket通过单个TCP连接提供全双工通信通道。 它提供客户端和服务器之间的持久连接，双方可以使用它来随时开始发送数据。 客户端通过称为WebSocket握手的进程建立WebSocket连接。 如果该过程成功，则服务器和客户端可以随时在两个方向上交换数据。 WebSocket协议以较低的开销实现客户端和服务器之间的通信，便于从服务器到服务器的实时数据传输。 这可以通过为服务器提供标准化的方式来实现，即在不被客户端询问的情况下将内容发送到浏览器，并允许在保持连接打开的同时来回传递消息。 通过这种方式，可以在客户端和服务器之间进行双向（双向）正在进行的对话。

在SSE下，客户端与服务器建立持久且长期的连接。 服务器使用此连接将数据发送到客户端。 如果客户端想要将数据发送到服务器，则需要使用其他技术/协议来执行此操作。

客户端使用常规HTTP从服务器请求数据。

请求的网页打开与服务器的连接。

只要有新信息，服务器就会将数据发送到客户端。

SSE 适用于那些，服务器要在一段时间批量发数据给客户端的场景，或者是服务器单方面向客户端实时发数据的场景。

---