WEBVTT

00:00.300 --> 00:03.180
이번 수업에서는 대리인에 대해 얘기해 볼게요

00:03.180 --> 00:05.880
프록시 서버는 네

00:05.880 --> 00:07.830
원격 리소스

00:07.830 --> 00:10.620
간에요 안 됩니다

00:10.620 --> 00:12.480
이러한 장치는 물리적인 하드웨어

00:12.480 --> 00:13.980
기반 어플라이언스일 수도

00:13.980 --> 00:16.470
있고 단순히 인프라 내의 다른 서버에 설치된

00:16.470 --> 00:19.020
소프트웨어일 수도 있습니다.

00:19.020 --> 00:22.410
어느 쪽이든 이 장치는 몇 가지 이점을 제공합니다

00:22.410 --> 00:25.200
네트워크 내 속도와 효율성을 높이고 보안을

00:25.200 --> 00:26.280
강화하며 감사를

00:26.280 --> 00:28.920
수행할 추가 기회를 제공하죠

00:28.920 --> 00:30.810
네 속도와 효율성이 증가합니다

00:30.810 --> 00:33.000
프록시를 사용하면요 프록시 서버는

00:33.000 --> 00:35.310
웹 캐싱이란 기능을 제공하니까요

00:35.310 --> 00:37.650
네 기본적으로 사용자가 프록시를 통해 웹사이트를

00:37.650 --> 00:41.250
요청하면 캐시 안에 로컬 복사본을 보관합니다 ???

00:41.250 --> 00:43.950
그런 다음 다른 사용자가 동일한 웹 사이트를 요청하면

00:43.950 --> 00:45.150
느린 wan 링크를 통해

00:45.150 --> 00:47.640
해당 웹 서버에서 직접 요청하는 대신 프록시 서버는

00:47.640 --> 00:49.830
자체 내부에 로컬로 저장한 캐시된 복사본을

00:49.830 --> 00:53.100
사용자에게 간단히 제공할 수 있습니다.

00:53.100 --> 00:54.900
시간과 bandwidth를 절약하고

00:54.900 --> 00:57.390
정적 웹사이트에 대해 잘 작동합니다

00:57.390 --> 00:59.730
이제 이 기술은 최신 Web 2를 다룰 때 제대로

00:59.730 --> 01:02.190
작동하지 않습니다. 0개

01:02.190 --> 01:04.620
페이스북, 트위터, 레딧 같은 사용자가

01:04.620 --> 01:06.330
생성한 콘텐츠를 사용하는

01:06.330 --> 01:08.340
곳 말이에요

01:08.340 --> 01:10.410
네 왜냐하면 여러분이 로그인할 때마다

01:10.410 --> 01:12.270
개인화된 경험을 하게 되니까요

01:12.270 --> 01:13.860
사용자에 따라서요

01:13.860 --> 01:16.800
캐싱이 효율적이지 않게 되죠

01:16.800 --> 01:20.250
프록시 서버의 두 번째 장점은 보안 강화입니다

01:20.250 --> 01:23.190
자 이런 일이 발생하는 건 각 프록시가 용인 가능한 사이트와

01:23.190 --> 01:24.450
허용되지 않는 사이트 목록을

01:24.450 --> 01:26.670
구성해 용인되지 않는다고 간주된 사이트들을

01:26.670 --> 01:29.160
차단하기 때문입니다

01:29.160 --> 01:30.390
네 그러니까 예를 들면

01:30.390 --> 01:32.400
예를 들어 직원이 회사 책상에 앉아서

01:32.400 --> 01:34.290
포르노나 도박이 담긴 웹사이트에

01:34.290 --> 01:36.090
접속하려고 하면

01:36.090 --> 01:39.690
프록시 서버는 그 액세스를 막도록 구성될 수 있어요

01:39.690 --> 01:41.940
마찬가지로, 회사 네트워크에서 액세스하고

01:41.940 --> 01:43.140
싶지 않은 맬웨어 및 기타

01:43.140 --> 01:45.180
콘텐츠를 호스팅하는 것으로 알려진 웹사이트를

01:45.180 --> 01:46.950
차단할 수도 있습니다.

01:46.950 --> 01:49.350
끝으로 프록시 서버는 네트워크에

01:49.350 --> 01:51.630
추가적인 감사 기능을 제공합니다

01:51.630 --> 01:53.790
사용자가 광역 네트워크로 나가기

01:53.790 --> 01:57.060
위해 요청한 모든 걸 기록하기 때문이죠

01:57.060 --> 01:58.740
이런 로그들은 직원이 접근이

01:58.740 --> 02:01.260
금지된 사이트를 방문하려 하는지 판단하는

02:01.260 --> 02:02.670
데 사용됩니다 도박이나

02:02.670 --> 02:05.460
포르노 같은 사이트요 앞서도 얘기했죠

02:05.460 --> 02:07.650
또한 직원들이 웹사이트에서 얼마나

02:07.650 --> 02:10.320
많은 시간을 보내는지도 알려줍니다

02:10.320 --> 02:12.630
그렇습니다 네 시스템 관리자에게

02:12.630 --> 02:17.220
요청할 수 있습니다 해당 웹 브라우징 활동에 대한

02:17.220 --> 02:19.380
보고서를 작성해 달라고

02:19.380 --> 02:21.540
말이죠

02:21.540 --> 02:23.550
그리고 프록시 서버에 쿼리를

02:23.550 --> 02:26.280
날리고 감사 로그를 살펴 주어진 사이트에

02:26.280 --> 02:29.190
얼마나 시간을 썼는지 확인합니다 조직 정책의

02:29.190 --> 02:31.980
범위 내에서 허용되는지요

02:31.980 --> 02:34.530
자 제가 it 책임자로 일했던 이전 조직에서

02:34.530 --> 02:35.820
네트워크가 시간이

02:35.820 --> 02:36.990
갈수록 느려지는

02:36.990 --> 02:38.490
걸 보기 시작했죠 사용자가

02:38.490 --> 02:41.940
더 늘어나면서 걱정이 됐거든요

02:41.940 --> 02:44.790
우리가 한 것 중 하나는 어떤 웹사이트가 대역폭을

02:44.790 --> 02:47.160
가장 많이 쓰는지 평가하기 시작한 거예요

02:47.160 --> 02:48.870
프록시 서버를 체크해서요

02:48.870 --> 02:50.400
당연히 첫 번째와 두

02:50.400 --> 02:53.610
번째가 유튜브와 페이스북이었죠

02:53.610 --> 02:55.620
네 이제 상위 관리자로 가서 더 많은

02:55.620 --> 02:58.020
대역폭을 사기 위해 추가 비용을 요청할

02:58.020 --> 03:00.270
수 있었죠 혹은 그 대역폭을 주기 싫다면

03:00.270 --> 03:02.400
이 사이트들을 차단하도록 요청해

03:02.400 --> 03:04.590
실제 작업 기능에 사용되는 대역폭을

03:04.590 --> 03:06.540
최대화했어요 사람들이 소셜 미디어에

03:06.540 --> 03:08.520
가는 데 말고요

03:08.520 --> 03:10.350
이제 이 조직의 경우 우리 경영진은

03:10.350 --> 03:12.660
인터넷 서비스에서 더 많은 양의 대역폭을 구입하는

03:12.660 --> 03:15.090
대신 직원들이 근무 시간 동안 YouTube를

03:15.090 --> 03:17.460
사용하도록 요구하는 타당한 비즈니스 이유를

03:17.460 --> 03:18.630
보지 못했기 때문에 YouTube를

03:18.630 --> 03:22.770
차단하기로 결정했습니다. 공급자.

03:22.770 --> 03:24.600
돈을 좀 모아서 직원들이 유튜브를

03:24.600 --> 03:27.100
못 보게 만들기로 한 거죠