[web network] SPDY ( 스피디 )

[web network] SPDY ( 스피디 )

Wiki

http://d2.naver.com/helloworld/140351

http://www.slideshare.net/oddpoet/spdy-13231459

-

두문자어가 아니며, Speedy 를 기반으로 구글이 만든 단어이다.

스피디 라고 읽는다.

-

구글이 개발한 비표준 개방형 네트워크 프로토콜이다. ( HTTP 2.0 에 들어갈 예정 )

-

SPDY 가 등장한 배경은 다음과 같다.

     더 많은 리소스

     다수의 도메인

     동적 동작

     보안이 중요한 이슈

-

웹 페이지 부하 레이턴시를 줄이고, 웹 보안을 개선한다.

압축, 다중화(Multiplexing, Pipiline 과는 다르다), 우선 순위 설정을 통해 레이턴시를 감소한다.

-

하나의 소켓 연결을 통해 페이지를 구성하는 여러 개의 하위 요소를 한꺼번에 전송받을 수 있다.

-

헤더를 gzip 또는 DEFLATE 알고리즘으로 압축하여 적은 용량을 전송한다.

그리고 기존에 전송한 헤더와 같은 내용의 헤더의 경우 재전송하지 않는다.

이 헤더 압축과 재전송에 대한 효율이 크다고 한다. 특히 모바일에서!

SPDY 가 HTTP+SSL 에 비해 39~55% 속도 향상을 보인다고 한다.

-

SPDY 서버는 클라이언트의 요청을 기다리지 않고, 페이지의 내용이 변경되었음을 클라이언트에 알리거나 새 변경내용을 직접 전송할 수 있다.(Push)

이것을 잘 사용하면, HTML 만을 요청했는데 관련된 js, css, image 등을 동시에 내려줄 수도 있다.

client 가 해당 js, css, image 등을 다시 요청하고 기다리는 수고를 덜 수 있다.

-

SPDY 는 SSL/TLS 사용이 요구된다. ( https 만 지원 )

그래서 TCP 위에서 항상 Secure 하도록 한다.

-

HTTP 를 대체하는 것이 아니라, HTTP 프로토콜 위에 전송 방식을 재정의하는 프로토콜이다.

-

이미 많은 Browser 최신버전들이 SPDY 를 지원하고 있다.

-

SPDY 적용을 위해서는 웹 사이트를 재작성할 필요가 없다.

다만, Browser(Client)와 서버가 SPDY 를 지원하기만 하면 된다.

-

-

SPDY 가 항상 뚜렷한 성능 향상을 보이는 것은 아니다.

다음의 경우에는 SPDY 가 오히려 Overhead 가 될 수도 있고, 성능 향상을 보이지 않을 수 있다.

     HTTP 만 사용하는 경우

          SSL 이 필요하므로, SSL Handshake 시간이 추가적으로 필요하다.

     도메인이 많은 경우

          SPDY 는 도메인별로 동작한다.

          커넥션은 도메인 갯수만큼 필요하고, Multiplexing 기능도 하나의 도메인안에서만 가능하다.

          또한 모든 도메인을 SPDY 를 지원하게 만들기는 어렵다.

     HTTP 가 병목이 아닌 경우

     RTT ( Round-trip delay time ) 이 작은 경우

          성능 향상은 있겠지만 두드러지지 않는다.

          반대로 RTT 가 크면서 패킷 손실율이 커질수록 SPDY 는 더 효율적이다.

          ( 2% 의 패킷 손실율(미국평균)에서 HTTP 보다 47% 성능 향상, RTT 가 100~200ms(미국평균) 일 때 HTTP 보다 20% 이상 빠름 )

     페이지 내의 리소스가 매우 적은 경우

-

SPDY 를 앱 레벨에서 적용하려면, 다음을 주의한다.

     하나의 커넥션만 사용

          가능한 적은 수의 커넥션을 사용하는 것이 유리하다.

          데이터를 더 나은 방법으로 패킷에 넣을 수 있고, 헤더 압축 효율이 좋아진다.

          커넥션 상태를 덜 확인하고, 핸드쉐이크도 적게 한다.

          커넥션 개수가 적어야 TCP 효율이 좋아지고 Bufferbloat 현상이 감소한다.

          ( BufferBloat 은 라우터나 스위치에서 패킷을 오래 버퍼링하여 전송 지연(latency)가 높아지고 처리량(throughput)도 줄어드는 현상 )

     domain sharding 을 피한다. ( [web network] Domain Sharding 이란? )

          domain sharding 은 흔히 웹 앱에서 브라우저의 동시 다운로드 개수 제한(일반적으로 hostname당 6개)을 피하기 위해 사용하는 일종의 편법이다.

          단일 커넥션을 사용할 경우 hostname sharding 이 불필요하다.

          hostname sharding 은 추가적인 DNS 쿼리를 발생시키고, 앱을 더 복잡하게 만든다.

     inlining 대신에 server push 를 사용한다. ( [web network] inlining 이란? )

          inlining 은 웹 앱에서 RTT 를 줄이기 위해 사용한다.

          그러나 inlining 은 웹 페이지가 보다 덜 캐시되게 하고 base64 인코딩 때문에 웹 페이지 크기를 크게 만든다.

          SPDY server push 를 사용하면 이로 인한 문제를 피할 수 있다.

     

     요청 우선순위를 사용한다.

          일반적으로 적용할 수 있는 간단한 휴리스틱 순위는 html > js, css > * 이다.

     적절한 SPDY 프레임 크기를 사용한다.

           SPDY 스펙에서 큰 크기의 프레임을 허용하지만, 때때로 작은 프레임이 바람직한 경우도 있다.

          프레임이 작은 경우에 프레임 interleaving 이 더 잘 동작한다.

          ( Frame은 TCP Level 의 Data 이름, Packet 은 IP Level 의 Data 이름 )

Browser, bufferbloat, client, css, deflate, deflate 알고리즘, dns query, domain sharding, gzip, header 압축, hostname sharding, HTML, http + ssl, http 2.0, inlining cache, js, multiplexing pipeline, Push, rount trip delay time, RTT, SPDY, spdy overhead, spdy push, spdy server, spdy 단점, spdy 서버, Speedy, SSL, ssl handshake, tcp 효율, TLS, [web network] SPDY ( 스피디 ), 네트워크 프로토콜, 다중화, 도메인, 동적 동작, 리소스, 모바일, 모바일 헤더 압축, 보안, 부하 레이턴시, 스피디, 압축, 요청 우선순위, 우선 순위, 웹 보안, 웹사이트, 효율, 휴리스틱