🥇कुबरनेटसह जीवनापासून: HTTP सर्व्हरने स्पॅनिश लोकांना कसे अनुकूल केले नाही

आमच्या क्लायंटचा एक प्रतिनिधी, ज्यांचे ऍप्लिकेशन स्टॅक Microsoft क्लाउड (Azure) मध्ये राहतात, त्यांनी एका समस्येचे निराकरण केले: अलीकडे, युरोपमधील काही क्लायंटच्या काही विनंत्या त्रुटी 400 सह समाप्त होऊ लागल्या (वाईट विनंती). सर्व अर्ज .NET मध्ये लिहिलेले आहेत, Kubernetes मध्ये उपयोजित आहेत...

अनुप्रयोगांपैकी एक API आहे, ज्याद्वारे सर्व रहदारी शेवटी येते. ही रहदारी HTTP सर्व्हरद्वारे ऐकली जाते केस्ट्रल, .NET क्लायंटद्वारे कॉन्फिगर केलेले आणि पॉडमध्ये होस्ट केलेले. डीबगिंगसह, आम्ही या अर्थाने भाग्यवान होतो की एक विशिष्ट वापरकर्ता होता ज्याने समस्या सातत्याने पुनरुत्पादित केली. तथापि, वाहतूक साखळीमुळे सर्व काही गुंतागुंतीचे होते:

इंग्रेसमधील त्रुटी यासारखी दिसली:

{
   "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":{}
}

त्याच वेळी, केस्ट्रेलने दिले:

HTTP/1.1 400 Bad Request
Connection: close
Date: Wed, 06 Mar 2019 12:34:20 GMT
Server: Kestrel
Content-Length: 0

कमाल शब्दशः जरी, Kestrel त्रुटी अत्यंत समाविष्टीत आहे थोडी उपयुक्त माहिती:

{
   "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":{}
}

असे दिसते की केवळ tcpdump या समस्येचे निराकरण करण्यात मदत करेल... परंतु मी ट्रॅफिक साखळीबद्दल पुन्हा सांगेन:

तपास

अर्थात, रहदारी ऐकणे चांगले आहे त्या विशिष्ट नोडवर, जेथे कुबर्नेट्सने एक पॉड तैनात केला आहे: डंपचे प्रमाण इतके असेल की कमीतकमी काहीतरी लवकर शोधणे शक्य होईल. आणि खरंच, त्याचे परीक्षण करताना, खालील फ्रेम लक्षात आली:

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

कचऱ्याची जवळून पाहणी केल्यावर हा शब्द लक्षात आला M.laga. स्पेनमध्ये M.laga शहर नाही असा अंदाज लावणे सोपे आहे (परंतु तेथे आहे मलागा). या कल्पनेचा फायदा घेत, आम्ही इंग्रेस कॉन्फिग्सकडे पाहिले, जिथे आम्ही एक महिन्यापूर्वी घातलेले पाहिले (क्लायंटच्या विनंतीनुसार) "निरुपद्रवी" स्निपेट:

    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;

या शीर्षलेखांचे फॉरवर्डिंग अक्षम केल्यानंतर, सर्वकाही ठीक झाले! (हे लवकरच स्पष्ट झाले की अनुप्रयोगाला या शीर्षलेखांची आवश्यकता नाही.)

आता समस्या पाहू अधिक सर्वसाधारणपणे. टेलनेट विनंती करून ते सहजपणे ऍप्लिकेशनमध्ये पुनरुत्पादित केले जाऊ शकते 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

... परत येतो 401 Unauthorized, अपेक्षेप्रमाणे. आम्ही असे केल्यास काय होईल:

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

परत येईल 400 Bad request — ऍप्लिकेशन लॉगमध्ये आम्हाला एक त्रुटी प्राप्त होईल जी आम्हाला आधीच परिचित आहे:

{
   "@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
}

परिणाम

विशेषतः Kestrel करू शकत नाही UTF-8 मधील योग्य वर्णांसह HTTP शीर्षलेखांवर योग्यरित्या प्रक्रिया करा, जे मोठ्या संख्येने शहरांच्या नावांमध्ये समाविष्ट आहेत.

आमच्या बाबतीत एक अतिरिक्त घटक असा आहे की क्लायंट सध्या अनुप्रयोगात केस्ट्रेलची अंमलबजावणी बदलण्याची योजना करत नाही. तथापि, AspNetCore मध्येच समस्या (नं. 4318, नं. 7707) ते म्हणतात की हे मदत करणार नाही ...

थोडक्यात: टीप आता केस्ट्रेल किंवा UTF-8 (2019 मध्ये?!) च्या विशिष्ट समस्यांबद्दल नाही, परंतु वस्तुस्थितीबद्दल आहे जागरूकता आणि सातत्यपूर्ण अभ्यास समस्यांचा शोध घेत असताना तुम्ही उचललेले प्रत्येक पाऊल लवकरच किंवा नंतर फळ देईल. शुभेच्छा!

PS

आमच्या ब्लॉगवर देखील वाचा:

स्त्रोत: www.habr.com

कुबर्नेट्ससह जीवनापासून: HTTP सर्व्हरने स्पॅनिश लोकांना कसे अनुकूल केले नाही

तपास

परिणाम

PS

एक टिप्पणी जोडा Отменить ответ