主持人 > 博客 > 管理 > 來自 Kubernetes 的生活：HTTP 伺服器為何不利於西班牙人

來自 Kubernetes 的生活：HTTP 伺服器為何不利於西班牙人

來自 Kubernetes 的生活：HTTP 伺服器為何不利於西班牙人

我們的客戶代表（其應用程式堆疊駐留在 Microsoft 雲端 (Azure) 中）解決了一個問題：最近，來自歐洲的一些客戶的一些請求開始以錯誤 400 結束（錯誤的請求）。 所有應用程式均以 .NET 編寫，部署在 Kubernetes 中...

應用程式之一是 API，所有流量最終都通過它。 此流量由 HTTP 伺服器監聽 紅隼，由 .NET 用戶端配置並託管在 Pod 中。 透過調試，我們很幸運，因為有一個特定的用戶始終重現了這個問題。 然而，流量鏈讓一切變得複雜：

來自 Kubernetes 的生活：HTTP 伺服器為何不利於西班牙人

Ingress 中的錯誤如下所示： 

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

同時，Kestrel 給出了：

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 才能幫助解決這個問題...但我會重複一下流量鏈：

來自 Kubernetes 的生活：HTTP 伺服器為何不利於西班牙人

調查

顯然，最好聽聽交通狀況 在該特定節點上，其中 Kubernetes 部署了一個 pod：轉儲量將使得至少很快就能找到一些東西。 事實上，在檢查它時，請注意到以下框架：

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 配置，我們看到了一個月前插入的配置（應客戶的要求） 「無害」片段:

    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;

禁用這些標頭的轉發後，一切都變得很好！ （很快就發現應用程式本身不再需要這些標頭。）

現在我們來看看問題 更普遍。 透過向應用程式發出 telnet 請求，可以輕鬆地在應用程式內重現它 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 標頭，這些字元包含在相當多的城市名稱中。

在我們的案例中，另一個因素是客戶目前不打算更改應用程式中 Kestrel 的實現。 然而，AspNetCore 本身的問題（№4318, №7707）他們說這沒有幫助......

總結一下：該說明不再是關於 Kestrel 或 UTF-8 的具體問題（2019 年？！），而是關於以下事實： 正念和持續的學習 你在尋找問題時所採取的每一步遲早都會取得成果。 祝你好運！

聚苯乙烯

另請閱讀我們的博客：

來源： www.habr.com

添加評論