서블릿(Servlet) 과 HTTP Request/Response Header

Servlet(서블릿)

웹프로그래밍에서 클라이언트의 요청을 처리하고 그 결과를 다시 클라이언트에게전송하는 Servlet 클래스의 구현 규칙을 지킨 자바 프로그래밍 기술.

• Servlet 특징

• 클라이언트의 요청에 대해 동적으로 작동하는 웹 어플리케이션 컴포넌트

• html을 사용하여 요청에 응답한다.

• Java Thread를 이용하여 동작한다.

• MVC 패턴에서 Controller로 이용된다.

• HTTP 프로토콜 서비스를 지원하는 javax.servlet.http.HttpServlet 클래스를상속받는다. UDP보다 속도가 느리다.

• HTML 변경 시 Servlet을 재컴파일해야 하는 단점이 있다.

• 서블릿 동작방식

1. 사용자(클라이언트)가 URL을 클릭하여 HTTP Request를 Servlet Conatiner로전송한다.

2. HTTP Request를 전송받는 Servlet Container는 HttpServletRequest,HttpServletResponse 두 객체를 생성한다.

3. Web.xml은 사용자가 요청한 URL을 분석하여 어느 서블릿에 대해 요청한 것인지확인한다.

4. 해당 서블릿에서 service메소드를 호출한 후 클라이언트의 POST,GET여부에 따라doGET() 또는 doPost()를 호출한다.

5. doGet() , doPost() 메소드는 동적 페이지를 생성한 후 HttpServletResponse객체에 응답을 보낸다.

6. 응답이 끝나면 HttpServletRequest, HttpServletResponse 두 객체를 소멸 시킨다.

HTTP Request/Response Header (Mesaage)

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식이다. 메시지에는 두가지 타입이 존재하는데: request는 클라이언트에 의해 전달되어 서버로부터클라이언트 요청에 의해 동작을 일으키는 것이고, response는 그에 대한 서버의회신이다.

• Request 메시지 구조

• 요청 라인 : GET / HTTP/1.1

• 요청 메소드 : GET, POST, PUT, DELETE

• 요청 URL

• HTTP 버전

• 요청 헤더 : 키-값 방식으로 들어감

• Accept : 클라이언트가 받을 수 있는 컨텐츠

• Cookie : 쿠키

• Content-Type : 메세지 바디 종류

• Content-Length : 메세지 바디 길이

• If-Modified-Since : 특정 날짜 이후에 변경됐을 때만

• 요청 바디(엔티티)

참조문서 : https://www.w3.org/Protocols/rfc1341/4_Content-Type.htm

1.form 형태 : URLEncoded 방식

• application/x-www-form-urlencoded

• 메세지 바디 : 쿼리 문자열

json 형태

• application/json

멀티파트 형태 : 이진파일 넘길 때 사용, 하나의 메세지 바디에 파트를 나눠서 작성

• boundary는 파트 구분자

• multipart/form-data: boundary=frontier

-Request 메시지형태

• Response 메시지 구조

• 응답 라인

• 버전

• 상태 코드

• 상태 메세지 : HTTP/1.1 200 OK

• 응답 헤더

• Content-Type : 바디 데이터의 타입

• Content-Length : 바디 데이터 크기

• Set-Cookie : 쿠키 설정

• ETag : 엔티티 태그

• 응답 바디 : HTML, JSON, Octet Stream 등이 있다.

상태 코드

• 1xx : 정보

• 2xx : 성공

• 200 : OK. 요청 성공

• 201 : Created. 생성 요청 성공

• 202 : Accepted. 요청 수락(처리 보장X)

• 204 : 성공했으나 돌려줄게 없음

• 3xx : 리다이렉션

• 300 : Multiple choices. 여러 리소스에 대한 요청 결과 목록

• 301,302,303 : Redirect. 리소스 위치가 변경된 상태

• 304 : Not Modified. 리소스가 수정되지 않았음

• 4xx : 클라이언트 오류

• 400 : Bad Request. 요청 오류

• 401 : Unauthorized. 권한없음

• 403 : Forbidden. 요청 거부

• 404 : Not Found. 리소스가 없는 상태

• 5xx : 서버 오류

• 500 : Internal Server Error. 서버가 요청을 처리 못함

• 501 : Not Implemented. 서버가 지원하지 않는 요청

• 503 : Service Unavailable. 과부하 등으로 당장 서비스가 불가능한 상태

Response 메시지형태

Request와 Response 메세지 형태의 차이를 보여주는 그림

• GET과 POST의 방식의 비교 및 차이

사용자(클라이언트)와 서버 간의 요청에 사용되는 요청방식중 GET, HEAD, POST, PUT,DELETE, OPTIONS, TRACE, CONNECT 이 있다. 하지만, 보안상의 이유로 웹서버가 GET,POST 2개 만을 허용하는 경우가 대부분이다.

GET방식

Get이라는 단어는 가져오다라는 뜻을 가진 단어이다. 우리가 필요한 정보를 얻기 위해도서관에서 책을 빌려 가져오는(GET)상황과 유사하게 GET은 어떠한 정보를 가져와서조회하기 위해서 사용되는 방식이다.

• URL에 변수(데이터)를 포함시켜 요청한다.

• 데이터를 Header(헤더)에 포함하여 전송한다.

• URL에 데이터가 노출되어 보안에 취약하다.

• 전송하는 길이에 제한이 있다.

• 캐싱할 수 있다.

GET방식은 URL형식으로 웹서버 측 데이터를 요청한다. URL을 통해 정보를 노출하기 때문에 주로 포털사이트의 검색어 전달, 게시판 페이지 번호 등 위험도와 관계없는 부분에서 많이 사용된다.

GET 방식은 간단한 데이터를 URL에 넣도록 설계된 방식으로 데이터를 보내는 양에 한계가 있다 즉, URL의 길이가 정해져있기 때문에, 많은 양의 정보를 전달할 수 없으며 URL형식에 맞지 않는 파라미터 이름이나 값은 인코딩되어 전달해야 한다

특별히 전송하는 데이터가 없으므로 GET방식에서 바디는 보통 빈 상태로 전송이 되며, 헤더의 내용 중 Body의 데이터를 설명하는 Content-type 헤더필드도 들어가지 않는다.

예를 들어 우리가 어떤 페이지에서 로그인을 하는 상황이라고 하고, id와 pw를 입력한 후 엔터를 눌러 요청하는 상황이고 www.mangkyu.com/login?id=mang&pw=kyu 와 같은 페이지가 있다면 여기서 GET방식은 ?마크를 통해 URL의 끝을 알리고, id라는 키(Key)에 대해선 mang이라는 값(Value)를, pw라는 키(Key)에 대해서는 kyu라는값(Value)를 전송하는 것을 볼 수 있다.

GET방식의 Request 전송예->파라미터가 URL에 포함되어 전송되는 것을 볼수 있다.

POST방식을 사용하여 데이터를 노출시키는 경우는 개인정보가 포함되지 않는 상황에서 캐싱을 하여 속도를 높이거나 즐겨찾기를 편리하기 위해 사용되는 경우가 많다.

우리가 어떤 물건 a에 대해서 즐겨찾기를 추가하면 그 물건의 이름이 A라는 정보를 URL에 추가하여 즐겨찾기를 생성할 수 있는 것이다.

Q) Cashing(캐싱)이란?

캐싱이란 한번 접근 후, 또 요청할시 빠르게 접근하기 위해 레지스터에 데이터를 저장시켜 놓는 것이다.

POST방식

POST라는 단어는 부치다, 제출하다라는 뜻을 가지고 있다. 예를 들어 우리가 어디에 서류를 제출하는 것은 우리에 대한 정보를 제출하여(POST) 추가하기 위함이다 이러한 상황과 유사하게 POST 방식은 데이터를 서버로 제출하여 추가 또는 수정하기 위해서 데이터를 전송하는 방식이다.

• URL에 변수(데이터)를 노출하지 않고 요청한다.

• 데이터를 Body(바디)에 포함시킨다.

• URL에 데이터가 노출되지 않아서 기본 보안은 되어있다.

• 전송하는 길이에 제한이 없다.

• 캐싱할 수 없다.

POST 방식은 클라이언트에서 서버로 데이터를 요청할 때 요청데이터를 HTTP Body에 담아 웹서버로 전송한다. 따라서 헤더필드 중 Body의 데이터를 설명하는 Content-Type이라는 헤더 필드가 들어가고 어떠한 데이터 타입인지를 명시해주어야 한다.

HTML Form을 이용하여 정보 전달 하기 때문에 회원아이디, 비밀번호, 개인정보 등 개인 정보 전송(정보를 보호해야할떼)에 많이 사용된다.

데이터를 Body에 포함시키는 이점 때문에 메세지 길이의 제한은 없지만 최대 요청을 받는 시간인 Time Out이 존재하므로POST 방식으로는 웹 서버의 응답 지연 시간만큼 전송 가능하다.

실제로 POST 방식은 URL에 데이터가 노출되지 않으므로 즐겨찾기나 캐싱이 불가능하지만 쿼리스트링(문자열)데이터 뿐만 아니라, 라디오 버튼, 텍스트 박스와 같은 객체들의 값도 전송이 가능하다.

**POST방식의 Request 전송예->파라미터가 헤더 BODY 포함되어 전송되는 것을 볼수 있다.

3. Servlet Container(서블릿 컨테이너)

간단하게 서블릿을 관리해주는 컨테이너이다.

우리가 서버에 서블릿을 만들었다고 해서 스스로 작동하는 것이 아니고, 서블릿을 관리해주는 것이 필요한데 그러한 역할을 하는 것이 바로 서블릿 컨테이너 이다. 예를 들어, 서블릿이 어떠한 역할을 수행하는 정의서라고 보면, 서블릿 컨테이너는 그 정의서를 보고 수행한다고 볼 수 있다.

서블릿 컨테이너는 클라이언트의 요청(Request)을 받아주고 응답(Response)할 수 있게, 웹서버와 소켓을 만들어 통신하며 대표적인 예로 톰캣(Tomcat)이 있다.. 톰캣은 실제로 웹서버와 통신하여 JSP(자바 서버 페이지)와 Servlet이 작동하는 환경을 제공해준다

Servlet Container 역할

• 웹서버와의 통신 지원

서블릿 컨테이너는 서블릿과 웹서버가 손쉽게 통신할 수 있게 해준다. 일반적으로 우리는 소켓을 만들고 listen, accept 등을 해야하지만 서블릿 컨테이너는 이러한 기능을 API로 제공하여 복잡한 과정을 생략할 수 있게 해준다.

그래서 개발자가 서블릿에 구현해야 할 비지니스 로직에 대해서만 초점을 두게끔 도와준다.

• 서블릿 생명주기(Life Cycle) 관리 

서블릿 컨테이너는 서블릿의 탄생과 죽음을 관리한다. 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메소드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 호출한다. 

또한 서블릿이 생명을 다 한 순간에는 적절하게 Garbage Collection(가비지 컬렉션)을 진행하여 편의를 제공한다.

• 멀티쓰레드 지원 및 관리 

서블릿 컨테이너는 요청이 올 때 마다 세로운 자바 쓰레드를 하나 생성하는데, HTTP 서비스 메소드를 실행하고 나면, 쓰레드는 자동으로 죽게된다. 원래는 쓰레드를 관리해야 하지만 서버가 다중 쓰레드를 생성 및 운영해주니 쓰레드의 안정성에 대해서 걱정하지 않아도 된다.

• 선언적인 보안 관리 

서블릿 컨테이너를 사용하면 개발자는 보안에 관련된 내용을 서블릿 또는 자바 클래스에 구현해 놓지 않아도 된다. 일반적으로 보안관리는 XML 배포 서술자에 다가 기록하므로, 보안에 대해 수정할 일이 생겨도 자바 소스 코드를  수정하여 다시 컴파일 하지 않아도 보안관리가 가능하다.

1.클라이언트의 요청이 들어오면 컨테이너는 해당 서블릿이 메모리에 있는지 확인하고, 없을 경우 init()메소드를 호출하여 적재한다. init()메소드는 처음 한번만 실행되기 때문에, 서블릿의 쓰레드에서 공통적으로 사용해야하는 것이 있다면 오버라이딩하여 구현하면 된다. 실행 중 서블릿이 변경될 경우, 기존 서블릿을 파괴하고 init()을 통해 새로운 내용을 다시 메모리에 적재한다.

2.init()이 호출된 후 클라이언트의 요청에 따라서 service()메소드를 통해 요청에 대한 응답이 doGet()가 doPost()로 분기된다. 이때 서블릿 컨테이너가 클라이언트의 요청이 오면 가장 먼저 처리하는 과정으로 생성된 HttpServletRequest, HttpServletResponse에 의해 request와 response객체가 제공된다.

3.컨테이너가 서블릿에 종료 요청을 하면 destroy()메소드가 호출되는데 마찬가지로 한번만 실행되며, 종료시에 처리해야하는 작업들은 destroy()메소드를 오버라이딩하여 구현하면 된다.

서블릿을 통한 helloworld 출력

소스코드

Helloworld출력

서블릿 매핑

접속 경로가 너무 긴 경우 짧은 이름으로 사용 할 수 있다.

보안에 노출되어 있는 경로를 다른 이름으로 간단하게 맵핑할 수 있다.

어노테이션을 이용하는 방법과, web.xml을 이용한 방법이 있다.

• 어노테이션을 이용한 서블릿 매핑

어노테이션을 이용하여 직접 url을 지정할수 있다.

어노테이션에 이용하여 helloworld URL에 서블릿을 매핑시켰다.

• Web.xml 을 이용한 서블릿 매핑

어노테이션으로 URL을 지정하는 것외에도 web.xml파일을 이용하여 URL을 매핑할 수 있다.

Web.xml을 이용한 이점은 프로젝트가 급격히 커지면서 일일히 어노테이션을 찾아가서 관리하기 어려울때, 하나에 web.xml 파일에서 관리하기 편한 이점이 있다

WebContent/WEB-INF아래에 web.xml 파일을 작성한다.

톰캣이 설치된 디렉토리에도 web.xml 파일이 있지만, 따로 설정하여 매핑하는것이 관리하기 편하고 가독성이 좋다.

Web.xml 파일

<servlet> ~~~~~</servlet> 태그를 사용하여 사용할 서블릿 파일과 서블릿에 대한 이름을 설정한다.

<servlet-mapping>~~~~~~</servlet-mapping> 태그에는 미리 지정한 서블릿을 매핑할 URL 주소와 함께 매핑한다.

어노테이션 부분을 주석처리한다.

어노테이션부분을 주석처리하더라도, Web.xml파일에 매핑할 URL을 지정했기 때문에(/hello URL로 매핑) 매핑한 URL을 찾아간다.

서블릿 메소드

서블릿의 실행동작 과정은 사실 매우 간단하다 왜냐하면 서블릿은 오직 하나의 중요한 상태를 가지기 때문이다. 여기서 중요한 상태는 초기화(initialized)를 말한다.

Init() 메소드

서블릿 일생 중 한번만 호출된다. init() 메소드는 service() 메소드 전에 실행되어야 한다.

클라이언트의 요청을 처리하기전에 서블릿을 초기화할 기회를 주는것이다.

초기화할 코드가 있다면 init()메소드를 재정의할수있다( 데이터베이스에대한 접속, 다른객체에 서블릿을 등록하는 등

Init() 메소드안에 오버라이딩을 통해 클라이언트요청전에 작업을 할수있다.

Service() 메소드

클라이언트의 HTTP 메소드(GET, POST 등)를 참조하여 doGet() / doPost() 혹은 다른 메소드를 호출할지 판단한다.

재정의는 하지않으며 doGet()/ doPost() 를 재정의하여 HttpServlet의 service()가 이를 실행하도록 한다.(특별한 경우가 아니라면 개발자는 오버라이딩하지 않고 신경쓰지않는다)

Service 메서드는 GenericServlet 클래스에 정의되어 있고 HttpServlet 클래스는 GenericServlet 클래스를 상속한다. 따라서 HttpServlet 클래스를 상속받은 클래스는 Service 메서드를 갖게 된다. 또한 service 메서드는 doGet 또는 doPost를 실행하도록 정의되어 있다. 만약 요청 방식(GET/POST)을 알 수 없다면 doGet을 호출한다.

Service()또한 오버라이딩을 할수있으나, 잘하지 않는다

doGet()혹은 doPost()

Service() 메소드가 클라이언트의 HTTP 메소드(GET, POST등) 를 참조하여 doGet()/doPost()를 호출한다.

여기서 doGet()/ doPost() 만 언급하는이유는 이것말고 나머지메소드는 사용할 경우가 거의없기떄문이다

이 메소드안에서 개발자는 알고리즘을 구현 하면된다.

doGet()/ doPost() 둘중 하나는 반드시 재정의해야한다.

doGet()과 doPost()메소드중 하나는 반드시 오버라이딩 하여 서블릿이 어떠한 동작을 할지 명시해야 한다.

destroy() 메소드

init()메소드와 마찬가지로 한 번만 호출된다.

웹 어플리케이션의 실행이 멈출 때, 서블릿이 사용한 자원을 초기화시킬 수 있도록 이 메서드를 호출한다.

서블릿이 사용한 자원을 초기화할 코드를 넣는다.

4.서블릿 클래스 전체의 모습