자바는 '가상머신'이란 실행 방식을 이용해 WORA(Write, Once, Run, AnyWhere)라는 모토를 가지고 한 번의 작성으로 어떤 플랫폼에서든 실행할 수 있는 방식으로 동작하는 언어
자바 기술의 동향과 종류
Java SE(Java Platform, Standard Edition)
- 데스크톱, 서버, 임베디드 시스템 개발을 위한 표준 자바 플랫폼으로 자바의 기본 개발 환경을 제공(자바 개발 환경인 JDK와 자바 런타임 환경인 JRE로 나뉨)
- JDK(Java Development Kit): 자바 개발 환경으로서 Java Virtual Machine(JVM)과 컴파일러, 디버거 및 애플리케이션 개발을 위한 도구들이 포함
- JRE(Java Runtime Environment): 자바 애플리케이션 개발 도구인 JDK의 일부로서, 자바 애플리케이션이 실행되는 데 필요한 최소한의 요건을 제공하며, JVM과 핵심적인 클래스들 그리고 각종 지원 파일들로 구성
JDK의 bin 디렉토리에 포함된 주요 개발 도구
- javac : 자바 컴파일러로 자바 소스를 바이트 코드로 변환
- java : 자바 프로그램 실행기, 자바 가상머신을 작동시켜 자바 프로그램 실행
- javadoc : 자바 소스로부터 HTML 형식의 API 도큐먼트 생성
- jar : 자바 클래스 파일을 압축한 자바 아카이브 파일(JAR) 생성, 관리
- jdb : 자바 응용프로그램의 실행 중 오류를 찾는 데 사용하는 디버거
- javap : 클래스 파일의 바이트 코드를 소스와 함께 보여주는 디어셈블

Java EE(Java Enterprise Edition)
- 자바의 기본적인 기능을 정의한 Java SE에 웹서버 역할을 추가한 것으로 자바 애플리케이션을 동작하게 하는 컨테이너 등을 표준화한 스펙
- Java EE의 기술로는 웹 프로그래밍에서 사용하는 JSP, Servlet과 비즈니스 모듈을 담당하는 EJB, 데이터베이스를 연동하는 JDBC, 서버의 자원을 관리해주는 JNDI, JTA, EJB등의 기술이 있다
이러한 Java EE 스펙에 따라 제품으로 구현한 것을 WAS(Web Application Server)라 부름
Java ME(Java Micro Edition):
- 모바일 장치나 내장형 장치(휴대전화, 셋톱 박스, PDA)와 같은 소형장치에서 실행되는 자바 애플리케이션을 지원하기 위해 경량화 된 기술들을 지원하는 플랫폼
웹에서의 자바 기술
Applet
- 서버에서 클라이언트 쪽으로 실행 파일을 내려 받아서 실행되는 방식으로 변경 (현재는 HTML5, CSS jQuery등의 기술들이 대신 함)
- 자바가 현재 위치까지 오게 한 요인 중 하나
Servlet
- 클라이언트가 웹 브라우저를 통해 요청하면 서버에서 실행한 후 결과값만 클라이언트로 전송하는 서버 프로그램. 또한, HTTP 프로토콜로 통신하는 웹의 특징과 속성들을 자유롭게
활용할 수 있는 API를 제공함으로써, 클라이언트의 요청과 서버의 응답에 관한 처리 작업을 쉽게 할 수 있음 - 클라이언트가 서버에 웹 문서를 요청하면 서버가 다른 애플리케이션을 통해 웹 문서를 재생성하여 제공하는 방식
JSP(Java Server Page)
- 간단한 코드로 구현할 수 있는 기술
- 일부 Servlet 객체는 변수 선언과 초기화 작업 없이 바로 사용해서 코드가 훨씬 간단
- Servlet과 같은 기능. 두 가지 차이 존재
웹 프로그래밍의 이해
웹문서
- 웹에서 클라이언트가 서버에 정보를 요청하면 응답하는 콘텐츠(정적/동적)
- 정적 웹 문서 (클라이언트가 웹 문서를 요청하면 웹서버는 이미 만들어져 있는 문서를 클라이언트에 제공)
1) 서버 애플리케이션 개발자가 문서를 변경하지 않는 한 항상 같은 내용을 전달
2) HTML, GIF, JPG, PDF, PPT 등이 있음 - 동적 웹 문서 (요청 시마다 다른 웹 문서의 내용을 클라이언트로 전달 하는 것)
1) 클라이언트가 서버에 웹 문서를 요청하면 웹 문서에 동적인 요소를 포함하는 방식(스크립트 방식) - JSP
2( 클라이언트가 서버에 웹 문서를 요청하면 서버가 다른 애플리케이션을 통해 웹 문서를 재생성하여 제공하는 방식 - 서블릿
3) CGI, ASP, PHP, JSP, Servlet 등이 있음
웹 애플리케이션
- 간단하게 웹에서 수행되는 애플리케이션
- 수행되는 위치에 따라서 2가지로 나뉨
- Server Side
1) 웹서버에서 수행되는 기술
2) 웹 애플리케이션이 서버에서 일차 수행되면서 서버의 자원을 활용하고, 그 결과를 클라이언트에 전송 - Client Side
1) 웹 클라이언트에서 수행되는 기술
2) 클라이언트에서 요청한 웹 애플리케이션이 클라이언트에 전송된 다음에 클라이언트 자원을 이용하고 클라이언트에 의해 수행 - 웹 애플리케이션이 미리 컴파일 되고 실행 파일이 만들어진 후 사용되면 컴파일 방식, 요청이 있을 때마다 해석되거나 컴파일이 필요 없을 때는 비 컴파일 방식
웹서비스
일반적으로 웹 서비스란 네트워크상에 분산된 자원들을 이기종 간에 서로 연동하여 자원을 공유하기 위한 추상적인 서비스 형태를 의미함.
- SOAP 기반 웹 서비스
SOA(Service Oriented Architecture)
1) 서비스 제공자가 공유 혹은 서비스하려는 자원을 UDDI라는 전여 서비스 저장소에 등록 (publish)
2) 서비스 요청자가 검색한 후 서비스 제공자와 HTTP의 응용 프로토콜인 SOAP를 이용하여 메시지를 주고받음
서비스 제공자와 요청자가 주고받는 SOAP 메시지는 SOAP 봉투, SOAP 헤더, SOAP 몸체로 구성된 하나의 XML 문서로 표현되며, 이것은 HTTP로 전달되므로 크기가 크며, 송수신 헤더와 몸체를 인코딩/디코딩해야 함

- RESTful 기반 웹 서비스
ROA(Resource Oriented Architecture)
1) 리소스 중심의 표현, 전달, 접근 방식의 기술
2) RESTful 웹 서비스는 SOAP 기반 웹 서비스의 문제점인 오버헤드 발생, 메시지의 인코딩/디코딩의 어려움을 보완
3) REST(Representational State Transfer)기반의 웹 서비스로서, HTTP의 기본 기능만으로 원격 정보에 접근 가능
4) 상호 연동을 위한 서비스를 등록하기 위한 저장소가 필요하지 않음, 단순히 서버와 클라이언트로만 분리
5) 리소스 접근을 위해 단순 URI로 표현하며, HTTP의 요청방식인 GET, POST, PUT, DELETE만으로 접근
6) XML, JSON, HTML, 텍스트, 이미지 등 원하는 형식으로 표현 가능

웹서버
HTTP프로토콜을 기반으로 하여 웹클라이언트로부터 요청을 서비스하는 기능을 담당, HTTP 서버라고도 불림
- 웹서버의 역할은 요청/응답하는 일로 나뉨
1) 클라이언트가 요청한 웹 문서를 찾아서 전달하는 기능을 처리한다.
2) 요청 파일이 없거나 문제가 발생하면 정해진 코드 값으로 응답한다.
3) 클라이언트로부터 요청에 대한 기본 사용자 인증을 처리한다.
4) 서버 프로그램에 대한 요청을 웹 애플리케이션 서버에 수행시키고 그 결과를 응답한다.
웹 애플리케이션 서버
- 웹 서버의 기능을 분리해서 처리하려는 목적으로 사용하며, 주로 web/was 로 나뉘어 사용한다.
- was는 웹서버, 컨테이너, 트랜잭션, 보안, 트래픽 관리, DB 커넥션 풀, 사용자 관리 등을 제공
- Java EE서버라고도 불리며, Servlet/JSP, 컨테이너, EJB컨테이너 기능까지 지원
- WebLogic, WebSphere, Jeus, JBoss, Tomcat 등
컨테이너
웹 컴포넌트를 저장하는 저장소 역할, 메모리 로딩. 객체 생성 및 초기화 등 Servlet의 생명주기를 관리하고 JSP를 Servlet으로 변환하는 기능을 수행하는 프로그램

- Servlet 컨테이너
클라이언트의 요청에 따라 servlet을 수행하는 프로그램
Servlet 표준 API에서 제공하는 추상 클래스와 인터페이스를 구현한 클래스를 제공하여 기본적인 동작 방식과 API 호환성을 지원합니다.
- JSP 컨테이너
JSP를 Servlet으로 변환하는 프로그램, Servlet으로 구현된 프로그램
JSP 컨테이너는 JSP 파일을 Servlet 소스로 변환 및 컴파일까지만 담당하는 프로그램이며, 변환된 Servlet의 수행은 Servlet 컨테이너가 담당
HTTP(Hyper Text Transfer Protocol)
TCP/IP 4계층에서 애플리케이션 계층에 해당하는 프로토콜로서, 전송 계층에서 TCP를 사용하여 웹 브라우저와 웹 서버 간에 통신하는 프로토콜.
- 무연결(Connectionless)
HTTP는 클라이언트와 서버 간에 요청이 있을 때마다 독립적으로 연결하여 통신하는 방식 - 무상태(Stateless)
요청마다 서로 다른 연결로 인식되어 요청 간에 정보를 공유해서 사용할 수 없는 상태 - 요청/응답(Request/Response)
요청정보와 응답정보를 주고받으며 통신이 이루어지는 방식
HTTP 요청정보

HTTP 요청방식
웹 클라이언트가 웹서버에 요청하는 서비스 처리 방식을 지정하는 것
- GET
웹브라우저의 주소 줄에 URL을 직접 입력하거나 하이퍼링크가 포함된 개체를 클릭할 때, 서버에 빠른 속도로 요청 가능하며 서버로 보내는 문자열 정보들이 웹 브라우저에 노출 됨
GET 방식의 요청은 브라우저에서 캐시가 가능하며 서버로 보내는 모든 문자열 정보들이 웹브라우저에 노출됨 - POST
데이터가 HTTP 요청정보의 몸체에 포함되어 전달
데이터 크기에 제한이 없고, 화면에 노출 되지않는다.
웹 클라이언트 측에서 보내는 데이터를 인코딩하고, 서버 측에서 디코딩해야 하므로 GET 방식보다 상대적으로 느리다.
주로 서버 측의 정보를 새로 생성하는 작업에 사용 - PUT
파일 업로드를 할 때 이용할 수 있으며, POST, PUT 방식 모두 같은 작업을 수행
일반적으로 서버의 리소스를 새로 생성할 때는 POST 방식으로 요청하고, 서버의 리소스를 수정할 때는 PUT 방식으로 구분 요청 - DELETE
서버의 리소스를 삭제하는 작업을 요청할 때 사용 - OPTIONS
요청 URI에 대하여 허용되는 통신 옵션을 알고자 할 때 사용 - HEAD
GET 방식과 같으나 요청정보의 몸체 없이 헤더 정보만 요청하는 방식입니다. 해당 자원이 존재하는지, 또는 서버에 문제가 있는지를 확인하기 위해 사용합니다. - TRACE
웹 클라이언트의 요청을 그대로 반환하는 방식으로 요청정보가 웹서버에 도달하기까지의 경로를 기록합니다.
ECHO서비스로 서버 상태를 확인하기 위한 목적으로 사용 - CONNECT
Proxy에 사용하기 위해 예약된 메소드로서 Proxy가 동적으로 접속할 수 있게 지원
요청 URI
웹 클라이언트가 웹 서버에 요청한 서비스 문서의 정보입니다. 요청 URI는 네트워크의 자원 정보인 URL의 일부로서 URL(Uniform Resource Locator)은 네트워크상에 존재하는 자원을 찾아가기 위한 정보
URL의 구성
- 프로토콜
서버와 통신하기 위한 규약으로서 서버마다 사용하는 프로토콜이 정해져 있다. - 서버 주소
네트워크상에서 연결된 컴퓨터를 찾아가기 위한 정보로서 IP 주소 또는 도메인 이름으로 표현 - 포트번호
동작하고 있는 서버로 접속하기 위한 정보
포트번호는 0~65,535번 까지 사용할 수 있으며, 0~1,023 사이의 번호는 well-known-port - URI
Uniform Resource Identifier의 약자로 서버에서 서비스하는 서버의 자원 정보
URL의 포트 번호 다음부터가 URI이다.
요청 헤더
헤더는 general-header, request-header, entity-header 3가지로 분류할 수 있다.
Accept | text/html,application/xhtml+xml, application/xml, image/webp, */*;q=0.8 |
Accept-Encoding | gzip, deflate, sdch |
Accept-Language | ko-KR, ko;q=0.8, en-US;q=0.6, en;q=0.4 |
User-Agent | Mozilla/5.0(Windows NT 6.1 WOW64) AppleWebKit/537.36(KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36 |
Cache-Control | No-cache, so-store, max-age |
- Accept
클라이언트가 인식하여 처리할 수 있는 파일 타입을 명시합니다. 여러 개의 파일 타입은 쉼표(,)로 구분하여 나열합니다. - Accept-Encoding
compress 또는 gzip과 같은 웹 클라이언트가 받아들일 수 있는 인코딩 방식을 지정
인코딩 방식을 쉼표(,)로 구분하여 나열하며, 지정하지 않으면 클라이언트에 어떤 형태도 받아들여지지 않음 - Accept-Language
클라이언트가 지원하는 언어를 지원 - User-Agent
클라이언트가 사용하는 웹 브라우저에 대한 정보를 보여줌
서버 쪽에서는 User-Agent 정보를 보고 일반 웹페이지와 모바일 웹페이지로 자동 분기합니다. - Cache-Control
no-cache: 캐시 안함
no-store: 신속히 넘긴 후 정보 제거
max-age=seconds: 지정된 시간보다 오래된 데이터는 캐시 안함
max-stale=seconds:지정된 시간이 아직 되지 않은 만료된 데이터를 보냄
min-fresh=seconds:지정된 시간 이후의 변경된 새로운 데이터만 보냄
only-if-cached: 새로운 데이터를 검색하지 않고 캐시에 있는 데이터만 반환
HTTP 응답정보

상태코드
상태 코드는 클라이언트의 요청에 대한 처리 결과를 의미합니다.
1xx는 조건부 응답, 2xx는 성공, 3xx는 리다이렉션 완료, 4xx는 요청 오류, 5xx는 서버 오류에 관한 상태 코드
- 200 OK - 클라이언트의 요청을 성공적으로 처리했음을 나타내며, 서버는 요청한 데이터를 포함하여 응답
- 400 Bad Request - 클라이언트의 요청에 문법적인 오류 등 잘못된 요청으로 서버가 요청을 해석할 수 없는 경우(잘못된 요청 형식을 수정하여 다시 요청)
- 401 Unauthorized - 클라이언트가 잘못된 인증 정보를 Authorization 헤더에 넣었음을 나타냄(클라이언트는 요청정보 헤더의 Authorization에 적절한 인증 정보를 설정 후 다시 요청)
- 403 Forbidden - 사용자 허가 모드 오류로서 클라이언트의 인증 정보에 상관없이 페이지에 대한 접근을 거부
- 404 Not Found - 클라이언트가 요청한 문서가 존재하지 않음(클라이언트의 요청에 대하여 서비스하는 요청 URI를 서버가 찾지 못한 경우)
- 405 Method Not Allowed - 클라이언트가 요청한 서비스 요청방식을 웹서버에서 지원하지 않음(요청한 서비스 요청방식을 확인한 후 서버 프로그램에서 해당 요청방식 처리 메소드가 구현되었는지를 확인)
- 500 Internal Server Error - 서버프로그램 실행 시 오류가 발생하여 서버 프로그램이 멈추었거나 올바르지 않은 응답 헤더 정보가 설정되었을 때 발생(서버 프로그램 내 구현 오류)
응답 헤더
Cache-Control | public, private, no-cache, no-transform, must-revalidate, proxy-revalidate, max-age=seconds |
Connection | close |
Content-Encoding | gzip |
Content-Type | text/html; charset=UTF-8 |
Date | Fri, 01 Jul 2022 12:15:23 GMT |
Server | nginx |
- Cache-Control
public: 어떠한 캐시라도 캐시할 수 있음
private: 공유된 캐시는 캐시하지 않음
no-cache: 캐시하지 않음
no-transform:데이터를 변환하지 안흥
must-revalidate: 클라이언트는 데이터를 재확인해야 함
proxy-revalidate: 개인적인 클라이언트 캐시를 제외하고 데이터를 재확인해야 함 - Connection
연결을 위해 지정하는 정보 - Content-Encoding
메시지를 전송할 때 사용할 인코딩 체계를 지정 - Content-type
클라이언트가 요청한 메시지의 데이터 포맷으로서 서버도 같은 데이터 타입으로 처리하여 응답 - Date
웹서버가 클라이언트에 응답한 날짜와 시간 - Server
클라이언트의 서비스 요청을 받아서 서비스를 처리한 서버의 이름과 버전 정보
'프로그래밍 > Servlet & JSP' 카테고리의 다른 글
[Servlet & JSP] Servlet 구현 및 실행 (0) | 2023.03.29 |
---|