전지적 개발자 시점

어제 HTTP/1.1과 HTTP/2.0을 핑덤을 이용해서 비교하는 포스팅을 했다. (어제 포스팅 : http://http2.tistory.com/14)

HTTP/2.0의 load time이 더 빠른 결과를 보여주긴 했지만, 어떠한 경우에는(사이트 규모가 작은경우) 그 차이를 체감하기 어려웠고, page size, request 숫자의 차이 등으로 100% 같은 환경에서 테스트해본것은 아니다.

HTTP/2.0이 빠르다는건 알겠는데 조금 찝찝한부분이있긴하다...

그래서 어제의 포스팅보다 조금 더 확신을 가질만한 사이트를 가져왔다.

(매달 데이터가 부족한 스마트폰 사용자는 이 포스팅만 봐도 충분하니 접속하는걸 권하진 않는다)

http://www.httpvshttps.com/ <- 이 사이트이다.

또한, 브라우저에서 HTTP/2.0을 지원하지 않을수도있다(대부분의 브라우저가 지원하긴 하지만,,)

브라우저가 HTTP/2.0의 지원하는지는 http://caniuse.com/#search=http2 여기서 확인하기 바란다.

먼저 위 사이트를 들어가면 0.62MB의 이미지 파일을 불러오면서 시간을 체크한다.

HTTP/1.1의 경우 14.7초. (여러번 시도해도 12~14초정도 나온다)

다음은 HTTP/2.0이다.

1.7초로 큰 차이를 보인다. (여러번 테스트한 결과 1~ 3초정도로 나온다,,, 이렇게 차이나도 되나 싶을정도로 빠르다;;)

HTTP와 HTTPS라고 나와서 HTTP/2.0으로 통신하는건지 확인해봤는데 HTTP/2 and SPDY indicator에 파란불이 들어오는것을 확인했다. -> HTTP/2.0으로 통신하는게 맞다.

이 사이트 말고도 HTTP/1.1과 HTTP/2.0을 비교하는 다른 사이트도 있는것 같은데...

어떠한 이유에선지 404 not found로 뜬다.

https://loadimpact.com/http2-vs-http1.1-performance

https://loadimpact.com/http2old

위 주소에서 찾았는데 현재 서비스는 하지 않는것같다.

지금까지 HTTP/2.0에대한 공부를하면서 이론적으로는 HTTP/1.1보다 더 빠르다는것을 배웠는데

실제 테스트에서도 같은 결과가 나오는지 궁금해서 실제로 1.1 버전과 2.0버전을 지원하는 사이트를 대상으로 테스트를 해봤다.

웹사이트의 성능을 측정을 도와주는 사이트는 대략적으로 이렇다.

1. https://tools.pingdom.com/

2. https://www.webpagetest.org/

3. https://developers.google.com/speed/pagespeed/insights/

4. https://gtmetrix.com/

그리고 HTTP/1.1과 HTTP/2.0을 지원해주는 사이트를 찾아야한다. (HTTP/2.0을 지원하는 사이트는 HTTP/1.1을 거치고 2.0으로 넘어가기 때문에 HTTP/1.1을 지원한다)

일단 잘 알고있는 nghttp2.org사이트가 두 버전 모두를 지원한다.

http://nghttp2.org로 접속하면 HTTP/1.1이고

https://nghttp2.org로 접속하면 HTTP/2.0이다. (클라이언트에서 https로 접속하고 다음에 http로 접속하면 cache때문인지 https로 접속이 된다.)

HTTP/1.1

다음은 핑덤 + http://nghttp2.org의 결과이다.

HTTP/2.0

그리고 핑덤 + https://nghttp2.org의 결과이다.

사이트 크기가 작아서 그런지 큰 차이는 없다.

(사실 이 포스팅을 하는 이유가 어제까지만해도 HTTP/2.0이 로딩속도가 2.3초정도로...1.1버전보다 느렸다. 이상하게 지금 해보니까 비슷하네;;)

조금 더 큰 규모의 사이트를 찾아보면 (보통 쇼핑몰 사이트가 사진이 많아서 규모가 크다)

다음은 알렉사 TOP500에서 찾은 사이트다.

1. http://www.aliexpress.com/

2. https://www.aliexpress.com/

그리고 다음은 핑덤 + 위 사이트이다.

HTTP/1.1

HTTP/2.0

HTTP/2.0이 속도면에서 많이 빠르다. 사이즈는 더 커졌다...? 리퀘스트도 조금 다르다...

테스트 지역을 달라스로 변경하고 다시 테스트 해보면

HTTP/1.1

HTTP/2.0

리퀘스트도 조금 다르고 사이즈는 아까와 다르게 작아졌다.

속도면에서 "HTTP/2.0이 HTTP/1.1보다 더 빠르다" 정도만 신뢰하면 될것같다.

HTTP/2.0의 기본 목표는 요청과 응답 멀티플렉싱을 통하여 레이턴시를 줄이고,

HTTP header필드를 압축하여 프로토콜 오버헤드를 최소화하며,

요청 우선순위와 서버푸시기능을 지원하는것이다.

HTTP/2.0에는 frame이라는게 존재한다.

frame이란 http/2.0 통신에서 사용되는 가장작은 단위를 말하며,

frame 2개가 합처지면 stream이다. 예를들면 header frame, data frame 이 두개를 하나의 stream으로 부를 수 있다.

( HTTP/1.1에서  head of line blocking문제를 HTTP/2.0에서는 frame, stream으로 해결했다)

사진을보면 클라이언트가 서버에게 HEADERS frame을 보낸다. (해당 요청은 GET요청이라서 HEADERS frame만 존재한다)

그리고 괄호안에 stream1이라고 나와있는데 이것은 스트림id값을 나타낸 부분이다.

클라이언트가 만든 스트림에 대한 id값은 1,3,5...로 홀수이고

서버가 만든 스트림은 2,4,6...으로 짝수가 된다.

위 경우는 클라이언트가 스트림id 1번에 대한 응답이기 때문에 서버는 스트림id 1번으로 HEADERS frame + DATA frame = 하나의 스트림으로 응답을 했다. header에는 HTTP 상태코드, 버전, 서버 등의 정보가 있고 data프레임에는 아마 우리가 ctrl+u를 누르면 보이는 소스가 있을것이다.

그리고 HEADERS frame에서 보면 'user-agent:' 으로 표시가 된 부분이 있고 ':path:'처럼 ':' 이 표시가 앞뒤로 있는게 있는데

user-agent는 HTTP/1.1, HTTP/2.0에서 쓰는 필드이고 ':'이 표시가 앞뒤로 있는것은 HTTP/2.0에서만 쓰는 필드이다.

다음은 naver로 GET 요청을 캡처한 화면이다.

HTTP/1.1에서 메타데이터는 단순한 text이고 크기는 500~800바이트정도이다. (만약 쿠키가 포함된 경우 킬로바이트까지 올라간다)

지금처럼 naver를 요청한 상태에서 또 다른 요청을 하게되면 아마 헤더는 크게 변함이 없을것이다.

중복된 필드가 존재할것이고 (대표적으로 User-agent) HTTP/1.1에서는 이런 중복된 데이터를 다시 보낸다.

하지만 HTTP/2.0에서는 중복전송하지 않는 방식으로 header를 압축한다.

다음은 HTTP/2.0에서 요청화면이다.

첫번째 요청에서는 6개의 필드를 보냈고, 두번째 요청에서는 중복되는 5개는 제외하고 1개의 필드만을 전송했다.

이렇게 HTTP/2.0은 중복헤더 데이터를 전송하지 않으므로 매 요청마다 오버헤드를 크게 줄일 수 있다.

같은 요청을 폴링하는 경우는 헤더가 변한게 없으므로 헤더 오버헤드는 0바이트이다.

이렇게 헤더 중복을 제거하고, 과거 포스팅한 Huffman coding방식으로 또 한번 압축을 진행한다.

이런 방식으로 HTTP/2.0에서는 header필드를 압축하여 프로토콜 오버헤드를 줄일 수 있다.

헤더 압축에 대해서 자세한 사항은 RFC7541 문서를 참고하기 바란다.

HTTP/2.0을 지원하는지 확인하는 방법 4번째로 keycdn.com 사이트를 이용하는 방법이 있다.

https://tools.keycdn.com/http2-test

위 링크로 이동하면 다음과 같은 화면이 나온다.

URL에 원하는 사이트를 입력하고 test버튼을 누르면 해당 URL이 HTTP/2.0을 지원하는지 나온다.

하단 부분에는 최근에 검색한 리스트가 나온다.

HTTP/2.0을 지원하는지 확인하는 방법 3번째로 curl 명령어가 있다. (과거 포스팅자료에서 잠시 등장한적이 있다)

윈도우를 사용하는 경우에는 curl명령어를 다운받아야한다. 이 글은 윈도우 기준으로 작성한다. (다른 OS라고 크게 다르지 않다)

    리눅스, 맥OS는 기본적으로 설치되어있다

    파이썬 아나콘다를 설치한 경우 아나콘다에 curl이 포함되어있어서 별도의 다운로드가 필요 없을수도있다.

RFC7540문서에는 HTTP/2.0을 지원하기 위한 조건에 http://, https:// 두가지 모두 지원한다고 나와있다.

하지만, 우리가 사용하는 대부분의 브라우저에서 http://, HTTP/2.0 의 조합을 지원하지 않는다.

현실적으로 HTTP/2.0을 사용하기 위해선 https://로 통신해야 한다고 생각하면된다.

https://로 통신하기 위해선 인증서가 필요하다. 그러므로 curl 명령어를 위한 인증서도 준비되어 있어야한다.

curl, 인증서는 아래 링크를 통한 사이트에서 받을 수 있다.

http://winampplugins.co.uk/curl/

해당 사이트에서 32bit or 64bit 본인에게 맞는것을 다운로드 하고 압축을 풀면 인증서와 curl이 나온다.

두 파일을 C:\Windows\System32안에 넣어주면 된다.

현재 PC에 curl이 설치되어 있는지 확인하기 위해선

    1. window + r을 눌러서 실행을 킨다

    2. cmd를 입력한다

    3. curl -V 를 입력한다 (V는 대문자이다)

다음과 같이 나오면 curl이 다운로드 된 상태이다.

이 curl의 옵션을 이용해서 우리는 HTTP/2.0 지원 여부를 확인할 수 있다.

(버전이 낮은 경우에는 이 옵션이 없을수 있으니 최신 버전으로 설치할것을 권장한다.)

curl -I --http2 URL -> 이 옵션을 통해서 확인이 가능하다.

    -I (대문자 i)는 header를 보는 옵션이다.

    --http2는 http/2.0으로 통신하기위한 옵션이다. (정확히는 header의 필드값을 추가시켜준다)

    URL부분에 우리가 목표로할 사이트의 주소를 넣어주면 된다.

http://nghttp2.org 사이트를 대상으로 위 옵션을 적용해서 실행해보면

다음과 같이 노란박스 안에 HTTP/2로 나온다.

그런데 위에 HTTP/1.1 101 Switching Protocols가 먼저 응답을 했다.

이번엔 https://nghttp2.org로 테스트를 해보면 (아까와 차이점은 http , https의 차이이다)

역시 해당 사이트는 HTTP/2.0을 지원하므로 1.1이 아닌 2.0버전으로 통신하는게 보인다.

하지만 101 스위칭 프로토콜 부분은 보이지 않는다.

이 부분에 대해선 RFC7540문서에서 다음을 참조하기 바란다.

3.2.  Starting HTTP/2 for "http" URIs

3.3.  Starting HTTP/2 for "https" URIs

http2로 통신하는 여부를 확인하는 또 다른 방법은 개발자 도구를 이용하는것이다.

F12를 통해서 개발자 도구를 실행시키면 Network 탭을 누르고 새로고침을 하면 다음과같은 창이 뜨는데

여기서 주황박스 위치를 우클릭하고 빨간 박스를 클릭하면 프로토콜을 볼 수 있다

google은 SPDY를 사용하고있는걸 확인 할 수 있다.

현재 보고있는 웹사이트가 http2(혹은 SPDY)를 지원하는지를 확인하고 싶으면

chrome 웹스토어에서 HTTP/2 and SPDY indicator를 통해서 확인하는게 가장 쉽다. (firefox에도 있는것같다)

해당 앱을 설치하면 우측 상단에 번개모양의 심볼이 생기는데

해당 심볼이 파란색이면 HTTP2를,

빨간색이면 SPDY를 지원한다.

둘 다 지원하지 않으면 아무색도 들어오지않는다.

"#1. HTTP/1.1에서 HTTP/2.0 (https인 경우)"글에서 와이어샤크로 캡처한 화면은 없었다.

http를 사용하는 사이트에서는 와이어샤크로 캡처하면 http2 스위칭하는 부분이 별도의 처리 없이 보였었는데

https를 사용하는 사이트를 와이어샤크로 캡처해보니 http2라고 안나오고 TLS라고만 나왔다. (하지만 실제로 통신은 HTTP/2.0으로 통신했다)

와이어샤크로 https://nghttp2.org를 캡처한 화면

(빨간박스 안에 http2는 보이지 않는다)

크롬에서는 HTTP/2.0로 통신한다고 나온다

해결방법은 암호화한(SSL or TLS) 패킷을 복호화해서 보여주면 된다.

와이어샤크가 패킷을 읽고 "이건 HTTP/2.0네?"라고 인지하고 http2표현하는것 같은데

암호화가 되어있어서 와이어샤크는 이 패킷을 읽을 수 없어서 암호화 형태를보고 (혹은 다룬부분을 보고...) SSL or TLS라고 표현하는것같다.

실제로 복호화하는 절차를 거친 후 패킷을 캡처해보니 http2라고 나오는걸 확인할 수 있다.

(복호화 하는 절차 : http://http2.tistory.com/6)

'http' URL을 가진 HTTP/1.1에서는 HTTP/2.0으로 통신하기 위해서 HTTP/1.1 101 Switching Protocols을 거치는 과정이 있었다.

하지만 'https' URL을 가진 웹사이트는 101 스위칭 프로토콜을 거치는 과정이 필요없다.

CMD창에서 curl 명령어를 통해서 101 스위칭 프로토콜을 받지 않고 바로 HTTP/2.0으로 받는걸 볼 수 있다.

또한 http로 접속한건 101 스위칭 프로토콜을 받은걸 볼 수 있다.

그리고 크롬 개발자 도구를 통해서도 현재 사용중인 프로토콜을 확인 할 수 있다.

다음글 보기: http://http2.tistory.com/5

HTTP/2.0을 지원하는 웹페이지는 HTTP/1.1를 동시에 지원한다.

해당 사이트가 HTTP/2.0을 지원하는지 모르기 때문에 맨 처음 connection이 이루어지면 1.1버전으로 통신을 하고

HEAD를 보낼때 "너 HTTP/2.0버전을 지원하니?"라고 물어본다. (빨간 박스 부분이 물어보는 부분이다)

아래 표는 'http' URL을 사용하는 사이트의 경우 HTTP/2.0을 시작하기 위한 예시를 나타낸다(RFC 7540참고)

아래 스크린샷은 curl 명령어를 통해서 nghttp2.org라는 사이트와 통신하는것을 캡처한것이다.

(106.186.112.116은 nghttp2.org사이트의 ip주소이다)

만약 서버가 HTTP/2.0을 지원하지 않으면 이 요청(빨간색박스)을 무시하고 기존 1.1버전의 사이트를 200 OK로 내려준다.

하지만 이 경우는 서버가 HTTP/2.0을 지원하므로 HTTP/1.1 101 Switching Protocols 이라는 답장을 했다. (초록색 박스)

(여기서 HTTP/1.1 101 Switching Protocols은 "지금 HTTP/1.1을 쓰고있는데 HTTP/2.0으로 바꾸자"라고 답을해준거라 생각해도 된다.)

그 후 프로토콜은 HTTP/2.0으로 상승해서 통신하는 부분을 볼 수 있다. (주황색 박스)

*다음과 같이 CMD에서 curl명령어를 통해 101 스위칭 프로토콜이 도착하고, HTTP/2.0으로 변경된걸 확인 할 수 있다.