서블릿 컨테이너을 위한 웹 애플리케이션 서버와 HTTP프로토콜의 이해

서블릿 컨테이너에서의 WAS와 HTTP

웹 애플리케이션 서버의 역할

• 웹 프로그램 : HTTP프로토콜로 통신하는 네트워크 프로그램의 일종
• 웹 애플리케이션 서버  : 클라이언트와 서버간의 소켓통신에 필요한 TCP/IP 연결 관리와 HTTP 프로토콜 해석 등의 네트워크 기반 작업을 추상화해 일종의 실행환경을 제공
• 원래는 Java EE 명세를 만족시키는 Java 구현체를 의미하짐나, 최근에는 개념이 일반화되면서 자바 이외의 프로그래밍 언어로 작성한 서버도 웹 애플리케이션 서버라고 부름
• 서블릿 컨테이너
• 여러 경량 프레임 워크(ex. struts, Spring 등)는 Java EE 정의 중 웹 애플리케이션 기술(JSP, 서블릿, Javaserver Faces, JSTL 등) 위에서 동작한다. 이 때 웹 애플리케이션 기술에 대한 구현체를 서블릿 컨테이너라고 부르는 것
• 대표적인 서블릿 컨테이너 : Apache Tomcat, Jetty, Grizzly 등
• Apache Tomcat : 오랫동안 서블릿 기술명세에 대한 참조 구현체였으며, 가장 잘 알려진 오픈 소스 계열의 서블릿 컨테이너
• Jetty : 실험적 시도를 과감하게 도입하는 서블릿
• Grizzly : 아파치 톰캣이 가진 Java EE 참조구현체의 역할을 새로 맡은 Glassfish.java.net의 서블릿 프레임 워크
• 서블릿 컨테이너 주요목표 : 서블릿을 동작시키는 것

HTTP프로토콜

• 웹서비스 : HTTP프로토콜로 메시지를 전송하는 시스템
• ex.클라이언트가 보낸 메시지는 HTTP 프로토콜에 실려 서블릿 컨테이너에 전송됨. 전소된 메시지를 서버측에서 재구성하려면 서블릿컨테이너는 반드시 HTTP 프로토콜 해석 기계를 구현해야함.
• HTTP 프로토콜
• 특징 : HTTP 프로토콜은 메시지의 끝이 어디인지 파악하는게 중요.
• HTTP 프로토콜 규약
• 1991년 당시 정의된 초기 HTTP프로토콜 규약 : https://www.w3.org/Protocols/HTTP/AsImplemented.html
• 현재의 HTTP 프로토콜 규약 : https://tools.ietf.org/html/rfc2616
• HTTP(Hypertext Transfer Protocol)은 말 그대로 하이퍼링크가 포함된 문서를 전송하기 위한 규약에서 시작됨
• 초기에는 HTTP에서 메시지의 끝을 행 구분자인 조합(CRLF)이라고 불리는 \r\n을 써서 구분.
• 단순 문자열 전송이상의 기능이 요구되면서 HTTP/1.0이 추가로 정의됨. 메시지 헤더의 Content-Length라는 헤더 값이 지정된 경우, 해당 크기만큼 메시지 바디가 따라나온다는 의미로 쓰임
• ex. Content-Length가 정의되어 있으면, 서버에서는 빈 메시지 헤더를 읽은 다음부터 Content-Length만큼 더 읽은 후 메시지를 완성
• 만약 HTTP 메시지 크기를 미리 알수 없는 경우라면?
• ex. 외부 DBMS의 데이터를 HTTP body에 지정하는 경우 등 동적으로 결과가 변하는 경우
• HTTP 바디에 출력될 내용을 메모리나 파일로 직접 써봐야만 실재 크기를 알 수 있음. HTTP body를 모두 만들어 보내면 명백한 서버 리소스 낭비
• 해결책 : 전송 버퍼를 사용해 HTTP 바디를 생성하는 도중 버퍼의 크기가 다 차면 해당 내용을 클라이언트로 부분 전송한 이후 다시 버퍼를 재활용