카테고리 보관물: webmasters

webmasters

3G 네트워크에서 웹 페이지의 초기 연결 및 SSL 핸드 셰이크 단계의로드 시간을 최적화하는 방법은 무엇입니까? + 모드가 아닌

내 웹 사이트 www.example.com (SSL 사용 가능)은 Amazon EC2 공유 호스팅에서 호스팅됩니다. Wi-Fi / 광대역 연결에서 더 빠르게로드됩니다 (로드 시간 <2 초). 모바일 ** (H + 모드가 아닌 H 모드) **의 3G 네트워크에 문제가 있습니다. 연결 단계를 시작하면 SSL 핸드 셰이크 프로세스에 12 초가 소요됩니다. Chrome 네트워크 탭을 통해 타이밍 매개 변수를 모니터링했습니다. 다음은 웹 페이지의 측정 된로드 타이밍입니다.

페이지로드 네트워크 타이밍 통계

페이지에서 처리되는 데이터 종류 :
테스트 된 웹 페이지는 AJAX를 통해 5 개의 키-값 페어 JSON 데이터를 수신하여 웹 페이지에 표시합니다. 5-6 개의 텍스트 컨텐츠 만있는 매우 가벼운 페이지입니다.

많은 웹 사이트가 3G 모바일 네트워크 (H 모드)에서 더 빨리로드되는 것을 보았습니다. 3G 네트워크에서 초기 연결 설정 단계에서 웹 사이트가 너무 느립니다. 초기 연결 단계에서 지연을 해결 / 최적화하는 방법에 대해 누군가 나를 도울 수 있습니까? 전용 호스팅으로 전환하면 현재 문제가 해결됩니까?

웹 서버가 사용 중이 아니며 항상 사용 가능한 CPU 및 메모리가 많이 있습니다.

서버 구성 :
Amazon EC2 인스턴스-공유 호스팅 (32 CPU 및 60GB RAM). 웹 서버-Apache. SSL-시만텍.

답변

초기 연결

초기 연결에는 SSL 협상이 포함되므로 핸드 셰이크가 높기 때문에 SSL 설정 방식에 심각한 문제가 있음을 나타내는 좋은 지표입니다.

Chrome : 리소스 타이밍 이해

TCP 핸드 셰이크 / 재시도 및 SSL 협상을 포함하여 연결을 설정하는 데 걸린 시간입니다.

SSL 핸드 셰이크 및 TTFB

SSL 핸드 셰이크를 완료하는 데 소요 된 시간과 TTFB를 기다리는 서버 (첫 바이트까지의 시간)라는 두 가지 주요 문제가 있습니다.

  • TTFB : 4079ms (1000ms 미만이어야 함)
  • SSL 핸드 셰이크 11830ms (100ms 미만이어야 함)

또한 3G / 4G 장치로 테스트 할 때 전화 신호의 강도가 다양하기 때문에 첫 바이트가 더 길어질 수 있습니다. 이로 인해 간헐적 인 연결 문제와 지연 시간이 달라질 수 있습니다.

1 단계 : SSL 문제 조사

SSL에 심각한 문제가 있으며 OpenSSL 또는 이와 유사한 설치에 결함이있을 가능성이 높습니다. SSL Labs를 사용하여 SSL 인증서를 테스트 한 다음 제안 된 문제 또는 경고를 수정하십시오.

SSL이 여전히 느리게 작동하는 경우 서버 과부하 또는 서버 오류 일 가능성이 큽니다. 나중에 발생하면 결함이있는 곳을 좁히려 고 노력해야합니다. 이 문제에 대한 추가 지원이 필요한 경우 서버 결함 스택을 사용하십시오. 한 사용자가 새 키를 작성하면 느리거나 느린 SSL 문제 를 해결했다고보고했습니다 .

서버 리소스 문제인 경우로드 밸런서가 도움이 될 수 있습니다.

2 단계 : TTFB 조사

SSL 문제를 조사한 후에도 여전히 TTFB가 증가하면 서버에 충분한 자원이 있는지 확인하여 서버를 테스트해야합니다.

첫 번째 바이트 시간은 다음의 영향을 받지만 다음에 제한되지 않습니다.

  • 서버를 호스팅하는 사용자에서 데이터 센터까지의 거리는 TTFB를 증가시킬 수 있습니다
  • 캐시되지 않은 GZIP는 TTFB를 증가시킬 수 있습니다
  • 혼잡 한 네트워크는 TTFB를 증가시킬 수 있습니다
  • 혼잡 한 서버는 TTFB를 증가시킬 수 있습니다

때때로 CPU와 RAM을 늘리는 것이 항상 최선의 방법은 아닙니다. 때로는 여러 서버를 나란히 쉽게 실행할 수있을뿐만 아니라 캐싱 및 SSL 요청을 실제로 오프로드하기 때문에 로드 밸런서 를 도입하는 것이 좋습니다 . 다른 장점은 다음과 같습니다.

출처

  • 캐싱 : 어플라이언스는 이미지와 같이 변경되지 않는 컨텐츠를 저장하고 웹 서버로 트래픽을 보내지 않고 클라이언트에 직접 제공 할 수 있습니다.
  • 압축 : 파일을 보내기 전에 압축하여 HTTP 객체의 트래픽 양을 줄입니다.
  • SSL 오프로드 : 웹 서버의 CPU에서 SSL 트래픽 처리가 필요하므로로드 밸런서가 대신이 처리를 수행 할 수 있습니다.
  • 고 가용성 : 하나의 장애가 발생한 경우 두 개의로드 밸런싱 어플라이언스를 사용할 수 있습니다.

TTFB를 낮추기위한 팁 :

답변

질문 제목을 읽으면 초기 연결 속도와 SSL / TLS 핸드 셰이크 속도를 높이기 위해 할 수있는 두 가지가 있습니다. 이들은 3G뿐만 아니라 모든 연결에서 작동하므로 모범 사례로 사용해야합니다.

먼저 HTTP / 2를 사용하여 사이트를 제공하십시오. 여기에는 Apache 2.4.17 이상이 필요합니다 .

둘째, OCSP 스테이플 링을 사용하도록 Apache를 구성하십시오. 여기에는 Apache 2.3.3 이상과 OpenSSL 0.9.8h 이상이 필요하며 여기에서 설정하는 데 유용한 안내서가 있습니다 . OCSP 스테이플 링은 속도를 높이 지 않지만 클라이언트를 위해 일부 작업을 수행하고 OCSP 조회를 시도하는 데 어려움을 덜어줍니다.

질문의 본문을 읽으면 호스팅 환경에 훨씬 더 큰 문제가 있다고 생각합니다. 해당로드 시간은 허용되지 않습니다. ‘공유 호스팅’이라고 언급 한 경우 해당 공유 호스팅을 관리하는 사람에게 연락하여 서버가 비정상적으로 느린 이유를 문의해야합니다. 다른 공유 호스트를 사용하거나 VPS를 직접 실행하는 것이 좋습니다 (더 많은 작업이지만 속도와 유연성이 향상됨).

이미 AWS를 사용하고 있으므로 프리 티어 를 사용해 테스트하고 자체 서버가 작동하고 최적화되도록 하시겠습니까? 테스트를 위해 하위 도메인 및 일부 정적 HTML 페이지와 함께 사용하고 기본 사이트를 위로 이동하십시오 (필요한 경우 프리 티어 제한을 넘어서 확대).

답변