HTTP 响应代码 – 永夜

当后端接口响应超时时，有时响应 404、有时响应 504 的排查分析

永夜 — Tue, 29 Oct 2024 09:15:02 +0000

浏览量： 88

1、当前端页面请求前端接口响应超时时，有时候响应 504（符合预期），有时候响应 404 （不符合预期）。如图1

图1



{
  "_request_time": "60.004",
  "_status": "404"
}

2、基于 _request_id:004c4f55c16c0904759fdb580d7c5df9 查询 ingress-nginx 的日志，ingress-nginx-controller 存在一条记录（10-14 16:01:33），响应 404。如图2

图2

3、基于 _request_id:004c4f55c16c0904759fdb580d7c5df9 查询 Frontend Service 的日志，Frontend Service 存在一条记录（10-14 16:01:33），请求 /50x.html ，响应 404，_upstream_status:504，表示 Backend Service 响应 504。如图3

图3

4、基于 _request_id:004c4f55c16c0904759fdb580d7c5df9 查询 Backend Service 的日志，Backend Service 存在一条记录（10-14 16:01:33），响应为 504，由于 Frontend Service 主动断开连接，记录的实际响应 499。如图4

图4

5、查看 Frontend Service 的 Nginx 配置。由于页面 50x.html 不存在，进而导致响应 404。最终决定注释掉相关的配置项。如图5

图5




    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   html;
    }

6、分析结论：如果前端服务（frontend-svc-80）正在等待 backend-svc-80 的响应，而 backend-svc-80 响应过慢，客户端会在响应 404 后主动关闭连接，导致 Backend Service Nginx 记录 499 状态码。 7、现在前端接口的请求的详细流程图：1. 客户端请求 → 2. Ingress Controller (ingress-nginx-controller) → 3. Frontend Service (frontend-svc-80) → 4. Backend Service (backend-svc-80) → 超时 (504|499) → 5. Frontend Service 返回 404 → 6. Ingress Controller 返回 404 8、通过第 5 步骤的调整后，当后端接口响应超时时，不再响应 404 ，符合预期。如图6

图6

同样的网址，在浏览器中响应 302，在 Postman 中响应 200 的排查分析

永夜 — Wed, 12 Apr 2023 01:26:11 +0000

浏览量： 110

1、同样的网址，在浏览器中响应 302。如图1

图1

2、同样的网址，在浏览器中响应 302，在 Postman 中响应 200。如图2

图2

3、决定查看一下 Nginx 的请求日志记录，存在 2 条请求记录，由此可以确定在 Postman 中请求时，实际上是经过了 302 跳转的，只不过最终响应 200 罢了。如图3、图4

图3

图4

在 Laravel 6 中，访问：https://object.local ，302 跳转至 https://xxx.xxx.xxx.top

永夜 — Thu, 10 Mar 2022 01:10:20 +0000

浏览量： 74

1、在 Laravel 6 中，访问：https://object.local ，302 跳转至 https://xxx.xxx.xxx.top 。如图1

图1

2、在源代码中查找：xxx.xxx.xxx.top，未找到。且数据库已经将 xxx.xxx.xxx.top 全部替换为 object.local。

3、在 Redis 中存在键名：laravel_cache:main_domain_cache，其值：s:26:”xxx.xxx.xxx.top”;。如图2

图2

4、清空 Redis 后，再次访问：https://object.local ，响应 500。未 302 跳转。符合预期。如图3

图3

HTTP 请求企鹅号的视频文件分片上传接口失败，报错：Curl error: #55 – TCP connection reset by peer

永夜 — Wed, 27 Oct 2021 02:37:57 +0000

浏览量： 67

1、HTTP 请求失败，报错：Curl error: #55 – TCP connection reset by peer。在请求企鹅号的视频文件分片上传接口时。如图1

图1



[24] common\jobs\UploadAssetJob (attempt: 1, PID: 14829) is finished with error: yii\httpclient\Exception: Curl error: #55 - TCP connection reset by peer in /mcloud/www/ccp_api/vendor/yiisoft/yii2-httpclient/src/CurlTransport.php:50
Stack trace:
#0 /mcloud/www/ccp_api/vendor/yiisoft/yii2-httpclient/src/Client.php(233): yii\httpclient\CurlTransport->send(Object(yii\httpclient\Request))
#1 /mcloud/www/ccp_api/vendor/yiisoft/yii2-httpclient/src/Request.php(444): yii\httpclient\Client->send(Object(yii\httpclient\Request))
#2 /mcloud/www/ccp_api/common/logics/http/qq_api/Video.php(217): yii\httpclient\Request->send()
#3 /mcloud/www/ccp_api/common/services/QqTpVideoMultipartUploadService.php(110): common\logics\http\qq_api\Video->authUploadTrunk(Array)
#4 /mcloud/www/ccp_api/common/services/QqTpVideoMultipartUploadService.php(194): common\services\QqTpVideoMultipartUploadService->httpUploadTrunk(Array)
#5 /mcloud/www/ccp_api/common/services/QqTpAssetService.php(183): common\services\QqTpVideoMultipartUploadService->upload(24, 43)
#6 /mcloud/www/ccp_api/common/jobs/UploadAssetJob.php(120): common\services\QqTpAssetService::uploadAssetVideoMultipartSync(24, 364)
#7 /mcloud/www/ccp_api/vendor/yiisoft/yii2-queue/src/Queue.php(246): common\jobs\UploadAssetJob->execute(Object(yii\queue\redis\Queue))
#8 /mcloud/www/ccp_api/vendor/yiisoft/yii2-queue/src/cli/Queue.php(162): yii\queue\Queue->handleMessage('24', 'O:26:"common\\jo...', '7200', '1')
#9 /mcloud/www/ccp_api/vendor/yiisoft/yii2-queue/src/cli/Command.php(146): yii\queue\cli\Queue->execute('24', 'O:26:"common\\jo...', '7200', '1', '14829')
#10 [internal function]: yii\queue\cli\Command->actionExec('24', '7200', '1', '14829')
#11 /mcloud/www/ccp_api/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#12 /mcloud/www/ccp_api/vendor/yiisoft/yii2/base/Controller.php(181): yii\base\InlineAction->runWithParams(Array)
#13 /mcloud/www/ccp_api/vendor/yiisoft/yii2/console/Controller.php(184): yii\base\Controller->runAction('exec', Array)
#14 /mcloud/www/ccp_api/vendor/yiisoft/yii2/base/Module.php(534): yii\console\Controller->runAction('exec', Array)
#15 /mcloud/www/ccp_api/vendor/yiisoft/yii2/console/Application.php(181): yii\base\Module->runAction('upload-asset-qu...', Array)
#16 /mcloud/www/ccp_api/vendor/yiisoft/yii2/console/Application.php(148): yii\console\Application->runAction('upload-asset-qu...', Array)
#17 /mcloud/www/ccp_api/vendor/yiisoft/yii2/base/Application.php(392): yii\console\Application->handleRequest(Object(yii\console\Request))
#18 /mcloud/www/ccp_api/yii(23): yii\base\Application->run()
#19 {main}.

2、查看视频文件的大小：1554129526 / 1024 / 1024 = 1482.13 MB。如图2

图2

3、查看企鹅号的视频文件分片上传。start_offset：分片的起始位置(从0开始计数)。end_offset：分片的结束位置。status：状态，0：禁用；1：待上传；2：上传中；3：上传中(已失败)；4：已上传。发现状态为3，即上传中(已失败)。已经上传至第 4 个分片，419430400 / 1024 / 1024 = 400 MB。单个分片文件大小为 100 MB。如图3

图3

4、第 5 个分片的起始位置：524288,000，那么第 4 个分片的结束位置：524287999，其值是正确的。查看存储中的原始文件：/2021/10/22/1634900031.6087.46572291.mp4，分片文件的数量总计为 15 个。分片文件不存在问题。如图4

图4



[root@api-589cf86d4c-rx5gw 22]# ls -lrt
-rw-r--r-- 1 65534 65534 1554129526 Oct 22 18:54 1634900031.6087.46572291.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:55 1634900031.6087.46572291_0.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:55 1634900031.6087.46572291_1.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:55 1634900031.6087.46572291_2.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:55 1634900031.6087.46572291_3.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_4.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_5.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_6.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_7.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_8.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_9.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_10.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_11.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_12.mp4
-rw-r--r-- 1 65534 65534  104857600 Oct 22 18:56 1634900031.6087.46572291_13.mp4
-rw-r--r-- 1 65534 65534   86123126 Oct 22 18:56 1634900031.6087.46572291_14.mp4

5、使用同样的视频文件再次上传，上传成功，未复现。以下是事务表中的 3 次记录。如图5

图5



start_offset    end_offset    status
629145600       734003199     2
1258291200      1363148799    2
1554129526      1554129526    4

6、总结：看来只有后续让测试人员再复现一下了。开发人员未复现的。这应该也是偶发问题的。基本上是很难解决了。比如说因为网络抖动、或者说企鹅号的服务器偶发不稳定。

在 Windows 10、 Nginx 1.10、PHP 7.4 中报错：413 Request Entity Too Large

永夜 — Thu, 16 Sep 2021 03:04:22 +0000

浏览量： 73

1、在 Windows 10、 Nginx 1.10、PHP 7.4 中报错：413 Request Entity Too Large。上传文件的大小：286MB。如图1

图1



413 Request Entity Too Large
nginx/1.10.1

2、查看 phpinfo，上传文件的大小限制为 1024M。如图2

图2



upload_max_filesize=1024M
post_max_size=1024M

3、在 Nginx 的 server 中添加：client_max_body_size 1024M;



client_max_body_size 1024M;

4、重启 Nginx 、PHP ，未再响应 413，问题解决。如图3

图3

HTTP 请求一个静态的 txt 文件，第 1 次响应 304，第 2 次响应 200 的分析

永夜 — Thu, 27 May 2021 06:56:28 +0000

浏览量： 100

1、HTTP 请求一个静态的 txt 文件，第 1 次响应 304，第 2 次响应 200。如图1

图1

2、参考网址：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/304 。HTTP 304 未改变说明无需再次传输请求的内容，也就是说可以使用缓存的内容。这通常是在一些安全的方法（safe），例如GET 或HEAD 或在请求中附带了头部信息： If-None-Match 或If-Modified-Since。第 1 次响应 304 的请求头中包含：if-modified-since: Thu, 27 May 2021 06:10:50 GMT。如图2

图2

3、参考网址：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/If-Modified-Since 。If-Modified-Since 是一个条件式请求首部，服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 。如果请求的资源从那时起未经修改，那么返回一个不带有消息主体的 304 响应，而在 Last-Modified 首部中会带有上次修改时间。不同于 If-Unmodified-Since, If-Modified-Since 只可以用在 GET 或 HEAD 请求中。

4、第 2 次响应 200 的请求头中未包含：if-modified-since: Thu, 27 May 2021 06:10:50 GMT。如图3

图3