Seorang wakil pelanggan kami, yang timbunan aplikasinya berada dalam awan Microsoft (Azure), menangani masalah: baru-baru ini, beberapa permintaan daripada beberapa pelanggan dari Eropah mula berakhir dengan ralat 400 (). Semua aplikasi ditulis dalam .NET, digunakan dalam Kubernetes...
Salah satu aplikasi ialah API, yang melaluinya semua lalu lintas akhirnya datang. Trafik ini didengari oleh pelayan HTTP , dikonfigurasikan oleh klien .NET dan dihoskan dalam pod. Dengan penyahpepijatan, kami bernasib baik dalam erti kata bahawa terdapat pengguna tertentu yang secara konsisten menghasilkan semula masalah itu. Walau bagaimanapun, semuanya rumit oleh rantaian lalu lintas:
Ralat dalam Ingress kelihatan seperti ini:
{
"number_fields":{
"status":400,
"request_time":0.001,
"bytes_sent":465,
"upstream_response_time":0,
"upstream_retries":0,
"bytes_received":2328
},
"stream":"stdout",
"string_fields":{
"ingress":"app",
"protocol":"HTTP/1.1",
"request_id":"f9ab8540407208a119463975afda90bc",
"path":"/api/sign-in",
"nginx_upstream_status":"400",
"service":"app",
"namespace":"production",
"location":"/front",
"scheme":"https",
"method":"POST",
"nginx_upstream_response_time":"0.000",
"nginx_upstream_bytes_received":"120",
"vhost":"api.app.example.com",
"host":"api.app.example.com",
"user":"",
"address":"83.41.81.250",
"nginx_upstream_addr":"10.240.0.110:80",
"referrer":"https://api.app.example.com/auth/login?long_encrypted_header",
"service_port":"http",
"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36",
"time":"2019-03-06T18:29:16+00:00",
"content_kind":"cache-headers-not-present",
"request_query":""
},
"timestamp":"2019-03-06 18:29:16",
"labels":{
"app":"nginx",
"pod-template-generation":"6",
"controller-revision-hash":"1682636041"
},
"namespace":"kube-nginx-ingress",
"nsec":6726612,
"source":"kubernetes",
"host":"k8s-node-55555-0",
"pod_name":"nginx-v2hcb",
"container_name":"nginx",
"boolean_fields":{}
}Pada masa yang sama, Kestrel memberikan:
HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0Walaupun dengan verbosity maksimum, ralat Kestrel mengandungi sangat sedikit maklumat berguna:
{
"number_fields":{"ThreadId":76},
"stream":"stdout",
"string_fields":{
"EventId":"{"Id"=>17, "Name"=>"ConnectionBadRequest"}",
"SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
"ConnectionId":"0HLL2VJSST5KV",
"@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
"@t":"2019-03-07T13:06:48.1449083Z",
"@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
"message":"Malformed request: invalid headers."
},
"timestamp":"2019-03-07 13:06:48",
"labels":{
"pod-template-hash":"2368795483",
"service":"app"
},
"namespace":"production",
"nsec":145341848,
"source":"kubernetes",
"host":"k8s-node-55555-1",
"pod_name":"app-67bdcf98d7-mhktx",
"container_name":"app",
"boolean_fields":{}
}Nampaknya hanya tcpdump akan membantu menyelesaikan masalah ini... tetapi saya akan mengulangi tentang rantaian trafik:
Siasatan
Jelas sekali, lebih baik untuk mendengar lalu lintas pada nod tertentu itu, di mana Kubernetes telah menggunakan pod: volum pembuangan akan sedemikian rupa sehingga mungkin untuk mencari sekurang-kurangnya sesuatu dengan cepat. Dan sesungguhnya, apabila memeriksanya, bingkai berikut diperhatikan:
GET /back/user HTTP/1.1
Host: api.app.example.com
X-Request-ID: 27ceb14972da8c21a8f92904b3eff1e5
X-Real-IP: 83.41.81.250
X-Forwarded-For: 83.41.81.250
X-Forwarded-Host: api.app.example.com
X-Forwarded-Port: 443
X-Forwarded-Proto: https
X-Original-URI: /front/back/user
X-Scheme: https
X-Original-Forwarded-For: 83.41.81.250
X-Nginx-Geo-Client-Country: Spain
X-Nginx-Geo-Client-City: M.laga
Accept-Encoding: gzip
CF-IPCountry: ES
CF-RAY: 4b345cfd1c4ac691-MAD
CF-Visitor: {"scheme":"https"}
pragma: no-cache
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.119 Safari/537.36
referer: https://app.example.com/auth/login
accept-language: en-US,en;q=0.9,en-GB;q=0.8,pl;q=0.7
cookie: many_encrypted_cookies; .AspNetCore.Identity.Application=something_encrypted;
CF-Connecting-IP: 83.41.81.250
True-Client-IP: 83.41.81.250
CDN-Loop: cloudflare
HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0
Setelah diperiksa lebih dekat tempat pembuangan itu, perkataan itu disedari M.laga. Sangat mudah untuk meneka bahawa tidak ada bandar M.laga di Sepanyol (tetapi ada ). Dengan menggunakan idea ini, kami melihat konfigurasi Ingress, di mana kami melihat konfigurasi yang dimasukkan sebulan yang lalu (atas permintaan pelanggan) coretan "tidak berbahaya".:
ingress.kubernetes.io/configuration-snippet: |
proxy_set_header X-Nginx-Geo-Client-Country $geoip_country_name;
proxy_set_header X-Nginx-Geo-Client-City $geoip_city;Selepas melumpuhkan pemajuan pengepala ini, semuanya menjadi baik! (Tidak lama kemudian menjadi jelas bahawa aplikasi itu sendiri tidak lagi memerlukan pengepala ini.)
Sekarang mari kita lihat masalahnya secara umumnya. Ia boleh diterbitkan semula dengan mudah di dalam aplikasi dengan membuat permintaan telnet kepada localhost:80:
GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=Desiree
... kembali 401 Unauthorized, seperti yang diharapkan. Apa yang berlaku jika kita lakukan:
GET /back/user HTTP/1.1
Host: api.app.example.com
cache-control: no-cache
accept: application/json, text/plain, */*
origin: https://app.example.com
Cookie: test=DΓ©sirΓ©e?
Akan kembali 400 Bad request β dalam log aplikasi kami akan menerima ralat yang sudah biasa kepada kami:
{
"@t":"2019-03-31T12:59:54.3746446Z",
"@mt":"Connection id "{ConnectionId}" bad request data: "{message}"",
"@x":"Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Malformed request: invalid headers.n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1Connection.TryParseRequest(ReadResult result, Boolean& endConnection)n at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.<ProcessRequestsAsync>d__185`1.MoveNext()",
"ConnectionId":"0HLLLR1J974L9",
"message":"Malformed request: invalid headers.",
"EventId":{
"Id":17,
"Name":"ConnectionBadRequest"
},
"SourceContext":"Microsoft.AspNetCore.Server.Kestrel",
"ThreadId":71
}Keputusan
Khususnya Kestrel memproses pengepala HTTP dengan betul dengan aksara yang betul dalam UTF-8, yang terkandung dalam nama bilangan bandar yang agak besar.
Faktor tambahan dalam kes kami ialah pelanggan tidak merancang untuk mengubah pelaksanaan Kestrel dalam aplikasi pada masa ini. Walau bagaimanapun, isu dalam AspNetCore sendiri (, ) mereka mengatakan bahawa ini tidak akan membantu...
Untuk meringkaskan: nota itu bukan lagi mengenai masalah khusus Kestrel atau UTF-8 (pada 2019?!), tetapi mengenai fakta bahawa kesedaran dan kajian yang konsisten Setiap langkah yang anda ambil semasa mencari masalah lambat laun akan membuahkan hasil. Semoga berjaya!
PS
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «»;
- Β«'.
Sumber: www.habr.com