🥇ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆಗಿನ ಜೀವನದಿಂದ: HTTP ಸರ್ವರ್ ಸ್ಪೇನ್ ದೇಶದವರಿಗೆ ಹೇಗೆ ಒಲವು ತೋರಲಿಲ್ಲ

ಮೈಕ್ರೋಸಾಫ್ಟ್ ಕ್ಲೌಡ್ (ಅಜುರೆ) ನಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟಾಕ್ ವಾಸಿಸುವ ನಮ್ಮ ಕ್ಲೈಂಟ್‌ನ ಪ್ರತಿನಿಧಿಯು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಿದ್ದಾರೆ: ಇತ್ತೀಚೆಗೆ, ಯುರೋಪಿನ ಕೆಲವು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಕೆಲವು ವಿನಂತಿಗಳು ದೋಷ 400 ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿದವು (ಕೆಟ್ಟ ವಿನಂತಿ) ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು .NET ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ...

ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಒಂದು 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

ಗರಿಷ್ಟ ವಾಕ್ಚಾತುರ್ಯದೊಂದಿಗೆ ಸಹ, ಕೆಸ್ಟ್ರೆಲ್ ದೋಷವು ತುಂಬಾ ಒಳಗೊಂಡಿದೆ ಸ್ವಲ್ಪ ಉಪಯುಕ್ತ ಮಾಹಿತಿ:

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

ಫಲಿತಾಂಶಗಳು

ನಿರ್ದಿಷ್ಟವಾಗಿ ಕೆಸ್ಟ್ರೆಲ್ ಸಾಧ್ಯವಿಲ್ಲ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ನಗರಗಳ ಹೆಸರುಗಳಲ್ಲಿ ಒಳಗೊಂಡಿರುವ UTF-8 ನಲ್ಲಿ ಸರಿಯಾದ ಅಕ್ಷರಗಳೊಂದಿಗೆ HTTP ಹೆಡರ್‌ಗಳನ್ನು ಸರಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಅಂಶವೆಂದರೆ ಕ್ಲೈಂಟ್ ಪ್ರಸ್ತುತ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕೆಸ್ಟ್ರೆಲ್ ಅನುಷ್ಠಾನವನ್ನು ಬದಲಾಯಿಸಲು ಯೋಜಿಸುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, AspNetCore ನಲ್ಲಿಯೇ ಸಮಸ್ಯೆಗಳು (No.4318, No.7707) ಇದು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ ...

ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ: ಟಿಪ್ಪಣಿ ಇನ್ನು ಮುಂದೆ ಕೆಸ್ಟ್ರೆಲ್ ಅಥವಾ ಯುಟಿಎಫ್ -8 (2019 ರಲ್ಲಿ?!) ನ ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಅಲ್ಲ, ಆದರೆ ವಾಸ್ತವದ ಬಗ್ಗೆ ಸಾವಧಾನತೆ ಮತ್ತು ಸ್ಥಿರ ಅಧ್ಯಯನ ಸಮಸ್ಯೆಗಳನ್ನು ಹುಡುಕುತ್ತಿರುವಾಗ ನೀವು ತೆಗೆದುಕೊಳ್ಳುವ ಪ್ರತಿಯೊಂದು ಹೆಜ್ಜೆಯೂ ಬೇಗ ಅಥವಾ ನಂತರ ಫಲ ನೀಡುತ್ತದೆ. ಒಳ್ಳೆಯದಾಗಲಿ!

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

ಮೂಲ: www.habr.com

ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆಗಿನ ಜೀವನದಿಂದ: HTTP ಸರ್ವರ್ ಸ್ಪೇನ್ ದೇಶದವರಿಗೆ ಹೇಗೆ ಒಲವು ತೋರಲಿಲ್ಲ

ತನಿಖೆ

ಫಲಿತಾಂಶಗಳು

ಪಿಎಸ್

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ Отменить ответ