깜장 블로그

HTTP와 WWW, 인터넷의 비약적인 발전을 일으킨 놈들이다.
기본적으로 서버와 클라이언트의 구조로 되어있다. 클라이언트( PC, Mobile Phone etc ) 가 서버에 요청을 하면 서버는 해당 웹페이지를 클라이언트에 전송해 주는 구조이다. request / response 라는 기본 개념에서 시작되었다. 그리고 각 웹페이지는 각 사이트(서버)에 존재를 하고, 우리는 이를 www 를 이용해서 각기 다른 host 에 요청을 하고, 원하는 웹페이지를 받는 것이다.
이 웹페이지를 보여주기 위해서, 해석하고 표현을 해주는 도구가 필요한데 이것이 바로 브라우저이다. 유명 브라우저에는 인터넷 익스프로러, 크롬, 파이어 폭스 등이 있다. 이러한 브라우저는 보통 제어기( controller ), 클라이언트 프로토콜 및 해석기( interpreter ) 의 세부분으로 나뉜다. 제어기는 키보드/마우스로부터 입력을 받아 클라이언트 프로그램을 사용하여 문서를 액세스 한다. 문서가 액세스 되고 난 뒤에는 해석기 중 하나를 사용하여 문서를 화면에 표시한다.
클라이언트 프로토콜은 FTP, HTTP 중에 하나가 될 수 있고, 해석기는 문서의 유형에 따라 HTML, Java or JavaScript 가 될 수 있다.

웹페이지를 엑세스 하기 위해서 URL ( Uniform Resource Locator ) 을 입력하는데, 이는 인터넷에서 어떤 종류의 정보든 지정할 수 있는 표준이다. 표준은 아래와 같다.

Protocol  : //

Host :

Port /

Path

간단히 설명하자면
Protocol : FTP, HTTP
Host : 정보가 위치하고 있는 컴퓨터이다.
Port : URL 은 선택적으로 port 번호를 포함할 수 있다. 이는 콜론 으루 구분.
Path : 정보가 위치하고 있는 파일의 경로 이름이다.


쿠키
인터넷 웹사이트의 방문기록을 남겨 사용자와 웹사이트 사이를 매개해 주는 정보이다.
고객이 특정 홈페이지를 접속할 때 생성되는 정보를 담은 임시파일이며, 애초에 인터넷 사용자들의 홈페이지 접속을 위해 만들어졌다. 특정 사이트를 처음 방문하면 아이디와 비밀번호를 기록한 쿠키가 만들어지고 다음에 접속했을 때 절차 없이 사이트에 빠르게 연결 할 수 있다.
쿠키는 사용하는 웹브라우저가 자동으로 만들기도 하고 갱신하기도 하며, 웹사이트로 기록을 전달하기도 한다. 이용자가 인터넷에서 어떤 내용을 봤는지 어떤 상품을 봤는지 모든 정보가 기록이 된다. 따라서 이에 따른 보안 문제가 발생할 수 도 있다.

이러한 쿠키의 생성과 저장에 대해서 알아보겠자.

네트워크에서 프록시, 핸드폰에 wifi 를 쓸때도 프록시.. 여기저기서 프록시 라는 말이 자주 나온다. 그런데 정작 프록시가 뭐하는 건지 모르겠어서 마침내 찾아보게 되었다. ( -_-; 이놈의 게으름병..)
책을 보면 HTTP 는 프록시 서버를 지원한다고 한다. 즉.. 프록시는 서버를 뜻하는 것이었다. 프록시 서버는 최신 요청에 대한 응답들의 복사본을 가지고 있는 컴퓨터 이다. HTTP 클라이언트는 프록시 서버로 요청을 보내고, 프록시 서버는 캐시(cache)를 검사를 하는데, 이때 해당 응답이 서버에 있게 되면 해당 응답을 보내주고, 그렇지 않으면 적절한 서버로 요청을 보내고, 프록시 서버에 돌아온 응답을 클라이언트에게 보내주게 된다. 그리고, 다른 클라이언트의 요청에 대비해 프록시 서버에 응답이 저장된다. 이렇게, 프록시 서버는 컴퓨터의 캐시와 같은 존재로써, 서버의 부하를 줄이고, 트래픽을 감소하고 지연을 개선하는 목적으로 운영이 된다. 이러한 프록시 서버를 사용하기 위해서는 클라이언트가 대상 서버 대신에 프록시를 액세스 하도록 설정 되어 있어야 한다. 핸드폰에 WIFI 를 설정할 때도 보면, proxy 서버를 설정하는 부분이 옵션으로 들어가 있는 것을 볼 수 있을 것이다.

1) GET  : URL로 자원 또는 파일을 달라고(get) 요청함

2) POST : Request 에 첨부한 몸체정보를 서버로 보내어, 요청한 URL 로 이 정보를 넘겨주라고 요청함. 용량이 큰 GET, 부가정보를 가진 GET

3) HEAD : GET이 무엇을 리턴하든 간에 헤더 정보만 요청함.
               이는 Response 의 몸체 정보가 없다는 것만 삐면 GET 과 동일함.
               요청한 URL 로부터 요청한 정보는 빼고 헤더 정보만 가져오는 것임.

4) TRACE : 요청한 메시지의 루프백(loopvack) 테스트를 요청함. 
                 서버로부터 받은 내용을 클라이언트 쪽에서 확인하기 위해 사용.
                 테스트 목적 또는 문제 해결을 위해 사용함

5) PUT : 동봉한 몸체 정보를 요청한 URL 로 올리기 위해 사용함.

6) DELETE : 요청한 URL에 있는 자원이나 파일을 삭제하기 위해 사용함.

7) OPTION : 요청한 URL이 응답할 수 있는 HTTP 메소드가 무엇인지 요청함.

8) CONNECT : 터널링의 목적으로 연결을 요청함.

Post/Redirect/Get( PRG ) 는 웹 개발자들이 특정 중복되는 폼을 요청하는 것을 피하도록 돕고, user agent 가 bookmarks, refresh 버튼을 좀더 더 직관적으로 사용할 수 있도록 해주는 흔한 디자인 패턴이다.
( user agent : 분산 컴퓨팅 시스템의 통신에서 사용되는 네트워크 프로토콜을 사용하는 클라이언트 프로그램을 말하고, 이 용어는 주로 World Wide Web 을 엑세스 하는 어플리케이션을 말한다. SIP( Session Initiation Protocol )와 같은 다른 시스템에서는 user agent 라는 용어를 통신 세션의 양 끝을 의미할 때 사용한다.
 출처 : http://en.wikipedia.org/wiki/User_agent )
HTTP POST 요청을 통해 서버에 웹 폼이 전달될 때, 특정 user agents에서 서버 응답을 재요청하려고 하는 웹 사용자는 original HTTP POST 요청 내용을 재요청할 수있고, 중복 웹 구매와 같은 원하지 않았던 결과를 야기할 수 있다. 이 문제를 피하기 위해 많은 웹 개발자 들이 웹페이지를 직접적으로 보내주는 대신에, POST operation이 redirection 명령어를 return 하는, PRG 패턴을 사용하고 있다.( redirection command : HTTP "Location" response header 를 함께 사용하여 HTTP 303 응답 코드 ( 가끔씩 HTTP 302 ) 를 사용하며, 브라우저에게 GTTP GET 요청을 사용하여 다른 페이지를 로드 하라는 명령을 한다 ) 그래서, 웹 사용자는 초기 HTTP POST 요청을 재전송하지않고, 서버 응답을 안전하게 재요청한다.
쉽게 설명을 하자면, 아래 두 그림을 보면 명확하게 알 수 있다.

①망 환경에서 사용자 간 또는 컴퓨터 간의 대화를 위한 논리적 연결.
②프로세스들 사이에서 통신을 하기 위해 메시지 교환을 통해 서로를 인식한 이후부터 통신을 마칠 때까지의 기간.