ݺߣ

ݺߣShare a Scribd company logo
SPDY & F5 SOLUTION 
skkim@itian.co.kr
What is the SPDY ?
HTTP 
A big friendly unsecured clear-text, line-oriented bear 
SPDY 
A multi-plexed binary TLS-wrapped protocol from the future
SPDY (SPeeDY) 
 배경 
‘어떻게 하면 Web을 더 빠르게 만들까?’ 하는 시도의 일부분으로 Google에서 
발표한 프로토콜로 spdy/2 부터 HTTP2.0의 개발에 기반이 되고 있다. 
HTTP protocol은 개발 된지 10년이 넘은 protocol로 개발되어 지금과 같은 Web 
Page는 예상할 수 없었고, 다음과 같은 특징이 제약 현대 Web환경에 제약이 
된다. 
 HTTP의 한계 
• 하나의 요청당 하나의 Connection 
• 오직 Client 만 요청가능 
• 압축되지 않은 Header 
• 반복되는 불필요한 Header 정보 
• 선택적인 Data 압축
SPDY (SPeeDY) 
 목적 
 Page Load Time(PLT)를 50%까지 감소. (SPDY project의 최종적인 목표) 
 적용방법의 복잡함을 최소화 
 Web Content 변경 회피, 오직 Client 의 Browser와 AP가 SPDY를 지원 하면 됨 
 Open-source로 제공 함으로써, Web 을 빠르게 만들고자 하는 사람들과 함께 성장 
 기술적 목적 
 하나의 TCP session 을 통해 많은 HTTP requset를 할 수 있도록 함 
 반복되는 불필요한 헤더의 삭제 및 헤더 압축을 통해 사용되는 대역폭의 감소 
 TSL(SSL)을 하위 프로토콜로 두어 좀 더 나은 보안효과를 얻고, 기존의 infra와 호환성을 
얻음. 차후 web 은 암호화된 connection에 대한 수요가 더 증가 할 것을 예상 
 서버도 클라이언트와의 communication 을 먼저 시작 할 수 있게 하고, 가능하다면 
data를 push 할 수 있게 함
SPDY design and features 
- binary protocol 
일반적인 HTTP GET & POST message format은 
그대로 유지하지만, frame format을 text에서 binary로 
바꾸어 해석이 더 빠르고, 오류 발생 가능성을 낮춤 
- multiplexing 
하나의 Connection에 다수의 Stream이 동시에 존재 
- Full –duplex interleaving 과 data priority 
한 Stream이 진행 중이더라도 다른 Stream이 끼어 들 
수 있으며, 우선 순위가 낮은 데이터 전송중에도 높은 
우선 순위의 데이터가 끼어들어 전송 될 수 있음 
SPDY는 SSL위의 Session Layer에 위치하며 
HTTP를 대체한다기보다 HTTP의 데이터 전송 포맷과 
커넥션 관리 부분을 고쳐서 TCP 커넥션을 보다 
효율적으로 쓰도록 만든 것이라 할 수 있음.
What is the Feature and Terminology of SPDY?
Frame of SPDY (HTTP2.0) 
SPDY도 HTTP2.0과 
마찬가지로 
HTTP 1.1 과 비교했을 때, 
기존의 Header 정보는 
Header Frame 으로 
Data는 Data Frame으로 나뉨 
(required)
Stream, Message and Frames 
binary framing mechnism으로 Client 와 
Server사이의 Data가 교환되는 방법이 바뀜 
- Stream 
A bidirectional flow of bytes within an 
established connection. 
- Message 
A complete sequence of frames that map to a 
logical message. 
- Frame 
The smallest unit of communication in 
SPDY(HTTP2.0), each containing a frame 
header, which at minimum identifies the stream 
to which the frame belongs
Multiplexing 
Frame의 format을 binary로 바꾸고, Header Frame과 Data Frame을 나눔으로써, 
Request 와 Response의 Full-Multiplexing이 지원됨. 
- 나누어진 Frame을 재 조합 하므로 inverlaeving에 제한이 없음. FIFO (X) => PLT Latency감소 
- 각 Request마다 Connection을 생성하는 RTT가 더 이상 필요 없으므로 PLT Latency감소 
! HTTP 1.x는 하나의 Connection에서 Requset에 대한 Response가 완벽하게 끝나기 전까지 끼어들 수 
없음. FIFO 로 먼저 도착한 Requset가 무조건 먼저 Response를 받음.
Header Compression 
SPDY HTTP2.0 
초기버전의 SPDY와 같이는 zlib 압축을 
사용했으나, 2012년 여름, TLS와 SPDY압축 
알고리즘에 대해 CRIME이라는 session 
hijacking공격이 발표되어, 결과적으로 zlib 압축 
알고리즘은 더 이상 사용되지 않고, 새로운 
알고리즘을 사용한다. Header Table 사용. 
압축 
SYN_STREAM SYN_REPLY 
SPDY 1~3.1 까지 모두 zlib compression 을 사용. 
CRIME에 취약하나 Request Header만 해당됨. 
Response는 해당 사항 없음. (참고) 
Google의 경우 압축레벨 6.
Advanced Feature 
Server Push 
- X-Associated-Content header를 이용하여 Client에게 Server Push를 알림. 
- Client가 요청 하기 전에 Server가 관련 데이터를 Client에게 Push. 
- main page에 유용. 
- http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-3.3-Server-Push-Transactions
SPDY - Benefits 
시험조건 
- 가상 home network 환경, 1% packet loss 가정 
- Top 100 site 중 25개 site를 각 10회씩 download한 
page load time의 평균을 비교 
DSL 2 Mbps downlink, 375 kbps uplink 
Cable 4 Mbps downlink, 1 Mbps 
uplink 
Average ms Speedup Average ms Speedup 
HTTP 3111.916 2348.188 
SPDY basic multi-domain* connection / TCP 
2242.756 27.93% 1325.46 43.55% 
SPDY basic single-domain* connection / TCP 1695.72 45.51% 933.836 60.23% 
SPDY single-domain + server push / TCP 1671.28 46.29% 950.764 59.51% 
SPDY single-domain + server hint / TCP 1608.928 48.30% 856.356 63.53% 
SPDY basic single-domain / SSL 1899.744 38.95% 1099.444 53.18% 
SPDY single-domain + client prefetch / SSL 1781.864 42.74% 1047.308 55.40% 
Table source: http://dev.chromium.org/spdy/spdy-whitepaper
SPDY in action
SPDY in action 
HTTP 
- 브라우저가 6개의 TCP connection 을 열고 각 
image마다 Request 
- 서버로부터 각 Request에 대한 
Response를 받을 때까지 기다림 
- 그리고, 나머지 4개의 이미지에 대한 
Request 
SPDY 
- 브라우저가 하나의 TCP connection을 생성하고 
각 이미지 마다 하나씩의 Stream을 열면서 총 10개의 
SYN_STREAM을 전송 
- Server는 10 개의 SYN_REPLY로 응답. 
이 때, Server는 Client의 Request가 끝나기를 기다리지 
않아도 됨 
- Server 10개 또는 그 이상의 DATA frame을 보냄. 각 
Stream마다 하나의 DATA frame은 무조건 존재하고, 여러 
개의 DATA frame으로 분리되어 전송 될 경우 자신이 
속한 Stream(Request)의 id를 가짐 
DATA frame은 interlaeving 가능하고 gzip 압축되어 
전송됨. 
-Client는 DATA Frame을 전송 받으면서도 다른 
Request가능. 
만약, Web page 에 10개의 image가 있다면 … 
SPDY는 하나의 TCP connection을 재 
사용함으로써, TCP 혼잡 제어를 통해 
Slow-Start 문제를 회피 할 수 있음.
How do client know available SPDY
NPN (Next Protocol Negotiation) 
- TLS 의 확장(extension) ex)SNI 
- Client Hello에 NPN extension 
- Server Hello에 지원가능한 NP List 
- Browser 가 Next Protocol 선택 SPDY 
- 암호화 통신 
- 만약 Explorer처럼 지원하지 않는 다면 그대로 
HTTP/1.1 통신 
TLS(SSL)는 꼭 필요한 것일까? 
SPDY whitepaper - 
장기적으로 보아 웹 환경에서 보안성은 점점 더 강조될 
것이므로, SPDY의 하위 프로토콜로 TLS를 지정하여 향후 더 
나은 보안성을 얻고자 한다. 
현재 네트워크 인프라와의 호환, 즉 기존의 프록시를 거치는 
통신과 호환성 문제가 발생하지 않도록 하기 위해 TLS가 
필요하다. 
443 포트로 들어온 요청이 SPDY인지 여부 및 요청에서 
사용하고 있는 SPDY 버전을 판별하여 이후의 통신을 SPDY로 
처리할지 판단. 만약 TLS NPN이 없다면 SPDY 사용을 위해 
추가적인 RTT(round-trip time)가 필요.
ALPN (Application Layer Protocol Negotiation) 
- NPN과 마찬가지로 TLS extension중 하나 
- SPDY 4 부터 ALPN 적용 예정 
- 2014년 7월 월 RFC에 NPN은 ALPN으로 대체됨 
- Google 이 Reference로 NPN과 ALPN을 모두 
지원 중 
- NPN과 차이 
- Client Hello에 Browser가 지원하는 NP List 
- Server Hello에 NP select 
- NP에 대한 협상이 clear text로 끝남.
Coevolution of SPDY and HTTP 2.0
SPDY and HTTP 2.0 
HTTP2.0 과 SPDY 는 비교대상이기 보다 함께 진화하는 관계 
2012년 여름, HTTP working group은 SPDY v2 draft를 HTTP2.0 표준의 시발점으로 채택됬다. 
하지만, SPDY는 거기서 멈추지 않고 HTTP2.0과 함께 진화했다. 
- SPDY v3은 2012년 발표됨 ( update된 framing format과 첫 flow control) 
- SPDY v4는 2014에 발표 예정 ( update된 framing format과 향상된 prioritization, flow control …etc) 
SPDY의 지속적인 개발의 동기는 간단하다. 
HTTP2.0표준에 추가 하기 전에 새로운 기능이나 제안을 적용하고 테스트해볼 수 있는 시험 모델이기 
때문이다. 
SPDY와 HTTP2.0 모두 증가하는 개발 단계, 수많은 테스트 등으로 개발자들에게는 부담이 될 수 
있지만, 이 또 한 모두 이점이 된다. HTTP2.0가 ‘준비완료’ 됫다고 말할 수 있을 때는 이미 대중적인 
client와 server의 환경에서 TEST를 거친 검증된 Protocol이라고 말 할 수 있을 것이다. 
SPDY의 개발은 HTTP2.0 이 완전히 HTTP1.1을 대체할 수 있을 때 멈출 것이다. 
High Performance Browser Networking – Ilay Grigoril, Chapter 12. HTTP 2.0 
http://chimera.labs.oreilly.com/books/1230000000545/ch12.html#ROAD_TO_HTTP2
SPDY and the SPDY Gateway
SPDY 
Legend: 
HTTP REQUESTS 
Client 
Browser 
Origin 
Web 
Server 
HTTP RESPONSES 
 SPDY client to SPDY server 
 Requests and responses are multiplexed 
 No blocking, no additional latency 
 Headers are compressed 
 Server can hint 
 Server can push
SPDY Gateway 
 SPDY client to SDPY virtual server to HTTP server 
Legend: 
Client 
Browser 
Origin 
Web 
Server 
SPDY 
HTTP 
HTTP REQUESTS 
HTTP RESPONSES 
 SPDY: Requests/responses across WAN 
 Latency minimized / Headers compressed 
 HTTP: Requests/responses across LAN 
 Little “hit” due to low latency 
 Limitations: 
 No Server Push 
 No Server Hints 
 Prioritization through iRules 
BIG-IP 
AAM SPDY
SPDY Gateway on the BIG-IP
How the SPDY Gateway works 
1) Client 는 HTTP를 통해 BIG-IP 시스템으로 연결 
2) BIG-IP 시스템은 iRule을 통하여 Response Header 에 정보 추가 
- Alternate Protocol : 443:npn-spdy/3 
<port> : <protocol> 을 의미 
3) Client 는 SPDY를 통해 Request 
4) BIG-IP는 SPDY Request를 HTTP Request로 변경하여 Server에 전달 
5) Server로부터 받은 HTTP Response를 SPDY Response로 변경하여 Client에 전달
Configuring a SPDY Gateway 
 80 Virtual Server 
 iRule 
 443 Virtual Server 
 HTTP Profile 
 SSL Profile (client) 
 SPDY Profile
Configuring a SPDY Gateway 
 80 Virtual Server 
 iRule 
when HTTP_RESPONSE { 
HTTP::header insert "Alternate-Protocol 443:npn-spdy/3" 
} 
443 : Port번호 
npn : Next Protocol Negotiation (TLS Extension) 
spdy/3 : SPDY ver. 3 (F5는 현재 ver. 3 까지 지원) 
!! 또는 Google 처럼 302 Redirect하는 Rule을 적용하거나, F5에 내장되어있는 http https 
redirect를 Rule을 적용하는 법도 있음.
Configuring a SPDY Gateway 
 443 Virtual Server 
 HTTP Profile 
 SSL Profile (client)
Configuring a SPDY Gateway 
 443 Virtual Server 
 HTTP Profile 
 SSL Profile (client) 
Virtual Server에 적용 
Profile 생성
Configuring a SPDY Gateway 
 443 Virtual Server 
 SPDY Profile 
Profile Description 
: Link 
Virtual Server에 적용
TEST LAB 
VIP 
30.30.30.30 : 80 
30.30.30.30 : 443 
30.30.30.89 30.30.30.254 10.10.10.253 10.10.10.1 
Port : 443 Port : 80 
BIGIP : TMOS 11.5.1 VE LTM 
Server : Linux Apache
F5 SPDY gateway packet flow ( port 80 ) 
chrome://net-internals/#spdy 
chrome://net-internals 이나 packet 
dump를 통해 확인하면 SPDY Gateway가 
적용 되었음을 확인 할 수 있지만, 
Browser에는 http 로 통신하는 것처럼 
보인다. 
이유) 첫 번째 Get Request에 대한 
Response로 80 응답 200 OK 를 받은 
후에야 443 Virtual Server와의 통신을 
시작하기 때문.. 
그렇다면 Google은? 
302 Redirect . http 요청에 대한 응답으로 
https URL을 응답으로 줌.
SPDY Session flow 
Header Frame 과 
DATA Frame 이 분리되어있어 
Frame 간 Full-Duplex 
Interleaving(양방향 끼어들기)를 
확인 
Stream_id =1 의 Get Request에 대한 
Respons를 받기도 전에 Stream_id 
=3 의 또 다른 Request를 전송. 
Stream_id 가 모두 홀수 인 이유) 
Server 만 요청하는 Flow이기 때문. 
Chrome://net-internals/#events 에서 확인가능
SPDY Statistics 
#tmsh show ltm profile spdy <프로파일명> #tmsh show sys connection 
SPDY v3 Count 확인 
Connection Table에 Connection 이 하나만 생성 됨을 확인
SPDY Statistics 
?? 왜 Connection 이 두 개가 생성되지?? 
Sever에 KeepAlive On ; 으로 설정되어 있어서 
첫 Request에 대한 Response를 주고도 
Connection이 계속 열려 있게 된다. 
Alternate-Protocol header에 443:npn-spdy/3을 
확인한 Client는 443 SPDY connection을 열면서 
동시에 열려있는 80 Connection으로 다음 Request 
를 보내고 443 connection이 열리면 이후 
Request는 SPDY를 통해 전송한다. 
SPDY의 효율을 극대화 하고자 한다면 
KeepAlive를 Off하는 것도 방법일 것이고, 
Server의 유연성을 생각 한다면 On해두는 것도 
나쁘지 않은 선택 같다.
SPDY Consideration and Troubleshooting
Considerations 
 이미 HTTPS를 사용하는 서비스여야 한다 
 HTTP만 사용하는 서비스는 SPDY의 이득이 적고, SSL 도입에 따른 추가 비용이 발생 
 Linux 커널을 교체할 수 있어야 한다. 
 initcwnd 조절로 얻는 성능상의 차이가 크기 때문에, 가급적 initcwnd가 조절 가능하거나 
10 이상의 기본 값을 가진 Linux로 교체할 수 있어야 함. CentOS의 경우 5.6 버전까지는 
initcwnd 조절이 되지 않음. 6.1부터 조절 가능하고, 6.2부터는 기본 값 10을 가지고 있음 
 SPDY 지원 브라우저 사용자의 비율을 고려한다. 
 국내 서비스에서는 아직도 SPDY를 지원하지 않는 Internet Explorer 사용자가 태반. 
모바일에서도 iOS는 아직 SPDY를 지원하지 않으며, Android는 3.0부터 지원을 시작. 
따라서, SPDY 지원 브라우저 사용자가 충분히 많아지기 전에는 SPDY의 성능 향상으로 
얻는 이익과 SPDY 도입 비용을 잘 비교해야 할 것.
Troubleshooting Tools 
 HTTPWatch 
 Added support for SPDY in v8.3
Troubleshooting Tools 
 Google Chrome 
 chrome://net-internals
F5 spdy 솔루션 선관

More Related Content

F5 spdy 솔루션 선관

  • 1. SPDY & F5 SOLUTION skkim@itian.co.kr
  • 2. What is the SPDY ?
  • 3. HTTP A big friendly unsecured clear-text, line-oriented bear SPDY A multi-plexed binary TLS-wrapped protocol from the future
  • 4. SPDY (SPeeDY)  배경 ‘어떻게 하면 Web을 더 빠르게 만들까?’ 하는 시도의 일부분으로 Google에서 발표한 프로토콜로 spdy/2 부터 HTTP2.0의 개발에 기반이 되고 있다. HTTP protocol은 개발 된지 10년이 넘은 protocol로 개발되어 지금과 같은 Web Page는 예상할 수 없었고, 다음과 같은 특징이 제약 현대 Web환경에 제약이 된다.  HTTP의 한계 • 하나의 요청당 하나의 Connection • 오직 Client 만 요청가능 • 압축되지 않은 Header • 반복되는 불필요한 Header 정보 • 선택적인 Data 압축
  • 5. SPDY (SPeeDY)  목적  Page Load Time(PLT)를 50%까지 감소. (SPDY project의 최종적인 목표)  적용방법의 복잡함을 최소화  Web Content 변경 회피, 오직 Client 의 Browser와 AP가 SPDY를 지원 하면 됨  Open-source로 제공 함으로써, Web 을 빠르게 만들고자 하는 사람들과 함께 성장  기술적 목적  하나의 TCP session 을 통해 많은 HTTP requset를 할 수 있도록 함  반복되는 불필요한 헤더의 삭제 및 헤더 압축을 통해 사용되는 대역폭의 감소  TSL(SSL)을 하위 프로토콜로 두어 좀 더 나은 보안효과를 얻고, 기존의 infra와 호환성을 얻음. 차후 web 은 암호화된 connection에 대한 수요가 더 증가 할 것을 예상  서버도 클라이언트와의 communication 을 먼저 시작 할 수 있게 하고, 가능하다면 data를 push 할 수 있게 함
  • 6. SPDY design and features - binary protocol 일반적인 HTTP GET & POST message format은 그대로 유지하지만, frame format을 text에서 binary로 바꾸어 해석이 더 빠르고, 오류 발생 가능성을 낮춤 - multiplexing 하나의 Connection에 다수의 Stream이 동시에 존재 - Full –duplex interleaving 과 data priority 한 Stream이 진행 중이더라도 다른 Stream이 끼어 들 수 있으며, 우선 순위가 낮은 데이터 전송중에도 높은 우선 순위의 데이터가 끼어들어 전송 될 수 있음 SPDY는 SSL위의 Session Layer에 위치하며 HTTP를 대체한다기보다 HTTP의 데이터 전송 포맷과 커넥션 관리 부분을 고쳐서 TCP 커넥션을 보다 효율적으로 쓰도록 만든 것이라 할 수 있음.
  • 7. What is the Feature and Terminology of SPDY?
  • 8. Frame of SPDY (HTTP2.0) SPDY도 HTTP2.0과 마찬가지로 HTTP 1.1 과 비교했을 때, 기존의 Header 정보는 Header Frame 으로 Data는 Data Frame으로 나뉨 (required)
  • 9. Stream, Message and Frames binary framing mechnism으로 Client 와 Server사이의 Data가 교환되는 방법이 바뀜 - Stream A bidirectional flow of bytes within an established connection. - Message A complete sequence of frames that map to a logical message. - Frame The smallest unit of communication in SPDY(HTTP2.0), each containing a frame header, which at minimum identifies the stream to which the frame belongs
  • 10. Multiplexing Frame의 format을 binary로 바꾸고, Header Frame과 Data Frame을 나눔으로써, Request 와 Response의 Full-Multiplexing이 지원됨. - 나누어진 Frame을 재 조합 하므로 inverlaeving에 제한이 없음. FIFO (X) => PLT Latency감소 - 각 Request마다 Connection을 생성하는 RTT가 더 이상 필요 없으므로 PLT Latency감소 ! HTTP 1.x는 하나의 Connection에서 Requset에 대한 Response가 완벽하게 끝나기 전까지 끼어들 수 없음. FIFO 로 먼저 도착한 Requset가 무조건 먼저 Response를 받음.
  • 11. Header Compression SPDY HTTP2.0 초기버전의 SPDY와 같이는 zlib 압축을 사용했으나, 2012년 여름, TLS와 SPDY압축 알고리즘에 대해 CRIME이라는 session hijacking공격이 발표되어, 결과적으로 zlib 압축 알고리즘은 더 이상 사용되지 않고, 새로운 알고리즘을 사용한다. Header Table 사용. 압축 SYN_STREAM SYN_REPLY SPDY 1~3.1 까지 모두 zlib compression 을 사용. CRIME에 취약하나 Request Header만 해당됨. Response는 해당 사항 없음. (참고) Google의 경우 압축레벨 6.
  • 12. Advanced Feature Server Push - X-Associated-Content header를 이용하여 Client에게 Server Push를 알림. - Client가 요청 하기 전에 Server가 관련 데이터를 Client에게 Push. - main page에 유용. - http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3-1#TOC-3.3-Server-Push-Transactions
  • 13. SPDY - Benefits 시험조건 - 가상 home network 환경, 1% packet loss 가정 - Top 100 site 중 25개 site를 각 10회씩 download한 page load time의 평균을 비교 DSL 2 Mbps downlink, 375 kbps uplink Cable 4 Mbps downlink, 1 Mbps uplink Average ms Speedup Average ms Speedup HTTP 3111.916 2348.188 SPDY basic multi-domain* connection / TCP 2242.756 27.93% 1325.46 43.55% SPDY basic single-domain* connection / TCP 1695.72 45.51% 933.836 60.23% SPDY single-domain + server push / TCP 1671.28 46.29% 950.764 59.51% SPDY single-domain + server hint / TCP 1608.928 48.30% 856.356 63.53% SPDY basic single-domain / SSL 1899.744 38.95% 1099.444 53.18% SPDY single-domain + client prefetch / SSL 1781.864 42.74% 1047.308 55.40% Table source: http://dev.chromium.org/spdy/spdy-whitepaper
  • 15. SPDY in action HTTP - 브라우저가 6개의 TCP connection 을 열고 각 image마다 Request - 서버로부터 각 Request에 대한 Response를 받을 때까지 기다림 - 그리고, 나머지 4개의 이미지에 대한 Request SPDY - 브라우저가 하나의 TCP connection을 생성하고 각 이미지 마다 하나씩의 Stream을 열면서 총 10개의 SYN_STREAM을 전송 - Server는 10 개의 SYN_REPLY로 응답. 이 때, Server는 Client의 Request가 끝나기를 기다리지 않아도 됨 - Server 10개 또는 그 이상의 DATA frame을 보냄. 각 Stream마다 하나의 DATA frame은 무조건 존재하고, 여러 개의 DATA frame으로 분리되어 전송 될 경우 자신이 속한 Stream(Request)의 id를 가짐 DATA frame은 interlaeving 가능하고 gzip 압축되어 전송됨. -Client는 DATA Frame을 전송 받으면서도 다른 Request가능. 만약, Web page 에 10개의 image가 있다면 … SPDY는 하나의 TCP connection을 재 사용함으로써, TCP 혼잡 제어를 통해 Slow-Start 문제를 회피 할 수 있음.
  • 16. How do client know available SPDY
  • 17. NPN (Next Protocol Negotiation) - TLS 의 확장(extension) ex)SNI - Client Hello에 NPN extension - Server Hello에 지원가능한 NP List - Browser 가 Next Protocol 선택 SPDY - 암호화 통신 - 만약 Explorer처럼 지원하지 않는 다면 그대로 HTTP/1.1 통신 TLS(SSL)는 꼭 필요한 것일까? SPDY whitepaper - 장기적으로 보아 웹 환경에서 보안성은 점점 더 강조될 것이므로, SPDY의 하위 프로토콜로 TLS를 지정하여 향후 더 나은 보안성을 얻고자 한다. 현재 네트워크 인프라와의 호환, 즉 기존의 프록시를 거치는 통신과 호환성 문제가 발생하지 않도록 하기 위해 TLS가 필요하다. 443 포트로 들어온 요청이 SPDY인지 여부 및 요청에서 사용하고 있는 SPDY 버전을 판별하여 이후의 통신을 SPDY로 처리할지 판단. 만약 TLS NPN이 없다면 SPDY 사용을 위해 추가적인 RTT(round-trip time)가 필요.
  • 18. ALPN (Application Layer Protocol Negotiation) - NPN과 마찬가지로 TLS extension중 하나 - SPDY 4 부터 ALPN 적용 예정 - 2014년 7월 월 RFC에 NPN은 ALPN으로 대체됨 - Google 이 Reference로 NPN과 ALPN을 모두 지원 중 - NPN과 차이 - Client Hello에 Browser가 지원하는 NP List - Server Hello에 NP select - NP에 대한 협상이 clear text로 끝남.
  • 19. Coevolution of SPDY and HTTP 2.0
  • 20. SPDY and HTTP 2.0 HTTP2.0 과 SPDY 는 비교대상이기 보다 함께 진화하는 관계 2012년 여름, HTTP working group은 SPDY v2 draft를 HTTP2.0 표준의 시발점으로 채택됬다. 하지만, SPDY는 거기서 멈추지 않고 HTTP2.0과 함께 진화했다. - SPDY v3은 2012년 발표됨 ( update된 framing format과 첫 flow control) - SPDY v4는 2014에 발표 예정 ( update된 framing format과 향상된 prioritization, flow control …etc) SPDY의 지속적인 개발의 동기는 간단하다. HTTP2.0표준에 추가 하기 전에 새로운 기능이나 제안을 적용하고 테스트해볼 수 있는 시험 모델이기 때문이다. SPDY와 HTTP2.0 모두 증가하는 개발 단계, 수많은 테스트 등으로 개발자들에게는 부담이 될 수 있지만, 이 또 한 모두 이점이 된다. HTTP2.0가 ‘준비완료’ 됫다고 말할 수 있을 때는 이미 대중적인 client와 server의 환경에서 TEST를 거친 검증된 Protocol이라고 말 할 수 있을 것이다. SPDY의 개발은 HTTP2.0 이 완전히 HTTP1.1을 대체할 수 있을 때 멈출 것이다. High Performance Browser Networking – Ilay Grigoril, Chapter 12. HTTP 2.0 http://chimera.labs.oreilly.com/books/1230000000545/ch12.html#ROAD_TO_HTTP2
  • 21. SPDY and the SPDY Gateway
  • 22. SPDY Legend: HTTP REQUESTS Client Browser Origin Web Server HTTP RESPONSES  SPDY client to SPDY server  Requests and responses are multiplexed  No blocking, no additional latency  Headers are compressed  Server can hint  Server can push
  • 23. SPDY Gateway  SPDY client to SDPY virtual server to HTTP server Legend: Client Browser Origin Web Server SPDY HTTP HTTP REQUESTS HTTP RESPONSES  SPDY: Requests/responses across WAN  Latency minimized / Headers compressed  HTTP: Requests/responses across LAN  Little “hit” due to low latency  Limitations:  No Server Push  No Server Hints  Prioritization through iRules BIG-IP AAM SPDY
  • 24. SPDY Gateway on the BIG-IP
  • 25. How the SPDY Gateway works 1) Client 는 HTTP를 통해 BIG-IP 시스템으로 연결 2) BIG-IP 시스템은 iRule을 통하여 Response Header 에 정보 추가 - Alternate Protocol : 443:npn-spdy/3 <port> : <protocol> 을 의미 3) Client 는 SPDY를 통해 Request 4) BIG-IP는 SPDY Request를 HTTP Request로 변경하여 Server에 전달 5) Server로부터 받은 HTTP Response를 SPDY Response로 변경하여 Client에 전달
  • 26. Configuring a SPDY Gateway  80 Virtual Server  iRule  443 Virtual Server  HTTP Profile  SSL Profile (client)  SPDY Profile
  • 27. Configuring a SPDY Gateway  80 Virtual Server  iRule when HTTP_RESPONSE { HTTP::header insert "Alternate-Protocol 443:npn-spdy/3" } 443 : Port번호 npn : Next Protocol Negotiation (TLS Extension) spdy/3 : SPDY ver. 3 (F5는 현재 ver. 3 까지 지원) !! 또는 Google 처럼 302 Redirect하는 Rule을 적용하거나, F5에 내장되어있는 http https redirect를 Rule을 적용하는 법도 있음.
  • 28. Configuring a SPDY Gateway  443 Virtual Server  HTTP Profile  SSL Profile (client)
  • 29. Configuring a SPDY Gateway  443 Virtual Server  HTTP Profile  SSL Profile (client) Virtual Server에 적용 Profile 생성
  • 30. Configuring a SPDY Gateway  443 Virtual Server  SPDY Profile Profile Description : Link Virtual Server에 적용
  • 31. TEST LAB VIP 30.30.30.30 : 80 30.30.30.30 : 443 30.30.30.89 30.30.30.254 10.10.10.253 10.10.10.1 Port : 443 Port : 80 BIGIP : TMOS 11.5.1 VE LTM Server : Linux Apache
  • 32. F5 SPDY gateway packet flow ( port 80 ) chrome://net-internals/#spdy chrome://net-internals 이나 packet dump를 통해 확인하면 SPDY Gateway가 적용 되었음을 확인 할 수 있지만, Browser에는 http 로 통신하는 것처럼 보인다. 이유) 첫 번째 Get Request에 대한 Response로 80 응답 200 OK 를 받은 후에야 443 Virtual Server와의 통신을 시작하기 때문.. 그렇다면 Google은? 302 Redirect . http 요청에 대한 응답으로 https URL을 응답으로 줌.
  • 33. SPDY Session flow Header Frame 과 DATA Frame 이 분리되어있어 Frame 간 Full-Duplex Interleaving(양방향 끼어들기)를 확인 Stream_id =1 의 Get Request에 대한 Respons를 받기도 전에 Stream_id =3 의 또 다른 Request를 전송. Stream_id 가 모두 홀수 인 이유) Server 만 요청하는 Flow이기 때문. Chrome://net-internals/#events 에서 확인가능
  • 34. SPDY Statistics #tmsh show ltm profile spdy <프로파일명> #tmsh show sys connection SPDY v3 Count 확인 Connection Table에 Connection 이 하나만 생성 됨을 확인
  • 35. SPDY Statistics ?? 왜 Connection 이 두 개가 생성되지?? Sever에 KeepAlive On ; 으로 설정되어 있어서 첫 Request에 대한 Response를 주고도 Connection이 계속 열려 있게 된다. Alternate-Protocol header에 443:npn-spdy/3을 확인한 Client는 443 SPDY connection을 열면서 동시에 열려있는 80 Connection으로 다음 Request 를 보내고 443 connection이 열리면 이후 Request는 SPDY를 통해 전송한다. SPDY의 효율을 극대화 하고자 한다면 KeepAlive를 Off하는 것도 방법일 것이고, Server의 유연성을 생각 한다면 On해두는 것도 나쁘지 않은 선택 같다.
  • 36. SPDY Consideration and Troubleshooting
  • 37. Considerations  이미 HTTPS를 사용하는 서비스여야 한다  HTTP만 사용하는 서비스는 SPDY의 이득이 적고, SSL 도입에 따른 추가 비용이 발생  Linux 커널을 교체할 수 있어야 한다.  initcwnd 조절로 얻는 성능상의 차이가 크기 때문에, 가급적 initcwnd가 조절 가능하거나 10 이상의 기본 값을 가진 Linux로 교체할 수 있어야 함. CentOS의 경우 5.6 버전까지는 initcwnd 조절이 되지 않음. 6.1부터 조절 가능하고, 6.2부터는 기본 값 10을 가지고 있음  SPDY 지원 브라우저 사용자의 비율을 고려한다.  국내 서비스에서는 아직도 SPDY를 지원하지 않는 Internet Explorer 사용자가 태반. 모바일에서도 iOS는 아직 SPDY를 지원하지 않으며, Android는 3.0부터 지원을 시작. 따라서, SPDY 지원 브라우저 사용자가 충분히 많아지기 전에는 SPDY의 성능 향상으로 얻는 이익과 SPDY 도입 비용을 잘 비교해야 할 것.
  • 38. Troubleshooting Tools  HTTPWatch  Added support for SPDY in v8.3
  • 39. Troubleshooting Tools  Google Chrome  chrome://net-internals

Editor's Notes

  • #6: The SPDY project defines and implements an application-layer protocol for the web which greatly reduces latency. The high-level goals for SPDY are: To target a 50% reduction in page load time. Our preliminary results have come close to this target (see below). To minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so requires no changes to existing networking infrastructure.   To avoid the need for any changes to content by website authors. The only changes required to support SPDY are in the client user agent and web server applications. To bring together like-minded parties interested in exploring protocols as a way of solving the latency problem. We hope to develop this new protocol in partnership with the open-source community and industry specialists. Some specific technical goals are: To allow many concurrent HTTP requests to run across a single TCP session. To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers. To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats. To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.   To enable the server to initiate communications with the client and push data to the client whenever possible.
  • #10: All communication is performed with a single TCP connection. The stream is a virtual channel within a connection, which carries bidirectional messages. Each stream has a unique integer identifier (1, 2, …, N). spdy의 경우 홀수 1,3,5,7,….. The message is a logical HTTP message, such as a request, or response, which consists of one or more frames. The frame is the smallest unit of communication, which carries a specific type of data—e.g., HTTP headers, payload, and so on.
  • #12: All communication is performed with a single TCP connection. The stream is a virtual channel within a connection, which carries bidirectional messages. Each stream has a unique integer identifier (1, 2, …, N). spdy의 경우 홀수 1,3,5,7,….. The message is a logical HTTP message, such as a request, or response, which consists of one or more frames. The frame is the smallest unit of communication, which carries a specific type of data—e.g., HTTP headers, payload, and so on.
  • #13: All communication is performed with a single TCP connection. The stream is a virtual channel within a connection, which carries bidirectional messages. Each stream has a unique integer identifier (1, 2, …, N). spdy의 경우 홀수 1,3,5,7,….. The message is a logical HTTP message, such as a request, or response, which consists of one or more frames. The frame is the smallest unit of communication, which carries a specific type of data—e.g., HTTP headers, payload, and so on.
  • #38: TCP Slow Start: 처음에는 initcwnd 크기의 congestion window로 패킷을 보내면서 점점 congestion window 크기를 키워 네트워크가 허용하는 최대값 혹은 수신 측의 TCP window까지 키우는 것을 TCP Slow Start라 한다. initcwnd 값이 작으면 네트워크가 허용하는 최대 크기까지 도달하는 동안 더 많은 Round-Trip이 필요하므로 페이지 최초 로딩 시간이 더 길어진다.