■ 전반적인 동작구조

Requset -> filter(Character Encoding, CORS관련 제어)-> intercepter(인증,권한 관련) -> JSP(Servlet) ->response


■ Request

* 기본형태

Request-Line

*(( general-header | request-header | entity-header ) CRLF)

CRLF

[ message-body ]


* 예시

Get /test/test.htm HTTP/1.1 //Requset-Line

Accept: */*  //클라이언트가 허용할수 있는 파일형식. */*은 모든 파일형식 지원 의미

Accept-Language: ko //클라이언트가 인식할 수 있는 언어.

Accept-Encoding: gzip, deflate //클라이언트가 인식할 수 있는 인코딩방식.

If-Modified-Since: Fri, 21 Jul 2006 05:31:13 GMT  //페이지가 수정되었을 경우 최신 버전 페이지 요청을 위한 필드

If-None-Match: "734237e186acc61:a1b"

User-Agent: Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1) //브라우저 정보

Host: localhost    //요청한 서버의 HOST

Connection: Keep-Alive


Refer// 특정 페이지에서 링크를 클릭하여 요청할 경우, 링크를 제공한 페이지를 나타낸다.

Cookie : 웹서버가 클라이언트에 쿠키를 저장한 경우, 쿠키의 정보를 이름-값 으로 웹서버에 전송한다.



1. Requset Line

OPTIONS : 요청 URI에서 사용할 수 있는 Method를 물어본다.

GET : 요청 URI의 정보를 가져온다.

HEAD : GET 요청에서 body는 제외하고 헤더만 가져온다.

POST : 요청 URI의 리소스의 새로운 정보를 보낸다.

PUT : 요청 URI에 저장될 정보를 보낸다.

DELETE : 요청 URI의 리소스를 삭제한다.

TRACE : 보낸 메시지를 다시 돌려보낸다.

CONNECT : 프록시에 사용하기 위해 예약된 메서드이다.


*MIME

type/subtype으로 이루어진 방식. 해당 문서가 어떤 타입인지 알려주는 기능을 한다.

ex) text/plain, text/html, multipart/form-data


* 쿠키와 세션

공통점 : 방문자가 브라우저를 열어서 서버에 접속하여 로그인하는 순간.

차이점 : 쿠키(방문자의 정보, 브라우져 종료시 삭제)는 클라이언트에 정보 저장. 세션은 서버에 정보저장. 


2. Request.get

브라우저를 통해 서버에 요청. 이때 request객체에는 요청정보가 담겨있다.

getContextPath(): 컨텍스트패스 ex)localhost 를 얻는다.

getMethod(): 요청이 get방식인지 Post방식인지 구분한다.

getSession(): 세션 객체를 얻는다.

getProtocol(): 프로토콜이 뭔지 알 수 있다. ex)HTTP, SMTP

getRequestURL(): 요청 URL을 얻는다.(http:?/ 부터 시작되는 주소)

getRequestURI() 요청 URI를 얻는다.(상세 주소)

getRemoteAddr(): 서버와 연결된 클라이언트의 IP주소를 구한다.



3. Request Header

- 쿠키 : 웹브라우저의 정보를 웹브라우저에 저장한 후에, 서버에 보내는 요청에 웹브라우저 정보를 포함해서 전송한다. 서버는 요청시 포함된 웹브라우저의 정보를 보고, 동일한 웹브라우저로부터 온 요청인지 판단 가능하다. 사용자의 정보를 유지하는데 사용된다. 유효시간을 통해 생성, 삭제등을 제어한다.

- 캐시 : 사용자가 요청한 정보를 브라우저에 저장하고 나중에는 서버에 요청하지 않고도 브라우저에 저장된 정보 사용가능하여 속도향상. Cache-Control의 옵션을 통해 제어 가능

- 인코딩 : Content-Type의 charset 부분에서 UTF-8 등으로 해당 문서의 문자셋 지정 가능


4. Stateless의 특징

- 주소창에 GET이라는 REST STATE를 나타내는 것을 금지한다.

- ex)biz/plan/produce/order는 허용하지만 biz/plan/produce/getProduceOrder, detailList는 허용하지 않는다.


5. Servlet

- Servlet: 자바를 사용하여 페이지를 동적으로 생성하는 서버 프로그램.


■ Response

- 서버에서 client의 프로그램에게 어떠한 동작을 시킨다.


*기본형태

Status-Line

*(( general-header | response-header | entity-header ) CRLF)

CRLF

[ message-body ]


* 예시

HTTP/1.1 200 OK //HTTP 버전과 응답코드

Server: Microsoft-IIS/5.1   //웹서버의 정보

X-Powered-By: ASP.NET

Date: Fri, 21 Jul 2006 05:32:01 GMT //현재 날짜.

Content-Type: text/html   //요청한 파일의 MIME 타입

Accept-Ranges: bytes

Last-Modified: Fri, 21 Jul 2006 05:31:52 GMT  //요청한 파일의 최종 수정일

ETag: "689cb7f886acc61:a1b"  //캐쉬 업데이트 정보를 위한 임의이 식별 숫자

Content-Length: 101 //헤더 이후 이어지는 파일의 데이터 길이


■ MVC

- Model : Logic

- Conroller : 어떤 로직을 부를지 결정하는 명령어.

- View : Client Side.

- MVC 쓰는 이유 : 유지 ,보수, 변환시 사용이 쉬움. 모델의 변경 없이 컨트롤러, 뷰 만 바꿀 수있고, 재사용 가능. 


■ 필터와 인터셉터

- 필터: 전체 부분에 관한 제어. 문자셋이나 CORS에 관한 부분 

- 인터셉터는 특정 제어를 한다. 인증과 권한에 관련된 부분. 인증은 Session을 체크하여 설정. 권한은 권한체크 따로 있음.

request -> 필터처리 ->인터셉터-> 서버(JSP)<컨트롤러, 서비스, repository) -> Post Interceptor-> filter ->Response


■  MSA란(Micro Service Architecture)

- 하나의 서버에 모든 비즈니스로직이 들어가있는 Monoritic Architecture는 여러 기술 혼용해서 사용하기 어려움. 수정시 컴포넌트간 의존성을 고려해야한다. 

- 따라서 시스템을 독립된 여러개의 시스템으로 나누고, 이 서비스를 조합하는 아키텍쳐 디자인 패턴이 필요.

- MSA는 언어, OS, DB에 관계없이 조합이 가능한 단위의 서비스이다. 서로다른 시스템에서 선택한 기능들만 MSA로 만들고 MSA들을 합치면 새로운 시스템을 구성할 수 있는 구조이다,

- 서비스 : 단일 기능 묶음으로 개발된 서비스 컴포넌트. 데이터 독립적으로 가공, 저장. REST API 통하여 기능 제공


■ Platform>Framework(같은 언어로된 기능의 모임)>Component(기능의 모임)> Library(소규모 기능의 모임)

라이브러리가 바로 msa가 해당되는 부분이다.

Library, Plug In이 담당하는 부분은 기능이다. MSA로 디자인하면 Framework와 관계없이 library, plugin 을 따로 가져다 쓸수 있다.


■ 서비스의 구성

IaaS : AWS. 인프라를 구축하고 조작가능. 서버만 제공하고 나머지는 사용자가 구성

PaaS : Platform. 서비스를 사용자가 설정해서 사용. 플랫폼을 이용하여 응용프로그램을 개발할 수 있는 API까지 제공

SaaS : 클라우드 환경에서 동작하는 어플리케이션을 서비스 형태로 제공하는것. 카페24처럼 가입하고 제공되는 서비스를 사용만 하는 서비스. 


■ Docker : 클릭으로 서비스 구성가능.


■ WAS : 요청에 대하여 처리하고 응답하는 기능을 한다. 


DB관련

■ PreapareStatement와 Statement의 차이

1. Statement는 executeQuery()와 executeUpdate()를 실행하는 시점에 Parameter로 SQL문을 전달한다. 그러나 매번 컴파일 해야한다.

1
2
3
4
5
6
7
8
9
10
11
 <%
    Class.forName("org.h2.Driver");
    String user="sa";
    String password="";
    String url="jdbc:h2:~/test";
    JdbcConnectionPool cp= JdbcConnectionPool.create(url,user,password);
    String sql="SELECT * FROM TEST ORDER BY ID";
    Connection connection=cp.getConnection();
    Statement statement=connection.createStatement();
    ResultSet rs= statement.executeQuery(sql);
%>
cs


2. PreparedStatement는 쿼리문장분석->컴파일-> 실행을 한번만 수행하고 캐시에 담아서 재사용 가능. sql문을 preapareStatement로 컴파일해놓고 ? 부분에만 변화를 주어 계속 재사용이 가능하다. 쿼리에 들어갈 파라미터가 계속 바뀌거나 혹은 바뀌면서 반복해서 수행해야하는 경우 사용한다. 혹은 sql injection공격을 방지하고 싶을때 PreapredStatement를 사용한다.  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<%@ page import="java.sql.*" %>
<%
    request.setCharacterEncoding("UTF-8"); //받아오는 값들을 한글로 인코딩합니다.
 
    Class.forName("org.h2.Driver");
    String user="sa";
    String password="";
    String url="jdbc:h2:~/test";
   
    String inputTitle = request.getParameter("title");
    String inputAuthor = request.getParameter("author"); 
    String inputPassword = request.getParameter("password"); 
    String inputContent = request.getParameter("content"); 
    
    try {    
        Connection connection=DriverManager.getConnection(url,user,password);
        
        String sql = "INSERT INTO TEST(TITLE,AUTHOR,PASSWORD,CONTENT,HIT,DATE) VALUES(?,?,?,?,1,sysdate)";
        PreparedStatement pstmt=connection.prepareStatement(sql);
        
        pstmt.setString(1, inputTitle);
        pstmt.setString(2, inputAuthor);
        pstmt.setString(3, inputPassword);
        pstmt.setString(4, inputContent);
        
        pstmt.executeUpdate();
        pstmt.close();
        
        connection.close();
        } catch(SQLException e) {
            out.println( e.toString() );
        } 
 
%>
cs

■ Connection 관련

1. Conn을 종료해주지 않으면 서버에 연결이 상주하기 때문에 close를 해주어야 포트번호 재사용이 가능하다.

2. Connection Pool은 connection에서 session을 따서 쓰는것이다. 미리 연결된 connection에서 Session을 따서 쓸 경우 connection시 필요한 3-handshake과정을 생략해도 되기 때문이다. connection 비용이 크기 때문에 한 내용을 10개로 쪼개어 10번의 connection으로 받는것보다 한 내용을 1번의 connection으로 받고 그 이후에 나누는 것이 좋다. 


* XML은 오류를 허용하지 않지만 HTML은 오류를 어느정도 허용(실행은 가능하도록 만듬)

'Web Programming > HTML,JavaScript' 카테고리의 다른 글

[JavaScript] jQuery 알아두어야할 개념  (0) 2018.09.05
HTML Q&A  (0) 2018.03.18
Javascript Q&A  (0) 2018.03.18

+ Recent posts