정적 파일로만 구성된 사이트가 있습니다.
방금 웹 사이트를 Github에서 직접 호스팅 하는 것이 얼마나 쉬운 지 알았습니다 . 대기 시간, 안정성, 용량 측면에서 어떻게 생각하십니까?
일반적으로 현재 정적 콘텐츠의 경우 "생산 등급"입니까? 대기 시간과 가동 시간 측면에서 Amazon S3 를 어떻게 비교 합니까?
정적 파일로만 구성된 사이트가 있습니다.
방금 웹 사이트를 Github에서 직접 호스팅 하는 것이 얼마나 쉬운 지 알았습니다 . 대기 시간, 안정성, 용량 측면에서 어떻게 생각하십니까?
일반적으로 현재 정적 콘텐츠의 경우 "생산 등급"입니까? 대기 시간과 가동 시간 측면에서 Amazon S3 를 어떻게 비교 합니까?
답변:
GitHub는 실제로 생산 준비가되었습니다. 이들은 복제, 클러스터링 및로드 밸런싱을 사용하여 낮은 대기 시간과 높은 가용성을 제공하며 그렇게하는 데 능숙하다고 말합니다. 상태 페이지 를 읽으면 최신 문제에 대한 아이디어를 얻을 수 있습니다 .
그러나 그들은 실제 호스팅이 아닙니다. 예를 들어 Amazon S3와 비교하여 Amazon은 다음과 같은 이점을 제공합니다.
GitHub 페이지를 사용하는 장점은 일반적으로 Jekyll (GitHub 페이지 뒤에있는 도구)을 사용하고 GitHub가 사이트를 컴파일하고 호스팅하기위한 노력을하려는 루비 사용자를위한 것입니다. 마지막으로, 저장소를 공개적으로 유지하는 한 무료입니다.
그러나 Jekyll을 로컬에서 사용하거나 다른 게시 도구를 사용하여 페이지를 정적으로 생성하여 Amazon에서 호스팅하는 것을 막을 수있는 것은 없습니다. 여러 프로젝트 에서이 작업을 수행하고 있습니다. 로컬 복사본을 Amazon 폴더와 동기화하는 몇 가지 명령 줄 도구가 있습니다.
큰 제한은 엔드 투 엔드 TLS / SSL 지원 이 아닙니다 .
페이지는 HTTPS가 아닌 HTTP를 통해 제공되므로 비밀번호 나 신용 카드 번호 전송과 같은 민감한 거래에 사용해서는 안됩니다.
https : // foo .github.io는 작동 하지만 완전히 안전하지는 않습니다 (2014 년 2 월 GitHub 지원 답변에서 발췌).
HTTPS 요청이 작동하는 것처럼 보이지만 CDN 제공자는 마지막에 암호화를 추가 및 제거한 다음 공개 인터넷을 통해 CDN 제공자에서 GitHub 페이지 인프라로 요청을 전송하여 신뢰도를 나타냅니다.
그렇기 때문에 GitHub 페이지에 대해 공식적으로 HTTPS를 지원하지 않습니다.
또한 비공식 문제인 맞춤 도메인에 대한 TLS / SSL 지원은 없습니다 .
많은 사람들이 Clouldflare를 통해 커스텀 도메인에서 HTTPS를 다루는 실험을 해왔습니다. Clouldflare는 특히 엔드 투 엔드 보안이 아니며 ( " 엄격한 전체 SSL"은 여기서 작동하지 않습니다.) 앞에서 사용하는 모든 Github의 Pages–CDN 링크는 위에서 설명한대로 안전하지 않습니다.
또 다른 작은 버그 : 일부 경로는 http로 다시 리디렉션됩니다 .
*.github.io하지만 사용자 정의 도메인에 유효한 SSL은 없습니다.
2018 년 현재 GitHub Pages 는 커스텀 도메인에서도 HTTPS를 완벽하게 지원합니다 .
GitHub Pages 는 또한 현재 Fastly 에서 제공 하는 CDN을 사용합니다 .
따라서 오늘 GitHub Pages에서 호스팅하는 모든 것이 안전하고 빠르며 안정적입니다.