java - 如何在 ELB 中使用 aws 应用程序生成的 session 粘性

Question

我一直在努力解决这个问题。

我在 ELB 后面的两个 EC2 实例上实现了一个非常简单的 HTTP 服务器。HTTP 服务器仅从 header 中读取 cookie，并在响应 header 中使用相同的 cookie 发回响应。

在客户端，我使用

curl --cookie "mychannelid=mytest; Expires=Sat, 27-Jun-2017 02:48:17 GMT" --header "Accept-Language: en" "http://myelb.elb.amazonaws.com:8000/test"

此外，在 elb 上，我使用 cookie 名称 mychannelid 启用了应用程序粘性。但是当我运行这个系统时，我仍然得到 50/50 的服务器分配。我该如何实现？

另外一个信息是，如果在HTTP服务器上生成cookie，并发回给客户端，同样，我需要用firefox访问HTTP服务器，那么我就可以得到我想要的东西。如果我用 curl 访问 HTTP 服务器，我不能。我不知道为什么，我检查了数据包，cookie 在 header 中。

Answer 1

当使用 Application-Controlled Session Affinity 时，ELB 在技术上不会根据您的应用程序 cookie 来决定粘性，相反，它会分配它自己的 AWSELB cookie，类似基于持续时间的 cookie，但遵循与您的应用程序 cookie 相同的到期日期。因此，每当浏览器(或任何其他客户端)返回 ELB 时，它应该发送两个 Cookie 而不仅仅是应用程序 Cookie。

首先，我们需要一个常规的 curl，而不是像您使用 --cookie "mychannelid=mytest" 那样发送 cookie，而是将收到的 cookie 保存到一个文件中名为 cookies.txt:

curl -c cookies.txt -v http://example.com/cookie.php 

(注意服务器上的cookie.php需要设置应用程序cookie，对我来说，我称之为STICKINESSID并将值设置为tomtest31mar1030)

显示正在返回 cookie 的 curl 输出:

...
* Added cookie STICKINESSID="tomtest31mar1030" for domain example.com, path /, expire 1459525228
< Set-Cookie: STICKINESSID=tomtest31mar1030; expires=Fri, 01-Apr-2016 15:40:28 GMT
* Added cookie AWSELB="85937D8F08DC213046BA84053FDD6504FB203E36C25DA455A6835969F6D49F8DF9878D0F954A8EC75B8EE2AE208ECFE0AC2CE02E2EDE8DD014D2F17F4C80301EDBC4AE5CC3EBD730BD3127FF8DAAD636359B592B73" for domain example.com, path /, expire 1459525228
< Set-Cookie: AWSELB=85937D8F08DC213046BA84053FDD6504FB203E36C25DA455A6835969F6D49F8DF9878D0F954A8EC75B8EE2AE208ECFE0AC2CE02E2EDE8DD014D2F17F4C80301EDBC4AE5CC3EBD730BD3127FF8DAAD636359B592B73;PATH=/;EXPIRES=Fri, 01-Apr-2016 15:40:28 GMT
...

即创建了一个包含 STICKINESSID 和 AWSELB cookie 的文件 cookies.txt:

$ cat cookies.txt 

#  Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

example.com FALSE   /   FALSE   1459525228  STICKINESSID    tomtest31mar1030
example.com FALSE   /   FALSE   1459525228  AWSELB  85937D8F08DC213046BA84053FDD6504FB203E36C25DA455A6835969F6D49F8DF9878D0F954A8EC75B8EE2AE208ECFE0AC2CE02E2EDE8DD014D2F17F4C80301EDBC4AE5CC3EBD730BD3127FF8DAAD636359B592B73

现在，有了保持粘性所需的两个 cookie，让我们测试在请求中发送它们:

$ for i in {1..20}; do curl --silent -b cookies.txt http://example.com/cookie.php | grep Instance; done
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
Instance Id: <b>i-xxxxxxxx</b><br/>Zone: <b>eu-west-1b</b><br/>Internal IP: <b>10.0.0.21</b><br/>
...

(假设http://example.com/cookie.php输出了一些调试信息，可以看到ELB后面实例的IP，可以测试粘性)

这表明，粘性在多个请求中得以保留。在没有 -b cookies.txt 的情况下尝试相同的测试以测试没有粘性。