사이트 속도 빠르게 하기

이거슨.. 굳이 wordpress 뿐만이 아니라 모든 사이트 공통 사항이 될 수 있다.

 

A. 1단계 사이트 개발자의 영역이다.

  1. 사이트 속도는 외부 URL을 최대한 제거 해야 빨라진다.
  2. 웹폰트 등도 외부 URL이기 때문에 최대한 제거하는것이 좋다.
  3. js 및 css 를 minify 를 한다.
  • js, css 를 작성하기 좋은 형태가 아닌 최대한 압축한 형태로 바꾸는 것이다.
    또한 브라우어에서 표현 가능한 DPI를 넘어서는 그림파일을 브라우져에서 표현 가능한 정도의 DPI로 낮추어 최적화 하는것이다. ( 일반적으로 72DPI 레티나 대응은 144DPI가 일반적이다. )
    쉬운 길은 Google PageSpeed Insights에서 사이트 속도 측정을 한번 한 뒤에.
    측정결과 아래 부분에 있는 “이 페이지에 최적화된 이미지, 자바스크립트, CSS 리소스를 다운로드하세요.” 에서
    최적화된(minify 및 이미지 용량 최적화) 파일을 다운받아 사이트에 적용하는 것이다.

 

B. 2단계 서버 관리자의 영역이다.

  1. 웹서버에서 memory 기반 캐싱 서비스를 도입한다.
  2. 웹서버 에서 DEFLATE(gzip) 전송 설정을 한다.
  3. 웹서버 에서 expires 설정을 한다.
  • 웹서버의 성능을 향상 시키는 방법으로 memory 계열의 캐쉬를 사용하는것이 좋다.
    이것은 서버의 IO 를 낮추어 주기 때문에 DISK 로드 에버리지가 줄어든다.
    컴퓨터 하드웨어를 만지고 있다면 알겠지만 disk(디스크) 보다 memory(메모리) 가 20배 이상 빠르다.
    또한 memory(메모리)는 cpu(중앙처리장치)보다 20배 이상 느리다.때문에 메모리 기반의 캐시 프로그램을 도입하도록 고려한다.
    php 익스텐션 방식이 훌륭하다.(추천순 opcache, xcache, APC)
    아파치 DSO 인 mod_deflate, mod_expires 를 이용하여 서빙되는 웹사이트의 데이터를 gzip 압축 전송하고 전송되는 파일의 브라우져캐시 기간을 설정한다.

opcache 는 php 5.5 이상에 내장되어 배포 되었으며 php 5.5 이상일 경우 php.ini 에 설정을 추가하는것만으로 동작한다.

xcache 는 링크 참조.

mod_deflate 및 mod_expires (httpd.conf 삽입)

제로보드 xe의 경우 php 소스내에서 자체적으로 gzip 전송을 을 구현했기 때문에 DEFLATE 안해도 됨.

 

추가적으로 아래와 같은 작업을 통해 사이트 속도를 좀더 가속화 할 수 있다.
다만 일반적으로 현재 한국내에서의 여건상 적용하는것을 추천하지는 않는다.
(한국내 대부분의 웹사이트의 https 사용률이 낮고 인증서관리가 어렵다.)

  1. force https 를 적용하고 Strict-Transport-Security 를 적용한다.
  2. https 를 이용하여 HTTP/2를 활성화 한다.

다만 이부분은 force https 를 적용 하는것부터가 문제가 된다.
외부url 에서 이미지등을 가져오는 경우에도 그 url이 https가 되어야 한다.
일반적으로 img 태그의 src 가 http://aaaa.com/image.jpg 일경우 //aaaa.com/image.jpg 이런식으로 바꾸면 된다.
1차문제는 이게 기존사이트를 바꾸려면 꽤 심한 하드코딩 노가다 이고… 2번째 문제는 aaaa.com 이 https 서비스가 되고 있느냐가 되겠다 = =aa..

 

이산을 넘어서 Strict-Transport-Security 를 적용하게 되면 https가 만료되면 사이트가 뜨지 않는다.
httpd.conf 및 .htaccess 에서 선언할 수 있으며 코드는 아래와 같다

주의: https를 적용하고 인증서 관리를 철저히 하지 않으면 사이트 안열림(설정상 최대 180일)

apache 버전이 2.4.17 (2015년 11월 배포됨) 버전 이상일 경우 일련의 과정을 통해 HTTP/2 서비스를 할 수 있다.
이건 약간 내용이 길고 난해 함으로 추후 별도 포스팅을 할 예정 이다. (지금 써놓은 포스팅 만큼 김 = =a)

그래서 결론은 GTmatrix 에서의 점수놀이 🙂
20160416_PicPick_152917애드센스와 젯팩 때문에 더이상 점수 상승이 어렵다 = =a
그리고 광고가 어떤거 나오냐에 따라 점수가 오르락 내리락 한다.

 

PS. 또다른 점수 놀이 사이트 https://www.webpagetest.org

 

CentOS5 에서 let’s encrypt 설치

일단 설치 법은 크게 다르지는 않지만 몇가지 막히는 부분이 있다.

 

이 다음 git을 통해 letsencrypt를 가져오는 명령어가 그냥 실행하면 되지 않는다.
아마도 git 에서 제공되는 SSL에서 지원하는 suite 가 centos 에 없거나 신뢰할수 있는 CA로 등록되어 있지 않는듯 하다. 때문에 GIT_SSL_NO_VERIFY=true를 하고 진행한다.

일단 설치는 잘 완료되 되었다.

 

이후 발급 시도시 SSL_set_tlsext_host_name 관련 에러가 날것이다.~]# cd /usr/local/letsencrypt

사유는 openssl 버전이 너무 낮기 때문에 발생하는것으로 판단된다.

 

때문에 별도의 수정이 좀 필요하다.

에러 해결은 github 의 antmd님의 댓글에서 발췌 했습니다. ‘ㅅ’a

를 한뒤에 아래 두파일의 의 1239번째줄과 296번째줄을 주석처리한다 ( # 으로.. )
~/.local/share/letsencrypt/lib/python2.7/site-packages/OpenSSL/SSL.py ( 1239줄 )

~/.local/share/letsencrypt/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/contrib/pyopenssl.py ( 296줄 )

 

그다음 다시 발급 시도를 하면 정상 발급이 된다.

 

 

ps. ~/.local의 파일 수정이 잘 안되는 분, 혹은 파일이 없는 경우 아래와 같이 수정된 소스를 다운받아 실행합니다.

 

apache 2.4.x HTTP/2적용

SPDY ( Stream Control Transmission Protocol )

  • HTTP/2 로 전환 되기 전 google 이 진행했던 웹 가속 프로토콜로 https 기반의 프로토콜 서비스로 현재는 HTTP/2에 흡수되어 개발이 종료 되었음.
    SPDY 지원 가능 브라우져 사용율( 77.39% ) ( 2016년에 chrome에서 지원 제거될 예정 )

 

HTTP/2 ( HyperText Transfer Protocol 2 )

  • 프로토콜 선언 h2, h2c 가 존재함 ( 좀더 확장 가능성 있음 )

 

  • h2의 경우 https 프로토콜 http/1.1 을 http/2 프로토콜로 사용이 가능
    h2는 SSL인증서를 통한 TLS 암호화를 통해 헤더를 압축 전송한다.
  • 단점: 브라우져 지원에 차이가 있음 (h2 HTTP/2 지원 가능 브라우져 사용률 = 70.15%)
    Internet Explorer 11 지원 (윈도우 10만 지원)
    EDGE 지원
    EDGE mobile 지원
    Firefox 36이상
    Firefox for Android 45이상
    Chrome 41이상
    Chrome for android 49 이상
    Safari(OSX 10.11) 9 이상
    Safari(iOS) 9.2이상
    Opera Software Opera 28 이상
    Opera Software Opera mobile 36 이상
  • 결론: 보편적 HTTPS 서비스가 된다는 조건하에 구현 가능( let’s encrypt )

 

  • h2c의 경우 http 프로토콜 http/1.1 을 http/2 프로토콜로 전환 가능
    h2c는 인증서없이 보편적 웹 프로토콜을 목표로 하기 때문에 base64로 압축 전송을 한다.
  • 단점: 지원하는 브라우져가 현재(2016-04-07) 없음
  • 결론: 구현 방법이 쉽지만 지원하는 브라우져가 없음 (현재 curl 7.43 버전 지원 )

 

아파치 2.4.17 버전 부터 DSO 모듈로( mod_http2.so ) HTTP/2를 지원 한다.

CentOS 6.x 대에서의 적용 방법에 대한 문서 이다.

 

먼저 CentOS 6.x 의 경우 기본적으로 openssl-1.0.1 이 설치 되므로 1.0.2 버전을 별도 컴파일 해야 한다.
( https://www.openssl.org/source )

 

이후 의존성인 nghttp2 를 설치한다 epel-release 에 있기 때문에 yum 에 repo 추가가 되어 있어한다.

 

Centos6 에 apache 2.4 설치의 경우 apr, apr-util, pcre 버전을 별도 컴파일 해야 설치 할 수 있다.
( https://apr.apache.org/download.cgi / ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre )

 

이후 아파치를 컴파일 한다. 여기서는 apache 2.4.20 버전을 설치 하였다. ( http://httpd.apache.org )

 

이후 httpd.conf 에서 http2_module을 주석 해제 하고 httpd-ssl.conf를 HTTP/2를 지원하도록  수정 한다.

 

파이어 폭스 > 디버그 모드 > 네트워크 에서 헤더 확인을 할경우 HTTP/2.0 을 확인할 수 있다.

20160406_PicPick_142800

시놀로지 나스에 Let’s encrypt 인증서 설치하기

20160324_PicPick_210642

우아아앙 DSM 6.0이 나오면서 시놀로지 나스가 Let’s encrypt 무료 인증서 설치가 된다.

 

 

그렇다 바로 해야지 이런건.. 먼저 내 시놀로지 웹스테이션으로 접속 ㄱㄱ..

20160324_PicPick_210245

제어판을 클릭한다.

 

 

 

20160324_PicPick_210249

제어판 내의 아무 메뉴나 클릭한다.

 

 

20160324_PicPick_210259

왼쪽메뉴의 보안 탭으로 들어가서 상단메뉴의 인증서 메뉴로 이동

 

 

20160324_PicPick_210305

당연히 기존 인증서를 교체를 선택하고 다음을 클릭!

 

 

20160324_PicPick_210404

도메인 이름자신의 시놀로지 DDNS 설정한 값을 넣고 이메일내 메일주소를 넣고 주제 대체이름에 내 도메인의 CNAME을 설정한 도메인을 추가해도된다.
예제)  synology.enteroa.kr 입력 ( 물론 사전에 내도메인에 synology 라는 호스트 추가 를  CNAME 으로 해서 enteroa.synology.me 를 해놓았다는 가정하에..)

 

 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

20160324_PicPick_210447

아 망했어요.. 80 port 여기 로직도 마찬가지로 80 포트로 체크하는 더러운….
참고로 자신이 쓰는 ISP(KT,SKT,U+등 초고속 인터넷 회선 회사들.)의 내부 정책에 따라 인바운드 80 포트는 막는 일이 많습니다.

 

아 U+ 계약 기간 얼마나 남았지 ㅠ_ㅡ KT로 바꿔야 80포트가 열리는데….

 

PS. 2017년 2월 16일 추가사항 ( 여전히 본인은 80포트제한으로 못하고 있지만.. )

혹여 80포트가 열려 있으신 분은 인증서를 발급 받은 뒤에 아래와 같은 방법으로 기본 사용 인증서를
synology.com 에서 자신의 도메인 인증서 ( Let’s encrypt ) 로 바꾸면 된다.
기본 말고 자신이 연결한 도메인, webdav 등등역시 let’s encrypt 인증서로 바꿉니다. (윈도우 10 에서 webdav 를 이용한 네트워크 드라이브 연결의 기본값이 https 로 바뀌었기 때문에 중요 합니다.)


 

이후에 아래 와 같이 HTTPS 관련 옵션을 모두 활성화 하고 웹서버가 재시작 하면 빠른 속도로 웹스테이션을 사용할 수 있다.

잘 설정된 HTTPS 는 일반 HTTP 보다 빠르다 ‘ㅅ’a

Server Name Indication.

아파치 2.2.12이상 / 아파치 2.4.8 이상 버전에서는 Server Name Indication 를 지원한다.
Server Name Indication은 TLS를 이용한 핸드쉐이크의 확장 기능이라고 보면 되겠다.

몇몇 브라우져 및 기기의 접속 제한이 있지만 이를 무시할 수 있을경우 하나의 서버에서
여러사이트의 SSL(https)를 단일 443 포트로 연결할 수 있다.

 

SNI를 설정할때는 먼저 서버명의 443포트를 먼저 선언해야 고객들의 혼란을 방지 할수 있다.
아파치의 경우 커넥션이 웹서버에 도달했을때 매칭이 되는 가상호스트가 없을경우 최상위에
선언되 버츄얼호스트로 연결한다.( nginx 는 반대로 마지막에 선언된 버츄얼호스트로 작동한다 )

서버 버전이 CentOS 6.5 미만에서는 ca-certificates / nss 업데이트가 필요할 수 있다.

아파치 2.4의 경우 버전을 만족한다면 단순히 443포트로 선언된 여러 가상호스트를 추가하는것만으로 세팅이 완료가 된다.

 

아파치 2.2 버전은 NameVirtualHost 를 선언해야 한다.

위와 같은 세팅만으로 여러 사이트가 443 기본 포트로 ssl 이용이 가능하다.
단  아래 조합은 브라우져에서 SNI 접속 기능이 없기 때문에 접속이 불가능 하다.
Windows XP – 인터넷 익스플로어(모든버전), 사파리
Android 2.3.7(진저브레드)을 포함한 이전 버전
BlackBerry 7.1을 포함한 이전 버전
WindowsMobile 6.5을 포함한 이전 버전
https://en.wikipedia.org/wiki/Server_Name_Indication

 

SNI 는 nginx 0.8.21 이상 / IIS 8.0 이상 역시 지원 한다.