설정
CloudFront와 함께 사용하려고 하는 webs/wix/etc와 유사한 웹 사이트 관리 시스템이 있습니다. 여기에는 다음과 같은 도메인과 하위 도메인이 있습니다.
- ourdomain: 당사의 기본 웹사이트
- admin.ourdomain: https를 통해 사용할 수 있는 모든 웹사이트에 대한 관리 인터페이스
- Images.ourdomain: S3 버킷
- router.ourdomain: 아래 참조
- [customersomething].ourdomain: 무료 사용자를 위한 하위 도메인
- [customersomething.com]: 프리미엄 고객을 위한 도메인
시스템은 대부분의 도메인이 router.ourdomain에 대한 CNAME-d(다른 도메인 등록 기관 등을 가진 고객에게 가장 쉬운 방법이기 때문에) 방식으로 작동하며 router.ourdomain은 우리의 A 별칭으로 지정됩니다. ELB와 EC2-s의 PHP는 HTTP_HOST 값을 기반으로 사이트를 처리하는 반면 이미지는 S3에서 나옵니다.
우리의 계획
이제 우리는 이 모든 것을 CloudFront 뒤에 두고 싶습니다. 대부분의 내용은 사소한 것입니다. S3를 CF 뒤에 두는 것은 쉬웠습니다. 자산.ourdomain 하위 도메인을 통해 CF 뒤에 모든 ourdomain/*.(js|css)를 배치하는 것은 쉬웠습니다. *.images.ourdomain을 사용하여 하위 도메인 사이를 즉시 샤딩하여 클라이언트측 로드 시간 등을 줄일 수 있다는 것은 즐거운 일입니다. "*.ourdomain"을 넣어 CF 뒤에 동적 PHP 무료 사이트를 포함한 모든 *.ourdomain 항목을 넣을 수도 있습니다. CF 매개변수에 넣습니다.
문제
그러나 우리가 알아낼 수 없는 한 가지는 동적으로 생성된 모든 PHP 사이트를 사용자 정의 도메인과 함께 CF 뒤에 배치하는 방법입니다. 알림: 이는 router.ourdomain에 대한 CNAME-d입니다. 각 도메인을 CF 매개변수에 넣는 것은 옵션이 아닙니다. 수만 개의 도메인 이름을 처리할 수 있어야 하고 각 도메인에 대해 수동 구성 없이 이를 수행해야 하기 때문입니다.
그래서 우리의 생각은 대체 도메인 이름으로 CF 구성에 router.ourdomain을 넣고, router.ourdomain이 경로 53의 CF를 가리키고, CF가 원본인 ELB를 가리켜야 한다는 것이었습니다. 우리가 발견한 것은 매번 "ERROR 요청을 만족시킬 수 없습니다. 잘못된 요청입니다. cloudfront(CloudFront)에서 생성되었습니다."라는 메시지를 받는 좋은 방법입니다. 실제로전부는 아니다시간은 다음과 같이www.ourdomain은 정상적으로 작동하지만(router.ourdomain에 CNAME 연결됨) 다른 모든 하위 도메인에서는 위의 오류가 발생합니다(*.ourdomain은 router.ourdomain에 CNAME 연결되지만 router에 CNAME 연결되는 하위 도메인에도 동일하게 적용됩니다. 우리의 도메인은 www와 물론 라우터를 제외하고 하나씩). 그래서 지금 우리는 이 문제를 어떻게 해결해야 하는지 전혀 모르고, www가 다른 모든 것에서는 작동하지 않는데 왜 www에서는 작동하는지, 그 반대의 경우도 마찬가지인지 이해하지 못합니다.
어떤 생각이나 아이디어라도 감사하겠습니다.
답변1
알림: 이는 router.ourdomain에 대한 CNAME-d입니다.
네, 그렇게 말씀하셨죠. 이에 대한 내용은 다음과 같습니다.
그것은 중요하지 않습니다.
예, CloudFront는 대체 호스트 이름을 CNAME으로 참조합니다. 예, CNAME DNS 레코드는 특정 사이트의 트래픽을 CloudFront에 도달하도록 라우팅하는 일반적인 방법입니다. 하지만 아니요, CloudFront 배포를 가리키는 CNAME으로 호스트 이름을 구성하는 것은 이제 Cloudfront 또는 일반적으로 HTTP와 관련이 없습니다.
브라우저는 웹 서버에 연결하려고 할 때 DNS에서 IP 주소를 조회합니다. 경로에 CNAME이 있으면 해당 정보는 삭제됩니다. 브라우저가 관심을 갖는 것은 "어떤 IP 주소에 연결해야 하는가?"입니다.
www.example.org가 webfarm.example.com의 CNAME이라고 가정해 보겠습니다. 브라우저는 www.example.org를 조회하고 webfarm.example.com의 IP 주소로 끝납니다.
응답을 받으면 브라우저는 웹 서버에 연결하고 요청을 보냅니다.
GET / HTTP/1.1
Host: www.example.com
Host:브라우저가 보낸 http 요청의 헤더에는 주소 표시줄에 표시된 호스트 이름이 포함되어 있습니다 . CNAME 정보는 전혀 사용할 수 없으며 브라우저나 웹 서버에서 알 수 없습니다.
그렇다면 CNAME은 요청 구문 분석 및 레이어 7 라우팅과 어떤 관련이 있을까요? 그럴 수 없습니다. CNAME 대상은 연결할 IP 주소를 찾는 경로로만 사용됩니다.
귀하의 배포판은 Cloudfront에서 해당 IP 주소를 사용하는 유일한 배포판이 아닙니다. 수백, 수천 가지가 더 있습니다. 헤더 까지 내려옵니다 Host:.
Host:"CNAME"(대체 호스트 이름) 목록은 요청이 속한 것으로 간주되어야 하는지 결정하기 위해 수신 헤더에서 일치시킬 CloudFront의 호스트 이름 세트입니다.당신의분포. Host:브라우저가 보낼 수 있는 헤더 목록입니다 . Host:헤더가 배포의 구성된 값과 일치할 때까지 해당 요청과 관련된 배포는 알 수 없으며 정의되지 않습니다.
Host:들어오는 헤더를 배포와 일치시킬 수 없는 경우 Cloudfront는 어떻게 합니까 ?
HTTP/1.1 400 Bad Request
따라서 표시되는 동작은 예상된 것이며 올바른 것입니다. 와일드카드는 대체 호스트 이름 구성 줄에서 가장 왼쪽에 있는 유일한 요소를 구성하는 한 CloudFront 구성에서 작동합니다. 그러나 이것은 DNS와는 아무런 관련이 없습니다.
고객이 배포에 참여하도록 하려면 CloudFront에서 다른 고객 소유 도메인 이름을 구성하는 것을 피할 수 없습니다.
그러나 수동이 아닌 API를 통해 프로그래밍 방식으로 수정할 수 있습니다.
http://docs.aws.amazon.com/AmazonCloudFront/latest/APIReference/PutConfig.html
배포당 이러한 별칭은 100개로 제한되지만 AWS 지원에 양식을 제출하여 증가를 요청할 수 있습니다. 하지만 실제로는 CloudFront가 요청 에스더에 하나의 호스트가 있는 지정된 경로의 객체를 캐시하지 않고 이를 다른 배포에 대한 캐시된 응답으로 반환하지 않기 때문에 이를 여러 배포로 나누는 것도 좋습니다. 호스트, 동일한 배포에서도 호스트 헤더를 원본 서버로 전달하는 경우(원본 서버가 차이점을 알 수 있는 경우 이를 수행해야 함) 요청의 중요한 매개변수가 한 요청에서 다른 요청으로 변경되었기 때문에 그럴 수 없습니다.