서블릿을 시작하기 전에 웹 어플리케이션 및 기초적 용어와 과정에 대해서 공부를 시작해보고자 한다.
웹 애플리케이션을 개발하다보면 다음과 같은 용어에 대해서 정리할 필요가 있게된다.
SOAP(Simple Object Access Protocol)과 RESTful(REpresentational State Transfer)에 대해서 아는가?
SOAP
일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜. SOAP은 프로그래밍 언어마다 지원해주는 것이 필요하다.
REST
기본 HTTP 프로토콜의 메소드 GET/PUT/POST/DELETE를 이용하여 서비스 제공자에게 서비스를 요청하여 JSON, XML, RSS 등으로 리소스를 반환하는 것을 말한다. 프로그래밍 언어에 독립적이다.
프록시서버(Proxy Server)란 무엇인가?
클라이언트와 서버 사이에서 통신을 중계해 주는 컴퓨터나 프로그램을 말한다.
프록시 서버는 두는 이유
1) 빠른 전송을 위하여 서버의 응답 결과를 캐시해 두는 것
예를 들어 클라이언트의 요청이 이전에 프록시 서버에 캐시되어있다면 서버에 요청을 생략하고 바로 응답해 줄 수 있게 된다.
2) 보안상의 이유로 프록시 서버를 둔다.
외부로 전달되는 데이터를 검사하여 특정 단어가 포함된 자료의 송, 수신을 차단하거나 보안 팀에 경고메시지를 전달 할 수 있게 된다.
웹 환경에서의 Server-Client 구조의 장점
이전의 서버 - 클라이언트 구조는 비즈니스 로직이 클라이언트에 있었기 때문에
변경이 필요하게 되면 클라이언트의 프로그램을 다시 깔아야 한다.
하지만 웹 환경에서의 서버 클라이언트의 구조에서는 클라이언트는 UI의 역할만 하게 된다.
변경이 필요하더라도 서버에서만 바꾸어주면 된다.
배치하는 즉시, 사용자는 재설치 없이 추가된 기능이나 변경된 기능을 이용할 수 있게 된다.
단점 : 다만 웹을 사용 할 때마다 UI를 계속 다운받는 형식이기 때문에 네트워크 오버헤드가 큰 편이다.
전통적인 서버-클라이언트 구조의 단점을 내세우며,
웹 환경의 서버 클라이언트 구조에 대해서 설명해본다면...
웹 환경에서의 서버 클라이언트의 구조(CS) 역시 단점 존재. 매번 클릭할때마다 UI를 다운 받아야한다.
하지만, 이러한 단점을 보완하고자 AJAX(Asynchronous Javascript And Xml) 등장
AJAX는 페이지를 전체를 갱신하는 것이 아니라 부분, 부분 갱신할 수 있게 해준다.
HTTP 프로토콜 이란?
HTTP 프로토콜은 웹 브라우저와 웹 서버 사이의 데이터 통신 규칙을 말한다.
즉 HTTP 통신 규약에 맞추어서 요청한다면
HTML파일을 요청하면 HTML파일을 보내주고, 이미지 파일을 요청하면 이미지 파일을 보내준다는 것이다.
http요청 응답에 대한 내부적으로 어떻게 동작하고 있는가?
요청과정(Request)
요청라인, 요청헤더, 공백라인과 요청 데이터로 구성
GET /web04/member/list HTTP/1.1 Host: localhost:9999 Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.132 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4 | cs |
요청 라인(Request-Line)
요청헤더
* 요청이나 응답 모두에 적용 할 수 있는 "일반헤더(General Header)"
* 요청 또는 응답 둘 중에 하나에만 적용 할 수 있는 "요청 헤더 또는 응답 헤더(Request Header / Response Header)"
* 보내거나 받는 본문 데이터를 설명하는 "엔티티 헤더(Entity-Header)"
HTTP헤더들
헤더 유형 |
헤더명 |
일반헤더 (General Header Fields) |
Cache-Control Connection Date Pragma Trailer Transfer-Encoding Upgrade Via Warning |
요청헤더 (Request Header Fields) |
Accept Accept-Charset Accept-Encoding Accept-Language Authorization Expect From Host If-Match If-Modified-Since If-Range If-Unmodified-Since Max-Forwards Proxy-Authorization Range Referer TE User-Agent |
응답헤더 (Response Header Fields) |
Accept-Ranges Age ETag Location Proxy-Authenticate Retry-After Server Vary WWW-Authenticate |
본문헤더 (Entity Header Fields) |
Allow Content-Encoding Content-Language Content-Location Content-MD5 Content-Range Content-Type Expires Last-Modified 기타확장헤더 |
GET요청
공백 라인으로 끝납니다. 서버에 보낼 데이터가 있다면 URL주소에 붙여 보냅니다.
POST요청
그에 비해 로그인이나 게시글을 등록하는 경우 POST를 사용하는데, POST요청은 공백 라인 다음에 메시지 본문이 들어갑니다.
응답과정(Response)
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=UTF-8 Content-Length: 1138 Date: Sun, 12 Jul 2015 07:16:42 GMT <html><head><title>회원목록</title></head> <body><h1>회원목록</h1> .........<생략> | cs |
상태라인
응답 메시지의 첫 라인은 응답 결과에 대한 상태 정보. 프로토콜 버젼과 상태 코드, 설명으로 구성
상태코드 |
상태설명 |
200 |
요청이 성공 이루어졌다. |
301 |
요청한 자원이 이동되었다. 헤더 정보에 이동 위치를 알려줄 테니 다시 요청하라. |
304 |
클라이언트가 임시 보관한 응답결과에 다르지 않다. |
400 |
잘못된 요청이다. |
404 |
요청한 자원을 못 찾았다. |
500 |
서버 내부에서 오류가 발생했다. |
GET과 POST 요청 방식의 차이는 무엇인가?
URL에 데이터가 있는 것은 GET방식, URL에 데이터가 없고 메시지 본문에 있는 것은 POST방식
GET요청의 특징
- URL에 데이터를 포함 - 데이터 조회에 적합
- 바이너리 및 대용량 데이터 전송 불가
- 요청라인과 헤드 필드의 최대 크기
* HTTP 사양에는 제한사항 없음
* 대용량 URL로 인한 문제 발생 => 웹 서버에 따라 최대 크기 제한
* 마이크로소프트 IIS 6.0 16KB
* APACHE 웹 서버 8KB
GET요청의 데이터 전달 형식은 어떻게 되는가?
서비스 주소 ? V1 = 23 & V2 = 15
서비스주소와 데이터를 ? 라는 문자를 이용해서 구분한다.
예) http://www.naver.com?v1=23&v2=15
GET 요청의 장점은 무엇인가?
URL에 데이터가 섞여 있기 때문에 결과 화면을 다른 사람들과 공유 할 수 있다.
링크를 클릭하게 되면 바로 결과화면을 볼 수 있다.
GET 요청의 문제점은 무엇인가?
(1) 보안에 좋지 않다.
주소에 데이터가 섞여있기 때문에 사용자의 로그인이나 중요 정보 요청에서 데이터가 밖으로 보인다.
그렇기 때문에 보안상의 이슈가 발생 할 수 있다.
(2) 바이너리 데이터를 전송 할 수 없다.
파일의 데이터는 URL에 붙여서 전송 할 수 없다.
BASE 64라는 인코딩 방식을 통해 바이너리 데이터를 문자화해서 보낼 수도 있지만, URI나 헤더 정보가 너무 크면
웹 서버에서 처리 할 수 없다.
이런 것은 POST를 통해 전송해야 한다.
POST요청의 특징
- URL에 데이터가 포함되지 않음 => 외부 노출 방지
- 메시지본문에 데이터 포함 => 실행 결과 공유 불가
- 바이너리 및 대용량 데이터 전송 가능
POST요청의 요청은 어떻게 이루어지는가?
요청라인과 요청헤더 다음에 공백라인이 있고 그 다음에 메시지 본문(Message Body)라 불리는 부분에 데이터가 위치해서 전송된다.
POST요청의 장점은 무엇인가?
입력값을 URL에 노출 시키지 않는다. 당연히 보안상으로 GET에 비해 좋다.
폼 태그를 통해 보내진 POST데이터는 Content-Length 와 Content-Type 등으로 구분한다.
Content-Type은 기본적으로 application/x-www-form-urlencoded형식으로 인코딩되어 보내진다.
POST요청의 문제점은 무엇인가?
(1) 요청 결과를 공유 할 수 없다.
즐겨찾기, 메일 등으로 그 결과값을 공유 할 수 없다.
POST요청은 데이터를 메시지 본문에 붙여서 전송하기 때문이다.
(2) GET방식과 마찬가지로 POST도 데이터를 전달 할 때 '이름=값&이름=값'형태로 보내진다.
결국 문자데이터를 보낼 때는 상관없지만 바이너리 데이터 등을 전송할 때는 이러한 '='이나 '&'값이 섞여 있을 수 있기 때문에 문제가 발생할 수 있다.
그래서 바이너리 데이터 등을 보낼 때는 멀티 파트 인코딩 방식을 통해 보내야 한다.
멀티 파트 인코딩 방식은 어떨때 사용하며 그렇게 사용하는 이유는 무엇인가?
POST형식 역시 데시지 본문에 '이름=값&이름=값'형태로 보내지기 때문에
바이너리 데이터에 혹시 = 이나 &가 섞여있으면 문제가 발생 할 수 있다.
그래서 멀티 파트 인코딩 방식을 사용하여 요청정보와 데이터를 확실히 구분 할 수 있게 한다.
예를들어 <form>태그의 enctype 속성을 'multipart/form-data'로 지정해서 file 전송을 할 수 있게 합니다.
