Socket.io: ELB 뒤에 있는 AWS EC2는 항상 오류를 인쇄합니다. 예기치 않은 응답 코드: 400

또한 중요한 경우 bower를 통해 설치했습니다.

"socket.io-client": "~1.1.0",

서버에 고정 연결이 있습니까?

Elastic Beanstalk를 사용하지 않는다고 가정합니다(지침이 훨씬 쉬울 것입니다).

EC2->네트워크 및 보안->로드 밸런서로 이동합니다.

로드 밸런서를 선택하고 리스너로 이동하십시오. 로드 밸런서 프로토콜과 인스턴스 프로토콜이 HTTP 및 HTTPS가 아닌 포트 80의 경우 TCP로, 포트 443의 경우 SSL로 설정되어 있는지 확인하십시오.

이런. 이것은 내가 다른 곳에서 본 적 없는 확실한 조언입니다. 오전에 해볼게
그리고 다시 보고합니다. 감사합니다!

2014년 10월 29일 수요일 오후 7:48 Vadim Kazakov [email protected]
썼다:

Elastic Beanstalk를 사용하지 않는다고 가정합니다(여기에 있는 지침은
훨씬 쉽게).

EC2->네트워크 및 보안->로드 밸런서로 이동합니다.

로드 밸런서를 선택하고 리스너로 이동하십시오. 두 로드 모두
밸런서 프로토콜 및 인스턴스 프로토콜은 포트 80에 대해 TCP로 설정되고
HTTP 및 HTTPS가 아닌 포트 443용 SSL.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Automattic/socket.io/issues/1846#issuecomment -61038664
.

그래서 내가 틀렸을 수도 있지만 우리 사이트는 HTTPS에서 실행되고 있습니다(SSL 인증서 사용). 그것들을 변경하면 많은 것들이 중단됩니다. 내 앱에서 X-Forwarded-Proto를 확인하여 요청이 HTTPS인지 확인하고 그렇지 않은 경우 강제로 리디렉션했습니다. 분명히 SSL/TCP가 있는 X-Forwarded-Proto 헤더가 없고 Express는 req.secure를 false로 보고합니다(내가 https를 입력했음에도 불구하고).

제안?

확실하지 않습니다. 소켓은 HTTP가 아닌 TCP/SSL 프로토콜을 사용하므로 웹 소켓이 작동하려면 TCP/SSL로 변경해야 합니다. 앱의 나머지 부분을 수정하는 방법에 대해서는 잘 모르겠습니다.

도와 주셔서 감사합니다. 새로운 환경을 만들고 좀 어지럽혀야 겠습니다. 기계에 톱니가 많이 있습니다!

웹 소켓을 자체 포트에서 실행할 수 있습니까? 그렇다면 몇 가지 문서를 연결할 수 있습니까? (없을수도 있지만 틀릴수도 있음)

원하는 포트에서 작동할 수 있습니다. 다음과 같이 포트를 연결할 때 지정하기만 하면 됩니다.

io('https://myserver:123');

Elasticbeanstalk를 사용 중이고 동일한 문제에 직면해 있습니다. SSL이 설치되어 있지 않지만 일반 http를 통해 연결되어 있습니다.

안녕,
SockJS를 사용하고 있지만 동일한 문제가 있습니다.
내 응용 프로그램은 Java Spring 4 응용 프로그램이며 개발 시스템에서 작동하며
AWS에서 동일한 오류가 발생합니다.
누군가가 업그레이드 헤더를 삭제한 것 같습니다. 클라이언트에서 볼 수 있습니다.

아직 해결책을 찾을 수 있습니다 ...

저는 같은 배를 타고 AWS 엔지니어와 실시간 채팅을 하고 있는데 둘 다 어리둥절합니다. ELB를 HTTP/HTTPS에서 TCP(또는 SSL(Secure TCP))로 변경해야 함을 확인했지만 여전히 400 오류가 자주 발생합니다. Elastic Beanstalk 부하 분산 클러스터로 이동할 때까지 이 문제가 발생하지 않았습니다.

app.use 미들웨어 항목(헤더/cors 관련)이 있는 경우, 또는 app.get("/", 어느 것이 저에게 효과가 있었는지 확실하지 않지만 결과를 게시해 주십시오.

업데이트: HTTP 또는 HTTPS 트래픽에 대해 구성되었는지 여부에 관계없이 socket.io가 실패하는 ELB임을 확인했습니다. EC2 중 하나로 직접 이동하면 모든 것이 훌륭하게 작동합니다.

첨부 파일은 ELB를 통과할 때 보고 있는 것입니다.

로드 밸런서 앞에 Route53 인스턴스를 추가하여 문제를 해결한 것 같습니다.
이제 AWS 환경에서 보안 연결로 작동하는 웹 소켓이 있습니다.

Route 53을 추가해 보십시오. 이렇게 해도 문제가 해결되지 않으면 구성을 공유해 드리겠습니다.

@yoav200 당신을 위해 일하게 만든 당신의 전체 구성을 공유할 수 있다고 생각하십니까? 즉, EBS 보안 + 프로토콜(http/tcp)의 포트, 필요한 모든 .ebextensions 등. 업그레이드 헤더를 유지하고 노드로 보내기 위해 내 nginx 구성을 해킹하기 위해 수많은 다른 일을 시도했지만 아무 것도 효과가 없었습니다. . FWIW - wiki 페이지는 이것에 정말, 정말 도움이 될 것입니다. 효과가 있었던 것은 내 EC2 인스턴스로 직접 이동하는 것뿐이었습니다.

내 도메인을 관리하는 Route 53 인스턴스를 설정했습니다.
내 도메인이 로드 밸런서를 직접 가리키는 레코드로 호스팅 영역을 구성했습니다.

로드 밸런서는 다음과 같이 내 Tomcat 인스턴스에 요청을 전달하도록 구성됩니다.

ELB용 보안 그룹은 매우 표준적입니다.

nginx를 사용하고 있습니까? 특별한 구성을 해야 했나?

지난 2일 동안 AWS 지원 엔지니어와 거의 8시간을 보냈습니다. 혼합에서 nginx를 추출해야 했지만 매우 가깝고 소켓은 http를 통해 ELB를 통해 잘 작동합니다. 내일은 ELB 수준 대신 서버 측에서 https 항목을 처리할 수 있다고 생각합니다.

나는 나의 발견과 함께 다시 보고할 것이다.

나는 nginx를 사용하지 않고 Amazon에서 모든 것을 관리하고 내 도메인도 Amazon으로 옮겼습니다.
그러나 인스턴스에 AWS를 사용하지만 nginx로 부하를 관리하는 호스팅된 클라우드 환경에서 내 애플리케이션을 마이그레이션했는데 문제가 없었습니다.

어떻게 작동하는지 물었을 때 그들의 대답은 다음과 같았습니다.

우리는 Amazon Elastic Load Balancer를 사용하지 않고 자체 NGinx 로드 밸런싱 계층을 사용합니다.
솔루션은 ELB 대신 Nginx 또는 HAProxy 서버를 사용하고 1개의 haproxy/nginx 노드가 있는 자동 크기 조정 그룹을 사용하여 구성 요소의 고가용성을 보장하는 것일 수 있습니다.

예, HAProxy가 또 다른 옵션이라고 들었지만 하루가 끝날 때까지 다음 서비스와 함께 작동하게 할 것이라고 확신합니다.

• Elastic Beanstalk
• ELB
• EC2 Autoscaling 그룹(EB에서 생성)
• RDS
• 엘라스티캐시

노드 앱은 현재 이러한 모든 서비스와 함께 작동하고 있지만 내가 말했듯이 HTTP를 통해서만 가능하므로 프로덕션 준비를 위해 할 일이 많지 않습니다. 나중에 찾은 결과/구성으로 다시 보고하겠습니다.

@niczak 어떻게 작동하는지 조금 공유해 주시겠습니까?

지금은 ElastiCache의 Redis를 사용하여 EC2의 Node 인스턴스에서 Socket.IO에 연결하려고 합니다.

소켓(http://coding-ceo.ghost.io/how-to-run-socket-io-behind)에 쉽게 연결할 수 있도록 공개 IP 주소로 응답과 함께 EC2 인스턴스를 공개했습니다. -elb-on-aws/). 내 ELB에서 고정 세션을 사용하고 있지만(연결된 상태로 유지되기를 바랍니다) 소켓이 여전히 연결되지 않고 멋진 실패 메시지가 표시됩니다. 핸드셰이크 응답을 받기 전에 연결이 닫혔습니다.

폴링은 잘 작동하지만 소켓과 전체 경로가 제대로 작동하도록 하려고 합니다.

여기에서 사용 사례를 보고 싶습니다. 그래서 내 인스턴스를 적절하게 구성할 수 있습니다(http 및 https가 아닌 HTTP에만 있는 경우에도). 지금 꽤 오랫동안 스스로를 몰아붙이고 있기 때문입니다.

도와 주셔서 정말 감사합니다!

@페트로가드

이봐 피트!

내 ELB 리스너는 가능한 한 간단하며(이미지 참조) 기본적으로 EC2 포트 80에서 iptables를 사용하여 8080으로 전달됩니다. 즉, HTTPS에서 내 서버에 도달하면 내 노드 앱이 8080에서 수신 대기하고 SSL 인증서 자체를 제공합니다.

인증서 처리를 위한 노드 코드는 다음과 같습니다.

        files = ["COMODOHigh-AssuranceSecureServerCA.crt", "AddTrustExternalCARoot.crt"];
        ca = (function() {
            var _i, _len, _results;
            _results = [];
            for (_i = 0, _len = files.length; _i < _len; _i++) {
                file = files[_i];
                _results.push(fs.readFileSync('/etc/ssl/tcerts/' + file));
            }
            return _results;
            })();

        httpsOptions = {
            ca: ca,
            key: fs.readFileSync('/etc/ssl/tcerts/multidomain.key', 'utf8'),
            cert: fs.readFileSync('/etc/ssl/tcerts/14432575.crt', 'utf8')
        };

        this.serverPort = 8080;
        var httpsServer = https.createServer(httpsOptions, apiInstance);
        httpsServer.listen(this.serverPort);
        startSockets(httpsServer);

웹 소켓이 작동하려면(긴 폴링으로 돌아가지 않고) Cross-Zone Load Balancing을 비활성화해야 했습니다. 불행히도 AWS는 ELB를 통해 웹 소켓을 지원한다고 주장하지 않으므로 이러한 유형의 구성 "해킹"이 필요합니다. 바라건대 이것은 당신을 시작하고 실행하기에 충분할 것입니다!

@niczak 감사

모든 것이 완벽하게 작동하고 HTTP 트래픽이 발생하여 문제가 발생했습니다. 또한 여러 인스턴스에서 redis가 작동합니다. 마지막은 reCluster에서 작업하고 tcp 경로가 특정 작업자에 고정되도록 허용하는 것입니다.

이것으로 많은 성공을 거두셨습니까? 나는 익스프레스를 사용하고 있으므로 고정 세션 이 잘 작동하지 않습니다. 그런 행운이 있었나요?

다시 한 번 감사드리며 이 모든 것이 완료되면 유사한 항목으로 어려움을 겪고 있는 다른 사람들을 위해 멋진 블로그 게시물을 얻을 수 있기를 바랍니다.

@niczak 감사

드디어 나도 일을 하게 되었다. 그러나 구성에 추가로
1) TCP 프로토콜을 사용하는 로드 밸런서
2) 교차 영역 로드 밸런싱을 비활성화하는 로드 밸런서

나도 설정해야지
3) 소프트웨어 구성 섹션에서 프록시 서버가 "없음"이어야 합니다.

좋은 소식입니다 @aidanbon 및 @petrogad , AWS의 소켓에 대한 허자입니다! :+1:

정말 감사합니다! 탄성 콩나무로 문제를 해결했습니다. nginx 프록시를 제거하는 것이 합리적입니다.

내 원래 게시물의 업데이트:

내 HTTPS를 SSL(443 ---> 내 사용자 지정 포트)로 변경하고 HTTP(80 ---> 내 사용자 지정 포트)를 남겼습니다.

익스프레스 !req.secure && X-Forwarded-Proto !=== 포트 80으로 들어오는 경우 HTTPS로 리디렉션하는 https로 확인하는 코드가 있습니다...

하지만

SSL로 변경하면 X-Forwarded-Proto가 정의되지 않은 상태로 돌아옵니다.... 이 연결이 끊어집니다. (또한 req.secure가 더 이상 사용되지 않는 것처럼 보입니다)

그래서 지금:

if (req.get('X-Forwarded-Proto') === 'http') {
            res.redirect('https://' + req.get('Host') + req.url);
        }

잘 작동하는 것 같고 콘솔에 더 이상 400 오류가 발생하지 않습니다.

Hullo - 다음을 수행하는 Elastic Beanstalk의 Node, NGINX, SSL 및 ELB를 사용하여 이 작업을 수행했습니다.

.ebextensions에서 컨테이너 명령을 만들어 프록시 웹 소켓을 포함하도록 nginx 구성 스크립트를 수정합니다.

container_commands:
    00proxy:
        command: sed -i 's/proxy_http_version.*/proxy_http_version\ 1.1\;\n\ \ \ \ \ \ \ \ proxy_set_header\ \ \ \ \ \ \ \ Upgrade\ \ \ \ \ \ \ \ \ \$http_upgrade\;\n\ \ \ \ \ \ \ \ proxy_set_header\ \ \ \ \ \ \ \ Connection\ \ \ \ \ \ \"upgrade\"\;/g' /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf

Elastic Beanstalk 웹 콘솔을 사용하여 로드 밸런서에 SSL 인증서를 설치합니다.

그런 다음 EC2 웹 콘솔로 이동하여 SSL 443 -> TCP 80에서 수신 대기하도록 로드 밸런서를 변경합니다. EB 웹 콘솔에서 변경할 때는 작동하지 않았고 EC2에서 직접 변경해야 했습니다.

모든 것이 작동해야 합니다. 리디렉션을 수행할 필요가 없었고 NGINX도 작동하도록 했습니다.

@ChrisEdson 이 솔루션을 사용하기 위해 패키지에 포함할 다른 것이 있습니까?
시도했지만 오류로 인해 배포에 실패했습니다. 로그에는 다음 행이 표시됩니다.

/etc/init.conf: Unable to load configuration: No such file or directory

코드를 게시할 수 있습니까?

2015년 9월 4일 금요일 오후 1시 13분에 Treyone [email protected]에서 다음과 같이 썼습니다.

@ChrisEdson 이 솔루션을 사용하기 위해 패키지에 포함할 다른 것이 있습니까?
시도했지만 오류로 인해 배포에 실패했습니다. 로그에는 다음 행이 표시됩니다.

/etc/init.conf: Unable to load configuration: No such file or directory

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment -137718880

앱 코드는 매우 기본적인 socket.io 구현으로 거의 즉시 사용 가능한 예제 사용법입니다.
내가 추가한 유일한 것은 .ebextensions의 .config 파일입니다. 이 파일에서 앞서 인용한 코드 조각을 복사했습니다.
그래서 포스팅할게 별로 없네요 :)

걱정하지 마세요. 코드나 로그 없이는 디버그하기 어렵습니다. 로그를 게시할 수 있습니까? 아마도 여기에 붙이기에 적합하지 않을 것입니다. 아마도 붙여넣기 상자에 넣을 것입니다.

2015년 9월 4일 금요일 오후 3시 26분에 Treyone [email protected]에서 다음과 같이 썼습니다.

앱 코드는 매우 기본적인 socket.io 구현으로 거의 즉시 사용 가능한 예제 사용법입니다.
내가 추가한 유일한 것은 .ebextensions의 .config 파일입니다. 이 파일에서 앞서 인용한 코드 조각을 복사했습니다.

그래서 포스팅할게 별로 없네요 :)

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment -137749890

흠, 수동 패키징 대신 grunt를 통해 코드를 게시했으며 매력처럼 작동합니다. 자동화는 필수입니다 ;)

그것을 듣고 기뻐!

2015년 9월 8일 화요일 오후 3시 14분에 Treyone [email protected]에서 다음과 같이 썼습니다.

흠, 수동 패키징 대신 grunt를 통해 코드를 게시했으며 매력처럼 작동합니다. 자동화는 필수입니다 ;)

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment -138572724

내 하루를 저장!

우리는 이 기본적인 문제도 보았습니다. 기본적으로 SocketIO는 웹 소켓 연결을 설정하기 위해 두 개의 요청을 보내기 때문에 이러한 호출이 인스턴스 간에 연합되면 세션 ID가 인식되지 않고 핸드셰이크가 실패하여 SocketIO가 긴 폴링으로 되돌아갑니다. 이것은 ws 또는 wss를 사용하는지 여부에 관계없이 사실입니다. 웹 소켓과 작동하도록 레이어 7(HTTP) 로드 밸런싱을 가져올 수 없으므로 레이어 4(TCP)에서 로드 밸런싱을 설정했다고 가정합니다.

수정 사항은 고정 세션을 활성화하여 호출이 인스턴스로 넘어가면 로드 밸런서가 계속해서 해당 요청을 동일한 인스턴스로 보내도록 하는 것입니다. 그러나 AWS의 ELB를 사용하는 경우 레이어 4 로드 밸런싱에 고정 세션을 사용할 수 없습니다.

우리가 결국 한 것은 SocketIO가 아닌 원시 웹 소켓을 사용하는 것이었습니다. 그러면 호출 간에 지속되어야 하는 세션 데이터가 없기 때문입니다(단 한 번의 호출, 핸드셰이크가 발생하고 작동함).

AWS 측의 수정 사항은 고정 세션이 레이어 4 로드 밸런싱에 어떤 방식으로든 사용될 수 있도록 하는 것입니다.

SocketIO 측의 수정 사항은 websocket 핸드셰이크가 이전 sessionID의 컨텍스트를 필요로 하지 않도록 만드는 것입니다. 연결 종료 시 신속하게 재연결, 클라이언트가 연결이 끊어졌다고 판단하면 연결이 이미 존재한다고 믿었기 때문에 백엔드가 핸드셰이크를 거부하도록 하는 대신 새 세션을 생성하고 성공적으로 다시 연결할 수 있습니다.

잠재적 수정은 Redis를 사용하여 모든 인스턴스에서 세션 상태를 유지하는 것입니다. 나는 이것을 테스트하지 않았다.

부하가 허용하는 경우 해결 방법은 가용성 영역당 단일 노드 인스턴스만 확인하고 영역 간 부하 분산을 비활성화하는 것입니다. 그렇게 하면 모든 호출이 기본적으로 단일 노드로 설정되어 이 문제를 피할 수 있습니다.

@aidanbon Proxy server to be "none" in the Software Configuration section 찾을 수 없습니까?

나는 단순히 우분투 서버와 mup 배포와 함께 MeteorJS를 사용하고 있습니다. 링크를 주시겠습니까 ??

건배

@sahanDissanayake 다음을 통해 프록시 서버 구성 옵션을 찾았습니다.

1. 관심 환경에서 "구성"을 클릭하십시오.
2. 구성 페이지에서 "소프트웨어 구성"을 클릭하십시오.
3. 이전 스크린샷과 같이 "프록시 서버" 드롭다운입니다.

참고: 내 환경은 거의 1년 전에 프로비저닝되었습니다. AWS 패널이 최신 환경에 맞게 업데이트되었는지 확실하지 않습니다. 그러나 오늘날에도 내 환경에서 이 드롭다운을 볼 수 있습니다.

@aidanbon 나는 ec2.. 이외의 다른 서비스를 사용하지 않으므로 설정이 나와 관련이 없습니까? 아니면 이 poxy 서버를 사용하기 시작해야 합니까?

그래서 내가 가진 문제는 내 웹 앱 웹 소켓이 포트 8080에서 작동하지만 포트 80에서는 작동하지 않는다는 것입니다.

이것이 문제다

@lostcolony 요약 감사합니다. 나는 같은 결론에 도달했다. 이 블로그 게시물을 읽었습니까? https://medium.com/@Philmod/load -balancing-websockets-on-ec2-1da94584a5e9#.hd2ectz8t? 그는 본질적으로 레이어 4(TCP)를 HAProxy 인스턴스로 전달할 수 있다고 말하고 있습니다. 그러면 HAProxy 인스턴스는 PROXY 헤더를 제거하고 고정 세션을 사용하여 트래픽을 올바른 인스턴스로 라우팅합니다. 그러나 두 HAProxy가 "백엔드" 서버 목록을 구성하는 방법과 실행 위치 및 실제 socket.io 서버가 실행되는 위치는 분명하지 않습니다. 당신은 그것을 이해할 수 있습니까?

편집: 나는 지금 클릭했다고 생각합니다. 그는 알려진 서버 세트를 가지고 있고 자동 크기 조정에 대해 신경 쓰지 않기 때문에 목록을 알고 있습니다...

서버 목록은 각 HAproxy 상자에 구성됩니다. 잘 모르겠어
일부를 작성하지 않는 한 Auto Scaling ec2 인스턴스에서 작동하도록 하려면
새 서버가 왔을 때 해당 목록을 업데이트하기 위한 추가 인프라
온라인. Socket.io 그들은 웹 앱과 동일한 서버에서 실행 중이므로
Elb를 통해 들어오는 연결은 HAproxy 인스턴스에 연합됩니다.
HAproxy 인스턴스는 IP 연결이 항상 동일한 위치로 이동하도록 합니다.
socket.io가 설정된 웹/앱 서버입니다.
2016년 1월 13일 오전 2시 50분에 "Felix Schlitter" [email protected]이 다음과 같이 썼습니다.

@lostcolony https://github.com/lostcolony 요약 감사합니다. 나
같은 결론에 도달했습니다. 이 블로그 게시물을 읽었습니까?
https://medium.com/@Philmod/load -balancing-websockets-on-ec2-1da94584a5e9#.hd2ectz8t?
그는 본질적으로 레이어 4(TCP)를
HAProxy 인스턴스는 PROXY 헤더를 제거하고
고정 세션을 사용하여 올바른 인스턴스로 트래픽을 전송합니다. 그러나 그렇지 않다
두 HAProxy가 "백엔드" 서버 목록을 얻는 방법이 분명합니다.
구성되고 실행되는 위치와 실제 socket.io 서버가 실행되는 위치.
당신은 그것을 이해할 수 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment -171208211
.

@lostcolony 좋아요, . 내가 얻지 못하는 것은 HAProxy 앞에서 ELB를 사용하는 이유입니다. HAProxy 인스턴스는 하나만 있어야 합니다. 그렇지 않으면 ELB가 올바른 HAProxy 인스턴스로 트래픽을 전송한다고 어떻게 보장할 수 있습니까? 그들(HAProxy 인스턴스)이 ElastiCache 또는 Redis 또는 이러한 라인을 따라 무언가를 사용하여 어떻게든 공통 고정 테이블을 공유하지 않는 한? ... 우리가 주제에서 _way_ 가고 있다는 것을 알고 있습니다.

IP를 기반으로 연결을 라우팅하도록 구성된 HAProxies가 있는 경우
같은 인스턴스에서 끝날 것이라고 보장할 수 있습니다. 즉, HAProxies가
모두 ip ABCD가 인스턴스 1로 연결된다는 동일한 규칙을 가졌습니다.
그런 다음 어떤 HAProxy가 ELB 히트에 관계없이 동일하게 종료됩니다.
장소. 그것이 당신이 보낸 링크에서 일어나는 일입니다. 균형을 잡고 있습니다.
소스를 통해, 즉 HAProxy 인스턴스가 IP를 해시하고 이를 사용하여
어떤 인스턴스로 이동하는지 결정합니다. 여러 HAProxies(모두 제공됨)
동일한 인스턴스에 대해 알고 있으므로 한 위치에서 다음으로 트래픽을 보냅니다.
동일한 백엔드 인스턴스.

2016년 1월 13일 수요일 오후 1:19, Felix Schlitter [email protected]
썼다:

@lostcolony https://github.com/lostcolony 좋습니다 .
HAProxy를 사용하여 Amazon의 자동 크기 조정과 관련된 흥미로운 프로젝트 -
최소한 참조용으로 유용합니다.
https://github.com/markcaudill/haproxy-autoscale. 내가 이해하지 못하는 이유는
HAProxy 앞에서 ELB를 사용하시겠습니까? HAProxy 인스턴스는 하나만 있어야 합니다.
그렇지 않으면 ELB가 트래픽을 오른쪽으로 보내는 것을 어떻게 보장할 수 있습니까?
HAProxy 인스턴스? 그것들(HAProxy 인스턴스)이 공통
어떻게 든 ElastiCache 또는 Redis 또는 그와 함께 무언가를 사용하는 고정 테이블
윤곽? ... 우리가 주제에서 _way_ 가고 있다는 것을 알고 있습니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment -171386260
.

@lostcolony 해시가 주어진 IP에 대해 결정적으로 파생된다는 것을 이해하지만 "해시 -> 인스턴스"의 매핑이 있어야 합니다. 귀하의 경우 "ABCD는 인스턴스 1로 지정됩니다"라는 규칙이 있지만 사용 가능한 서버 목록이 주어지면 HAProxy가 리디렉션할 위치를 스스로 결정하는 것을 원하지 않습니까? 결국 "ABCD"는 일부 클라이언트의 IP일 뿐이며 사전에 알려지지 않았습니다.

해시를 인스턴스에 매핑하는 규칙은 모든 HAProxy에서 동일합니다.
인스턴스. 즉, ABCD는 결과에 관계없이 동일한 해시를 생성합니다.
적중하는 HAProxy 인스턴스 및 해당 해시는 동일한 서버에 매핑됩니다.
모든 HAProxy가 알고 있는 경우 사용 중인 HAProxy 인스턴스 문제
같은 인스턴스(그리고 아마도 같은 순서/같은 이름으로). 그만큼
실제 IP는 중요하지 않기 때문에 미리 알 필요가 없습니다.
모든 IP는 전달하는 HAProxy에 관계없이 동일한 서버로 해시됩니다.
을 통해.

완전히 위조된 예의 경우(HAProxy는 그렇지 않은 것을 사용합니다.
예측 가능, 확신합니다), 3개의 서버가 있다고 상상해 보십시오.
server0, server1, serve2의 순서로 (실제 세부 사항은 중요하지 않습니다.
명확한 순서가 있다는 것만으로 암시적이면 괜찮습니다). 모든 HAProxy
인스턴스에는 동일한 순서로 동일한 서버가 있습니다. 그들도 같은
들어오는 IP 주소를 처리하는 방법에 대한 규칙입니다. 이 진부한 예의 경우,
주소의 네 부분을 모두 정수로 더합니다(쉽게 확장 가능
IPv6 지원, 모두 16진수로 10진법으로 합산), 3으로 나누기
나머지. 따라서 IP 123.12.61.24 = (123+12+61+24) % 3 또는 1입니다. 따라서 라우팅됩니다.
server1에. 따라서 어떤 HAProxy 인스턴스가 들어오더라도
연결은 server1로 전송됩니다.

이제 server1이 오프라인이 되면 알고리즘이 모든 HAProxy에서 변경됩니다.
모든 부분을 추가하려면 모듈러스 2.

그리고 이것은 일반적으로 netsplit을 얻지 않는 한 작동합니다.
HAProxy 인스턴스는 다른 서버 목록을 갖습니다). 하나의 HAProxy가 보는 위치
3개의 인스턴스, 다른 하나는 2개의 인스턴스를 봅니다. 그런 일이 발생하면 보장할 수 없습니다.
동일한 백엔드에 도달합니다. 그리고 실제로 그것은 문제가 될 수 있습니다. 하지만
그것이 링크에서 설명하는 솔루션입니다.

2016년 1월 13일 수요일 오후 3시 51분, Felix Schlitter [email protected]
썼다:

@lostcolony https://github.com/lostcolony 해시가
주어진 IP에 대해 결정적으로 파생되지만 매핑이 있어야 합니다.
"해시 -> 인스턴스". 귀하의 경우에는 다음과 같은 규칙이 있다고 말합니다.
"ABCD는 인스턴스 1로 연결됩니다"라고 말하지만 원하지 않습니까?
HAProxy는 사용 가능한 목록이 주어지면 리디렉션할 위치를 스스로 결정합니다.
서버? 결국 "ABCD"는 일부 클라이언트의 IP일 뿐이고 알려지지 않았습니다.
앞.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment -171428465
.

Elastic Beanstalk에서 웹 인터페이스에서 TCP 및 SSL을 사용하도록 로드 밸런서를 설정했는데도 로드 밸런서 구성을 직접 확인했을 때 보안 리스너에 대해 여전히 HTTPS를 사용하고 있다는 것을 알았습니다. 따라서 EC2 > 로드 밸런서 섹션에서 포트가 다음과 같이 설정되어 있는지 확인해야 합니다.

정렬되면 .ebextensions에 다음을 추가하면 모두 잘 작동합니다. :)

container_commands:
  01_nginx_static:
    command: |
      sed -i '/\s*proxy_set_header\s*Connection/c \
              proxy_set_header Upgrade $http_upgrade;\
              proxy_set_header Connection "upgrade";\
          ' /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf

그러나 고정 세션 지원이 TCP를 통해 작동하지 않기 때문에 인스턴스가 하나만 있는 경우에만 100% 작동합니다.

@lostcolony , @williamcoates 게시물은 지금 설명 감사합니다. 내가 그것을 하는 것을 잊었다는 것을 믿을 수 없다. 귀하의 설명이 큰 도움이 되었습니다. 시간 내주셔서 감사합니다.

https://github.com/indutny/sticky-session/issues/47#issuecomment -227499752

그래서 나는 같은 문제가 있었고 HTTPS를 사용하도록 ECB를 설정한 것으로 나타났습니다.
HTTPS를 SSL로 변경했는데 더 이상 메시지가 표시되지 않습니다.
따라서 HTTP/HTTPS가 아닌 TCP/SSL을 사용하십시오.

2016년 8월부터 "클래식" ELB 대신 Amazon의 ALB(Application Load Balancer)를 사용할 수 있습니다. HTTP 80 및 HTTPS 443의 리스너와 함께 "즉시" 작업했습니다.

@trans1t 스윗맨, 정보 감사합니다! 나는 그것을 확인해야 할 것입니다.

@niczak - 또한 소켓 트래픽 고정을 위해 ALB로 전환했습니다. 그러나 나는 처음에 ALB 고정 세션 구성에 어려움을 겪었습니다(이 주제에 대한 문서가 너무 많지 않았기 때문에 최소 몇 달 전에는). 마침내 그것을 알아 냈습니다. 핵심은 "고정성은 대상 그룹 수준에서 정의됨"이므로 트래픽을 제공할 대상 그룹을 만든 다음 고정성을 추가해야 합니다.

@aidanbon 환상적인 정보입니다. 공유해 주셔서 감사합니다!

AWS Application Load Balancer에 여전히 문제가 있는 사람을 위해 보안 정책을 업데이트해 보십시오. 다른 웹 사이트의 정확한 설정에서는 완벽하게 작동했지만 보안 정책이 약 1년 뒤쳐져 있음에도 동일한 문제가 발생했습니다. 최신 버전으로 업데이트하면 문제가 해결된 것 같습니다.

@michaelmitchell 아무거나 변경

내 애플리케이션에서 아무 것도 변경하지 않았습니다. 내가 취한 유일한 추가 단계는 새 정책으로 변경한 후 작동하지 않는 것으로 나타났기 때문에 ALB에서 HTTPS 리스너를 제거했다가 다시 추가하는 것이었습니다.

그러나 보안 정책을 업데이트한 후에도 오류가 표시되는 것은 내 브라우저 세션이 이전 보안 정책을 유지하고 있을 가능성이 있다는 것을 배웠으므로 리스너를 추가/다시 추가하는 것이 실제로 필요한지 확실하지 않지만 시크릿 모드를 여는 것은 잘 작동했고 그 후에 내 모든 크롬 세션을 닫고 다시 열면 제대로 작동했으며 그 이후로 보지 못했습니다.

좋은 정보 감사합니다!

르 벤. 2017년 3월 31일 à 12:02, Michael Mitchell [email protected] a
에크리트 :

내 응용 프로그램에서 아무것도 변경하지 않고 내가 한 유일한 추가 단계
다음과 같이 ALB에서 HTTPS 리스너를 제거하고 다시 추가했습니다.
새 정책으로 변경해도 작동하지 않는 것 같습니다.

그러나 보안을 업데이트한 후에도 오류가 표시된다는 것을 배웠습니다.
정책은 이전 보안 정책을 유지하는 내 브라우저 세션일 가능성이 큽니다.
그래서 리스너를 추가/재추가하는 것이 정말로 필요한지 확실하지 않지만,
시크릿을 여는 것은 잘 작동했고 모든 크롬 세션을 닫은 후에
다시 열면 잘 작동하고 그 이후로 보지 못했습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/socketio/socket.io/issues/1846#issuecomment-290672158 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ADrIi_SXqccWOLUMIWF1IhClGXvKAGMcks5rrM8sgaJpZM4C0swP
.

이 스레드가 AWS/socket.io의 문제를 파악하는 장소가 된 것 같습니다.

내 설정은 클라이언트가 socket.io 연결에 대한 데이터로 HTTPS 요청을 한다는 것입니다.
HTTPS 요청은 고정 세션에 필요한 쿠키로 응답해야 합니다. 문제는 socket.io 연결에서 cookie 헤더를 전달할 수 없다는 것입니다.

다음 리스너와 함께 ALB를 사용하고 있습니다.

다음과 같이 구성된 고정성을 가진 대상 그룹을 가리킵니다.

다음을 사용하여 먼저 HTTPS 끝점에 도달했습니다.

fetch(`https://${url}/hub/api/spinup/${uuid}`, {
                method: 'GET',
                headers: headers,
            })

그런 다음 소켓을 초기화하십시오.

connection = io(`wss://${url}:443/`, {
            path: `/user/${uuid}/spawn`,
        })

HTTPS 요청이 적중하는 인스턴스는 _반드시_ 소켓 연결이 적중하는 인스턴스여야 합니다.

소켓이 설정되면(운이 좋지 않아 올바른 인스턴스에 도달하는 경우) 그곳에 머물고 모든 것이 잘 작동하지만 문제는 웹 소켓이 HTTPS 요청과 동일한 엔드포인트에 도달하도록 하는 것입니다.

내 첫 번째 본능은 사용하는 것입니다.

connection = io(`wss://${url}:443/`, {
    path: `/user/${uuid}/spawn`,
    extraHeaders: {
        cookie: cookieValueFromFetchResponse
    }
})

이것은 node 에서 작동하지만 브라우저에서 cookie 는 XMLHTTPRequests에서 금지된 헤더이므로 함께 보낼 수 없습니다.

비슷한 일을 한 사람이 있습니까?

비슷한 작업은 하지 않았지만 ALB에는 여전히 헤더 기반 라우팅이 없지만 호스트 기반 라우팅은 있습니다. 이것은 매우 해킹적이지만 기본적으로 ALB 뒤의 각 인스턴스가 해당 인스턴스에 대해 알고 있는 명시적 경로를 갖도록 만들 수 있습니다. 초기 HTTP 요청이 나가면 응답의 일부에 경로가 포함되고 웹 소켓에 대한 연결에는 해당 경로가 포함됩니다. 즉, HTTP 요청은 인스턴스 '5'에 도달하고(어떤 기준에 따라 생성된 UUID가 더 좋음) 응답의 일부로 '5'를 반환하고 웹 소켓은 url/5로 열립니다. ALB에는 url/5가 인스턴스 5로 라우팅된다는 규칙이 있습니다.

자동 크기 조정을 사용하는 경우(인스턴스가 애완동물이 아닌 소인 경우) 인스턴스에서 실행 중인 코드가 ALB 설정을 수정하여 적절한 도메인을 해당 도메인으로 라우팅하도록 해야 합니다.

https://aws.amazon.com/blogs/aws/new-host-based-routing-support-for-aws-application-load-balancers/에서 자세히 읽어보십시오.

그러나 가능한 한 사용하고 있는 패턴을 피하고 싶을 수도 있습니다. HTTP 요청으로 들어오는 데이터는 모든 인스턴스(DB 또는 이와 유사한 것)에 액세스할 수 있는 방식으로 저장되거나 일단 설정되면 웹 소켓 연결을 통해 전송되어야 합니다. 그대로, HTTP 요청과 웹 소켓이 열리는 사이에 인스턴스가 죽을 수 있으며 동일한 문제가 발생할 수 있습니다(훨씬 덜 자주).

@lostcolony 조언에 감사드립니다. 시도해 볼 가치가 있습니다.

http 요청은 websocket 서버가 회전하도록 하는 것입니다(실제로는 도커 컨테이너에 있지만 추상화되어 있습니다). 연결되는 인스턴스에 웹 소켓 서버가 존재하도록 두 요청을 동일한 인스턴스로 라우팅해야 합니다.

이 줄을 사용하면 jupyter 서버를 elb 뒤에 배치하는 데 도움이 됩니다.

service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp

누군가가 aws에서 kubernetes를 사용하여 이 티켓에 올 경우를 대비하여.

HTTP2 를 비활성화하면 괜찮습니다. ELB에 대해 다른 작업을 수행할 필요가 없습니다.

안녕,
SockJS를 사용하고 있지만 동일한 문제가 있습니다.
내 응용 프로그램은 Java Spring 4 응용 프로그램이며 개발 시스템에서 작동하며
AWS에서 동일한 오류가 발생합니다.
누군가가 업그레이드 헤더를 삭제한 것 같습니다. 클라이언트에서 볼 수 있습니다.

아직 해결책을 찾을 수 있습니다 ...

안녕하세요 @yoav200 입니다 .

나 좀 구해줘.
나는 같은 문제에 갇혀있다. 도와주세요
Websocket에 Springboot 2.x 및 SockJ를 사용하고 있습니다.
aws에 배포된 tomcat 애플리케이션을 만들었습니다.
클래식 로드 밸런서가 있는 Elastic beantalk

이제 문제는
iOS 개발자가 연결할 수 없습니다. 백엔드에 도달하지만 핸드셰이크 중에 실패합니다.
아래는 CLB와 ALB 모두에서 얻은 로그입니다.

2019-12-13 15:21:22.662 DEBUG 27543 --- [nio-8080-exec-2] oswsDispatcherServlet: GET "/wtchat/websocket", 매개변수={}
2019-12-13 15:21:22.701 DEBUG 27543 --- [nio-8080-exec-2] oswsssWebSocketHandlerMapping : org.springframework.web.socket.sockjs.support에 매핑됩니다. SockJsHttpRequestHandler@30c6a17
2019-12-13 15:21:22.714 DEBUG 27543 --- [nio-8080-exec-2] oswssthDefaultSockJsService : 전송 요청 처리 중: GET http://mydomain.com/wtchat/websocket
2019-12-13 15:21:22.716 오류 27543 --- [nio-8080-exec-2] cwcMyHandshakeHandler : 잘못된 업그레이드 헤더로 인해 핸드셰이크 실패: null

2019-12-13 15:21:22.717 DEBUG 27543 --- [nio-8080-exec-2] oswsDispatcherServlet : 400 BAD_REQUEST 완료

나는 당신이 말한 것을 따랐습니다.

로드 밸런서를 직접 가리키는 Route 53에 레코드 세트를 생성했습니다.

이 작업을 수행한 후에도 위와 같은 오류가 발생합니다.

내가 뭘 더 해야 합니까?