서블릿 생명주기와 API
언제 서블릿 클래스를 로딩하는가?
서블릿의 생성자는 언제 호출되는가?
얼마나 올랫동안 서블릿은 살아있는가?
서블릿은 언제 자원을 초기화하는가?
또 사용한 자원은 언제 꺠끗이 청소 하는가?
서블릿의 인생은 사실 매우 간단하다.
왜냐하면 서블릿은 오직 하나의 중요한 상태를 가지기 떄문인데, 바로 초기화(initialized)를 말한다.
서블릿이 초기화 되지 않았다는 말은, 초기화되는중(생성자를 실행하거나 init()메소드를실행하거나)이거나
아니면 소멸되는 중(destroy() 메소드를 실행)이거나, 그것도 아니면 존재하지 않음 (does not exist) 중 하나이다.
당신이 작성한 서블릿은 생명주기 메서드를 상속 받아야하는데
서블릿 API를 살펴보면
Servlet 인터페이스에선 service(), init(), destroy() 이 세개가 생명주기(라이프사이클) 메소드이다.
GenericServlet 클래스는 추상클래스이다. 필요한 대부분의 서블릿 메소드를 구현하였으며, 여기에는 Servlet 인터페이스에 정의된 것도있다. 이클래스를 상속받아 클래스를 생성할 일은 거의 없지만 대부분 서블릿의 '서블릿 행위' 라고하는 것들은 바로 이클래스로부터 나왔다는 것을 기억하자.
HttpServlet 클래스 역시 추상클래스이다. HTTP적인 측면을 반영하기 위해 service()메소드를 재정이한것이다. 즉 service() 메소드는 오로지 HTTP request와 HTTP response만 받아들이고 다른 어떤 서블릿 Request 와 response는 받지않는다.
서블릿 일생에 있어 3번의 중요한 순간들
1. init()
컨테이너는 서블릿 인스턴스를 생성한 다음 init() 메소드를 호출한다. 이메소드는 service()메소드전에 실행되어야 한다.
클라이언트의 요청을 처리하기전에 서블릿을 초기화할 기회를 주는것이다.
초기화할 코드가 있다면 init()메소드를 재정의할수있다( 데이터베이스에대한 접속, 다른객체에 서블릿을 등록하는 등)
2. service()
최초 클라이언트의 요청을 받았을때, 컨테이너는 새로운 스레드를 생성하거나 스레드풀로부터 서블릿을 가져와서 서블릿의 service() 메소드를 호출한다
클라이언트의 HTTP 메소드(GET, POST 등)를 참조하여 doGet() / doPost() 혹은 다른 메소드를 호출할지 판단한다.
재정의는 하지않으며 doGet()/ doPost() 를 재정의하여 HttpServlet의 service()가 이를 실행하도록 한다.
3.doGet()혹은 doPost()
service() 메소드가 클라이언트의 HTTP 메소드(GET, POST등) 를 참조하여 doGet()/ doPost()를 호출한다.
여기서 doGet()/ doPost() 만 언급하는이유는 이것말고 나머지메소드는 사용할 경우가 거의없기떄문이다
이 메도드안에서 코딩작업을 하면된다.
doGet()/ doPost() 둘중 하나는 반드시 재정의해야한다.
서블릿초기화 : 객체가 서블릿이 되는 순간
서블릿의 일생은 컨테이너가 서블릿 파일을 찾아서 로딩할 떄부터 이다.(생성하는게아니다)
이작업은 컨테이너가 시작할때(예로 톰캣이 실행될때) 이루어지는데 컨테이너는 배포된 웹 애플리케이션이 어떤것이
있는지 체크하고 관련 서블릿 클래스 파일들을 검색한다.
첫번째 단계가 클래스를 찾는것인 셈이다.
클래스를 로딩하는것은 두번째 단계이다. 이작업은 컨테이너가 시작될떄 로딩되기도하고, 최초 클라이언트가 접슨시 로딩되기도 한다. 서블릿이 일찍 로딩하든 아니면 실행시 로딩하든 상관없이, service() 메소드는
서블릿 초기화가(서블릿 생성자 -> init()) 완전히 완료된다음 실행 된다.
생성자의 실행은 서블릿이 '존재하지 않음(dose not exist)' 상태에서 '초기화됨' 상태로 옮겨감을 의미한다
이는 클라이언트의 요청에 서비스할 준비가 되었다는 말이다. 하지만 생성자는 단지 객체를 만드는것이지 서블릿을 만드는 것이 아니다. 서블릿이 되기 위해서는 서블릿적인(servletness)을 내려 받아야 한다.
객체가 서블릿이 된다는 것은 서블릿에 고유한 권한을 가진다는것을 의미하는데 예를 들어 ServletContext를 가지고
컨테이너로부터 정보를 읽어올 수있는 능력 같은 것이다.(이는 뒤에 설명)
'공부 > Sevlets&JSP' 카테고리의 다른 글
| ServletConfig 와 ServletContext (0) | 2011.06.27 |
|---|---|
| Request, Response (0) | 2011.06.27 |
| MVC 패턴 (0) | 2011.06.24 |
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
MVC 패턴
비지니스 로직과 프리젠테이션 로직을 깔끔하게 분리하는 문제는 모든 소프트웨어 개발에서 해결해야 하는 아주 중요한문제이다.
특히 웹 애플리케이션에서 이부분은 더욱 그런데 왜냐하면 비지니스 로직 자차게 웹 인터페이스를 통해서만 접근된다고 단정할수
없기 떄문이다. 또 한가지를 들자면 소프트웨어 개발에 있어서 개발환경이나 내부구조등의 스펙은 항상 변할수 있기때문이다.
서블릿, JSP 환경에서 MVC
| 뷰(view) 프리젠테이션에 대한 책임을 지며 컨트롤러로부터 모델 정보를 읽어온다. 뷰는 또한 사용자가 입력한 정보를 컨트롤러에게 넘겨주어야한다. JSP 가 이역활을한다 컨트롤러(Controller) Request 객체에서 사용자가 입력한 정보를 뽑아내어, 모델에 대하여 어떤작업을 해야하는지 알아낸다. 모델 정보를 수정한다든지, 뷰(JSP)에게 넘겨줄 새로운 모델을 만든다든지 등과 같은작업을 한다 서블릿이 이역활을 한다 모델(Model) 비즈니스 로직이 바로 여기에 들어간다. 모델 정보(state)를 읽어오거나(getter) 수정하는(setter) 로직도 여기 포함된다 MVC패턴에서 모델은 데이터베이스와 통신하는 유일한 곳이다( 물론 DB통신만을 전담하는 객체를 따로 빼낼수도 있다) 자바 빈(java Bean)이 이역활을 한다. |
'공부 > Sevlets&JSP' 카테고리의 다른 글
| Request, Response (0) | 2011.06.27 |
|---|---|
| 서블릿 생명주기와 API (0) | 2011.06.24 |
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
| CGI 와 Servlet 의차이 (0) | 2011.06.22 |
서블릿 매핑, 배포 서술자(DD, Deployment Descriptor)
컨테이너는 클라이언트가 날린 요청에 들어 있는 URL을 가지고 어떤 서블릿인지 찾아낸다.
URL과 서블릿을 매핑하는 방법은 개발자가 이를 어떻게 설정하는가에 따라 달라진다.
서블릿은 세가지 이름을 가질수있는데
| 1. classes/registration/SignUpServlet.class 처럼 파일 위치를 알려주는 이름인 파일 위치명(file path name) 2. 서블릿 배포명 - 이이름은 내부적으로만 사용되는 이름이며, 클래스 이름이나 파일 이름과 같을 필요는 없다. 3. URL 이름 - 공공의(public) 이름으로 누구나 다알아도 되는이름이다. 이이름은 HTML 코드 안에 코딩하는 이름이며, 사용자가 클릭해서 서블릿을 호출할 때 사용하는 이름이다. 이 URL 이름이 HTTP 요청 안에 포함되어 서버로 전송되는 이름이다. |
본래에 파일위치명 을 놔두고 다름이름을 만들어서 헷갈리게 하는이유는
서블릿 이름을 다른 이름으로 매핑하면, 애플리케이션의 유연성, 보안성이 좋아지기 떄문이다.
가령 JSP나 HTML 안에 서블릿의 실제 경로와 파일 이름을 하드 코딩한다고 해보자
만약 그서블릿을 담고있는 디렉토리 구조를 바꿔야 하는 상황이 벌어졌다면, 개발자는 파일이란 파일은 다 검색해서 하드코딩된 부분을 찾아 수정해야 하는 번거러움이 있다.
하지만 DD에 매핑을 하게되면 실제 파일명을 하드코딩하는 것이 아니라 DD에 매핑된 URL 이름만 명시 해놓기 떄문에
디렉토리 구조가 변경되었다하더라도 파일은 수정할필요없이 DD만 수정하면 되는 것이다.
보안문제를 보면 클라이언트가 파일 위치명을 알게된다면, 실제 경로를 알수 있다는 말인데 이는 직접 브라우저 주소란에 이정보를 입력하여 접근 할수 있다는 것이다. 클라이언트가 여러분의 서버 디렉토리 구조랑 파일이름들을 모두 알수있다는 뜻이며 여러분이 설정한 방식으로 폼이나 페이지에 접근하지 않고, 클라이언트가 직접 접근하게 되기때문에 보안상 문제가 발생할수있는것이다.
배포 서술자(DD, Deployment Descriptor)에에서
URL을 서블릿에 매핑하기
웹컨테이너도 서블릿을 배포하려면, 배포서술자(이하 DD) 라는 XML 파일을 먼저 만들어야 한다(있다면 수정하면 된다).
DD 파일에는 서블릿과 JSP를 어떻게 실행하느냐에 관한 많은 정보들이 들어 있는데 우선 URL과 서블릿 매핑에 대해 알아보자.
매핑을 하려면 두 가지 작업을 해야 하는데, 먼저 URL 이름을 내부에서만 사용하는 이름으로 매핑하고, 그다음 내부 이름을 실제 클래스 이름으로 매핑하면 작업 끝이다.
URL 매핑을 위한 두 가지 항목
1. <servlet>
내부에서만 사용하는 이름과 완전한(패키지 이름까지 포함하여) 클래스명과 서로 매핑한다.
2. <servlet-mapping>
내부에서 사용하는 이름과 URL 이름을 서로 매핑한다.
DD형식을 보면
<web-app ...>
<servlet>
<servlet-name>Internal name 1</servlet-name>
<servlet-class>foo.Servlet1</servlet-class>
</servlet>
<servlet>
<servlet-name>Internal name 2</servlet-name>
<servlet-class>foo.Servlet2</servlet-class>
</servlet>
..............................................
.............................................
<servlet-mapping>
<servlet-name>Internal name 1</servlet-name>
<url-pattern>/public1</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Inrernal name 2</servlet-name>
<url-pattern>/public2</url-pattern>
</servlet-mapping>
</web-app>
각각을 살펴보면
클라이언트로부터 요청이 들어오면 컨테이너는 DD에서 위에 순서대로(1->2->3->4) 서블릿을 검색한다
/public2 라는 URL 이름으로 요청이들어왔다면 DD내에서 매핑된이름인 Internal name2로 실제 서블릿 명(실제위치)을 찾게 되는 것이다.
URL명과 실제 서블릿 명을 서로 매핑하는 일 말고도 DD에서 할수 있는 일은 많다.
보안역활(Security Role) 설정, 오류페이지 설정, 항목 라이브러리, 초기화 구성 및 관련 정보 설정 등 무척 많다.
그리고 서버가 J2EE의 모든 규격을 구현한 서버라면 EJB 선언 및 접근에 관련된 내용도 여기서 설정한다.
DD의 이점
- 이미 테스트된 소스 코드의 대한 수정 최소화
- 소스 코드가 없더라도, 애플리케이션을 목적에 맞게 수정할 수 있다.
- 코드 변경이나 컴파일을 다시 하지 않아도 서버 자원(예를 들면 데이터베이스 연결)을 바꿀수 있다.
- 접근 제어 목록(ACL, Access Control List), 보안 역활(Security Role)과 같은 보안에 관련된 업무도 쉽게 관리할 수 있다.
-프로그래머가 아닌 사람이 웹 애플리케이션을 배포하고 설정을 수정하는데 수월하다.
'공부 > Sevlets&JSP' 카테고리의 다른 글
| 서블릿 생명주기와 API (0) | 2011.06.24 |
|---|---|
| MVC 패턴 (0) | 2011.06.24 |
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
| CGI 와 Servlet 의차이 (0) | 2011.06.22 |
| CGI(Common Gateway Interface) (0) | 2011.06.22 |
서블릿 컨테이너(Servlet Container)
그러면 서블렛은 doPost() 또는 doGet()메서드를 호출하며 여기에 두메소드에 인자로들어가는
HTTP Request 와 HTTP Resopnse 객체를 누군가 생성해서 서블릿으로 넘겨줘야한다.
또한 서블릿이 생성, 소멸하는 시점에서 자원 관리도해야하는데 이것들을 하는것이 바로 컨테이너이다.
웹서버가 사용자로부터 서블릿에 대한 요청을 받으면 , 서블릿을 바로호출하는 것이 아니라, 서블릿을 관리하고 있는 컨테이너에게 이 요청을 넘깁니다. 여기서 컨테이너란 물론 서블릿이 배포(deploy)된 컨테이너를 말한다. 요청을 넘겨받은 컨테이너는 HTTP Request와 HTTP Response 객체를 만들어, 이를 인자로 서블릿 doPost()나 doGet() 메소드중 하나를 호출한다.
컨테이너가 하는일
| 통신(Communication) 지원 -컨테이너는 서블릿과 웹서버가 서로 통신할 수 있는 손쉬운 방법을 제공한다. 다시말해, 서버와 대화하기위해 개발자가 직접 ServerSocket을 만들고, 특정 포트에 리스닝하고, 연결요청이 들어오면 스트림을 생성하는 등 이런 복잡한 일련의 일을 할필요가 없다는 것이다. 컨테이너는 이런 통신 기능을 API로 제공하고 있다. 따라서 웹 서버와 서블릿이 서로 통신하기위한 통로인 통신 API에 대해 개발자가 고민할 필요가없다. 생명주기(LifeCycle) 관리 -개발자 관점에서 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메서드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 호출하는 작업을 컨테이너가 한다. 또한 서블릿이 생명을 다한 순간에는 적절하게 가비지 컬렉션을 진행한다. 즉 서블릿의 탄생과 죽음을 관리한다. 멀티스레딩 지원 -컨테이너는 요청이 들어올 떄마다 새로운 자바 스레드를 하나 만듭니다. 클라이언트의 요청에 따라 적절한 HTTP 서비스 메소드를 실행하면 그걸로 스레딩 작업은 끝이 난다(스레드가 죽는다.). 스레드 안전성에 대해선 서버가 다중 요청에 대한 스레드 생성 및 운영에 대해서 알아서 해주니 걱정 할 필요없다. 선언적인 보안관리 -컨테이너를 사용하면 보안에 관련된 내용을 서블릿 또는 자바클래스 코드 안에 하드코딩 할 필요가 없다. 컨테이너가 있는 환경이라면 보안관리는 XML 배포 서술자에 기록하면되는데 이말은 보안에 대해 뭔가 수정할 일이 생기더라도 자바 소스 코드를 수정하여 다시 컴파일하지 않아도 보안관리가 가능하다는 말이다. JSP 지원 |
컨테이너가 요청에 응답하는 것을 그림으로 보면
'공부 > Sevlets&JSP' 카테고리의 다른 글
| MVC 패턴 (0) | 2011.06.24 |
|---|---|
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
| CGI 와 Servlet 의차이 (0) | 2011.06.22 |
| CGI(Common Gateway Interface) (0) | 2011.06.22 |
| 웹 서버에 응답과 요청 (0) | 2011.06.22 |
CGI 와 Servlet 의차이
그리고, 서블릿의 모태는 CGI라고 할수 있다.
기존의 HTML은 정적인 페이지만을 서비스 할수 있었지만,
CGI는 요청페이지내에 서버용 프로그램을 삽입하여,
서버에서 처리한 결과를 서비스 할수 있다.
CGI는 사용자의 요청이 있을때마다 프로세스를 하나씩
생성한다. 이로인한 단점은 서버의 부하인데
이러한 단점을 극복한 한단계 업그레이드된 버전이
바로 servlet과 jsp이다.
servlet과 jsp는 인-프로세스방식을 사용하는데,
이는 메모리에 라이브러리를 로드시킨뒤 한번 로드된 라이브러리
(프로세스 라고도 함)를 여러 요청에 이용할수 있는 방식이다.
(서버에 부하가 작아짐)
또 하나의 차이점은 servlet과 jsp는 자바의 모든 성질을 그대로
가지고 있기 때문에 스레드 처리도 가능하다는 것이다.
| 즉 GI가 클라이언트 프로세스로 처리하는데 반해 서블릿은 클라이언트를 쓰레드로 처리한다. 그래서 많은 클라이언트의 요구를 효과적으로 처리할 수 있다. 서블릿 객체는 쓰레드가 여러 개 돌아가면서 처리하기 때문에 서블릿 메소드들은 반드시 멀티쓰레드에 대한 고려를 해야한다. |
'공부 > Sevlets&JSP' 카테고리의 다른 글
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
|---|---|
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
| CGI(Common Gateway Interface) (0) | 2011.06.22 |
| 웹 서버에 응답과 요청 (0) | 2011.06.22 |
| Head First Servlets&JSP (0) | 2011.06.08 |
CGI(Common Gateway Interface)
웹 서버는 정적인 페이지 서비스만 제공한다.
정적인페이지란 디렉토리에 있는파일 그대로를 말하는데 서버는 단지 클라이언트가 요청한 파일을 찾아서 그대로 클라이언트에게 넘겨줄 뿐이다. 즉 모든 클라이언트가 동일한 결과를 본다는 뜻이다.
웹서버 혼자서 할 수 없는 두가지
1. 동적인 컨텐츠 생성
앞에서 말했듯이 웹 서버는 단지 정적인 페이지만을 제공할 뿐이다. 그러나 도우미(Helper)애플리케이션이 웹 서버와 협력해서
동적이고, 실시간으로 작성한 페이지를 제공할 수 있다. 예로 이미지 디렉토리에서 임의로 그림을 하나 골라 제공하는 페이지 같은 것을 말한다
2. 서버상에 데이터 저장하기
사용자가 폼에 데이터를 입력하고 전송 버튼을 눌렀을경우 웹서버는 혼자 파일이나 데이터베이스에 데이터를 저장할수 없다.
이 경우 웹 서버는 자신을 도와줄 애플리케이션에게 SOS요청을 하는데 웹서버는 파라미터를 애플리케이션에 넘겨주고 응답하도록 부탁한다.
이런 도우미 애플리케이션을 CGI(Common Gateway Interface) 라고 부르며 대부분의 CGI 프로그램은 펄(Perl) 스크립트로 작성한다. 물론 펄 말고도 C, 파이썬, PHP 같은 언어도 있다.
CGI를 가지고 현재시간(동적)을 클라이언트에게 제공하는 것을 살펴보면
1. 사용자는 정적인 페이지가 아닌 CGI 프로그램에 대한 URL을 클릭한다.
2. 웹 서버는 들어온 요청이 도우미 프로그램을 호출하는 것임을 간파하고는, 해당 프로그램을 실행한다. 물론 GET 또는 POST로 넘어온 파라미터를 그대로 넘겨준다
3. 도우미 프로그램은 현재 시간이 들어간 페이지를 만들어(동적으로) 서버에 HTML 형식으로 넘겨준다. 이시점에서 웹 서버가 도우미 프로그램으로부터 받는 페이지는 정적인 페이지이다.
4. 도우미 프로그램은 페이지를 장사를 끝내고 셔터 문을 내린다. 클라이언트는 정적인 페이지가 된 HTML 페이지를 서버로부터 받는다.
'공부 > Sevlets&JSP' 카테고리의 다른 글
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
|---|---|
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
| CGI 와 Servlet 의차이 (0) | 2011.06.22 |
| 웹 서버에 응답과 요청 (0) | 2011.06.22 |
| Head First Servlets&JSP (0) | 2011.06.08 |
웹 서버에 응답과 요청
웹 서버는 클라이언트로부터 요청을 받아, 요청한 것을 넘겨주는 일을 한다.
즉, 사용자가 웹 브라우저로, 서버에 있는 자원(resource)을 요청하면 서버는 사용자가 요청한 것을 넘겨주는 것(응답)으로 작업이 완료된다. 잠깐 웹클라이언트 에대해서 설명하자면
| - 웹 클라이언트는 사용자가 서버에 요청을 보낼 수 있는 기능을 제공한다. 서버에 요청을보내고 서버가 보내온 요청결과를 화면에 출력하는 일도 클라이언트의 역활 -클라이언트라는 용어는 사용자, 브라우저(응용프로그램) 을 뜻하기도하는데 브라우저는 서버랑 통신하는 넷스케이프나 모질라와 같은 소프트웨어를 말합니다. 브라우저의 주된역활을 HTML 코드를 읽어서(파싱), 화면에 보이는 것이다. |
HTTP(HyperText Transfer)와
HTML(Hypertext Markup Language)
클라이언트로부터 요청을 받고나면, 서버는 브라우저에게 보낼 컨텐츠타입이 무엇인지 알려준다. 브라우저는 이것을보고 어떻게 화면에 출력할지 준비한다. 서버가 보내는 것은 HTML이라는 명령문으로, 이는 브라우저가 화면에 컨텐츠를 어떻게 출력할지에 대한 명령(instruction)으로 이루어져 있다. 그러므로 웹 브라우저는 HTML을 이해하고 있다.
웹상에서 일어나는 클라이언트와 서버간 대화는 거의 대부분 HTTP 프로토콜로 이루어진다.
HTTP프로토콜은 요청과 응답으로 이루어진 아주 단순한구조로 클라이언트가 HTTP요청을 보내면, 서버는 HTTP 응답으로 답한다.
| HTML-브라우저가 서버로부터 받은 요청결과를 화면에 표시할 방법을 지정해준다. HTTP-웹 상에서 클라이언트와 서버가 서로 대화하기 위한 규약, 언어를 지칭 서버는 클라이언트로 HTML을 전송하기 위해 HTTP를 사용한다!! |
HTTP 프로토콜을 살펴보면
| HTTP는 TCP/IP 위에서 돌아간다. TCP/IP에서 TCP는 한쪽 노드에서 다른 쪽 노드로 파일을 보내는 역활을 하며 IP는 한 호스트에서 목적지 호스트까지 패킷을 옮기고 이동하기 위한 기반(베이스)프로토콜 이라고할수 있다. 하지만 HTTP는 TCP/IP를 기반으로하여 웹에서만 사용하는 프로토콜이며, TCP/IP를 이용해서 한 지점에서 다른 지점으로 요청과 응답을 전송한다. 즉, HTTP구조는 요청-응답의 끊임없는 주고 받음 이라고 말할수 있다.(클라이언트는 요청하고 서버는 여기에 응답한다) |
HTML은 HTTP 응답안에 들어있다. HTTP응답에는 HTTP뿐만아니라 헤더정보라는것도 들어있는데 브라우저는 헤더정보로 컨텐츠를 어떻게 화면에 보여줄지에 대한 힌트를 얻는다.
요청과응답(HTTP 메소드)
HTTP 프로토콜에는 메소드가 여러가지 있는데, 그중 가장 많이 사용하는 것은 GET과 POST이다.
GET은 HTTP 메소드 중 가장 단순하며 단순히 서버에게 자원을 요청한다. 열기서 말하는 자원이란 HTML페이지나 JPEG 이미지, PDF문서 등을 말한다. GET의 핵심은 서버로부터 뭔가를 돌려(get back) 받는다 라는 것이다.
POST는 좀더 강력하다. POST는 서버에게 자원을 요청할때 필요한 정보를 함께 넘겨준다.
하지만 GET 방식역시 많지는 않지만 데이터를 보낼수있는데!! 다음과 같은이유로 GET보다는 POST를 사용해야하는 경우가있다.
| - GET으로 보낼수 있는 글자수는 제한이 있다. - GET의 데이터 전송방식은 브라우저 주소란에 기입하는 URL 뒤에 붙이는 식으로 중요한 데이터든 아니든 간에 화면에 노출이된다. 그러므로 패스워드처럼 민감한 데이터는 GET으로 보내지 않는것이 현명할 것이다. ex) http://apis.daum.net/blog/category/list.do?blogName=finerss URL /웹서버상 자원에대한경로 ? 는 경로와 파라미터를구분하는 구분자이다. 한마디로말해 URL자체가 하나의 긴 문자열(String)이라는 것이다 - 위에 두가지 이유로 GET 으로 전송하는 URL은 즐겨찾기에 등록할 수 있지만, POST는 대부분 그렇지 못하다. 브라우저에 따라 폼의 서밋(submit) 결과를 즐겨찾기에 등록할수도, 못할 수도 있다. |
<GET방식>
| 요청 라인 (HTTP메소드와 웹서버상 자원에대한경로, 그리고 파라메터가 URL바로다음 ?문자를 구분자로 기술하며 개별 파라메터는 &값으로 구분,브라우저가 요청한 프로토콜버전 을 담고있다) |
| 요청 헤더 (Header) |
<POST방식>
| 요청라인 (HTTP메소드와 웹서버상 자원에대한경로, 그리고 파라메터가 URL바로다음 ?문자를 구분자로 기술하며 개별 파라메터는 &값으로 구분,브라우저가 요청한 프로토콜버전 을 담고있다) |
| 요청 헤더 (Header) |
| 메시지몸체 (파라메터는 여기서부터 기술. GET에서는 요청라인에 표기를 했기떄문에 길이에 제한이 있었지만 POST에서는 제한이 없습니다.) |
위와 같은 방식으로 GET/POST 는 서버에 요청한다.
지금까지 서버로 보내는 요청을 알아보았고 이제 반대로 서버가 클라이언트로 보내는 응답에 대해 알아보자.
HTTP응답은 간단히 헤더와 몸체로 구성되어있다. 헤더에는 사용된 프로토콜이 뭔지, 보내준 요청이 성공했는지, 몸체에 포함된 컨텐츠의 종류는 무엇인지 등이 있고, 몸체에는 HTML과 같은 컨텐츠가 들어있다. 브라우저는 바로 이정보를 화면에 출력한다.
| HTTP 응답 헤더 |
| 컨텐츠 |
헤더에 Content-type 의값이 있는데 보통 MIME타입이라고 부른다. MIME타입이란 브라우저에게 "지금 서버가 이러 이러한 데이터를 보내려고하니 화면에 보여줄 준비를하시오" 라는 정보인데 서버가 보내주는 MIME타입은 클라이언트가 보낸 요청의 헤더중 Accept란에 기술되어있는 값과 관련이있다. (요청헤더의 Accept 설명은 행복한아빠님의블로그 에 잘설명되어있다)
URL(Uniform Resource Locators)
| (1)http://(2)www.wickedlysmart.com(3):80(4)/beeradvice/select/(5)beer1.html |
(1): 프로토콜(Protocol)-서버와 대화하기위하여 사용하는 커뮤니케이션프로토콜.
(2): 서버(Server)-인터넷 상에 이름 이이름은 ip주소에 매핑된다.
(3): 포트(Port)- 포트는 URL에서 옵션이다 어떤포트번호로 어떤서버 애플리케이션이 서비스되는지알수있다 80이 디폴트
(4): 서버에서 자원의 위치
(5): 자원- 요청된 컨텐츠 이름. 자원에는 HTML,Servlet,dlalwl,PDF,음악 등 서버가 제공하는 모든것이다포함되어있다. 자원을 명시하지않으면 많은 웹 서버들은 index.html을 기본으로 넘겨준다.
*숨겨진 부분 : 질이어(쿼리 스트링): GET방식이라면, 이데이터는 URL의 뒷부분에 파라미터로 죽 붙여서 날아온다 ?마크를 필두로 파라미터 이름과 파라미터값을 한 쌍으로 해서, 여러 쌍일경우 &로 구분해서 날아온다
'공부 > Sevlets&JSP' 카테고리의 다른 글
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
|---|---|
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
| CGI 와 Servlet 의차이 (0) | 2011.06.22 |
| CGI(Common Gateway Interface) (0) | 2011.06.22 |
| Head First Servlets&JSP (0) | 2011.06.08 |
Head First Servlets&JSP
설명들과 예제들을 간추려서 내가 다시봐도 알아볼수있도록 작성할것이다.!
start~!
'공부 > Sevlets&JSP' 카테고리의 다른 글
| 서블릿 매핑, 배포 서술자(DD, Deployment Descriptor) (0) | 2011.06.23 |
|---|---|
| 서블릿 컨테이너(Servlet Container) (1) | 2011.06.22 |
| CGI 와 Servlet 의차이 (0) | 2011.06.22 |
| CGI(Common Gateway Interface) (0) | 2011.06.22 |
| 웹 서버에 응답과 요청 (0) | 2011.06.22 |
