F5 SPDY GATEWAY solution (Korean)

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

14. SPDY in action

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