1. SPDY
더 빠른 웹을 위한 프로토콜
신규서비스개발팀 / 최윤상
1

2. 횽들 SPDY가 모하는거야? 누가 정리해놓은거 없삼?
횽들 안냥~ 나 발표해야 되는데 SPDY가 모야?
댜블로3 할 시간도 없는데 ... 후딱~냉큼~간략하게 정리좀 해조라. 응?
출처 : 디시인사이드 개발자 | 게시판 내 검색 | 저장된 페이지
야 SPDY쓰면 정말 빨라지냐?
IE판인 한국에서 이거 쓰면 효과있냐? 써본사람~손!
사장님이 이거 효과 없으면 인쎈 안준대!
출처 : 디시인사이드 개발자 | 게시판 내 검색 | 저장된 페이지
2

3. 안녕~횽 왔다~
횽이 정리해줄께
SPeeDY 스피-디 라고 읽어
압축을 해서 속도를 높이겠다는거지!
작명센스가 괜찮지?
3

4. 횽들이 만들었대
“make the web faster” initiative
https://developers.google.com/speed/
라는 전지구적 음모의 일부분이지
느림의 미학 따윈 모르는 놈들!
4

5. 근데 횽~
십수년간 웹을 써왔는데
왜 갑자기 속도 타령인거야?
5

6. HTTP가 언제 만들어졌는지 알아?
무려 20년전에 만들어 졌다구
1991 1996 1999 2012
HTTP 0.9 HTTP 1.1 아직도
HTTP 1.0 HTTP 1.1
6

7. 1996년
Yahoo가 코흘리개 꼬맹이이던 시절이지
꼴랑 이미지 2개짜리 페이지야
3 Requests
34KByte
http://web.archive.org/web/19961219135447/http://www9.yahoo.com/
7

8. 요즘은 어떨거 같애?
73 Requests
658.4 KB
8

9. 15년 이 지난 지금
웹문서 하나를 보여주기 위해서
20배 이상의 리소스들을
다운로드 받아야 하는 상황이 된거야
9

10. TBL 횽이 이런걸 고려했을까? 당시에?
HTTP 만들때
이런 상황은 상상도 안해봤어~
미안~
10

11. 그니깐 HTTP 만들때는 이랬던거지
네트웍 관련된건 TCP가 알아서 하겠지
HTTP는 요청/응답 형태로 심플하게!
Latency? 그건 먹는거임? 우걱우걱~
애초에 네트웍 성능에 대한건 크게 고민 안했던거야
그래서 이제 latency가 문제되는거고
11

12. 횽말은
웹이 느린게 HTTP 때문이라는거야?
12

13. 그렇다고 할 수 있어.
몇 가지 요인이 있는데...
HTTP는 기본적으로
커넥션당 하나의 요청을 처리하도록
설계되어있어
13

14. 자~ HTTP Connection을 Tube라고 생각해봐
미안해~ 귀찮아서 발로 그렸어
14

15. 이 Tube로는 동시전송이 불가능해
그래서 요청/응답은 순차적으로 이루어지게 되지
15

16. 결국 latency를 줄이려면
동시에 여러 요청/응답을
처리할수 있도록
Tube가 여러개 있어야 하는거지
그래서 요즘 브라우저들이
도메인당 연결을 6개씩 쓰는거야
16

17. 이런 꼼수로 브라우저의
도메인 당 커넥션 수를 늘리면
클라이언트의 병렬수행 효율은 높아짐에 따라
Latency도 작아지겠지
17

18. “커넥션 당 하나의 요청”의
또 다른 문제는
TCP Slow Start 야
18

19. 이 그림 기억나지?
TCP는 혼잡회피를 위해서
소심하게 네트웍 상황을 간보는거야
19

20. 근데 그동안은 패킷을 쬐끔씩만 주고 받으니깐
Latency가 커질 수 밖에 없어
20

21. 70여개의 리소스들을 다운로드 받는데
모든 TCP connection들이
각각 1패킷 씩 보내면서 warm up하는
미친 짓을 하고 있다고!
아~! 땅 파랬더니
삽질 한번 할때마다
준비운동하는거구나!
21

22. 정리하면
HTTP는 TCP 커넥션을
비효율적으로 사용하고 있어서
Latency가 문제가 된다는거지
22

23. HTTP의 또다른 문제는
압축을 하지 않는다는거야
23

24. 잉? 거짓말!
24

25. 봐~ 압축하잖아!
25

26. 자~ HTTP 메시지 구조를 볼까?
여기서 StartLine, Header은
Plain Text Format인데다가
심지어는 압축도 안해
Body 압축도 선택적으로 이루어질 뿐이지
26

27. Header 그게 얼마나 된다구
압축 안하는게 문제가 돼?
27

28. Cookie, User-Agent 등등
갈수록 HTTP Header는 커지고 있어
28

29. 매 요청마다
동일한 Header들이 중복되어 전송되고 있지
29

30. 너 많이 컸다!
나 요즘 머리크기만
2KB정도 돼!
30

31. HTTP Header가 커지고 있는 현재 추세를 봤을때
이젠 Header 압축은 선택이 아니라 필수야
31

32. 그럼
SPDY는 이 문제를 어떻게
해결해주는거야?
32

33. SPDY는
동시 송수신이 가능한
큰 Tube를 쓰는 방식이라고 할 수 있어
즉, stream들을 multiplexing 하는거야
33

34. Multiplexed Streams ?
그냥 HTTP Pipelining
쓰면 똑같은거 아녀?
34

35. HTTP Pipelinging은 이래...
req#1
req#2
req#3 첫번째 응답을 받기전에 두번째, 세번
째 요청을 보낼 수 있다는 점에서는
res#1
같아
res#2
req#4 근데 기본적으로 FIFO라서
res#3
순서대로 응답이 오는거지
즉, 하나가 지연되면
나머지 응답들도 죄다 늦어지는거지
35

36. 이제 SPDY를 볼까?
이건 SYN_STREAM 이라고 세션을 시작할 때 보내는
control frame이야
36

37. 응~! 맞아!
SPDY는 Binary Protocol이얌
37

38. 하나의 TCP 연결 위에서
다수의 Stream을 동시에 처리하는거지
38

39. bandwidth 제한에 따른 지연을 막기 위해
요청에 대한 우선 순위를 줄 수도 있어~
훗~ 이런건 기본이랄까~
39

40. 헤더들은 기본적으로 압축되어 전송돼
다른 control/data frame에서도 data 블럭도 마찬가지야
40

41. 간단한 샘플을 하나 보자구
이미지가 10개 정도 있는 웹페이지야
41

42. HTTP의 경우
42

43. SPDY의 경우
43

44. 요약해줄께
SPDY는 하나의
커넥션으로
완전하게 다수의 요청/응답을
동시에 송수신이 가능하게 하는
프로토콜이야
44

45. 자...잠깐!
이거 HTTP를 완전히 대체하는거야?
45

46. 아냐
SPDY는 SSL과 HTTP 사이에서 작동해
46

47. HTTP의
데이터 전송 포맷과
커넥션 관리부분을
살짝 고쳐서
TCP 커넥션을 효율적으로 쓰도록
바꿨다고 보면 돼
47

48. 그럼
SPDY를 쓰면 얼마나 좋아져?
48

49. Top 25개의 사이트에 대해서
평균 페이지 로딩 시간을 측정해봤지...
49

50. 미안~!
저런거 보면 정신이 혼미해지지?
간단하게 정리해줄께~
50

51. 39~55%
HTTP+SSL 대비
51

52. 오호~좀짱!
더 자세히 설명해봐!
52

53. 헤더압축 효과가 제법 커
실험해보니 압축하면
요청헤더의 크기가 88%
응답헤더의 크기가 85%
정도 줄어들어
이걸로도 페이지 로딩시간을 45~1142ms 정도 줄여주더라고
53

54. 그리고
패킷손실율와 RTT가 큰
네트웍 환경에서
SPDY의 성능향상 폭이 더 크더라고
54

55. 패킷손실율이 2%일 때 HTTP보다 47% 가량 빨라
(미국 기준의 평균패킷손실율은 1~2%정도)
55

56. RTT가 100~200ms일 때 HTTP보다 20% 이상 빨라
(미국 기준의 평균RTT 100~200ms정도)
SPDY는 모든 요청을 병렬로 처리하기 때문에
RTT의 영향을 덜 받게 되지
56

57. 자세한 결과 데이터는 Reference 참고해
57

58. 그리고
SPDY에게는 비장의 무기
Server Push가 있어
58

59. 아~ 이런거?
Comet
AJAX long-pooling
web socket
59

60. 땡~!!!
60

61. HTTP는 이렇지...
웹페이지를 파싱한 다음에
필요한 리소스를 각각 요청해서 다운로드하지
61

62. SPDY의 Server Push는 이렇게 해
관련된 리소스를 요청하지 않아도
서버에서 한번에 보내주는거지
62

63. html에 대한
요청
html과 관련된
css, js, image도
모두 보내준달까
63

64. HTTP는 이런 요청/응답 패턴이 나오는데 ...
64

65. Server Push를 사용하면 이런 요청/응답 패턴이 돼
no request
no wait
65

66. SPDY protocol이
관련 resource를 알아서 push해주는거야?
66

67. 설마~
그럴리가 있겠어 ㅜ.,ㅜ
67

68. 이렇게 서버 측 코딩이 필요해 ...
68

69. 혹은 서버 측에서
HTML을 parsing해서 push 해줄 수도 있겠지
69

70. 횽 생각에는 Server Push가
HTTP의 요청/응답 시맨틱스를 벗어나기 때문에
앞으로 어떻게 될지는 잘 모르겠어
70

71. 또 Server Push와 비슷한
Server Hint라는 기능도 있어
71

72. Server Hint는...
X-Subresources 라는 응답헤더로
웹페이지에 딸린 리소스들을 알려주는 건데
72

73. Server Push보다 인상적이지 않으니깐 스킵할께
73

74. 서버와 클라이언트를
모두 바뀌어야 하잖아. 맞지?
근데 나 지금 바로 써볼 수 있는겨?
곧 평가시즌이라구!
74

75. 맞아
SPDY는 SPDY를 지원하는
Web Server와 Browser가 모두 필요해
75

76. 현재
크롬 브라우저가 SPDY를 지원하고 있어
구글이 만든거니깐 당연히
그리고
Firefox는 13버전부터
SPDY를 지원하기로 했대
76

77. 현재 Chrome+Firefox 점유율이 50%가 넘었거든...
꼴통 IE를 무시한다치면
브라우저 쪽은 어느 정도 환경이 만들어졌다고 봐도 돼
77

78. 그리고 SPDY를 지원하는
Web server는
Apache의 mod_spdy가 있고
Jetty도 SPDY connector를 제공해
Nginx도 곧 SPDY 모듈을 내놓을거야
78

79. Python SPDY Server
Ruby SPDY
node.js SPDY iPhone SPDY
이 외에도
spdylay (C lib) 많은 웹서버 구현체와
라이브러리들이 있어 Netty SPDY
Erlang SPDY
Go SPDY
Java SPDY spindly(C lib)
79

80. SPDY는
오픈 프로토콜이고
IETF에서 HTTP 2.0의 일부로 논의되고 있어
그러니깐 앞으로 SPDY 지원이
더 나아질 거라는거야
횽 말 믿어~
80

81. 좋아~좋아~
나 울 서비스에 SPDY 적용할래
81

82. 근데 있자나 이제 와서 고백하는건데
SPDY를 쓸려면 SSL이 필요해
엥? 이제 와서 뭥미?
HTTPS로 운영되는 서비스를
담당하고 있는 경우라면
도입을 고려볼 수 있을거야
미안해 ㅡ.,ㅡ
82

83. SPDY에 대한 더 자세한 사항은 아래를 참고해
http://dev.chromium.org/spdy
white paper, specification 등 공식문서들이 있어
“The SPDY Book: Making Websites Fly”, 2011
현재로서는 유일한 SPDY 책인 것 같아
TLS Next Protocol Negotiation
https://technotes.googlecode.com/git/nextprotoneg.html
구글이 IETF에 제안한 NPN에 대한 내용이 있어
Apache mod_spdy
http://code.google.com/p/mod-spdy/
mod_spdy를 쓸려면 꼭 읽어봐
HTTP : The Definitive Guide
HTTP의 교과서! 이건 필독이얌! SPDY 한글 자료
http://oddpoet.net/archives/409
http://oddpoet.net/archives/425
83

84. Thank You
빠빠~ 횽 간다
84