SPDY
신규서비스개발팀 / 최윤상
더 빠른 웹을 위한 프로토콜
1
횽들 SPDY가 모하는거야? 누가 정리해놓은거 없삼? 횽들 안냥~ 나 발표해야 되는데 SPDY가 모야? 댜블로3 할 시간도 없는데 ... 후딱~냉큼~간략하게 정리좀 해조라. 응? 출처 : 디시인사이드 개발자 | 게시판 내 검색 | 저장된 페이지
야 SPDY쓰면 정말 빨라지냐?IE판인 한국에서 이거 쓰면 효과있냐? 써본사람~손! 사장님이 이거 효과 없으면 인쎈 안준대! 출처 : 디시인사이드 개발자 | 게시판 내 검색 | 저장된 페이지
2
SPeeDY 스피-디 라고 읽어
횽이 정리해줄께
압축을 해서 속도를 높이겠다는거지!
작명센스가 괜찮지?
안녕~횽 왔다~
3
횽들이 만들었대
“make the web faster” initiative
라는 전지구적 음모의 일부분이지
https://developers.google.com/speed/
느림의 미학 따윈 모르는 놈들!
4
근데 횽~
십수년간 웹을 써왔는데
왜 갑자기 속도 타령인거야?
5
HTTP가 언제 만들어졌는지 알아?
무려 20년전에 만들어 졌다구
1991 1996 1999 2012HTTP 0.9
HTTP 1.0HTTP 1.1 아직도
HTTP 1.1
6
1996년Yahoo가 코흘리개 꼬맹이이던 시절이지
꼴랑 이미지 2개짜리 페이지야
http://web.archive.org/web/19961219135447/http://www9.yahoo.com/
3 Requests 34KByte
7
요즘은 어떨거 같애?
73 Requests 658.4 KB
8
15년 이 지난 지금웹문서 하나를 보여주기 위해서
20배 이상의 리소스들을
다운로드 받아야 하는 상황이 된거야
9
HTTP 만들때 이런 상황은 상상도 안해봤어~
미안~
TBL 횽이 이런걸 고려했을까? 당시에?
10
네트웍 관련된건 TCP가 알아서 하겠지
그니깐 HTTP 만들때는 이랬던거지
HTTP는 요청/응답 형태로 심플하게!
Latency? 그건 먹는거임? 우걱우걱~
애초에 네트웍 성능에 대한건 크게 고민 안했던거야
그래서 이제 latency가 문제되는거고
11
횽말은
웹이 느린게 HTTP 때문이라는거야?
12
HTTP는 기본적으로
커넥션당 하나의 요청을 처리하도록
설계되어있어
그렇다고 할 수 있어. 몇 가지 요인이 있는데...
13
자~ HTTP Connection을 Tube라고 생각해봐
미안해~ 귀찮아서 발로 그렸어
14
이 Tube로는 동시전송이 불가능해
그래서 요청/응답은 순차적으로 이루어지게 되지
15
결국 latency를 줄이려면동시에 여러 요청/응답을
처리할수 있도록Tube가 여러개 있어야 하는거지
그래서 요즘 브라우저들이 도메인당 연결을 6개씩 쓰는거야
16
이런 꼼수로 브라우저의
도메인 당 커넥션 수를 늘리면
클라이언트의 병렬수행 효율은 높아짐에 따라
Latency도 작아지겠지
17
“커넥션 당 하나의 요청”의 또 다른 문제는
TCP Slow Start 야
18
이 그림 기억나지?TCP는 혼잡회피를 위해서소심하게 네트웍 상황을 간보는거야
19
근데 그동안은 패킷을 쬐끔씩만 주고 받으니깐Latency가 커질 수 밖에 없어
20
70여개의 리소스들을 다운로드 받는데모든 TCP connection들이각각 1패킷 씩 보내면서 warm up하는미친 짓을 하고 있다고!
아~! 땅 파랬더니삽질 한번 할때마다 준비운동하는거구나!
21
정리하면 HTTP는 TCP 커넥션을 비효율적으로 사용하고 있어서 Latency가 문제가 된다는거지
22
압축을 하지 않는다는거야
HTTP의 또다른 문제는
23
잉? 거짓말!
24
봐~ 압축하잖아!
25
Body 압축도 선택적으로 이루어질 뿐이지
여기서 StartLine, Header은
Plain Text Format인데다가
심지어는 압축도 안해
자~ HTTP 메시지 구조를 볼까?
26
Header 그게 얼마나 된다구
압축 안하는게 문제가 돼?
27
Cookie, User-Agent 등등갈수록 HTTP Header는 커지고 있어
28
매 요청마다 동일한 Header들이 중복되어 전송되고 있지
29
너 많이 컸다!
나 요즘 머리크기만 2KB정도 돼!
30
HTTP Header가 커지고 있는 현재 추세를 봤을때
이젠 Header 압축은 선택이 아니라 필수야
31
그럼
SPDY는 이 문제를 어떻게
해결해주는거야?
32
SPDY는동시 송수신이 가능한 큰 Tube를 쓰는 방식이라고 할 수 있어
즉, stream들을 multiplexing 하는거야
33
Multiplexed Streams ? 그냥 HTTP Pipelining
쓰면 똑같은거 아녀?
34
HTTP Pipelinging은 이래...
첫번째 응답을 받기전에 두번째, 세번째 요청을 보낼 수 있다는 점에서는 같아
근데 기본적으로 FIFO라서 순서대로 응답이 오는거지
즉, 하나가 지연되면 나머지 응답들도 죄다 늦어지는거지
req#1
req#2
req#3
res#1
res#2
res#3
req#4
35
이제 SPDY를 볼까?
이건 SYN_STREAM 이라고 세션을 시작할 때 보내는 control frame이야
36
응~! 맞아!
SPDY는 Binary Protocol이얌
37
하나의 TCP 연결 위에서다수의 Stream을 동시에 처리하는거지
38
bandwidth 제한에 따른 지연을 막기 위해요청에 대한 우선 순위를 줄 수도 있어~
훗~ 이런건 기본이랄까~
39
헤더들은 기본적으로 압축되어 전송돼
다른 control/data frame에서도 data 블럭도 마찬가지야
40
이미지가 10개 정도 있는 웹페이지야
간단한 샘플을 하나 보자구
41
HTTP의 경우
42
SPDY의 경우
43
요약해줄께
SPDY는 하나의 커넥션으로
완전하게 다수의 요청/응답을
동시에 송수신이 가능하게 하는
프로토콜이야
44
자...잠깐!이거 HTTP를 완전히 대체하는거야?
45
아냐SPDY는 SSL과 HTTP 사이에서 작동해
46
HTTP의
데이터 전송 포맷과
커넥션 관리부분을
살짝 고쳐서 TCP 커넥션을 효율적으로 쓰도록 바꿨다고 보면 돼
47
그럼
SPDY를 쓰면 얼마나 좋아져?
48
Top 25개의 사이트에 대해서 평균 페이지 로딩 시간을 측정해봤지...
49
미안~! 저런거 보면 정신이 혼미해지지?
간단하게 정리해줄께~
50
39~55%HTTP+SSL 대비
51
오호~좀짱!더 자세히 설명해봐!
52
실험해보니 압축하면
요청헤더의 크기가 88%응답헤더의 크기가 85%정도 줄어들어
이걸로도 페이지 로딩시간을 45~1142ms 정도 줄여주더라고
헤더압축 효과가 제법 커
53
그리고
패킷손실율와 RTT가 큰
네트웍 환경에서 SPDY의 성능향상 폭이 더 크더라고
54
패킷손실율이 2%일 때 HTTP보다 47% 가량 빨라
(미국 기준의 평균패킷손실율은 1~2%정도)
55
SPDY는 모든 요청을 병렬로 처리하기 때문에RTT의 영향을 덜 받게 되지
RTT가 100~200ms일 때 HTTP보다 20% 이상 빨라(미국 기준의 평균RTT 100~200ms정도)
56
자세한 결과 데이터는 Reference 참고해
57
그리고 SPDY에게는 비장의 무기
Server Push가 있어
58
아~ 이런거?Comet
AJAX long-poolingweb socket
59
땡~!!!
60
HTTP는 이렇지...
웹페이지를 파싱한 다음에필요한 리소스를 각각 요청해서 다운로드하지
61
SPDY의 Server Push는 이렇게 해
관련된 리소스를 요청하지 않아도서버에서 한번에 보내주는거지
62
html에 대한 요청
html과 관련된 css, js, image도 모두 보내준달까
63
HTTP는 이런 요청/응답 패턴이 나오는데 ...
64
Server Push를 사용하면 이런 요청/응답 패턴이 돼
no request no wait
65
SPDY protocol이 관련 resource를 알아서 push해주는거야?
66
설마~그럴리가 있겠어 ㅜ.,ㅜ
67
이렇게 서버 측 코딩이 필요해 ...
68
혹은 서버 측에서 HTML을 parsing해서 push 해줄 수도 있겠지
69
횽 생각에는 Server Push가 HTTP의 요청/응답 시맨틱스를 벗어나기 때문에앞으로 어떻게 될지는 잘 모르겠어
70
또 Server Push와 비슷한
Server Hint라는 기능도 있어
71
X-Subresources 라는 응답헤더로웹페이지에 딸린 리소스들을 알려주는 건데
Server Hint는...
72
Server Push보다 인상적이지 않으니깐 스킵할께
73
서버와 클라이언트를모두 바뀌어야 하잖아. 맞지?
근데 나 지금 바로 써볼 수 있는겨?곧 평가시즌이라구!
74
맞아SPDY는 SPDY를 지원하는
Web Server와 Browser가 모두 필요해
75
현재 크롬 브라우저가 SPDY를 지원하고 있어
구글이 만든거니깐 당연히
그리고Firefox는 13버전부터
SPDY를 지원하기로 했대
76
현재 Chrome+Firefox 점유율이 50%가 넘었거든...
꼴통 IE를 무시한다치면 브라우저 쪽은 어느 정도 환경이 만들어졌다고 봐도 돼
77
그리고 SPDY를 지원하는
Web server는
Apache의 mod_spdy가 있고
Jetty도 SPDY connector를 제공해
Nginx도 곧 SPDY 모듈을 내놓을거야
78
이 외에도 많은 웹서버 구현체와 라이브러리들이 있어
Python SPDY Server
Ruby SPDY
node.js SPDY
Netty SPDY
Go SPDYErlang SPDY
Java SPDY spindly(C lib)
spdylay (C lib)
iPhone SPDY
79
SPDY는 오픈 프로토콜이고IETF에서 HTTP 2.0의 일부로 논의되고 있어
그러니깐 앞으로 SPDY 지원이 더 나아질 거라는거야횽 말 믿어~
80
좋아~좋아~나 울 서비스에 SPDY 적용할래
81
근데 있자나 이제 와서 고백하는건데
SPDY를 쓸려면 SSL이 필요해
엥? 이제 와서 뭥미?
HTTPS로 운영되는 서비스를 담당하고 있는 경우라면
도입을 고려볼 수 있을거야미안해 ㅡ.,ㅡ
82
SPDY에 대한 더 자세한 사항은 아래를 참고해
http://dev.chromium.org/spdywhite paper, specification 등 공식문서들이 있어
“The SPDY Book: Making Websites Fly”, 2011 현재로서는 유일한 SPDY 책인 것 같아
TLS Next Protocol Negotiationhttps://technotes.googlecode.com/git/nextprotoneg.html구글이 IETF에 제안한 NPN에 대한 내용이 있어
Apache mod_spdy http://code.google.com/p/mod-spdy/ mod_spdy를 쓸려면 꼭 읽어봐
SPDY 한글 자료http://oddpoet.net/archives/409http://oddpoet.net/archives/425
HTTP : The Definitive GuideHTTP의 교과서! 이건 필독이얌!
83
Thank You빠빠~ 횽 간다
84