Transcript
Page 1
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
WAN 가속화 기술 분석
Version 1.0
2014년 5월 15일
넷매니아즈/㈜엔앰씨컨설팅그룹
(www.netmanias.com, 02-3444-5747)
넷매니아즈 기술문서
Page 2
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
목차
Part 1. WAN 가속화 기술 요약
Part 2. TCP Proxy
Part 3. TCP Optimization
Part 4. Data Deduplication
Part 5. HTTP Optimization
Page 3
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Server/Storage
Branch OfficeServer/Storage
Branch OfficeWAN
Server/Storage
Branch OfficeBranch OfficeWAN
Server/Storage
Branch OfficeBranch OfficeWANData Center (Private Cloud)
Server/Storage
Branch OfficeWAN
Branch OfficeBranch OfficeBranch OfficeInternetPublic B2B Cloud
Branch OfficeBranch OfficeBranch OfficeInternetPublic B2B Cloud
Branch OfficeBranch OfficeADNInternet
Data Center (Private Cloud)
Data Center (Private Cloud)Data Center (Private Cloud)
클라우드 서비스 이용자(기업)의 IT 환경의 변화
.배경
.Private Cloud: 데이터 센터 통합
.Public B2B Cloud: Office 365, Salesforce 등 클라우드 서비스 이용
.이슈
.IT 통합으로 IT 시스템 구축 및 운용 비용은 대폭 절감
.하지만 WAN을 통한 원격 접속시 LAN 환경과 달리 어플리케이션 성능이 현격히 떨어짐 - 멀리 있으므로 당연히 느림
.솔루션
.Private Cloud 솔루션: WAN Acceleration (Riverbed)
.Public B2B Cloud 솔루션: Cloud Acceleration (Akamai Cloud Acceleration Service)
IT 시스템
통합
(경비 절감)
느리다!
어플리케이션
서비스
아웃소싱
느리다!
Page 4
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Part I. WAN 화 기술 요약
Page 5
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
1.1 WAN 화 개념
Without WAN Optimization With WAN Optimization
WANData Center
RTTUserLANLAN
10MB10MB10MB31
ThroughputSlow StartCongestion
AvoidanceAvailable BandwidthRTTRTTRTTHTTP GETHTTP 200 OK2.6MbpsRTT
( )
이 a
2.6Mbps (64KB/200ms)
ThroughputFast
StartCongestion
Avoidance0.8
100Mbps10MB10MB0.08
3. RTT (HTTP Optimization)
2. 이 (Data Deduplication)
1. 리 (TCP Optimization)
UserData Center
10MB100Mbps
(2.5MB/200ms)
1MBHTTP 200 OKRTTRTTRTTHTTP GETWAN
Page 6
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
1.2 리버베드 WAN 기 최적화 기술 요약
HTTP의 비
TCP의 비
32TCP Connection PoolingTCP Protocol OptimizationData Deduplication
이 WAN 서
TCP 최
시 환 (RTT )
WAN 기 리 TCP 어 아 TCP
이 이 변경 이
TCP 변경 , 이 넷 서 최
123URL LearningObject Prefetch TableHTTP Parsing and Prefetching456HTTP Pipelining7
개의 아 . RTT
리 아
리 아
WAN 서의 요 HTTP 시 환 최소화
WAN 의 1WAN 의 설이
( 비용)
어플리케이션 의 문 점
리버베드 WAN 최적화 기술
Page 7
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
1.3 리버베드 WAN 기 과 예 (TOLLY GROUP)
17.44.777.620.1222.866.549.49.51.20.63.92.61.31.420.9050100150200250512Kbps,
250ms RTT2048Kbps,
100ms RTT512Kbps,
250ms RTT2048Kbps,
100ms RTT512Kbps,
250ms RTT2048Kbps,
100ms RTT512Kbps,
250ms RTT2048Kbps,
100ms RTTHTTPFTPCIFSMAPINo WAN OptimizationWAN Optimization14.5x faster7.8x faster19.9x faster10.1x faster171.4x faster47.5x faster24.7x faster10.6x fasterDownload time (sec)
http://www.tolly.com/ts/2005/Riverbed/Steelhead/TollyTS205109-RiverbedSteelhead1010-May2005.pdf
.HTTP
. 512Kbps, RTT 250ms: 14.5배 개 (다운 드 시 : WAN 기 입 = 17.4 , 입 후 = 1.2 )
. 2Mbps, RTT 100ms: 7.8배 개 (다운 드 시 : WAN 기 입 = 4.7 , 입 후 = 0.6 )
Page 8
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Part II. TCP Proxy
Page 9
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
2.1 TCP Proxy 개념
.TCP Proxy 개념: 클라이언 와 서버 신되 TCP 요청 (TCP SYN, SYN/ACK, ACK) 서 채 다 과 같이 3개의 TCP
생 (클라이언 와 서버 서 TCP 이 되어 다 생각 )
①클라이언 와 클라이언 측 WAN 기 TCP
②클라이언 측 WAN 기와 서버 측 WAN 기 TCP
③서버 측 WAN 기와 서버 TCP
.TCP Proxy 목적: WAN 기 클라이언 와 서버 주 래픽 채서 최적화 기술 적용해야 , 이 위해 TCP WAN
기 서 종단시킴
Application (HTTP) OptimizationData Deduplication & CompressionTCP OptimizationWANClient-side
SteelheadServer-side
SteelheadClientServerRouterCERouterBranch OfficeData CenterWANClientServerCEBranch OfficeData CenterCETCP ConnectionTCP ConnectionTCP ConnectionTCP Connection(a) TCP Connection without Steelhead(b) TCP Connection with Steelhead
CETCP ProxyTCP Proxy
Page 10
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
2.1 TCP Proxy 개념 (계 )
TCP
Client
TCP
Server
TCP
Proxy
TCP
Proxy
TCP
Proxy
TCP
Proxy
TCP
Client
TCP
Server
Normal TCP
Normal TCP Optimized TCP
TCP
Client
TCP
Server
TCP
Proxy
TCP
Proxy
Optimization
(TCP 최적화,
HTTP 최적화,
중복전달 제거)
TCP
Proxy
TCP
Proxy
TCP Connection
1. TCP Proxy: 클라이언트와 서버 간의 End-to-end TCP 연결을 잘라(split) 3개의 분리된 TCP connection을 만듦
2. Optimization: WAN 가속기 구간의 TCP 연결 상의 트래픽 전달을 최적화 함
Optimization
(TCP 최적화,
HTTP 최적화,
중복전달 제거)
WAN (Long RTT, Expense Cost)
5050
10.1.1.10
80
20.1.1.10
5050
10.1.1.10
X
1.1.1.1
80
20.1.1.10
Y
2.2.2.2
5050
10.1.1.10
80
20.1.1.10
클라이언 와 서버 아무 변경이나 설정이 요없
Page 11
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
2.2 TCP Proxy 절차 (1)
Client와 Server 의 첫 째 TCP 설정
TCP 설정 절차
①Auto Discovery
②클라이언 측 WAN 기와 서버 측 WAN 기
TCP 생
③서버 측 WAN 기와 서버 TCP 생
④클라이언 와 클라이언 측 WAN 기 TCP
생
TCP Connection 3(Unoptimized)
TCP Connection 2(Optimized)
TCP Connection 1(Unoptimized)
WANClient-side
SteelheadServer-side
Steelhead10.1.1.1020.1.1.101.1.1.12.2.2.2ClientServerRouterCERouterBranch OfficeData Center1 TCP SYN(s)10.1.1.10:5050 a (d)20.1.1.10:802 TCP SYN + Probe Request(s)10.1.1.10:5050 a (d)20.1.1.10:80TCP Option (76) = 1.1.1.1 (Client-side Steelhead IP)
3 TCP SYN/ACK + Probe Response(d)10.1.1.10:5050 ß (s)20.1.1.10:80TCP Option (76) = 2.2.2.2 (Server-side Steelhead IP),
1.1.1.1 (Client-side Steelhead IP)
5 TCP SYN(s)1.1.1.1:4321 a (d)2.2.2.2:78006 TCP SYN/ACK(d)1.1.1.1:4321 ß (s)2.2.2.2:78007 TCP ACK(s)1.1.1.1:4321 a (d)2.2.2.2:78008 Setup Information(s)1.1.1.1:4321 a (d)2.2.2.2:7800Client Endpoint = 10.1.1.10:5050,
Server Endpoint = 20.1.1.10:809 TCP SYN(s)10.1.1.10:5050 a (d)20.1.1.10:8010 TCP SYN/ACK(d)10.1.1.10:5050 ß (s)20.1.1.10:8011 TCP ACK(s)10.1.1.10:5050 a (d)20.1.1.10:8012 Connection Result: OK(d)1.1.1.1:4321 ß (s)2.2.2.2:780013 TCP SYN/ACK(d)10.1.1.10:5050 ß (s)20.1.1.10:8014 TCP ACK(s)10.1.1.10:5050 a (d)20.1.1.10:80TCP ProxyTCP Proxy4 TCP Proxy Mapping Table
§Client Endpoint
= 10.1.1.10:5050
§Server Endpoint
= 20.1.1.10:80
§Server-side Steelhead IP
= 2.2.2.2TCP Proxy Mapping Table
§Client Endpoint
= 10.1.1.10:5050
§Server Endpoint
= 20.1.1.10:80
§Client-side Steelhead IP
= 1.1.1.1:4321Auto DiscoveryCESourceProtocolIn-Path Rule10.1.1/24TCPRuleAutoDest20.1.1/24Dest PortAllSourceProtocolPeering Rule10.1.1/24TCPRuleAcceptDest20.1.1/24Dest PortAllLookup In-Path RuleLookup Peering RulePre-configurationPre-configurationProbe Result is cached
for 10 secondsListening on port 7800Riverbed
Proprietary Protocol
3.3.3.3
Intercept
Normal Routing
내 뒤 10.1.1.10이 20.1.1.10 앞
기 누 냐?
2.2.2.2
20.1.1.10 앞
기 2.2.2.2이다!
서버 20.1.1.10과 TCP 맺었다
이 TCP 통해 통신 클라이언
와 서버의 정보 a “서버 측 WAN
기야, 서버와 TCP 맺어라!”
TCP Proxy 위
정보 획득
TCP Proxy
위
정보 획득
Page 12
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
2.2 TCP Proxy 절차 (2)
Client와 Server 의 두 째 TCP 설정
TCP 설정 절차
①클라이언 와 클라이언 측 WAN 기 TCP
생
②클라이언 측 WAN 기와 서버 측 WAN 기
TCP 생
③서버 측 WAN 기와 서버 TCP 생
.클라이언 측 WAN 기 Auto Discovery 과정이 끝나면 서버의 IP 주소와 서버 측 WAN 기의
IP 주소 저장 이후 동일 서버 향 TCP
요청 이 신되면 Auto Discovery 과정 생략
TCP Connection 3(Unoptimized)
TCP Connection 2(Optimized)
TCP Connection 1(Unoptimized)
WANClient-side
SteelheadServer-side
Steelhead10.1.1.2020.1.1.101.1.1.12.2.2.2ClientServerRouterRouterCECEBranch OfficeData Center1 TCP SYN(s)10.1.1.20:4040 a (d)20.1.1.10:804 TCP SYN(s)1.1.1.1:4322 a (d)2.2.2.2:78005 TCP SYN/ACK(d)1.1.1.1:4322 ß (s)2.2.2.2:78006 TCP ACK(s)1.1.1.1:4322 a (d)2.2.2.2:78007 Setup Information(s)1.1.1.1:4322 a (d)2.2.2.2:7800Client Endpoint = 10.1.1.20:4040,
Server Endpoint = 20.1.1.10:808 TCP SYN(s)10.1.1.20:4040 a (d)20.1.1.10:809 TCP SYN/ACK(d)10.1.1.20:4040 ß (s)20.1.1.10:8010 TCP ACK(s)10.1.1.20:4040 a (d)20.1.1.10:80TCP ProxyTCP Proxy2 TCP SYN/ACK(d)10.1.1.20:4040 ß (s)20.1.1.10:803 TCP ACK(s)10.1.1.20:4040 a (d)20.1.1.10:80TCP Proxy Mapping Table
§Client Endpoint
= 10.1.1.20:4040
§Server Endpoint
= 20.1.1.10:80
§Server-side Steelhead IP
= 2.2.2.2:7800 (Already known that Server
IP 20.1.1.10 is behind Steelhead 2.2.2.2
a Skip Auto Discovery Process)
TCP Proxy Mapping Table
§Client Endpoint
= 10.1.1.20:4040
§Server Endpoint
= 20.1.1.10:80
§Client-side Steelhead IP
= 1.1.1.1:4322Listening on port 7800
Server-side Steelhead IPAuto Discovery Table2.2.2.2Server IP20.1.1.10Connection Result: FailureTCP FINSourceProtocolIn-Path Rule10.1.1/24TCPRuleAutoDest20.1.1/24Dest PortAll
약 서버 죽었으면…
클라이언 측 WAN 기 “서버 20.1.1.10이
WAN 기 2.2.2.2 뒤 ” 알 다.
따라서
①Auto Discovery 과정이 요 없
②서버 측 TCP 이 맺어 진 후 Connection
Result: OK 신할 요 없다.
약 서버 죽었으면 Connection Result: Failure
신 클라이언 TCP 끊
TCP Proxy 위
정보 획득
TCP
Proxy
위
정보 획득
Page 13
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
2.3 TCP Proxy 통 이
TCP
Client
TCP
Server
TCP
Proxy
TCP
Proxy
TCP
Proxy
TCP
Proxy
5050
10.1.1.10
X
1.1.1.1
80
20.1.1.10
7800
2.2.2.2
5050
10.1.1.10
80
20.1.1.10
srcIP: 10.1.1.10
dstIP: 20.1.1.10
srcPort: 5050
dstPort: 80
srcIP: 1.1.1.1
dstIP: 2.2.2.2
srcPort: X
dstPort: 7800
srcIP: 10.1.1.10
dstIP: 20.1.1.10
srcPort: 5050
dstPort: 80
srcIP: 20.1.1.10
dstIP: 10.1.1.10
srcPort: 80
dstPort: 5050
srcIP: 2.2.2.2
dstIP: 1.1.1.1
srcPort: 7800
dstPort: X
srcIP: 20.1.1.10
dstIP: 10.1.1.10
srcPort: 80
dstPort: 5050
.클라이언 와 서버 주 TCP 이 은 WAN 기 의해 IP 주소 TCP 포 호 변경 과정 쳐 서 통신이 이루어 짐
.즉, 클라이언 와 서버 입장 서 TCP 이 transparent
Page 14
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Part III. TCP Optimization
3.1 TCP Connection Pooling
3.2 Increasing TCP initial Window
3.3 TCP Window Scaling
3.4 Advanced Congestion Avoidance (High-Speed TCP)
Page 15
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
3.1 TCP Connection Pooling
.클라이언 측 WAN 기와 서버 측 WAN 기 리 20개의 TCP 생 해 클라이언 서 서버 TCP 요청 면
WAN 기 기 생 되어 TCP 나 사용 으 써 TCP 과정으 최소화
TCP Connection Pooling 개념
WANClient-side
SteelheadServer-side
SteelheadRouterRouterCECEBranch OfficeData CenterTCP 3-way handshakeTCP ProxyTCP ProxyTCP Connection #1TCP Connection #2TCP Connection #20...
TCP Connection PoolTCP Connection #1TCP 3-way handshakeThere’s no TCP 3-way handshake in WANTCP DataTCP DataClientServer
기 생 TCP 사용
Page 16
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
3.1 TCP Connection
Pooling (계 )
TCP Connection Pooling 적용
이 과정
WANClient-side
SteelheadServer-side
Steelhead1.1.1.12.2.2.2RouterRouterCECEBranch OfficeData Center1 TCP SYN(s)10.1.1.10:5050 a (d)20.1.1.10:80TCP ProxyTCP Proxy2 TCP SYN/ACK(d)10.1.1.10:5050 ß (s)20.1.1.10:803 TCP ACK(s)10.1.1.10:5050 a (d)20.1.1.10:804 Setup InformationTCP Connection #1(s)1.1.1.1:4321 a (d)2.2.2.2:7800Client Endpoint = 10.1.1.10:5050,
Server Endpoint = 20.1.1.10:805 TCP SYN(s)10.1.1.10:5050 a (d)20.1.1.10:806 TCP SYN/ACK(d)10.1.1.10:5050 ß (s)20.1.1.10:807 TCP ACK(s)10.1.1.10:5050 a (d)20.1.1.10:80TCP Data(s)10.1.1.10:5050
a (d)20.1.1.10:80TCP Data(s)1.1.1.1:4321 a (d)2.2.2.2:7800TCP Data(s)10.1.1.10:5050
a (d)20.1.1.10:80TCP Data(d)10.1.1.10:5050
ß (s)20.1.1.10:80TCP Data(d)1.1.1.1:4321 ß (s)2.2.2.2:7800TCP Data(d)10.1.1.10:5050
ß (s)20.1.1.10:80TCP Connection #1TCP Connection #2TCP Connection #20...
432178007800780043225000TCP PortTCP PortTCP Connection Pool10.1.1.10Client20.1.1.10ServerClient-side Steelhead
§Client Endpoint
= 10.1.1.10:5050
§Server Endpoint
= 20.1.1.10:80
§Server-side Steelhead IP
= 2.2.2.2:7800 (Already known that 20.1.1.10 is behind 2.2.2.2)
Pick the free TCP Connection in the Pool a TCP Connection #1Server-side Steelhead
§Client Endpoint
= 10.1.1.10:4040
§Server Endpoint
= 20.1.1.10:80
§Client-side Steelhead IP
= 1.1.1.1:4321
TCP 설정 절차
①클라이언 와 클라이언 측 WAN 기 TCP
생
②클라이언 측 WAN 기 TCP Connection Pool
서 나 택 후, 해당 TCP 통해 서버 측
WAN 기 TCP 정보
③서버 측 WAN 기와 서버 TCP 생
TCP Connection Pool 서
TCP 택
클라이언 와 서버의 TCP
정보
Page 17
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Unoptimized TCP ConnectionClientServerWANRTT = 200ms3-way handshake...
100KB Download Time = 1.4sec7 x 200ms RTT = 1.4sUnoptimizedUnoptimizedOptimized TCP ConnectionClient-side
SteelheadClientServer-side
SteelheadServerWANRTT = 190ms5ms5ms...
TCP Connection Pool100KB Download Time = 1sec(cwnd=1, 4,380B)
(cwnd=2, 8,9260B)
(cwnd=4, 17,520B)
5 x 200ms RTT = 1s(cwnd=1, 1,460B)
(cwnd=2, 2,920B)
(cwnd=4, 5,840B)
(cwnd=8, 11,680B)
Congestion Window
(# of Bytes)
Congestion Window
(# of Bytes)
Number of TransmissionsNumber of Transmissions1480BFile download complete2920B5840B11680B23360B46720B4380B8760B17520B35040B140160B93440B643216842112483264280320B70080B16File download
complete
3.2 Increasing TCP
Initial Window
.Legacy TCP Protocol
.현재 클라이언 /서버 통신 방법
.Initial Congestion Window = 1 MSS =
1460bytes
.Large Initial Window (RFC 3390)
.리버베드 WAN 기 통신 방법
.Initial Congestion Window
= min (4 x MSS, max (2 x MSS, 4380bytes))
.MSS = 1460bytes a Initial Congestion Window
= 4380 bytes
.즉, TCP 직후 Initial Window Size 기존
TCP 보다 3배 크게 기 이 률 향상시킴
RTT 회수 cwnd (bytes) Byte Sending Byte Remaining
1 1 x MSS (1,460B) 1,460 100,940
2 2 x MSS (2,920B) 2,920 98,020
3 4 x MSS (5,840B) 5,840 92,180
4 8 x MSS (11,680B) 11,680 80,500
5 16 x MSS (23,360B) 23,360 57,140
6 32 x MSS(46,720B) 46,720 10,420
7 64 x MSS(93,440B) 10,420 Finished
RTT 회수 cwnd (bytes) Byte Sending Byte Remaining
1 3 x MSS (4,380B) 4,380 98,020
2 6 x MSS (8,760B) 8,760 89,260
3 12 x MSS (17,520B) 17,520 71,740
4 24 x MSS (35,040B) 35,040 36,700
5 48 x MSS (70,080B) 36,700 Finished
Legacy TCP Protocol
Large Initial Window (RFC 3390)
1
2
4
8
1
2
4
Legacy TCP Protocol
Large Initial Window (RFC 3390)
cwnd
cwnd
Page 18
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
3.3 TCP Window Scaling
Legacy TCP Protocol
.WAN RTT = 200ms
.TCP Window Size = 64KB (Max Value)
a TCP Max Throughput = 2.6Mbps
TCP Window Scaling (RFC 1323)
.WAN RTT = 200ms
.TCP Window Size = 2.5MB
a TCP Max Throughput = 100Mbps
.RFC 1323(TCP Extensions for High Performance): 기존 TCP의 최 window size 64Kbytes 최 1Gbyte까 시켜
향상 시킴
.리버베드 WAN 기 적용
.Windows XP/2003 서버 적용
Bandwidth = 100MbpsRTT = 200msSenderReceiverHigh BDP Network = 2.5MBWin = 64KBTCP Max Throughput = 2.6MbpsTCP Max Throughput = TCP Receive Window Size (bit) / RTT (seconds)
so, TCP Max Throughput = (64 x 1024 x 8) / 0.2 = 2.6MbpsWin = 64KB
RTT = 200msSenderHigh BDP Network = 2.5MBWin = 2.5MBTCP Max Throughput = TCP Receive Window Size (bit) / RTT (seconds)
so, TCP Max Throughput = (2.5 x 1024 x 1024 x 8) / 0.2 = 100MbpsSteelheadWin = 64KBReceiverSteelheadTCP Max Throughput = 100Mbps
Win = 64KBWin = 2.5MB
Page 19
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
3.3 TCP Window Scaling (계 )
Legacy TCP Protocol
TCP Window Scaling (RFC 1323)
MSS = 1460B, Window Size = 64KB
a TCP ACK 없이 보 개 = 44개 (2.6Mbps)
MSS = 1460B, Window Size = 2.5MB
a TCP ACK 없이 보 개 = 1,795개 (100Mbps)
Unoptimized TCP ConnectionClientServerWANRTT = 200ms3-way handshake...64KB64KB...
144...
144Max Download Throughput = 2.6MbpsTCP Receive Window Size = 64KB(44 TCP Segments)
TCP Receive Window Size = 64KB(44 TCP Segments)
UnoptimizedUnoptimizedOptimized TCP ConnectionClient-side
SteelheadClientServer-side
SteelheadServerWANRTT = 190ms5ms5msTCP Connection Pool...64KB64KB...
2.5MB64KB64KB2.5MB11795Max Throughput = 100Mbps100Mbps100MbpsTCP Receive Window Size = 2.5MB(1,795 TCP Segments)
.Windows XP/2003 서버에 적용. Registry를 통해 변경 가능
(디폴트로 Disable)
.리버베드 WAN 가속기에 적용
Page 20
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
3.4 Advanced Congestion Avoidance
Legacy TCP Protocol High-Speed TCP (RFC 3649)
. 발생시 현재의 congestion window 50% 감소 (
반으 감소)
.이후 RTT 마다 congestion window 1씩 순차적으
(정상 래 걸림)
현재 이 률이 높은 상황 서 (Congestion window 크기 상황)
. 이 발생 경우 congestion window 게 감소시켜 급격 떨어 것 방
.이후 RTT 마다 congestion window 크게 시켜
빠르게 올림
현재의 이 률이 낮은 상황 서 기존 TCP 동 과 유사
게 동
Segment/RTT (cwnd)
TimeCongestion Avoidance- ‘cwnd increase’ is large while cwnd is a high value- ‘cwnd increase’ is small while cwnd is a low valueLoss Reaction- ‘cwnd decrease’ is small while cwnd is a high value- ‘cwnd decrease’ is large while cwnd is a low value
.현재 클라이언 와 서버 통신 방법
.리버베드 WAN 기 통신 방법
Segment/RTT (cwnd)TimeCongestion Avoidance- cwnd linear increase
Loss Reaction- cwnd decrase by 50%
Page 21
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
3.5 TCP Protocol Optimization 요약
.Fast Start: 기 높 (Initial Congestion Window 크기 크게 )
.TCP Window Scaling: 최 률 높 (TCP Window Size 크기 최 1GB까 )
.High-Speed TCP: 현재 률이 높으면 (1) 발생시 률 게 낮추 (2) 이후 정상 빠르게
Throughput (bps)
With TCP Optimization by SteelheadWithout TCP Optimization (Standard TCP)
Packet LossSlow StartTimeCongestion AvoidanceFast StartAdvanced Congestion Avoidance1Increasing TCP Initial Window (RFC 3390)
2TCP Window Scaling (RFC 1323)
Maximum TCP ThroughputMaximum TCP Throughput3High-Speed TCP (RFC 3649)
Other Optimization Technologies in Steelhead
§Delayed and Selective Acknowledgments (RFC 2018)
§Explicit Congestion Notification (RFC 3168)
§Limited and Fast Re-transmits (RFC 3042/2582)
§Slow Start with Congestion Avoidance (RFC 2581)
Page 22
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Part IV. Data Deduplication
Page 23
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.1 Data Deduplication 개념 (1)
.서버 서 클라이언 되 이 (예, A.ppt 파일) 서버 측 WAN 기 서 신 면
.그 이 조각 내어 세그먼 생 각 세그먼 유 식 자 레퍼런스(reference) 할당 “세그먼 와 레퍼런스” 컬 저장소
(PSS: Persistent Segment Store) 저장
.이후 “세그먼 와 레퍼런스” 피어 WAN 기
.클라이언 WAN 기 신 세그먼 와 레퍼런스 컬 저장소 저장 레퍼런스 외 세그먼 클라이언
새 운 파일
최 이 해서 “세그먼 ”와 “레퍼런스”
WANClientServerRouterCERouterBranch OfficeData CenterCEA.ppt
(10MB)
A.ppt
(10MB)
DataNew ReferenceNew SegmentPSSPSSReferenceSegmentReferenceSegmentSynchronized PSS (Persistent
Segment Store)
TCP ConnectionTCP ConnectionTCP Connection10MB Data10MB + α Data10MB DataR1R2R3R4R5R6New Segment + New ReferenceStore Segmented Data & ReferenceStore Segmented Data & Reference
S1S2S3S4S5S6
Page 24
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.1 Data Deduplication 개념 (2)
.클라이언 서 동일 파일(A.ppt 파일) 요청 경우
.서버 측 WAN 기 컬 저장소 참조 각 세그먼 “레퍼런스(R1 ~ R6)” 피어 WAN 기
.클라이언 측 WAN 기 신 레퍼런스 참조 자신의 컬 저장소 저장되어 “세그먼 ” 찾아 래 이 클라이언
.따라서 WAN 통 량이 획기적으 어듬
파일
ReferenceWANClientServerRouterCERouterBranch OfficeData CenterCEA.ppt
(10MB)
A.ppt
(10MB)
DataPSSPSSReferenceSegmentReferenceSegmentSynchronized PSS (Persistent
Segment Store)
TCP ConnectionTCP ConnectionTCP ConnectionReference10MB Data10MB Data1~2KB DataR1R2R3R4R5R6Replace Segmented Data with ReferenceReplace Reference with Segmented Data
이 해서 “레퍼런스”
Page 25
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.1 Data Deduplication 개념 (3)
. 약 A.ppt 파일의 내용 일 변경 이 신 경우(A’.ppt)
.서버 측 WAN 기 변경 세그먼 해서 레퍼런스(R7)와 께 컬 저장소 저장
.“ 이 레퍼런스(R1~R5)”와 “새 운 세그먼 (S7) 해당 레퍼런스(R7)” 피어 WAN 기
.클라이언 측 WAN 기 새 운 세그먼 (S7)와 레퍼런스(R7) 컬 저장소 저장
.이 컬 저장되어 세그먼 (S1 ~ S5)과 새 운 세그먼 (S7) 이용해 래 이 클라이언
.이와 같이 변경 이 내용 WAN 통해 되므 량 일
이 일 변경 파일
이 “레퍼런스”
최 이 해서 “세그먼 ”와 “레퍼런스”
Reference + New SegmentWANClientServerRouterCERouterBranch OfficeData CenterCEA’.ppt
(10.5MB)
A’.ppt
(10.5MB)
DataPSSPSSReferenceSegmentSegmentDataSynchronized PSS (Persistent
Segment Store)
TCP ConnectionTCP ConnectionTCP ConnectionReference10MB Data10MB Data< 1MB DataNew Reference & SegmentR1R2R3R4R5R7Replace Segmented Data with ReferenceStore New Segmented Data & ReferenceReplace Reference with Segmented Data
Store New Segmented Data & Referencemodified
S7
Page 26
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.2 Data Deduplication 절차: Encoding 요약
Input Data
(TCP Stream)
Input Buffer (Data Bytes)
FingerprintFingerprintFingerprintFingerprint
Segment
Cut Point?
Slide WindowNoYesHash (ex. SHA-1)
PSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5HashHash CalculcationCompare to
Stored Hash ValueMatch
Found?
NoDefine ReferenceR1R2R3R4R5R6ReferenceSASBSCSDSESFContentH1H2H3H4H5H6HashYesRetrieve ReferenceContent Exact MatchMatched?
NoYesH3H6PSSStore to PSS
(1) Reference
(2) Content
(3) HashPSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5HashR3Output BufferWrite to Buffer
(1) Reference
(2) ContentWrite to Buffer
(1) ReferenceCompressedData
13425R3R6SFBinding = Reference + ContentR6SFH6세그먼 경계점 추출
세그먼 해쉬 계산
이 저장 세그먼 ?
저장 세그먼 이면 “레퍼런스”
출력 버퍼 저장
새 운 세그먼 이면 “레퍼런스, 세그먼
, 해쉬값” 컬 저장
“레퍼런스와 세그먼 ” 출력 버퍼 저장
레퍼런스, 혹은 레퍼런스와 세그먼 피어
WAN 기
Page 27
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
YesInput Data
(TCP Stream)
Input Buffer (Data Bytes)
FingerprintFingerprintFingerprintFingerprint
Segment
Cut Point?
Slide WindowNoHash (ex. SHA-1)
Hash Calculcation012348514950
4.2 Data Deduplication 절차: Encoding (1)
세그먼 경계점 추출 (Content based Segmentation)
SASBSCSDSESFSBSCSDSESFSG
SASBSCSDSESFSCSDSESFSASHSIRegions that were changedRegions that were changed
① TCP 세션 단위 입력 버퍼 이 저장
② 입력 버퍼 저장 이 Sliding
Window 크기(예. 48bytes) 잘라 Rabin
Fingerprint 의 입력 파라 넣
그 과값 얻
hash value = fingerprint(48bytes data)
③ 그 과값(해쉬값) 해 “세그먼 경계점” 조건
확
약 그 조건 경우 Sliding Window 이동
다시 Fingerprint 계산 행
“세그먼 경계점” 조건의 예
.Fingerprint 과값 1023으 modulo 산 그 과 0이면 세그먼
경계점으 정의
if (hash value % 1023) == 0
.Fingerprint 과값의 위 13 bits 값이 리 정의 상 값(pre-
determined breakpoint value)과 같으면 세그먼 경계점으 정의
if (hash value && 0b1111111111111) == Predetermined Breakpoint
Value
④ 세그먼 의 최소, 최 크기 정의
(예. 최소크기 512bytes ~ 2Kbytes, 최 크기 64Kbytes)
. 약 최소 크기보다 은 크기 서 세그먼 경계점이 나 면
계 sliding window 이동 다 경계점 찾
. 약 최 크기까 경계점이 나 경우 최 크기 점 경계점으 정의
.Content based Segmentation의 장점:
체 이 일 변경(바이 추 ,
변경, 삭 ) 되어 나머 세그먼 의
경계점 영향 주
Page 28
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Segment
Cut Point?
YesHash (ex. SHA-1)
PSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5HashHash CalculcationCompare to
Stored Hash ValueMatch
Found?
NoYesInput Buffer (Data Bytes)
4.2 Data Deduplication 절차: Encoding (2)
세그먼 해쉬 계산
① 세그먼 경계점 추출 후,
해당 세그먼 해싱
② 해싱 과값과 PSS( 컬 저장소) 저장되어
해쉬값 비
일치 해쉬값이 a 세그먼 이 PSS 저장되어
다 의 . 즉, 세그먼 신 적이 ( 이 )
일치 해쉬값이 없 a 세그먼 이 PSS 저장되어
다 의 . 즉, 세그먼 신 적이 없 (새 운 이 )
.세그먼 PSS 저장되어 확 방법으 세그먼 해쉬값 계산 후 비 행
Page 29
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.2 Data Deduplication 절차: Encoding (3)
해쉬값이 PSS 존재 경우 (Duplicated Data)
PSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5Compare to
Stored Hash ValueMatch
Found?
NoYesRetrieve ReferenceContent Exact MatchMatched?
NoYesH3PSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5HashR3Output BufferWrite to Buffer
(1) ReferenceR3H3
① “PSS 저장 세그먼 ”와
“ 신 이 의 세그먼 ”
exact match 행 a 해슁 충돌
확 절차
.이 했던 세그먼 해서 “레퍼런스” 출력 버퍼 저장
② PSS 저장 레퍼런스 값 와서
③ 출력 버퍼 저장
Page 30
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.2 Data Deduplication 절차: Encoding (4)
해쉬값이 PSS 존재 경우 (New Data)
PSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5HashCompare to
Stored Hash ValueMatch
Found?
NoDefine ReferenceR1R2R3R4R5R6ReferenceSASBSCSDSESFContentH1H2H3H4H5H6HashH6PSSStore to PSS
(1) Reference
(2) Content
(3) HashOutput BufferWrite to Buffer
(1) Reference
(2) ContentR6SFBinding = Reference + ContentR6SFH6
.새 운 세그먼 해서 “레퍼런스”, “세그먼 ”, “해쉬값” PSS 저장
.출력 버퍼 “레퍼런스”와 “세그먼 ” 저장
① 레퍼런스 값 정의 : 레퍼런스(16Bytes) 각 세그먼 마다 유 값
야 , 이 위해 (1) 자신의 유 식 자(IP 주소 혹은
MAC 주소 사용)와 (2) sequential number의 조합으 그
값 생
② 레퍼런스, 세그먼 , 해쉬값 PSS 저장
③ 출력 버퍼 바 딩(레퍼런스와 세그먼 ) 저장
Page 31
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.2 Data Deduplication 절차: Encoding (5)
Output BufferWrite to Buffer
(1) Reference
(2) ContentWrite to Buffer
(1) ReferenceCompressedData
R3R6SFBinding = Reference + Content
세그먼 이
이 신했던 세그먼 해서 “레퍼런스” 최 세그먼 해서 “바 딩(레퍼런스 + 세그먼 )”
SCSDSESFR1R2R3R4R5R6SASBSASBSCSDSESFR1R2R3R4R5R6(a) New Data
SASBSCSDSESF
(b) Duplicated DataR1R2R3R4R5R7SASBSCSDSESX
(c) Duplicated & New DataSXReceive Data from LAN (Client or Server)Transmit Data to WAN (Reference + New Data)
Receive Data from LAN (Client or Server)Transmit Data to WAN (Reference)
Receive Data from LAN (Client or Server)Transmit Data to WAN (Reference + New Data)
. 이 : 3 경우 존재할
Page 32
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.3 Data Deduplication 절차: Decoding
CompressedData
Input BufferData DecodingIs Referece?
PSSR1R2R3R4R5ReferenceSASBSCSDSEContentH1H2H3H4H5HashYesGet Referenced
Segment from PSSReferenceContentOutput Buffer (Data Bytes)
Write to Buffer
(1) Content
R3SCSCNoStore to PSS
(1) Reference
(2) Content
(3) HashHash (ex. SHA-1)R1R2R3R4R5R6ReferenceSASBSCSDSESFContentH1H2H3H4H5H6HashPSSR6SFH6R3R6SFWrite to Buffer
(1) ContentSFOutput Data
(TCP Stream)
1234
신 “레퍼런스” 해서
① PSS 저장 “세그먼 ” 와서
② 출력 버퍼 세그먼 저장
TCP 세션 단위 입력 버퍼 이 저장
신 이 해 “바 딩”과
“레퍼런스” 추출
신 “바 딩” 해서
① 해당 세그먼 해쉬 계산 후
② 해쉬값, 레퍼런스, 세그먼 PSS
저장
③ 출력 버퍼 세그먼 저장
이
Page 33
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
4.4 Hierarchical Segment Presentation
.세그먼트 사이즈를 작게 하면?
.세그먼트에 매칭되는 데이터 개수는 많아 지겠으나 WAN으로 전달되는 레퍼런스의 수가 많아져 압축의 이점을 얻을 수 없음
.세그먼트 사이즈를 크게 하면?
.매칭된 세그먼트의 압축 효율은 높아지나 세그먼트에 매칭되는 데이터 개수가 작아 결과적으로 전체적인 압축 효율이 떨어짐
.Hierarchical Segment Presentation: 세그먼트에 대한 레퍼런스 생성 후 다시 여러 개의 레퍼런스들를 모아 새로운 레퍼런스를 정의하여 이 문제를 해결
SXSXSASBSCSDSESFPSS
(Persistent Segment Store)
SGSHSISJSKR11R12R13R14R15R16R17R18R19R110R111R21R22R23R24R31R32R41First Level Binding:
(R11, SA)(R12, SB)(R13, SC)(R14, SD)(R15, SE)(R16, SF)(R17, SG)(R18, SH)(R19, SI)(R110, SJ)(R111, SK)
Second Level Binding:
(R21, R11 + R12)(R22, R13 + R14 + R15)(R23, R16 + R17)(R24, R18 + R19 + R110 + R111)
Third Level Binding:
(R31, R21 + R22)(R32, R23 + R24)
Firth Level Binding:
(R41, R31 + R32)
Segmented DataReferenced DataReferenced DataReferenced DataReferenced DataR11R12R13R14R15R16R17R18R19R110R111R21R22R23R24R31R32R41ReferenceSASBSCSDSESFSGSHSISJSKR11+R12R13+R14+R15R16+R17R18+R19+R110+R111R21+R22R23+R24R31+R32ContentWANServerSASBSCSDSESFSGSHSISJSKR41SASBSCSDSER24SHSISJSKNew Data
RXR31
Page 34
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
Part V. HTTP Optimization
5.1 HTTP Pipelining
5.2 Parsing and Prefetching
5.3 URL Learning
5.4 Object Prefetch Table
Page 35
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
5.1 HTTP Pipelining
라우저의 다운 드 방식 (No Pipelining) WAN 기의 다운 드 방식 (Pipelining)
HTTP GET 요청 응답으 HTTP 200 OK 신되어야 다
HTTP GET 시 보내 식의 순차적 방법 사용
HTTP GET 요청 나의 TCP 통해 병렬적으 보내
그 응답 또 병렬적으 방식 사용
.Pipelining은 WAN과 같이 RTT가 큰 환경에서 웹 페이지 로딩
완료 시간을 대폭 개선해주며 HTTP 1.1에서 표준화
HTTP GETHTTP GETHTTP 200 OKHTTP GETHTTP 200 OKHTTP GETHTTP 200 OKWANClientServerHTTP 200 OKdone
HTTP GETHTTP 200 OKHTTP GETHTTP 200 OKHTTP GETHTTP 200 OKWANdoneClient-side
Steelhead
Server-side
SteelheadClientServerHTTP GETHTTP 200 OK
.인터넷 익스플로러는 미지원, 크롬은 개발자 페이지(chrome://flags) 를 통해 사용 가능 (디폴트로 Disable)
Page 36
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
WANClient-side
SteelheadServer-side
SteelheadClientServerRouterCERouterBranch OfficeData Center1 HTTP GET2 HTTP 200 OK5 HTTP 200 OKTCP 3-way handshakeTCP 3-way handshakeTCP Connection Pool (No TCP 3-way handshake)
GET /techdocHost: intranet.example.com<html>
<head>
<script language=javascript type=text/javasciprt src=/jQuery.js />
</head>
<body>
<img width=1 height=1 src=/image.jpg>
</body>
</html>
jQuery.js file3 HTTP GETGET /jQuery.js4 HTTP GETGET /image.jpg6 HTTP 200 OKimage.jpg file7 HTTP GETGET /jQuery.js8 HTTP 200 OKjQuery.js file9 HTTP GETGET /image.jpg10 HTTP 200 OKimage.jpg fileSaving Pre-feteched
ContentsHTML ParsingPipelined Pre-fetching
CE
5.2 Parsing and Prefetching
Parsing and Prefetching 기술
.클라이언 측 WAN 기 “서버 서 클라이언
되 HTML 문서 분석” 해당 페이
기 위해 요 알아내
.클라이언 해당 요청 기 리 서버 pipeline 방식으 요청
. 신 컬 저장 이후 클라이언 서 해당 요청 시 클라이언 측
WAN 기 서 바 응답 주 방식
Tag Name Tag Attribute Example
Base href <base href=http://www.example.com/images/>
Body background <body background=img002.jpg>
Img src <img width=1 height=1 src=img001.jpg>
Link href <link rel=stylesheet type=text/css href=theme.css>
Script src <script language=javascript type=txt/javascript src=/relative.js>
WAN 가속기 설정: HTTP Tags to Prefetch
① HTML 문서 분석
② HTML 문서 포 동시 요청
③ 이후 클라이언 요청 해 WAN 기 서 응답
Page 37
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
5.2 Parsing and Prefetching (계 )
WAN 기 없 경우 WAN 기 Parsing and Prefetching 적용 경우
50 의 시 환(50개의 HTTP GET 시 와 50개의 HTTP
200 OK 시 )으 페이 딩 시 = 11
Parsing and Prefetching 기 의해 5개(예 )의
pipelining 방식으 리 요청 신 = 3.2 (3.4배
개 )
ClientServerWANRTT = 220ms...
Web Page Loading Time = 11sec50 x 220ms RTT = 11sHTTP GET(base page)
HTTP GET(1.jpg)
HTTP GET(2.jpg)
HTTP GET(3.jpg)
HTTP GET(49.jpg)
HTTP
200 OKHTTP
200 OKHTTP
200 OKHTTP
200 OKHTTP
200 OK
HTTP GET(49.jpg)
Client-side
SteelheadClientServer-side
SteelheadServerWANRTT = 200ms10ms10msHTTP
200 OKHTTP
200 OK...
Web Page Loading Time = 3.2secAssumption: Max Request of Pipelining = 5WAN: 11 x 200ms RTT = 2.2sClient side LAN: 50 x 10ms RTT = 0.5s, Server side LAN: 50 x 10ms RTT = 0.5s
HTTP GET(base page)
HTTP GET(1.jpg ~ 5.jpg)
HTTP GET(1.jpg)
Page 38
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
WANClient-side
SteelheadServer-side
SteelheadClientServerRouterCERouterBranch OfficeData Center1 HTTP GET2 HTTP 200 OK3 HTTP GET4 HTTP 200 OK5 HTTP GET6 HTTP 200 OKTCP 3-way handshakeTCP 3-way handshakeTCP Connection Pool (No TCP 3-way handshake)
GET /techdocHost: intranet.example.com<html>
<head>
<script language=javascript type=text/javasciprt src=/jQuery.js />
</head>
<body>
<img width=1 height=1 src=/image.jpg>
</body>
</html>
GET /jQuery.js
Host: intranet.example.comReferer: http://intranet.example.com/techdocjQuery.js fileGET /image.jpg
Host: intranet.example.comReferer: http://intranet.example.com/techdocimage.jpg fileURL LearningURL LearningURL Learninghttp://intranet.example.com/techdoc/jQuery.js/image.jpgURL Learning Information
CE
5.3 URL Learning
URL Learning 기술
.클라이언 측 WAN 기 클라이언 서 서버
HTTP GET 시 의 “Requested URI”
와 “Referer” 헤더 분석
.각 URL (HTML 문서 ) 어떤 포
되어 학습
URL Learning 통해
intranet.example.com/techdoc URL jQuery.js와
image.jpg 포 되어 학습
② HTTP GET
Request-URI: /jQuery.js
Referer: http://intranet.example.com/techdoc
① intranet.example.com/techdoc
페이 접
③ HTTP GET
Request-URI: /image.js
Referer: http://intranet.example.com/techdoc
Page 39
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
5.3 URL Learning (계 )
.클라이언 서 HTTP GET 시 면, 클라이언 측 WAN 기 학습 URL
리 서버 pipeline 방식으 요청 신
저장
.이후 클라이언 서 해당 요청 시 클라이언 측 WAN 기 서 바 응답 주 기술
Parsing and Prefetching과 URL Learning 비
.Parsing and Prefetching: 서버 HTTP 200 OK
시 통해 HTML 문서 신 후 prefetch
행
.URL Learning: 클라이언 의 최 HTTP GET 시
의해 prefetch 행되므 상 적으 좀 더 빠른
응답 공
. URL Learning의 경우 동일 URL 해 이용자마다 서 다른 응답 페이 공 dynamic 컨텐츠의 경우 과 볼 없
① HTTP GET(URL: intranet.example.com/techdoc) 신
직후, 학습 URL 정보 바탕으 URL 포
동시 요청
WANClient-side
SteelheadServer-side
SteelheadClientServerRouterCERouterBranch OfficeData Center1 HTTP GET5 HTTP 200 OK6 HTTP 200 OKTCP 3-way handshakeTCP 3-way handshakeTCP Connection Pool (No TCP 3-way handshake)
<html>
<head>
<script language=javascript type=text/javasciprt src=/jQuery.js />
</head>
<body>
<img width=1 height=1 src=/image.jpg>
</body>
</html>
jQuery.js file2 HTTP GETGET /techdoc
Host: intranet.example.com3 HTTP GETGET /jQuery.js
Host: intranet.example.comReferer: http://intranet.example.com/techdoc4 HTTP GETGET /image.jpg
Host: intranet.example.comReferer: http://intranet.example.com/techdoc7 HTTP 200 OKimage.jpg file8 HTTP GETGET /jQuery.jsHost: intranet.example.comReferer: http://intranet.example.com/techdoc9 HTTP 200 OKjQuery.js file10 HTTP GETGET /image.jpg
Host: intranet.example.comReferer: http://intranet.example.com/techdoc11 HTTP 200 OKimage.jpg filePipelined Pre-fetching
based on URL Learning
InformationSaving Pre-feteched
Contents
CEGET /techdoc
Host:
intranet.example.com
http://intranet.example.com/techdoc/jQuery.js/image.jpgURL Learning Information
③ 클라이언 요청 해 WAN 기
서 응답
② 신 저장
Page 40
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
5.3 URL Learning (계 )
WAN 기 없 경우 WAN 기 URL Learning 적용 경우
50 의 시 환(50개의 HTTP GET 시 와 50개의 HTTP
200 OK 시 )으 페이 딩 시 = 11
URL Learning기 의해 5개(예 )의
pipelining 방식으 리 요청 신 = 3 (3.7배 개 )
Client-side
SteelheadClientServer-side
SteelheadServerWANRTT = 200ms10ms10msHTTP GET(base page)
HTTP GET(1.jpg ~ 4.jpg)HTTP
200 OK...
Assumption: Max Request of Pipelining = 5Web Page Loading Time = 3secWAN: 10 x 200ms RTT = 2sClient side LAN: 50 x 10ms RTT = 0.5s, Server side LAN: 50 x 10ms RTT = 0.5s
HTTP GET(49.jpg)
HTTP GET(1.jpg)
Page 41
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
WANClient-side
SteelheadServer-side
SteelheadClientServerRouterCERouterBranch OfficeData Center1 HTTP GET2 HTTP 200 OK3 HTTP GET4 HTTP 200 OK5 HTTP GET6 HTTP 200 OKTCP 3-way handshakeTCP 3-way handshakeTCP Connection Pool (No TCP 3-way handshake)
GET /techdocHost: intranet.example.comCache-Control: no-cache<html>
<head>
<script language=javascript type=text/javasciprt src=/jQuery.js />
</head>
<body>
<img width=1 height=1 src=/image.jpg>
</body>
</html>
GET /jQuery.jsHost: intranet.example.comLast-Modified: Mon, 1 Oct 2012 08:14:40 GMTCache-Control: max-age=604800 (1 week)
jQuery.js fileGET /image.jpgHost: intranet.example.comLast-Modified: Mon, 1 Oct 2012 08:14:40 GMTCache-Control: max-age=604800 (1 week)
image.jpg fileStore max-age of Content (jQuery.js)
Store max-age of Content (image.jpg)
ContentObject Prefetch Table/jQuery.js/image.jpgmax-age604800604800URLintranet.example.comintranet.example.comCache content
(jQuery.js)
Cache content
(image.jpg)
Steelhead ConfigurationMaximum Object Prefetch Table Time (sec):86400
CE5.4 Object Prefetch Table
Object Prefetch Table 기술
.Object Prefetch Table은
①서버 서 의 캐싱 유 시
(max-age) 클라이언 측 WAN 기 서
저장
②이후 클라이언 HTTP GET 시
의 If-Modified-Since 드 클라이언 측
WAN 기 검사
③캐시 료 시 경우 클라이언 측 WAN
기 클라이언 게 HTTP 304 Not
Modified 시 응답
.따라서 WAN 서의 요 HTTP 시
환 기술
① 각 의 캐싱 유 시
(max-age) 학습
② WAN 기 설정
캐싱 유 시
Page 42
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
WANClient-side
SteelheadServer-side
SteelheadClientServerRouterCERouterBranch OfficeData Center1 HTTP GET2 HTTP 200 OK3 HTTP GET5 HTTP GETTCP 3-way handshakeTCP 3-way handshakeTCP Connection Pool (No TCP 3-way handshake)
GET /techdoc
Host: intranet.example.comCache-Control: no-cache<html>
<head>
<script language=javascript type=text/javasciprt src=/jQuery.js />
</head>
<body>
<img width=1 height=1 src=/image.jpg>
</body>
</html>
GET /jQuery.js
Host: intranet.example.comIf-Modified-Since: Mon, 1 Oct 2012 08:14:40 GMTGET /image.jpg
Host: intranet.example.comIf-Modified-Since: Mon, 1 Oct 2012 08:14:40 GMT4 HTTP 304 Not Modified6 HTTP 304 Not Modified
CEContentObject Prefetch TablejQuery.jsimage.jpgmax-age561600561600URLintranet.example.comintranet.example.comMax OPT Time4320043200After 12 hours
5.4 Object Prefetch Table (계 )
④ 두개의 캐싱 유 시 이 모두 료되
은 경우 WAN 기 HTTP 304
Not Modified 응답
참 : 클라이언 의 Cache Validation 절차
.클라이언 서버 은
캐싱 이후 동일 요청 시 HTTP GET
시 If-Modified-Since 드 추 서버
. 약 클라이언 요청 변경되 은
경우 서버 포 HTTP 200 OK 시
신 HTTP 304 Not Modified 시 응답
클라이언 캐싱 재사용할 게
③ 이용자의 HTTP GET with If-Modified-Since 시 신
Page 43
NMC Consulting Group Proprietary and Confidential
NETMANIAS
www.netmanias.com
5.4 Object Prefetch Table (계 )
WAN 기 없 경우
WAN 기 Object Prefetch Table 적용 경우
50 의 시 환(1개의 HTTP GET/HTTP 200 OK 시 와 49개의 HTTP GET with IMS/HTTP 304 Not Modified 시 )으
페이 딩 시 = 11
HTML 문서 HTTP 요청과 응답 이후, 클라이언 서
49개의 HTTP GET with If-Modified-Since 시 해 클라이언 측 WAN 기 서 응답.
페이 딩 시 = 0.71 (15.5배 향상)
ClientServerWANRTT = 220ms...
Web Page Loading Time = 11sec50 x 220ms RTT = 11sHTTP GET(base page)
HTTP IMS
GET (1.jpg)
HTTP IMS
GET (2.jpg)
HTTP IMS
GET (3.jpg)
HTTP IMS
GET (49.jpg)
HTTP
200 OKHTTP
200 OKHTTP
200 OKHTTP
200 OKHTTP
200 OKHTTP
304 Not
ModifiedHTTP
304 Not
ModifiedHTTP
304 Not
ModifiedHTTP
304 Not
Modified
Client-side
SteelheadClientServer-side
SteelheadServerWANRTT = 200ms10ms10msHTTP GET(base page)
HTTP
200 OK...
HTTP
304 Not ModifiedHTTP
304 Not ModifiedHTTP
304 Not Modified
HTTP IMS
GET (1.jpg)
HTTP IMS
GET (2.jpg)
HTTP IMS
GET (49.jpg)
Web Page Loading Time = 710msWAN: 1 x 200ms RTT = 200msClient side LAN: 50 x 10ms RTT = 500msServer side LAN: 1 x 10ms RTT = 10ms
Part 1~3까지의 TCP 비교 자료는 너무 오래된 자료를 인용한 듯 합니다.
제가 알기로 현재 윈도우즈는 Compound Windows), 리눅스는 NewReno, Cubic 표준을 많이 사용하고
있는 것으로 알고 있고 (리버베드에 대한 톨리의 리포트 이후인 2006년부터 개발/적용된 것으로 압니다)
"standard TCP"만 쓰는 OS는 이제는 거의 볼 수 없는 것 아닌 가 생각합니다.
상기 개선 사항들이 주로 Initial Window & Window Scaling 부분과 Congestion Avoidance 부분으로
알고 있어 현 시점에서는 자료상의 비교 수치와 현실간에는 차이가 있을테니
자료를 이해할 때 주의가 필요할 듯 합니다.
Hi,
Thanks a lot for providing help to understand protocols.
Kindly update the english version of this document.
Thanks a lot.
Vijay
위에서 다른 분이 이미 언급해 주셨지만, Legacy TCP가 Initial MSS를 1로 하지만, CUBIC등 최신 OS에서는 1로 하지 않으니 Initial Window Size 의미 없고, RFC1323도 이미 Linux를 포함한 모든 OS에 적용이 되었으니 Window Scaling 별 의미 없네요. 분실 패킷만 재전송하는 SACK도 서버와 Client TCP 거의 대부분 구현되어 들어가 있으니 중간에 장비들을 거쳐야 하는 것이 더 성능 잡아 먹지 않을까 하는 생각이 드는데요. 망변경할때마다 같이 변경하고 하려면 운용하는데도 상당히 운용자를 머리 아프게 할 것 같습니다. 혹시 사용해 보시고, 정말 효과 좋다 성능 도움이 많이 된다 그런 경험담 같은 것은 없을까요? Congested 된 망에서는 아무런 소용이 없을듯 하고, VPN 같이 네트워크 대역폭이 보장된 망에서는 서버에서 네트워크 drop 발생하지 않도록 Rate 조절(shaping) 하도록 하면 충분히 높은 성능을 보장할 수 있을 것인데, 굳이 큰 돈 들여 중간에 장비 놔야 하는지 의문이네요.
vpn쓴다고 빨라졌으면 모든횟가 그리쓰겠죠, delay도 고려해야되고, 무엇보다도 서버에서 rate조절로 충분히 높은성능을 보장할수있다는말은 테스트해보고 하시는 말씀인지, 어디 reference인지 알수있나요? 해외지사를 가진 대부분의 기업에선 wan가속기 솔루션을 쓰고있는걸로아는데, 굳이 필요하지도않을걸 왜 비싼돈 들여 쓸까요?