Web Caching -8조- 20041738 황세선 20062405 박민희.

Presentation on theme: "Web Caching -8조- 20041738 황세선 20062405 박민희."— Presentation transcript:

1 Web Caching -8조- 황세선 박민희

2 목차 웹 캐싱이란? 등장 배경 및 발전 과정 웹 캐싱 이용의 이점 웹 캐싱의 종류 웹 캐싱의 동작 방식과 로그 정보
웹 캐싱의 현실과 향후 진로 프록시 서버 프로그램(burp suite) 참고 자료

3 웹 캐싱이란? [웹 캐싱(Web Caching)] 인터넷 게이트웨이 가까이에 설치되어 다른 사용자가 방문했던
사이트의 경우 원 서버에 요청하지 않고 캐시 서버에서 응답해주는 방식 [일반적인 웹 캐싱 구조]

4 등장 배경 및 발전 과정 [등장 배경] [발전 과정] 2000년도 전후로 웹의 폭발적인 성장
사용자 환경의 변화와 데이터 전송량의 증가 사용자의 증가로 네트워크 대역폭을 절약하고 안정적인 서비스의 필요성 부각 [발전 과정]

5 웹 캐싱 이용의 이점 [인터넷 속도 향상] [대역폭 절감] - 콘텐츠를 바로 LAN상에서 가지고 오기 때문에 체감속도 향상
인터넷기업의 경우 사용자와 가까운 곳에 캐시서버를 위치 시킴 ☞ 좀 더 질 높은 서비스를 소비자에게 제공 서버에서 처리할 내용을 캐시서버에서 처리 ☞ 서버의 부하를 줄일 수 있고 서버의 투자 비용을 절감 [대역폭 절감] 많은 콘텐츠들이 WAN을 거치지 않고 바로 LAN상에서 처리 ☞ 대역폭을 절감. 전용선의 추가 설치보다 훨씬 저렴한 Caching Solution을 구축 ☞ 비용면에서 많은 효과를 거둠

6 웹 캐싱의 종류 [포 워드 캐시(Forward Cache)] 인터넷 사용자 앞에 캐싱 서버가 존재
인터넷 구간의 회선 비용 절감 로컬응답으로 컨텐츠의 빠른 전송

7 웹 캐싱의 종류 [리버스 캐시(Reverse Cache)] 웹 사이트 서버 앞에 캐싱 서버가 존재
서버의 부하를 줄여 주는 역할 캐시 서버의 다운으로 전체 서버의 다운되는 문제점을 가짐

8 웹 캐싱의 종류 [트랜스 페어런츠(Transparent Cache)] 사용자 입장에서는 캐시가 있는지 없는지
모르는 상태로 캐시 서버를 위치 시킴 - 포워드나 리버스 형태 모두 사용될수 있음 별도의 장비(로드 밸런서, 라우터, L4 스위치)의 도움을 받아서 구성 웹 캐시에 문제가 생기더라도 로드 밸런서 와 같은 장비에서 이를 감지해 웹 서버의 다운을 방지

9 웹 캐싱의 동작 방식과 로그 정보 [용어설명] 프록시(Proxy) : ‘대리인’ 이라는 뜻으로 클라이언트를 대신해
웹 서버에게 요청을 하고 결과를 클라이언트에게 돌려주는 역할 Hits & Misses : 웹 캐싱 서버에 요청 컨텐츠가 존재할 경우 ’Hits’, 없을 경우 ‘Misses’ 신선도(Freshness) : 신선한(Fresh) 과 신선하지 않은(Stale)으로 구분 되고 웹 캐싱 서버 신선도 유무를 판단하여 전송 여부 결정 유효성 : Hits 된 컨텐츠가 신선하지 않을 경우, 서버에게 재사용 가능 한지를 체크 Cachable & Non-Cachable : 일반적으로 정적 컨텐츠에 대해서는 Cachable 하다 판단하고, 캐시 서버로 활동, Non-Cachable일때는 프록시(Proxy) 서버로 활동

10 웹 캐싱의 동작 방식과 로그 정보 [Cachable?] 요청프로토콜이 HTTP일 때(SSL과 같은 보안 프로토콜은 안됨)
요청하는 방법이 GET이나 HEAD일 때 요청헤더가 no-cache, no-store등을 포함하고 있지 않을 때 요청헤더의 URL이 동적콘텐츠가 아닐 때 (?,asp,php,jsp,pl,/cgi-bin/ or .cgi등이 아닐 때) 응답하는 콘텐츠가 동적 콘텐츠가 아닐 때 응답하는 상태코드가 200 OK 일 때 응답헤더에 Set-Cookie 항목이 없을 때 응답헤더에 인증 정보가 없을 때

11 웹 캐싱의 동작 방식과 로그 정보 [동작 방식] 1.Hits -> 2. 신선도 체크 -> 3. 유효성 검사 -> 4. 응답 -> 5. 업데이트

12 웹 캐싱의 동작 방식과 로그 정보 [유효성 관련 HTTP 헤더]
HTTP 의 요청헤더(GET) 또는 응답헤더(OK) 에 유효성 관련 정보가 기록 (참고

13 웹 캐싱의 동작 방식과 로그 정보 [Squid 로그 정보]
- 타임스탬프 - 서버가 시작된 1970/01/01부터의 시간경과(milliseconds) - 경과시간 - 클라이언트 소켓이 열리고 닫히는데 걸린 시간(milliseconds) - 클라이언트IP - 클라이언트의 IP - 캐시결과/HTTP코드 – 요청한 컨테츠에 대한 캐시결과와 HTTP상태코드 - 크기 - 클라이언트에 전송된 바이트 - 요청 방법 - 클라이언트의 요청 방법 - URL - 요청된 URL - 식별자 - RFC 931에 설명된 인증에 사용된 식별자 - 계층데이터/호스트 - 요청된 오브젝트를 어디서 가져왔는지를 표시 - 컨텐츠 타입 - 서버쪽에서 넘겨준 오브젝트의 타입

14 웹 캐싱의 동작 방식과 로그 정보 [캐시결과/HTTP 코드] TCP_HIT : 요청한 컨텐츠가 캐시에 있어서 응답한 경우
TCP_MISS : 요청한 컨텐츠가 캐시에 없어서 실제 서버로 요청을 하여 응답한 경우 TCP_IMS_HIT : 클라이언트가 If-Modified-Since 필드를 요청 헤더에 보냈는데 HIT가 난 경우 TCP_IMS_MISS : 요청헤더에 If-Modified-Since가 포함되어 있지만, 캐시가 신선하지 않다고 판단되어 실제 서버로 재요청을 한 경우 TCP_REFRESH_HIT : 요청한 컨텐츠가 신선하지 않아 실제 서버로 요청했는데, '304 Not Modified'를 받아 캐시에서 클라이언트로 응답한 경우 TCP_REFRESH_MISS : 요청한 컨텐츠가 신선하지 않아 실제 서버로 요청했는데, 서버에서 새로운 컨텐츠를 전송 받아 캐시에 저장하고 다시 클라이언트로 응답 TCP_CLIENT_REFRESH : 클라이언트 요청 헤더에 'no_cache'를 포함한 경우 TCP_CLIENT_REFRESH_MISS : 클라이언트 요청에 'no-cache'나 'no-store'같은 캐시를 제어하는 필드를 포함해서 캐시가 서버로부터 컨텐츠를 가져왔을 경우 TCP_DENIED : 클라이언트 요청이 캐시에 의해서 거절당했을 경우 (컨텐츠필터링과 연관)

15 웹 캐싱의 현실과 향후 진로 [웹 캐싱의 현실] [향후 진로]
10여년 전의 초기 설계된 캐싱 알고리즘의 사용으로, 최근의 서비스 형태와는 적합하지 않아 한계가 있음. 대부분의 대형 웹 캐싱 업체들은 사업을 포기하거나 방향을 바꾸는 실정 웹 캐싱 시장은 축소되고 있음 [향후 진로] 아직 대형 프로젝트에서는 웹 캐싱 서버가 포함 되는 경우가 많음. 웹 캐싱의 한계를 극복하기 위한 연구가 계속 되고 있으며, 향상된 웹 서비스를 위한 방법이 나올 것이라고 기대함

16 프록시 서버 프로그램(burp suite)
[burp suite v1.1] 기능 Proxy Server 서버 기능 HTTP 헤더 정보 추출 및 변경 기능 웹 공격 기능 [실행 화면]

17 프록시 서버 프로그램(burp suite)
[Proxy Server 서버 기능] - Explorer->도구->인터넷 옵션->연결->LAN 설정

18 프록시 서버 프로그램(burp suite)
[HTTP 헤더 정보 추출 및 변경 기능]

19 프록시 서버 프로그램(burp suite)

20 프록시 서버 프로그램(burp suite)

21 프록시 서버 프로그램(burp suite)

22 프록시 서버 프로그램(burp suite)

23 프록시 서버 프로그램(burp suite)

24 프록시 서버 프로그램(burp suite)

25 프록시 서버 프로그램(burp suite)

26 프록시 서버 프로그램(burp suite)
[웹 공격 기능]

27 참고 자료 - NRC와 함께 하는 Live 네트워크 10장 김진규 | 한빛미디어 | 2002.11.28
- - - -