웹페이지 서버 요청 방식과 웹 기초

클라이언트가 웹서버에 요청하는 방식은 크게 네 가지이다.

html 1.0까진 get과 post방식까지만 지원하지만 1.1부터는 put과 delete방식까지 사용한다.

post는 insert를 할 때 이용하는 요청방식,

put은 update,

get은 select(ex. 인터넷 주소창),

delete는 delete를 할 때 이용한다. 요청을 딱히 하지 않으면 자동으로 get방식으로 요청된다. 이런 요청방식을

insert -> C reate

select -> R ead

update -> U pdate

delect -> D elete

이 앞글자만 따서 CRUD 방식이라고 한다.

 

이제 클라이언트가 서버에 요청하는 형태를 보자.

클라이언트가 서버에 요청한다. 요청하는 방식은 크게 url 과 uri가 있다.

주소가 크게 두 가지가 있다.

http://ip address : port / context / a. jpg 

이렇게 컨텍스트가 있는 폴더를 찾아가 파일을 그대로 불러오는 방식은 url이라고 한다. 

http://ip address : port / user / 1

이렇게 폴더의 주소가 아닌 파일에 식별자를 부여해 식별자로 파일을 불러오는 방식을 uri라고 한다. url은 폴더의 구조를 쉽게 노출하기 때문에 현재는 uri를 더 선호한다.

Client 가 apache에 avi나 jpg, html 등을 요청하면 apache는 webcontent에서 관리하고 있던 파일들 중에 일치하는 파일이 있다면 클라이언트가 요청한 '그대로' 전송해준다. 브라우저가 인식할 수 있는 파일의 형태이기 때문이다. 그런데, jsp나 서블릿의 형태로 요청한다면? 브라우저가 인식할 수 없기 때문에 apache는 tomcat에게 파일의 변환을 요청한다. 그렇게 되면 apache는 본인이 관리하면 web content 에서 web container로 파일을 전송해준다. 이 곳이 tomcat이 파일을 관리하는 곳이다. 여기서 jsp 파일을 java 파일로 변환되고, 컴파일 되어서 class 파일이 된다. 이 컴파일 된 파일을 jvm이 실행하고, 그 실행결과를 다시 tomcat이 html로 변환해 jsp 중 자바 파일이 있던 곳에 붙여준다. 이 렇게 html로 완벽히 변환된 파일을 apache에게 넘겨주고, 이 html 파일을 응답으로 넘겨준다.

그런데 왜 컴파일된 class 파일을 그대로 두고, html 파일은 임시파일로 한번만 쓰고 버리게 될까? html은 정적인 파일로써 자바에서 변수의 값이 바뀌게 되어도 이것을 반영할 수 없지만 class파일의 경우 그대로 반영되기 때문이다.

 

그럼 톰캣의 역할은 무엇일까? 역할은 다음과 같다.

1. 컴파일(jsp를 서블릿 형태로 변환해준다)

2. html 변환

3. 응답

4. request, response

이 4번의 형태를 잘 생각해보자. 내가 로그인을 했을 때, 아이디와 패스워드가 일치한다면 일치했을 때 접근 가능한 사이트로 보내줄 것이다. 그러나 이 상태에서 재요청을 한다면? 아이디와 패스워드가 사라진 상태로 요청될 것이다. 그렇기 때문에 scope가 필요해진다.

 

scope에는 네 가지가 있다. scope는 종류에 따라 나타나고 사라지는 시기가 다 다르다.

1. application : tomcat 시작할 때 생성, 끝날 때 삭제

2. session : request시 생성, 브라우저 종료 시 삭제

3. request : request시 생성, 다시 request 되면 삭제

4. page