웹과 서블릿

웹 이란? 인터넷 네트워크

옛날에 웹 이라는 것이 개발되기 이전에는, 멀리 떨어져 있는 컴퓨터들끼리는 통신이 어려웠다. 물론 데이터를 주고받는 행위도 포함이다.
예를들어, 서울에 있는 민지의 컴퓨터에 있는 사진이나 문서 등 파일을 대전에 있는 해린이라 전달받고 싶었다면, 해린이가 직접 민지의 컴퓨터에 갔어야만 했다. 이러한 단점을 개선하기 위해 “웹”이 탄생했다.

웹 이란, 멀리 떨어져 있는 컴퓨터들 끼리 데이터 공유가 가능한 정보 공간이다. 정보공간이라고 해서 물리적으로 존재하는 공간은 아님.
기술적인 시스템도, 프로그램도 아닌 그냥 어떤 추상적인 개념 이다.

웹 통신 과정 예시

컴퓨터1이 컴퓨터2에 있는 abc.txt 데이터파일을 요청해서 보려고 함.
컴퓨터1은 한국에있고 컴퓨터2는 일본에 있음-> 따라서 두 기기간 통신을 하려면 ‘웹’서비스를 이용해야 한다.
그러기 위해서는 데이터를 요청하는 입장인 컴퓨터1 에는 웹 브라우저(크롬,엣지 등)가, 요청에 응답하는 입장인 컴퓨터2 에는 웹서버가 설치되어 있어야 한다.

<웹>
웹이란 멀리 떨어져 있는 기기간의 통신을 가능하게 하는 환경또는 서비스를 의미한다.
기능적인 시스템도 프로그램도 아닌, 어떠한 추상적인 개념 이다.

<웹 브라우저, 웹 서버>
멀리 떨어져 있는 사람끼리 통신하려면 전화기가 필요하듯이, 멀리 떨어져 있는 두 대의 컴퓨터가 통신하려면 그에 걸맞는 도구가 필요하다.
통신을 ‘요청’ 하는 컴퓨터는 client라고 하며, 웹브라우저 프로그램이 설치되어 있어야한다. (크롬,엣지,사파리 등)
요청에 ‘응답’ 하는 컴퓨터는 resource라고 하며, 웹서버 프로그램이 설치되어 있어야 한다. (아파치,Nginx등)

<http, url>
이제 두 대의 컴퓨터는 웹서비스를 이용한 원격통신을 한다.
데이터를 요구하는 client는 웹 브라우저의 주소창에 url을 입력해서 통신요청을 보낸다.
사람이 언어를 사용해서 대화할때 효율적인 소통을 위해 문법이 필요하듯이, 웹서비스에서도 통신언어의 문법, 즉 통신규약이 필요하다. 그것을 http 라고 한다.
그리고 통신규약을 지켜 작성한 일련의 문자열을 url이라고 한다.

url구조 :

리소스란?
url을 검색해서 받아온 결과물.
이미지,음성,문서 파일 등등..
서버에서 전달받은 데이터를 말함

http메시지 구조

요청메시지 : 서버에게 보낼 데이터의 유무에 따라 메시지바디의 포함유무 결정.

요청메시지의 start line : http method,쿼리,http version 으로 구성.

응답메시지의 start line : http version,상태코드, 상태 문구 로 구성.

헤더
http 전송에 필요한 모든 부가정보 有.

<http 메서드>

GET : 리소스 조회에 사용된다.

ex)
1. 클라이언트가 /users/10 에 데이터 요청
GET/users/10 HTTP/1.1
Host:localhost:3000

2. 서버에 도착 -> 해당 메시지에 맞는 데이터 찾아 보내줌
   /users/10에서 데이터 찾음
   {
   "id" : "10",
   "name" : "podo",
   "email" : "test@gmail.com"
   }

3. 응답 데이터 -> 응답 메시지의 바디부분에 해당 데이터가 있다
   HTTP/1.1 200 OK
   Content-type: application/json
   Content-Length: 52
   {
   "id" : "10",
   "name" : "podo",
   "email" : "test@gmail.com"
   }

POST : 요청데이터 처리, 주로 등록에 쓰임
ex)
1. 요청 -> 클라이언트에서 서버의 users에 데이터 요청
POST /users HTTP/1.1
Content-type: application/json
{
"name" : "sogeum",
"email" : "test2@gmail.com"
}

2. 서버에 도착 -> users에 신규 리소스 식별자 생성해서 데이터 등록
   /users/11
   {
   "id" : "11",
   "name" : "sogeum",
   "email" : "test2@gmail.com"
   }

3. 응답 데이터 -> 서버에서 클라이언트에 응답메시지 모내줌. header 필드에
   location 값이 추가 됨(신규 리소스 주소).

• 신규 리소스 생성에 대한 상태코드인 201이 포함되어있다.
  HTTP/1.1 201 Created
  Content-type: application/json
  Content-Length: 52
  Location: /users/11
  {
  "id" : "11",
  "name" : "sogeum",
  "email" : "test2@gmail.com"
  }

PUT : 리소스를 완전히 대체, 해당 리소스 없으면 생성
ex)
1. 클라이언트 요청 ->

2. 서버에 도착. 서버에서는 원래있던 데이터를 요청받은 데이터로 변경.
name과 이메일 바뀜.

3. 만약 이메일없는 데이터 보내면 기존의 데이터를 이메일 없는데이터로 대체.
이부분이 POST와 차이점..

• post와 put의 차이점.
  

PATCH : 리소스의 일부분만 변경
1. 변경하고자 하는 데이터를 서버에 요청

2. 서버에도착 -> 리소스 부분 변경
   

DELETE : 리소스 삭제
1. 요청

2. 서버에도착 -> 해당리소스 삭제

<HTTP상태코드>

• redirection? : 3XX 에서 , 요청 완료를 위해 웹브라우저에서 추가작업조치가 필요하다-> redirection.
  웹 브라우저는 3XX응답 결과에 location 헤더가 있으면 그위치로 자동 이동.
  
  만약, /coke URL사용안하고 zero-coke로 변경됐다면, /coke url로 접속하던 유저는 바뀐 리소스 주소를 담은 location헤더를 3XX 응답결과로 받는다.
  웹 브라우저는 로케이션 헤더에 담긴 리소스 주소로 자동 리다이렉트 하게됨
  

---

#Servlet

서블릿 이란?
(서블릿,스프링의 정의는 CGI이다. /Common Gateway Interface
: 서버와 애플리케이션간에 데이터를 주고받는 '방식')

• 동적페이지 만드는데 사용되는 Web Application Server 프로그램.
• Web Server랑은 조금 다름. 웹서버 뒷단에서 보조해주는 역할.
• 자바로 만들어진 코드 뭉탱이 이다.

사용자가 요구하는 데이터가 '동적데이터' 이다-> 요청시 프로그래밍을 거쳐서 전달해야하는 데이터를 뜻함
동적데이터 : 요청이 발생할 때 마다 서버측에서 프로그래밍논리에 따라 데이터가 가공돼서 전달되는 데이터를 의미.

static data : 매 요청마다 변겨오디지 않고 항상 동일한 값을 반환한다.
예로 css파일, 자바스크립트 이런파일.

dynamic data : 클라이언트의 요청에 따라 프로그래밍로직을 통해 가공되는 데이터. 서버측에서 동적으로 생성되어 클라이언트에게 전달됨. 예를 들어, 사용자의 요청에 따라 데이터베이스에서 가져온 정보, 계산 결과, 사용자의 입력에 기반한 응답 등은 동적인 데이터입니다.

이러한 동적데이터를 생성,전달 위해서는 서버사이드기술(서블릿,jsp,스프링 등)을 사용해야함. 그결과로 동적데이터 생성하여, WS에 전달하고 클라이언트로
응답 보낸다.

웹서버랑 WAS는 조금 다름.
즉 WAS의 주요 임무는 동적인 요청을 받아 처리해주는 서버임.

웹서버와 was가 기능적으로 동일한 영역이 있지만, 목적이 다르다.

WAS는 동적인 데이터를 위주로 처리하는 서버로써,
DB와 연결되어 사용자와 데이터를 주고받고 조작이 필요한 경우 WAS를 활용한다.

그렇다면 웹서버가 할 수 있는 일을 WAS가 전부 가능하다면 웹서버는 굳이 사용하지 않아도 되지 않을까…? 라고 생각이 들 수 있는데 그렇진 않습니다
->딱 내가 한 생각;;

물론 정적인 콘텐츠만을 제공하는 웹사이트를 서버에 배포한다면 웹서버만으로도 충분합니다. 그런데 동적인 컨텐츠를 제공해야 하는 웹서비스 배포를 해야 한다고 한다면 정적, 동적 요청 처리가 모두 가능한 WAS만을 사용해도 되지 않겠냐는 생각을 할 수도 있습니다.

하지만 WAS는 DB 조회 및 다양한 로직을 처리하는 데 집중해야 합니다.
따라서 단순한 정적 콘텐츠는 웹 서버에게 맡기며 기능을 분리해 서버 부하를 방지해줘야 합니다.

만약 WAS가 정적 콘텐츠 요청까지 처리하게 된다면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지고 이에 따라 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어지게 됩니다.

웹 서비스는 아래처럼 다양한 구조를 가질 수 있습니다.

Client -> 웹서버 -> DB
Client -> WAS -> DB
Client -> 웹서버 -> WAS -> DB