Spring MVC/01.WebProgramming

01. 웹 프로그래밍 개요

  • -

이번 포스트에서는 "웹 프로그래밍"의 개요와 자바 기반 웹 프로그래밍 주요 특성에 대해 살펴보자.

 

웹 프로그래밍

 

웹 프로그램과 WAS

웹 프로그램이란 통상 원격지의 서버(server)에서 실행되는 프로그램을 말한다. 원격지의 서버란 네트워크 저 너머 특정 IP(192.168.0.1)에서 동작하고 있다.

stand alone application web application

일반적인 stand alone application의 경우는 클래스들이 동일한 컴퓨터의 JVM 위에서 동작하기 때문에 실행을 위해 고려할 내용이 별로 없다. 하지만 네트워크 너머 원격지 서버에서 실행되는 프로그램을 실행시키려면 어떻게 해야 할까? 

어떻게 호출 해야하고 결과를 어떻게 확인해야 할지 막막하다. 일단 직접 호출할 수는 없으니 네트워크를 통해 정보를 주고 받기 위한 약속(Protocol)을 정했는데 이것이 HTTP(HyperText Transfer Protocol)다. HTTP에는 요청/응답의 절차, 형식 등이 정의 되어있다.

그럼 HTTP를 준수해서 동작하도록 서버 프로그램을 작성하면 되는데 HTTP는 너무 방대하고 비지니스 로직과는 무관한 부분이므로 프로젝트에서 구현한다는 것은 무리이다. 따라서 이를 처리해주기 위한 별도의 프로그램을 이용하는데 이것을 Web Application Server 즉 WAS라고 한다.

WAS는 JEE(Java Enterprise Edition)를 구현하고 있다. JEE는 대규모의 웹 애플리케이션 개발에 필요한 여러 API와 서비스를 제공하는 플랫폼이며 WAS는 이러한 JEE 기술을 기반으로 비지니스 로직을 처리할 수 있게 해준다.이처럼 WAS는 개발자가 네트워크등에 머리아프지 않고 비지니스 로직에 집중할 수 있게 해주는 아주 중요한 도구이다. WAS의 종류에는 여러 가지가 있는데 그 중 우리는 아파치의 톰켓 이라는 것을 이용해보자.

WAS(Container)와 Web Application(Context)

서버의 OS에는 WAS가 설치되고 WAS는 웹 서비스를 처리한다. 서비스를 외부에서 사용하기 위해서는 포트를 사용하는데 일반적으로 웹서비스의 기본 포트는 80이며 개발용으로는 8080을 주로 사용한다.(전혀 강제성은 없다.)

WAS는 여러 웹 애플리케이션을 포함해서 동작하기 때문에 Container라고도 부르며 각각의 애플리케이션을 Context라고 부른다. 

WAS = container, Application = context, Container Root, Context Root

container와 context의 개념이 나오면서 두 개의 절대경로가 등장하는데 바로 container root와 context root이다. 나중에 프로그래밍 과정에서 참조되는 내용이므로 잘 정리해두자.

구분 설명 예시
container root WAS의 경로 http://192.168.0.1:8080
context root WAS에 설치된 application http://192.168.0.1:8080/contextA

실제 사용자의 요청을 처리하는 것은 container에 포함된 context라는 것을 유념하자.

WAS와 Servlet

Servlet이란 Server + applet(applecation + let)으로 서버(WAS)에서 실행되는 작은 java의 컴포넌트 정도로 해석될 수 있다. 실제 사용자의 요청을 처리하는 웹 컴포넌트가 이 Servlet이다.

웹 애플리케이션에서는 이런 Servlet 객체의 생성 및 라이프사이클 전반에 대한 관리를 WAS가 담당하게 된다. 따라서 WAS를 광의로는 Application의 Container라고도 하고 협의로는 Servlet Container(서블릿 컨테이너)라고도 부른다.

다음은 WAS에서 Servlet이 동작하는 절차를 보여준다.

Servlet의 동작

  1. WAS는 HelloServlet, GuguServlet과 같은 Servlet을 각각 고유한 url에 매핑하여 관리한다. 
  2. 브라우저에서 WAS에 특정 작업을 요청한다. 요청은 HTTP 프로토콜을 통해 WAS로 전달된다.
  3. WAS는 url의 context 이름을 분석해서 context를 결정한다.
  4. url에 적합한 Servlet을 찾아 ServletRequest와 ServletResponse객체를 생성해서 Servlet을 호출한다. 
  5. 서블릿에서는 요청을 동적으로 처리해서 응답을 생성한다
  6. 생성된 응답을 HTTP 프로토콜을 통해 클라이언트로 전달하면 브라우저가 HTML을 해석해서 화면에 출력한다.

그럼 이런 요청과 응답은 어떻게 구성되어있을까?

요청

 

Http Request의 구성

  • 요청은 Request Line(요청 라인, start-line)과 Request Header(요청 헤더), 그리고 Request Body(요청 바디)로 구성된다.
  • Request Header(요청 헤더)는 key:value 형태로 작성되며 요청에 대한 부가적인 정보를 제공한다. 예를 들면 클라이언트 브라우저의 정보, 인증 토큰, 쿠키 등이 헤더에 포함된다.
  • Request Body(요청 본문)은 POST 또는 PUT 메서드를 이용해 서버에 데이터를 전송할 때 사용되며 HTML 폼 데이터나 JSON 데이터가 포함된다.

출처: https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

Request Line(요청 라인)

Request Line은 URL과 Http method로 구성된다.

먼저 URL(Uniform Resource Locator)은 다음의 구조를 갖는다.

URL의 구성

요소 설명
프로토콜(protocol) 서버와 클라이언트 사이의 통신 규약 ex: HTTP, HTTPS, FTP
호스트(HOST) 리소스가 위치하는 서버의 도메인 이름이나 IP 주소
포트(Port) 리소스를 제공하는 서비스의 포트 번호로 일반적으로 HTTP는 80(생략), HTTPS는 443을 기본으로 사용
컨텍스트명(Context) WAS에 설치된 컨텍스트(애플리케이션)의 이름으로 '/'로 매핑될 경우는 생략 가능
경로(Path) 컨텍스트 내에서 리소스의 위치를 지정하는 디렉토리 경로나 파일 경로
쿼리스트링(QueryString) URL에 추가적인 매개변수를 전달할 때 사용되며 '?' 다음에 key=value 형태로 작성되며 여러 개일 경우 '&' 문자로 연결 처리 


HTTP 메서드클라이언트가 서버에 요청을 보낼 때 사용하는 방식으로 주요 메서드는 GET/POST/PUT/DELETE등이 있다. 각 방식의 특징은 나중에 상세히 살펴보자.

출처: https://ko.wikipedia.org/wiki/HTTP

 

응답

 

Http Response의 구성

  • 응답은 서버가 클라이언트에게 보내는 정보로 Status Line(상태 라인, start line), Response Header(응답 헤더), Response Body(응답 본문)으로 구성된다.
  • Response Header(응답 헤더)는 key:value의 구조로 서버의 종류, 응답 길이, 캐싱 여부 등 응답에 대한 부가적인 정보를 제공한다.
  • 응답 본문(Response Body): HTML, JSON, 이미지 등 클라이언트로 저달되는 내용이 담긴다.

출처: https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

 

Status Line(상태 라인)

Status Line(상태 라인)은 응답의 상태 코드와 상태 메시지가 포함된다.

상태코드란 클라이언트(브라우저)에게 서버의 응답 상태를 전달하는데 사용된다. 이는 클라이언트가 응답을 받았을 때 서버의 처리 결과를 파악하고 적절한 조치를 취할 수 있도록 도와준다. 이런 상태 코드는 크게 5가지로 분류될 수 있다.

  • 1XX대(정보 제공): 임시 응답으로 현재까지의 클라이언트 요청이 잘 처리되고 있으니 계속 진행하라는 의미
  • 2XX대(성공): 클라이언트의 요청이 서버에서 성공적으로 처리됨
  • 3XX대(리다이렉션): 요청을 처리할 주소가 변경되었으니 다시 시도하도록 함
  • 4XX대(클라이언트 에러): 없는 페이지를 요청했거나 파라미터가 누락되는 등 클라이언트의 요청에 문제가 있음
  • 5XX대(서버 에러): 프로그램 자체의 오류나 DB, 서버 등의 문제로 요청 처리에 문제가 있음

이처럼 각 번호대로 다양한 상태 코드가 존재하는데 그 와중에서 자주 사용되는 녀석들만 살펴보자.

2XX: 성공 응답

코드 의미 설명
200 OK(성공) 서버가 요청 처리에 성공함
201 Created(생성됨) 요청의 결과로 새로운 리소스가 생성됨(주로 POST, 일부 PUT 요청 성공 시)
202 Accepted(허용됨) 요청을 접수했지만 처리가 완료되지는 않음
204 No Content(콘텐츠 없음) 처리에 성공했고 클라이언트에게 돌려줄 내용은 없음(주로 DELETE요청 성공 시)

 

4XX: 클라이언트 에러

코드 의미 설명
400 Bad Request(잘못된 요청) 요청의 구문이 잘못됨
401 Unauthorized(권한 없음) 단어 뜻 자체는 권한 없음이지만 인증을 통과하지 않음을 의미
403 Forbidden(접근 금지됨) 해당 리소스에 대한 접근 권한이 없음. 401과의 차이점은 서버가 클라이언트가 누구인지 알고 있는 상태
404 Not Found(찾을 수 없음) 지정한 리소스를 찾을 수 없음
405 Method Not Allowed(허용되지 않은 메서드) 요청한 URI가 지정한 메서드를 지원하지 않음(GET만 지원하는데 POST로 요청 등)

 

5XX: 서버 에러

코드 의미 설명
500 Internal Server Error 클라이언트의 요청은 유효하지만 서버가 처리에 실패함

 

'Spring MVC > 01.WebProgramming' 카테고리의 다른 글

06. MVC와 Model2  (0) 2024.08.20
05. JSP  (0) 2024.08.12
04. Front Controller Pattern  (0) 2024.08.08
03. Servlet 분석  (0) 2024.08.05
02. Hello Servlet  (0) 2024.03.05
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.