SPDY에 대해 간결하고 명확하게 쓴 문서

참여 방법

Todo1. 각 문단에서, 중요한 정보 부분을 굵게 표시합니다~

중요한 정보가 아닌 부분은 회색으로 표시합니다.

참여하신 분

@Hong Hwanmin

@김나솔

What Web Users Need to Know About SPDY

웹을 사용하는 사람들이

SPDY 프로토콜에 대해 알아야 하는 것들

By Joe Brockmeier / April 19, 2012 11:07 AM / 1 Comment

inShare36

Share on Tumblr

More Sharing Services

[1] Slowly but surely, SPDY ("speedy") is becoming more widely used. The Google-backed protocol, a modification to HTTP, is designed to help reduce latency and bolster security. Even if you don't manage a Web server yourself, you should know about SPDY and what it offers to you - and the Web at large.

확실히 SPDY를 더 많이 사용하고 있다. SPDY가 퍼지는 속도가 느리기는 하지만....

SPDY는 구글이 지원하는 프로토콜이며, 속도를 개선하고 보안을 향상하기 위해  HTTP를 변형한 것이다.  

웹서버를 운영하는 사람이 아니더라도, 웹을 사용하는 사람으로서 SPDY에 대해, 그리고 SPDY가 주는 이점에 대해서 알아야 한다. 그리고 웹 전반에 대해서도 알아야 한다.

[2] SPDY has been in development for a couple of years, but a few things will start to accelerate its deployment.

[3] First, Google has put out a SPDY module for Apache, which will make it much easier for organizations to deploy SPDY. Nginx is expected to have an implementation by end of May. That covers a huge chunk of the server market already.

# SPDY를 지원하는 것과 관련하여, 서버와 클라이언트 중에, 서버 쪽에 대한 얘기를 하고 있음.

우선 SPDY는 구글이 아파치용으로 내놓은 모듈이다. 

우선, 구글은 아파치용 SPDY를 내놓았다. 즉, 조직에서는 SPDY를 구현(implement)하기가 쉬울 것이다.

Nginx은 5월 말에 SPDY 모듈을 지원할 예정이다. (역자주 : Nginx는 Apache와 함께 시장을 많이 점유하고 있는 웹서버이다.) 이 말은, SPDY가 서버 시장은 이미 많은 부분을 커버할 수 있다는 의미이다.

[4] Second, SPDY should be on by default in Firefox 13, and Chrome (and Chromium) already supports SPDY. Which means that organizations have more incentive than ever to start turning on SPDY.

# 이번에는 클라이언트에서 SPDY 지원해주는 것에 대한 내용을 언급함.

그리고, 파폭 13에서는 기본으로 SPDY를 지원해줄 것이다.

크롬에서는 이미 SPDY를 지원한다.

즉 조직 입장에서는 SPDY를 실제로 사용하려는 동기가 그 어느 때보다 더욱 강해질 것이다.

QQ.

Which means

that organizations have (more) incentive (than ever)     /  more than ever 어느 때보다 더

to start turning on SPDY.

앞에 말한 것은 뜻한다. 조직은 좀더 장려된다. (이전보다) SPDY로 향하는 것을 시작하는 것을.

맞나요?

which가 가리키는 것은 위에서 말한 것을 가리키는 것 맞아요~

즉, 조직은 SPDY를 turn on 하기 시작할 인센티브가 그 어느 때보다도 많다..

오 이해됨.

GOOD!

What SPDY Is, and What It Offers

SPDY란 뭔가, SPDY는 어떤 점이 좋나?

[5] SPDY is a two-layer HTTP-compatible protocol. To break that down into more manageable terms, SPDY is like HTTP, but with additional features designed for today's Web. The "upper" layer provides HTTP's request and response semantics,
while the "lower" layer manages encoding and sending the data.

그니깐 SPDY에는 레이어가 두 개 있는데,

상위 레이어가 하는 역할 - HTTP 요청, 응답 시맨틱스 부분을 담당하고..

하위 레이어가 하는 역할 -  데이터를 인코딩하고 보내는 부분을 담당함.

[6] The lower layer of SPDY provides a number of benefits over standard HTTP. Namely, it sends fewer packets, uses fewer TCP connections and uses the TCP connections it makes more effectively.

# 하위 레이어는 HTTP에 비해 장점이 많이 있는데, 그 장점을 세부적으로 언급함~

패킷을 더 적게 보내고,,

TCP 연결을 더 적게 사용하고.

또한 TCP를 더욱 효율적으로 사용한다.

[7] A single SPDY session allows concurrent HTTP requests to run over a single TCP/IP session. As Patrick McManus writes in SPDY: What I Like About You, it's great for high-latency environments "because a resource never needs to be queued on either the client or the server for any reason other than network congestion limits."

SDPY는 하나의 TCP/IP 세션을 연결해서 (단일 SPDY 세션에서), HTTP 요청을 동시에 여러 개 보낼 수 있나 봄. 표준 HTTP는 연결 하나 (세션 하나)에 동시 요청 하나인데. 웹 서버의 성능 저하는 연결 수의 폭주로 인하여, 서버 쪽 쓰레드 (연결당 하나)가 동시에 많이 돌면서 생기는 거라. 그래서 아파치와 같은 전통적인 웹서는 엔진엑스와 같은 최근에 나오는 웹서버들은 비동기 방식의 통신을 통해서 쓰레드 하나에 여러 연결을 다룰 수 있어서 성능이 좋다고 함. 이 프로토콜을 이용하면 아마도 아파치와 같은 웹서버에서도 성능향상이 기대됨.

맞게 이해한건가? ^^

[8] SPDY cuts down on the number of TCP handshakes required,
and it
cuts down on packet loss and bufferbloat. 

SPDY의 장점을 두 가지 언급하고 있음..
필요한 TCP handshakes의 수를 줄여주고,
손실되는 패킷하고 bufferbloat를 줄여줌..


Says McManus, "
SPDY's parallelism, by virtue of being on a single TCP stream, leverages one busy shared congestion control block instead of dealing with 36 independent tiny ones. Because the stream is much busier it rarely has to guess at how much to send (you only need to guess when you're idle, SPDY is more likely to be getting active feedback), if it should drop a packet it reacts to that loss much better via the various fast recovery mechanisms of TCP, and when it is competing for bandwidth at a choke point it is much more responsive to the signals of other streams - reducing the over buffering problem."

QQ.

와 이거 왜이리 문장이 긴가요? 제대로 줄바꿈 한건가요?

Because the stream is much busier

it rarely has to guess at how much to send

(you only need to guess when you're idle,

SPDY is more likely to be getting active feedback),

if it should drop a packet

it reacts to that loss

much better via the various fast recovery mechanisms of TCP,

and when it is competing for bandwidth at a choke point

it is much more responsive to the signals of other streams

- reducing the over buffering problem."

Because the stream is much busier

it rarely has to guess at how much to send

(you only need to guess when you're idle,

SPDY is more likely to be getting active feedback),

if it should drop a packet

it reacts to that loss much better

via the various fast recovery mechanisms of TCP,

and when it is competing for bandwidth at a choke point

it is much more responsive to the signals of other streams

- reducing the over buffering problem."

저도 비슷하게 줄바꿈하게 되네요, 뒷부분의 위상만 약간 다르네요~

thanks~

[9] There's currently a lot of redundancy and bandwidth wasted in HTTP headers. SPDY compresses HTTP headers, which means that fewer bytes have to be transmitted between client and server.

현재는 이러이러 한데, - HTTP 헤더에서 redundancy와 대역폭이 많이 낭비되는데..

SPDY에서는 HTTP 헤더를 줄여주니깐, (압축해주니깐)

클라이언트, 서버 간에 서로 주고 받는 바이트 수가 적어짐..

[10] All that adds up to serious performance improvements.

According to Google's initial whitepaper on SPDY,

you could see "a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL),

and 39% - 55% over SSL."

(위의 그림을 봐 주세요.

- SPDY나 SSL은 선택적입니다. (각각 있어도 되고 없어도 되고)

- SPDY는 속도를 증가시켜주는 역할을 하고 , SSL은 보안을 강화시켜주는 역할을 합니다.

- 각각은 계층(레이어)형태로 순차적으로 쌓이게 됩니다. 가장 단순한 형태로 TCP계층위에 HTTP계층이 오도록 구성할 수 있고, 속도만을 고려하여 TCP계층위에 SPDY계층을 그리고 그 위에 HTTP계층을 오게 구성할 수있고, 또는 속도와 보안을 둘 다 고려하여 TCP위에 SSL계층 그 위에 SPDY계층 그리고 그 위에 HTTP계층이 오게 구성할 수 있습니다.

이를 토대로 해석해보면 TCP계층위에 HTTP계층이 있는것보다 TCP위에 SPDY 그 위에 HTTP가 있는 경우가 27~60% 속도향상이 되고,

TCP계층위에 SSL계층위에 HTTP계층이 있는것보다 TCP위에 SSL위에 SPDY이 있는것이 39%~55% 속도향상이 있다는 얘기네요. over는 말 그대로 ~위에 의 뜻이네요.)

이는 결국 성능 개선으로 이어지고..

뒷부분은 성능 개선.. 에 대한 구체적인 사례를 제시한 것.

SPDY에 대해 구글에서 작성한 초기 백서에 보면,

SPDY의 경우에 페이지 로드 속도가 TCP(SSL 안쓴)보다 27%-60%만큼 속도가 빨랐다.

그리고 TCP(SSL를 쓴)에 비해서는 39%-55% 만큼 페이지 로드 속도가 더 빨랐다.

Security 보안에 관한 부분

[11] In addition to better performance, SPDY is also more secure. Despite the best efforts of the Electronic Frontier Foundation (EFF) and others, we're a long ways away from HTTPS Everywhere - which means that most Web traffic is still sent unencrypted.

SPDY는 더 안전하다.

EFF의 노력에도 불구하고 HTTPS는 잘 안 쓰고 있다.

결국 웹 트래픽 중 대부분이  encrypted 되지 않은 상태라는 문제가 있다..

QQ. we're a long ways away from HTTPS Everywhere.

이거 직역하면, 우리는 긴 길이었다. 어디에서도 HTTPS와 멀리 떨어진. 인데.

우리는 긴 길을 가고 있었다. 근데 그길 어디에서도 HTTPS와는 멀었다. 라는 뜻 같은데.

왜 we are a long ways 라고 했을까요? 우리는 긴 길이다? ㅠㅠ

long ways는 꾸며주는 역할을 하니, 빼고 생각해보죠.

We’re away from HTTPS Everywhere.

우리는 HTTPS Everywhere로부터 떨어져있다.

HTTPS Everywhere가 슬로건 같은게 아닌가 싶어요. 어디서나 HTTPS를 쓰자, 그런 의미같은데요,

우리는 그 슬로건으로부터 떨어져있다.

그런데, 얼마나 떨어져 있대요?
long ways away.. - 긴 거리 만큼 떨어져 있대요 :)

[12] That will be a thing of the past with SPDY. Current implementations of SPDY mandate SSL, which isn't universally liked but seems the best way to nudge the Web forward to encrypting traffic most of the time.

SPDY를 사용하면, 이건 옛날얘기가 될거다.

SPDY에서는 SSL을 꼭 써야 하고,, 이걸 쓰면 ... 보안 문제가 줄어들 것..

SSL이 필수가 되는군요.

Push and Hint

[13] Finally, SPDY adds two new mechanisms that will also help speed up the Web. Server Push and Server Hints.

SPDY에서는 두 가지 새로운 매커니즘을 추가한다.

이름하여 서버 푸쉬와 서버 힌트

이 두가지로 인해 웹은 더 빨라 질것이다.

[14] Just what it sounds like,

Server Push will send resources to clients without being asked.

If you request a Web page URL, for example, SPDY might also decide to send down images associated with the page even if they've not been requested yet. Note that there's a potential downside here, since servers could wind up sending redundant or unneeded content.

#두 가지 새로운 매커니즘 중에서 서버 푸쉬에 대한 설명이 나옴..

서버 푸쉬란 클라이언트가 요청하지 않았는데도 자원을 보내는 것.

물론, 잠재적인 문제점도 있다. 브라우저에서 필요하지 않은 내용까지 보내므로..

[15] Server Hints doesn't send the content, but it does send the URL so that the client can decide if it needs it. If the content isn't cached, a browser or other SPDY client can then make the request a bit faster than it might have otherwise.

서버 힌트란, 내용을 보내지는 않고, URL을 보내서, 클라이언트가 이것을 필요로 하는지 여부를 판단할 수 있게 하는 것..

Getting SPDY

[16] The only, or at least the major, problem with SPDY? 

You need SPDY support on two ends to make it work. You need a browser that supports SPDY, and Web servers that are delivering content using SPDY. If you're one of millions using Chrome, you already have SPDY support. If you're using Firefox, SPDY support will be the default with Firefox 13. Note that Firefox 11 already supports SPDY; you just have to turn it on manually. It's unclear when other browsers will support SPDY, but it may be awhile before you see SPDY in Internet Explorer or Safari.

# SPDY의 주요한 문제 (유일한) 문제점을 언급하고 있음.

여튼 그 문제가 뭐냐면, 클라이언트(브라우저)와 서버 둘다 SPDY를 지원해줘야 한다는 점.

파폭 13에서는 디폴트로 지원하고, 파폭 11에서는 수동으로 켜줘야 하는 상태..

크롬에서는 이미 지원해주는 상태.

다른 브라우저들이 SPDY을 언제 지원해줄지는 아직 불확실한 상태.

익스플로러나 사파리에서 지원하는 날은 좀 소원하지 않을지..

[17] Very few websites support SPDY at the moment. Google, of course, has been rolling out SPDY. Twitter is also offering SPDY. But it's going to be some time before most users see the effects of SPDY across all or even most of the sites they visit. But the odds are good that you'll start seeing a significant benefit from SPDY before you're using IPv6 at home.

현재 SPDY를 지원하는 웹사이트는 얼마 없다.

구글, 트위터는 지원해주지만, 대부분의 웹 이용자가 SPDY를 웹에서 평소에 보게 될 날은 아직 멀지 않았을지. 하지만 IPv6을 집에서 쓰는 것보다는, SPDY를 써서 얻게 된 장점을 볼 날은 빨리 올 가능성이 높다.

SDPY의 중요한 이점을 보기 시작하는 것이 집에서 IPv6를 사용하는 것보다 먼저일 확률이 높다. 라는 뜻으로 보면 될듯?

QQ.

정말 SPDY에 대해 간결하고 명확하게 잘 쓰여진 문서 같아요.

읽고 나니 느껴지는게 HTTP 프로토콜의 심플함에서는 좀 벗어나게 되는거 아닌가 싶기도 해요.

하나의 연결로 요청을 보내고 응답을 받고 끝” 이게 최대 장점인데 말이죠.