Your SlideShare is downloading. ×
SPDY : 더 빠른 웹을 위한 프로토콜
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

11,370
views

Published on

Published in: Technology

11 Comments
121 Likes
Statistics
Notes
No Downloads
Views
Total Views
11,370
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
288
Comments
11
Likes
121
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 2012HTTP 0.9 HTTP 1.1 아직도 HTTP 1.0 HTTP 1.1 6
  • 7. 1996년Yahoo가 코흘리개 꼬맹이이던 시절이지 꼴랑 이미지 2개짜리 페이지야 3 Requests 34KBytehttp://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. 아~ 이런거? CometAJAX 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