HTTP CODE 状态码500|502|504分析

i-neojos

已于 2023-01-30 08:31:03 修改

阅读量1.6w

点赞数 2

分类专栏： Go学习理解文章标签： golang

于 2020-10-03 16:42:40 首次发布

本文链接：https://blog.csdn.net/whynottrythis/article/details/108911239

版权

Go学习理解专栏收录该内容

58 篇文章 1 订阅

订阅专栏

给别人轻松讲明白一个问题，才能算自己真正了解这个问题。

Origin Header 头让我熟悉了一次sheme

从HTTP的头Origin说起，想起之前客户端定义scheme，因为不了解，问了开发的同事“scheme是什么？”反正我当时是不明白他们讲的。

在了解HTTP Origin语法的时候，我其实才真正明白：scheme 指请求所使用的协议，通常是HTTP、HTTPS或者其他。

Origin: <scheme> "://" <host> [":" <port>]

Origin表示请求来至哪个站点。在WebSocket通信的时候，明确指明要校验这个参数。

状态码预览

500

服务器内部错误。比如：服务端处理出现异常。同时，在PHP错误日志中可以查看异常发生的调用栈信息。

502

作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。比如nginx从php-fpm接收到了不完整的response数据。

比如：服务端尝试连接mysql，但长时间链接不上，就会返回502错误。

可以浏览一些具体的文章：

504

网关超时。为了完成您的 HTTP 请求，该服务器访问一个上游服务器，但没得到及时的响应

比如：nginx超过了自己设置的超时时间，不等待php-fpm的返回结果，直接给客户端返回504错误。但是此时php-fpm依然还在处理请求（在没有超出自己的超时时间的情况下）。

当Go服务发生Panic时的状态码

500

首先我们启动一个Go的原生服务，然后在服务前设置Nginx作为服务的代理。这里配置中配置 Nginx 到 Go 服务使用长链接。

直接在代码中手动调用 panic，然后请求接口，观察接口的状态码返回值。

r.POST("/panic", func(context *gin.Context) {
	panic("this panic")
})

使用 curl 命令请求接口，同时，打印接口的详细信息。在程序处理请求的过程中发生panic的话，服务返回的500。这里，建议加上 -v 参数。

➜  ~ curl -v -X POST  http://127.0.0.1:8081/panic
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0)
> POST /panic HTTP/1.1
> Host: 127.0.0.1:8081
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Date: Sat, 03 Oct 2020 02:01:14 GMT
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

通过网络的请求情况，我们来佐证一下这个过程，对这个过程抓包分析。图中标志①的地方是因为程序中发生了 panic 导致，可以看出，虽然程序发生了panic，但是整个链接（63509端口到8001端口）并没有因为panic而断开；之后是②部分，服务端主动发起了3次心跳（默认间隔15秒）；最后，在③阶段，客户端主动断开了链接。

在这里插入图片描述

如果对 panic的信息进行了 recover 呢，我们调整一下代码，在 router 前加一个中间件来专门 recover 请求中的 panic信息：

func MiddleRecover(ctx *gin.Context) {
	defer func() {
		if r := recover(); r != nil {
			log.Println("panic occur", r)
		}
	}()
	
	ctx.Next()
}

我们继续使用curl 请求 /panic 接口，接口正常返回了，状态码是200。

➜  ~ curl -v -X POST  http://127.0.0.1:8081/panic
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8081 (#0)
> POST /panic HTTP/1.1
> Host: 127.0.0.1:8081
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 03 Oct 2020 02:08:39 GMT
< Content-Length: 0
<
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

502

那么，如何触发502的状态码呢，通过前面对状态码的介绍：“从上游服务器接收到无效的响应”。从网络传输来看，在传输的过程中，如果服务端主动断开链接，就会导致502。服务端怎么样才会主动断开链接呢，有一种比较常见的情况，就是整个服务 crash。

我们在新建一个请求，用来导致整个服务发生 panic，这里采用 map 并发读写的panic，因为这个panic 是runtime层发生的panic，整个服务只能crash，不能被recover。代码中模拟了 map 的并发读写操作。注意，并不一定每次都能触发panic

result := make(map[int]int)
r.POST("/crash_panic", func(context *gin.Context) {
	go func() {
		for {
			result[1] = 1
		}
	}()
	_ = result[1]
	context.JSON(http.StatusOK, "")
})

我们还是通过 curl 来请求几次，看一下结果。在系统崩溃时，返回的状态码确实是502。

➜  nginx curl -v -X POST http://127.0.0.1:1144/crash_panic
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 1144 (#0)
> POST /crash_panic HTTP/1.1
> Host: 127.0.0.1:1144
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 502 Bad Gateway
< Server: nginx/1.19.1
< Date: Sat, 03 Oct 2020 08:21:45 GMT
< Content-Type: text/html
< Content-Length: 157
< Connection: keep-alive
<
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.19.1</center>
</body>
</html>
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

依旧通过网络抓包来看一下连接断开的过程。从图中的②可以看出，服务端主动断开了网络的连接。因为服务Down机了，在Down机的时候会主动断开服务端的连接。

在这里插入图片描述

504

最后，我们再来看一下504，没有得到及时的响应。怎么样才算是网络超时呢，看一下实验的 nginx 配置文件。

upstream mysvr {
        server 127.0.0.1:8081;
        keepalive 300;       #这个很重要！
}

server {

        keepalive_requests 120; #单连接请求上限次数。

        listen  1144;      #监听端口
        location / {       #请求的url过滤，正则匹配，~为区分大小写，~*为不区分大小写。
                proxy_pass  http://mysvr;  #请求转向mysvr 定义的服务器列表
                proxy_set_header Host $host;
                proxy_set_header Connection "";   #设置Connection为长连接（默认为no）
                proxy_connect_timeout 30;         #与upstream server的连接超时时间
                proxy_read_timeout 60s;           #nginx会等待多长时间来获得请求的响应
                proxy_send_timeout 12s;           #发送请求给upstream服务器的超时时间
                proxy_http_version 1.1;
        }
}

对配置文件做一下改动，将proxy_read_timeout从60秒调整到3秒，然后我在程序中sleep 3秒看一下效果:

r.POST("/timeout", func(context *gin.Context) {
	time.Sleep(time.Second * 4)
	context.JSON(http.StatusOK, "")
})

下面是 curl 请求的过程以及网络抓包的截图：

➜  nginx curl -v -X POST http://127.0.0.1:1144/timeout
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 1144 (#0)
> POST /timeout HTTP/1.1
> Host: 127.0.0.1:1144
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 504 Gateway Time-out
< Server: nginx/1.19.1
< Date: Sat, 03 Oct 2020 08:33:54 GMT
< Content-Type: text/html
< Content-Length: 167
< Connection: keep-alive
<
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.19.1</center>
</body>
</html>
* Connection #0 to host 127.0.0.1 left intact
* Closing connection 0

通过第二列的时间项，我们可以计算出，大概在3秒后，nginx主动断开了链接，然后客户端收到了504的状态码。
在这里插入图片描述

i-neojos

关注

2
点赞
踩
5

收藏

觉得还不错? 一键收藏
1
评论
HTTP CODE 状态码500|502|504分析

给别人轻松讲明白一个问题，才能算自己真正了解这个问题。Origin Header 头让我熟悉了一次sheme从HTTP的头Origin说起，想起之前客户端定义scheme，因为不了解，问了开发的同事“scheme是什么？”反正我当时是不明白他们讲的。在了解HTTP Origin语法的时候，我其实才真正明白：scheme 指请求所使用的协议，通常是HTTP、HTTPS或者其他。Origin: <scheme> "://" <host> [":" <port>]
复制链接

扫一扫