💙애플릿(Applet)
서버에서 클라이언트 쪽으로 실행 파일을 내려 받아서 실행되는 방식
현재 사용하는 HTML5, CSS, jQuery 등의 기술이 사용되기 전 사용된 기술
클라이언트에서 내려 받아야 실행된다는 약점이 있다.
💙서블릿(Servelt)
클라이언트에서 웹 브라우저를 통해 요청하면, 서버에서 실행한 후 결과값만 클라이언트로 전송
HTTP 프로토콜로 통신하는 웹의 특징과 속성들을 자유롭게 활용할 수 있는 API를 제공하면서, 클라이언트의 요청과 서버의 응답에 관한 처맂가업을 쉽게 할 수 있게 한다.
💙 JSP(JavaServer Page)
HTML 페이지 안에서 스크립트 형태로 구현되는 것.
서블릿은 컨트롤러 페이지를 만들 때 사용하지만, jsp는 뷰 페이지를 만들 때 사용
💙 웹 문서
웹에서 클라이언트가 서버에 정보를 요청하면 응답하는 컨텐츠
정적 웹 문서
클라이언트가 웹 문서를 요청하면 이미 만들어진 문서를 클라이언트에 제공
-> HTML, GIF, JPG, PDF, PPT 등
동적 웹 문서
요청 시 마다 다른 웹 문서의 내용을 클라이언트로 전달하는 것
-> CGI, ASP, PHP, 서블릿, JSP 등
💙 SOAP(Simple Object Access Protocol) 기반 웹 서비스
- 다른 언어로 다른 플랫폼에서 빌드 된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜
- 프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 빌트인 룰이 적용되어 페이지 로드시간이 길어짐
- 데이터에 대한 요청이 전송되는 경우 HTTP, SMTP, TCP 등의 다양한 애플리케이션 레이어 프로토콜을 통해 처리 될 수 있으나, 요청이 수신되면 XML 문서 형식으로 반환되면서 크기가 크고, 송수신시 헤더와 몸체를 인코딩/디코딩 해야하는 작업을 거쳐야한다.
💙 RESTful 기반 웹 서비스
REST(Representational State Transfer)는 웹 서비스와 모바일 애플리케이션 경량화의 필요에 맞춘 아키텍처 원칙 세트
리소스 접근을 위해 단순 URI로 표현하며, HTTP의 요청방식(GET, POST, PUT, DELETE)만으로 접근 가능
SOAP는 구조가 복잡하지만, RESTful 기반 웹 서비스의 리소스는 HTTP 요청방식으로 서비스되므로 XML, JSON, HTML, 텍스트, 이미지 등 원하는 형식으로 표현이 가능
경량화 되어 있어 선호되는 메시지 형식이며, RESTful API는 유연하고 설정이 쉬움
💙 웹 서버
웹에서 서버 기능을 수행하는 프로그램
HTTP 프로토콜을 기반으로 웹 클라이언트로부터의 요청을 서비스하는 기능을 담당
- 클라이언트가 요청한 웹 문서를 찾아서 전달
- 요청 파일이 없거나 문제가 발생하면 정해진 코드 값으로 응답
- 클라이언트로부터의 요청에 대한 기본 사용자 인증을 처리
- 서버 프로그램에 대한 요청을 웹 애플리케이션 서버에 수행시키고 그 결과를 응답
💙 웹 애플리케이션 서버
웹 서버의 기능을 분리해서 처리하려는 목적으로 웹 애플리케이션 서버(WAS, Web Application Server)를 사용
클라이언트로부터 요청받은 일과 화면에 표현하는 로직(Presentation Logic)까지만 웹 서버에서 담당하고, 다양한 기능을 수행하는 로직(Business Logic)은 컨테이너가 담당하도록 WAS에서 일을 나누어 역할을 분담
WAS는 크게 웹 서버 기능과 컨테이너 기능으로 구분
대부분 상용화된 WAS는 웹 서버나 컨테이너 기능 외에 엔터프라이즈 환경에서 필요한 트랜잭션, 보안, 트래픽 관리, DB 커넥션 풀, 사용자 관리 등의 다양하고 강력한 기능을 제공
웹 서버 기능에 서블릿/JSP 컨테이너 그리고 EJB 컨테이너 기능까지 지원하는 서버를 제공
WAS를 JavaEE 서버라고도 한다
💙 HTTP
TCP/IP 4계층에서 애플리케이션 계층(Application Layer)에 해당하는 프로토콜
무연결(Connectionless)
HTTP는 클라이언트로부터 요청이 들어와 서버가 응답하면 클라이언트와의 연결을 끊고 클라이언트가 새로운 요청을 하면 또 다른 연결을 맺음
HTTP는 클라이언트와 서버 간에 요청이 있을 때 마다 독립적으로 연결하여 통신하는 방식
무상태(Stateless)
HTTP의 무연결(Connectionless) 특성 때문에 이전 연결에서 했던 작업 내용을 다음 요청에서 그대로 사용할 수 없다.
이처럼 상태정보가 유지되지 않는 특성 -> 무상태(Stateless)
이전 요청이 있을 때 사용한 정보를 계속 사용하고 싶다면, 서버나 클라이언트 측에 정보를 저장하고 유지한 후 사용하는 정보 유지 기술 필요
요청·응답(Request·Response)
HTTP는 웹 클라이언트가 서버에 TCP 접속을 처리한 후 요청 메시지를 보내면, 웹 서버는 요청 메시지를 근거로 서비스를 처리한 다음, 그 결과인 응답 메시지를 클라이언트에 보냄으로써 통신
💙 HTTP 요청 방식
GET
- 웹 브라우저의 주소 줄에 URL을 입력하거나 하이퍼링크가 포함된 개체를 클릭 시
- 직접 GET 방식을 지정하여 서비스 요청 시
브라우저에서 캐시(cache)가 가능하며 클라이언트가 서버로 전송하는 문자열이 있는 경우 요청정보 헤더의 요청 줄에 포함되는 URI 뒤에 ? 기호와 함께 추가되어 전달된다.
그로 인해 전송되는 모든 문자열 정보들이 웹 브라우저에 노출되는 특징이 있으며, 헤더에 포함되므로 전달되는 문자열 크기에 제한이 있다.
GET은 기본 요청방식으로 서버에 빠른 속도로 요청할 때 사용한다.
POST
데이터가 HTTP 요청정보의 몸체에 포함되어 전달된다.
데이터 크기에 제한이 없고, 화면에 노출되지 않는다.
POST 방식은 웹 클라이언트 측에서 보내는 데이터를 인코딩하고, 서버 측에서 디코딩해야하므로 GET 방식보다 상대적으로 처리속도가 느리다.
PUT
파일 업로드할 때 이용 가능. POST와 PUT 모두 같은 작업 수행이 가능.
일반적으로 서버의 리소스를 새로 생성할 때는 POST 방식으로 요청하고, 서버의 리소스를 수정할 때는 PUT 방식으로 구분하여 요청
DELETE
서버의 리소스를 삭제하는 작업을 요청할 때 사용
OPTIONS
요청 URI에 대하여 허용되는 통신옵션을 알고자 할 때 사용
HEAD
GET 방식과 같으나 요청정보의 몸체 없이 헤더 정보만 요청하는 방식
TRACE
웹 클라이언트의 요청을 그대로 반환하는 방식. 요청 정보가 웹서버에 도달하기까지의 경로를 기록
CONNECT
proxy에 사용하기 위해 예약된 메소드. proxy가 동적으로 접속할 수 있게 지원
💙 URI(Uniform Resource Identifier)
웹 클라이언트가 웹 서버에 요청한 서비스 문서의 정보
인터넷에 있는 자원을 나타내는 유일한 주소
요청 URI는 네트워크의 자원 정보인 URL의 일부로서
URL은 네트워크상에 존재하는 자원을 찾아가기 위한 정보
💙 URL(Uniform Resource Locator)
네트워크 상에서 자원이 어디 있는지를 알려주기 위한 규약
🤍 회고
HTTP나 웹 관련 기술을 정리하다 보니, 그동안 헷갈렸던 URI와 URL의 차이를 제대로 이해하게 됐다. 이런 기본 개념들이 잡히니까 HTTP 요청 방식이나 서버 구조도 훨씬 잘 이해된다. OSI 7계층역시 대학 시절 여러 수업에서 반복해서 접했던 내용이 다시 등장하는 걸 보니, 역시 자주 언급되는 개념은 중요한 이유가 있다는 걸 느꼈다.
