SPDY더 빠른 웹을 위한 프로토콜       신규서비스개발팀 / 최윤상                        1
횽들 SPDY가 모하는거야? 누가 정리해놓은거 없삼?횽들 안냥~ 나 발표해야 되는데 SPDY가 모야?댜블로3 할 시간도 없는데 ... 후딱~냉큼~간략하게 정리좀 해조라. 응?출처 : 디시인사이드 개발자 | 게시판 내 검...
안녕~횽 왔다~횽이 정리해줄께  SPeeDY 스피-디 라고 읽어       압축을 해서 속도를 높이겠다는거지!               작명센스가 괜찮지?                             3
횽들이 만들었대“make the web faster” initiative        https://developers.google.com/speed/                     라는 전지구적 음모의 일부분이지...
근데 횽~ 십수년간 웹을 써왔는데왜 갑자기 속도 타령인거야?                  5
HTTP가 언제 만들어졌는지 알아?                  무려       20년전에 만들어 졌다구1991 1996 1999                         2012HTTP 0.9            ...
1996년Yahoo가 코흘리개 꼬맹이이던 시절이지                                                       꼴랑 이미지 2개짜리 페이지야                        ...
요즘은 어떨거 같애?              73 Requests                658.4 KB                            8
15년 이 지난 지금 웹문서 하나를 보여주기 위해서  20배 이상의 리소스들을다운로드 받아야 하는 상황이 된거야                      9
TBL 횽이 이런걸 고려했을까? 당시에?            HTTP 만들때        이런 상황은 상상도 안해봤어~              미안~                           10
그니깐 HTTP 만들때는 이랬던거지   네트웍 관련된건 TCP가 알아서 하겠지   HTTP는 요청/응답 형태로 심플하게!   Latency? 그건 먹는거임? 우걱우걱~애초에 네트웍 성능에 대한건 크게 고민 안했던거야  ...
횽말은웹이 느린게 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하는미친 짓을 하고 있다고!             아~! 땅 파랬더니            삽질 한번 할때마다  ...
정리하면HTTP는 TCP 커넥션을비효율적으로 사용하고 있어서Latency가 문제가 된다는거지                     22
HTTP의 또다른 문제는 압축을 하지 않는다는거야                 23
잉? 거짓말!          24
봐~ 압축하잖아!            25
자~ HTTP 메시지 구조를 볼까?여기서 StartLine, Header은Plain Text Format인데다가심지어는 압축도 안해            Body 압축도 선택적으로 이루어질 뿐이지              ...
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은 이래...          req#1          req#2          req#3     첫번째 응답을 받기전에 두번째, 세번                    째 요청을 보낼 ...
이제 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%             정도 줄어들어이걸로도 페이지 로딩시간을...
그리고 패킷손실율와 RTT가 큰      네트웍 환경에서SPDY의 성능향상 폭이 더 크더라고                       54
패킷손실율이 2%일 때 HTTP보다 47% 가량 빨라     (미국 기준의 평균패킷손실율은 1~2%정도)                                55
RTT가 100~200ms일 때 HTTP보다 20% 이상 빨라       (미국 기준의 평균RTT 100~200ms정도)    SPDY는 모든 요청을 병렬로 처리하기 때문에          RTT의 영향을 덜 받게 되지...
자세한 결과 데이터는 Reference 참고해                            57
그리고SPDY에게는 비장의 무기Server Push가 있어                  58
아~ 이런거?     CometAJAX long-pooling   web socket                    59
땡~!!!        60
HTTP는 이렇지...         웹페이지를 파싱한 다음에    필요한 리소스를 각각 요청해서 다운로드하지                              61
SPDY의   Server Push는 이렇게 해    관련된 리소스를 요청하지 않아도     서버에서 한번에 보내주는거지                             62
html에 대한   요청            html과 관련된           css, js, image도           모두 보내준달까                             63
HTTP는 이런 요청/응답 패턴이 나오는데 ...                              64
Server Push를 사용하면 이런 요청/응답 패턴이 돼                       no request                        no wait                          ...
SPDY protocol이관련 resource를 알아서 push해주는거야?                              66
설마~그럴리가 있겠어 ㅜ.,ㅜ                67
이렇게 서버 측 코딩이 필요해 ...                       68
혹은 서버 측에서HTML을 parsing해서 push 해줄 수도 있겠지                                 69
횽 생각에는 Server Push가HTTP의 요청/응답 시맨틱스를 벗어나기 때문에앞으로 어떻게 될지는 잘 모르겠어                             70
또 Server Push와 비슷한Server Hint라는 기능도 있어                       71
Server Hint는... X-Subresources 라는 응답헤더로웹페이지에 딸린 리소스들을 알려주는 건데                           72
Server Push보다 인상적이지 않으니깐 스킵할께                                73
서버와 클라이언트를모두 바뀌어야 하잖아. 맞지?근데 나 지금 바로 써볼 수 있는겨?          곧 평가시즌이라구!                       74
맞아     SPDY는 SPDY를 지원하는Web Server와 Browser가 모두 필요해                              75
현재  크롬 브라우저가 SPDY를 지원하고 있어                    구글이 만든거니깐 당연히              그리고  Firefox는 13버전부터SPDY를 지원하기로 했대               ...
현재 Chrome+Firefox 점유율이 50%가 넘었거든...꼴통 IE를 무시한다치면브라우저 쪽은 어느 정도 환경이 만들어졌다고 봐도 돼                                      77
그리고 SPDY를 지원하는Web server는   Apache의 mod_spdy가 있고   Jetty도 SPDY connector를 제공해   Nginx도 곧 SPDY 모듈을 내놓을거야                   ...
Python SPDY Server                               Ruby SPDY     node.js SPDY                      iPhone SPDY              ...
SPDY는오픈 프로토콜이고IETF에서 HTTP 2.0의 일부로 논의되고 있어            그러니깐 앞으로 SPDY 지원이            더 나아질 거라는거야            횽 말 믿어~         ...
좋아~좋아~나 울 서비스에 SPDY 적용할래                     81
근데 있자나 이제 와서 고백하는건데 SPDY를 쓸려면 SSL이 필요해    엥? 이제 와서 뭥미?  HTTPS로 운영되는 서비스를    담당하고 있는 경우라면   도입을 고려볼 수 있을거야             미안해 ...
SPDY에 대한 더 자세한 사항은 아래를 참고해              http://dev.chromium.org/spdy                 white paper, specification 등 공식문서들이 있...
Thank You       빠빠~ 횽 간다                  84
Upcoming SlideShare
Loading in...5
×

SPDY : 더 빠른 웹을 위한 프로토콜

12,596

Published on

Published in: Technology
12 Comments
138 Likes
Statistics
Notes
No Downloads
Views
Total Views
12,596
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
325
Comments
12
Likes
138
Embeds 0
No embeds

No notes for slide

Transcript of "SPDY : 더 빠른 웹을 위한 프로토콜"

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

    Recortar slides é uma maneira fácil de colecionar informações para acessar mais tarde.

×