Proxy Server 란

Java/Networking 2013. 2. 1. 23:20

프록시 서버는 웹 브라우저(예: Internet Explorer)와 인터넷 사이의 중간 역할을 하는 컴퓨터입니다. 프록시 서버는 자주 사용되는 웹 페이지의 복사본을 저장하여 웹 성능을 향상시키는 데 도움을 줍니다. 브라우저가 프록시 서버의 모음(캐시)에 저장된 웹 페이지를 요청하면 프록시 서버가 이 웹 페이지를 제공하므로 웹으로 이동하는 것보다 더 빠릅니다. 또한 프록시 서버는 특정 웹 콘텐츠 및 악성 소프트웨어를 필터링하여 보안 향상에 도움을 줍니다.

프록시 서버는 대개 조직 및 회사의 네트워크에 사용됩니다. 일반적으로 집에서 인터넷에 연결할 때는 프록시 서버를 사용하지 않습니다

 

출처: 마이크로 소프트

        http://windows.microsoft.com/ko-KR/windows-vista/What-is-a-proxy-server

'Java > Networking' 카테고리의 다른 글

기본 HTTP 웹서버 구현 – TinyHttpd Server  (0) 2013.02.12
서버와의 시간동기화 [ 소켓통신 ]  (0) 2013.02.12
소켓통신 프로그램의 기본 구조  (0) 2013.02.07
RMI (Remote Method Invovation)  (0) 2013.02.01
Proxy Server 란  (1) 2013.02.01
Posted by Steven J.S Min

댓글을 달아 주세요

  1. Steven J.S Min 2013.02.01 23:23 신고  댓글주소  수정/삭제  댓글쓰기

    요약 : 클라이언트와 서버 사이에서 데이터를 중계하는 역할을 하는 서버.

    클라이언트(웹 브라우저)에서 어떤 인터넷 주소의 정보검색에 대한 요구를 받으면, 그 주소를 그 전에 읽어 저장한 장소에서 찾아, 있으면 그 정보를 즉시 찾아 주고, 없으면 그 주소지의 서버로부터 가지고 와서 저장장소에 저장한다. 여기서 프락시란 대리인을 뜻하는 말이다.

    프락시 서버의 기능에는 캐시 기능이 있다. 네트워크의 트래픽을 줄이고, 데이터의 전송 시간을 향상 시킨다.방화벽 기능을 담당하기도 한다. 인터넷 동시 접속자가 많을 때, 음란사이트 등 유해 사이트를 차단할 때, 내부 사용자 IP주소를 사설 IP주소로 설정하여 보안을 강화할 때, 해커 등 외부의 침입을 방지하고자 할 때 유용하다. 인터넷을 사용할 때 보안이나 규제가 필요한 기업이나 학교 등에서 많이 도입하고 있다.

    웹 프락시의 개념으로 웹 브라우저가 프락시 서버를 명기하거나 특별한 설정 없이 (transparent caching) 프락시를 이용할 수 있다. 이런 경우 데이타의 흐름이 모두 프락시 서버를 거쳐서 일어나게 된다. 즉, 어떤 웹사이트로 접속을 시도하면, 우선 프락시 서버로 연결하여 데이터를 가져온 다음에 이것을 사용자의 PC에 전달한다. 이것의 장점은 웹에서 검색할 때마다 통신선로를 타고 검색하는 것은 통신망의 속도도 느리고, 통신오류가 발생하면 재전송을 하는 등의 일 때문에 더욱 속도가 느려질 수 있지만, 먼저 프락시 서버를 연결하여 여기서 찾고자 하는 데이터를 갖고 있으면 빠르게 사용자에게 전달할 수 있다.

    방화벽과 캐시 등의 기능들과 하나의 패키지로 통합되어 있는 경우도 있고, 별도의 서버 프로그램에서 수행될 수도 있다. 예를 들어 방화벽 서버와 함께 한 컴퓨터 내에 있을 수도 있고, 별도의 서버에 존재하면서 방화벽을 통해 요구를 전달하는 것도 가능하다. 현재 주로 이용되고 있는 프록시 소프트웨어로는 탑프래시·보라매·MS프록시·인터폴·웹빌더·스푼 등이 있다

    출처: 네이버지식백과
    http://terms.naver.com/entry.nhn?cid=200000000&docId=1180260&mobile&categoryId=200000779

결론부터 말하면 NonBlocking의 원리, Network 프로그래밍일 경우 OS에서 동작하는 Socket의 동작 방식을 모르기 때문이다.

Java의 Standard IO의 경우 사실 단순하다.
하나의 Connection에 대해서 하나의 Thread가 1:1로 대응되어,
개발시 하나의 Connection에 대한 처리 로직이 명확하고, 다른 Connection에 대해 독립적이기 때문이다.

쉽게 말해 개발자가 개발하기 쉬운 구조다.

하지만 NIO의 경우 다수의 Client Connection을 극단적인 경우 하나의 Thread 만으로도 처리할 수 있는 구조이다.

NonBlocking에 대한 심도 깊은 이해가 필요하다.
사실 NonBlocking은 의미적으로는 간단하다.
NonBlocking Method를 호출할때 일반 IO와 달리 Blocking 되지 않고 즉시 Return됨을 의미한다.

하지만 Blocking IO만 접해왔던 개발자들에게 즉시 Return이라는 것은 쉽게 이해할 수 없는 부분이다.

왜냐하면 read(buffer) 라는 method를 call해서 int형으로 넘겨받은 값이, 실질적으로 client에 전송된 byte의 수를 의미하는 것인데, 이것은 달리 해석하면, data 전송이후 실질적으로 client가 해당 data를 consume한 것이 확인 되었을때 알 수 있는 값이기 때문이다.

쉽게 말해서 blocking method 호출시 최소한 작업 완료에 대한 응답값이 필요하다.
서버가 특정 data를 전송했을때, client로 부터 data가 consume되었다는 프로토콜 구조적인 확인이 필요하고, 이때 client의 처리가 지연될 경우 method 호출로 인해 blocking 되는 시간은 길어진다고 볼 수 있다.

다시 본론으로 돌아와서,
그렇다면 NIO 의 write(buffer) 를 호출했을때 어떠한 원리로 blocking 없이 즉시 return 값을 받을수 있을까?

이것을 이해하기 위해서는 OS의 Socket에 대한 이해가 필요하다.
더 자세히 말해 Socket Buffer에 대한 이해가 절대적으로 필요하다. 

결론부터 얘기하면,
Kernel Level의 모든 Socket Object는 자체적인 Read/Write Buffer를 가진다.
Socket Buffer로 넘겨진 data는 실질적으로 OS의 Kernel로 그 제어권이 넘어간 것이라 할 수 있다.
Application Level에서 Socket Buffer의 Data가 넘어가는 순간 실질적인 Data 전송의 스케쥴링은 Socket을 컨트롤 하는 OS에 달렸다고 볼수 있다. (물론 Application Level에서 Socket Buffer의 크기를 조절하여, 간접적인 Data 전송 스케쥴도 가능하긴 하다)
NIO의 핵심 메카니즘은 Socket Buffer에 단순히 Data를 Write하고 Read하는 역할 밖에는 하지 않는다.

단순히 메모리상의 특정 영역(Java Memory Area)에서 OS의 영역(Socket Buffer in Kernel)으로 데이터를 Write/Read하는 작업만을 하기때문에, 실질적으로 Blocking이 없다고 볼 수 있다.

예측할 수 없는 Data가 불규칙적으로 오고가는, Socket Buffer의 Data를 효과적으로 감시하기 위해서는, Polling이 아닌 Event기반의 감시자(Monitor Object)가 필요한데, 그 역할을 하는 것이 NIO의 Selector Object이다.

Selector에 대한 자세한 설명은 다음 강좌에 연재하겠다.

어찌되었건, NIO의 핵심은 구현 관점에서 NonBlocking Call과 Event기반의 처리라 볼 수 있다.
특징은 기존 IO에 비해 구현은 훨씬 복잡해지면서 Thread의 수를 최소화 할 수 있어서 대량접속에 대한 처리에 대해 쓰레드의 Context Switching 비용의 부담에서 벗어 날 수 있다.

물론 구현이 복잡해 지는 만큼, Design(설계)시 고려사항이 많아지며, 필수적이고 잘 알려진, Network, Thread,  I/IO 관련 Design Pattern에 대한 이해가 필수적이다.

 

출처: 김영곤(gonni21c@gmail.com)

http://jakarta.tistory.com/91

Posted by Steven J.S Min

댓글을 달아 주세요

XML-RPC

Java/Java for XML 2013. 2. 1. 23:11
분산 환경에서 통신을 하는 방법에는 메시지 전달 방식요청/응답 방식이 있습니다.
우선, 메시지 전달 방식에는 소켓이 있고 요청/응답 방식에는 HTTP, RPC, RMI 등이 있습니다.
그럼 요청/응답 방식 중 하나인 RPC에 대해 먼저 살펴 보겠습니다.

1. RPC(Remote Procedure Call)
한 프로그램이 네트워크상의 다른 컴퓨터에 위치하고 있는 프로그램에 서비스를 요청하는데 사용되는 프로토콜로
같은 프로그램내의 함수(Procedure)를 호출하는 것과 같이 원격 프로그램내의 함수를 호출해서 결과를 받습니다.
또 RPC는 요청하는 프로그램이 결과가 반환 될 때 까지 일시 정지되어야 하는 동기식 운영 방식입니다.
 
2. XML-RPC
XML 기반의 분산 시스템 통신방법으로서 HTTP를 통하여 간단하고 이식성 높은 원격 프로시저 호출을 지원합니다.
리모트 프로시저의 호출에 대하여 XML 형태로 매개변수나 리턴값을 반환하게 됩니다.

3 XML-RPC의 통신 방식


4. XML-RPC의 장점
HTTP를 이용하므로 Web 상의 모든 종류의 어플리케이션과 상호 동작이 가능하며 객체 기반의 통신을 가능하게 합니다.
독자적인 HTTP 서버 클래스로도 사용 가능하며, 간단한 구조로 인해서 성능이 향상되며 구현이 간단하고 용이합니다.
다양한 언어를 지원하므로 플랫폼 및 개발 언어에 독립적이며 상대적으로 개발 비용이 적게 듭니다.
 
5. XML-RPC의 단점
HTTP를 이용하므로 HTTP의 단점도 그대로 상속받게 되는데 우선 상태가 유지되지 않는다는 단점이 있습니다.
연속으로 두번 함수를 호출할때 서버에서는 이 두함수 요구를 환전히 별개의 요구로 받아 처리합니다. 
즉 이전함수 호출에서 어떤 객체를 생성했다고 해도 다음 호출에서 그 객체를 사용할 수 없게 됩니다
또한 http는 대량의 데이터 전송에 그다지 효율적이지 못합니다. 

 

출처:http://hicoffee.tistory.com/37 

'Java > Java for XML' 카테고리의 다른 글

XMLEncoder & XMLDecoder  (0) 2013.02.05
XML-RPC  (0) 2013.02.01
Posted by Steven J.S Min
TAG XML-RPC

댓글을 달아 주세요

많이 늦었다.

이미 순간 순간 중요한 기억들... 잊지 말았어야할 중요한 기억들을 잊고 살았다.

 

이제 부터라도 머리속 생각들을 정리를 해야 하지 않을까해서 바쁘지만 그나마 인터넷이라는 힘을 빌려 블로그를 정리해본다.

 

2013년 1월 1일, 날씨는 모처럼 흐림. RMIT 대학도서관에서

'Life of Aussie > Diary' 카테고리의 다른 글

아름다운 호주...  (0) 2016.02.22
베드버그  (0) 2014.05.15
무서운 벌금....  (0) 2013.02.20
무엇인가 정리하면서 살아야 하지 않을까?  (0) 2013.02.01
Posted by Steven J.S Min

댓글을 달아 주세요