🥇কুবারনেটসের জীবন থেকে: কীভাবে 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 নিজেই সমস্যাগুলি (№4318, №7707) তারা বলে যে এটি সাহায্য করবে না ...

সংক্ষেপে বলা যায়: নোটটি আর কেস্ট্রেল বা UTF-8 (2019 সালে?!) এর নির্দিষ্ট সমস্যাগুলি সম্পর্কে নয়, তবে এই সত্যটি সম্পর্কে মননশীলতা এবং ধারাবাহিক অধ্যয়ন সমস্যাগুলি অনুসন্ধান করার সময় আপনি যে প্রতিটি পদক্ষেপ গ্রহণ করেন তা শীঘ্রই বা পরে ফল দেবে। শুভকামনা!