초록꼬마의 devlog
article thumbnail

2021.12.29(수)

🌿 network/web 통신 개요

출처: 학원 강의 자료

🌿 서버 작업 환경을 위한 Eclipse workspace 세팅 및 서버 생성

  1. 새로 workspace(작업환경) 만들어서 Eclipse로 열기
  2. workspace 세팅하기
    2a) 웹 어플리케이션 작업을 위해 Java EE 환경으로 설정(기본값)
    2b) Window > Show view -> 보여질 UI tabs(폴더 구조를 더 명확하게 보기 위한 navigator, console, problems, servers) 세팅
    2c) encoding 설정 및 서버 runTime environments 세팅
    2c-1) Window > preferences -> utf-8로 encoding 설정 등
    2c-2) 서버 runTime 잡기: Eclipse에서 서버를 실행할 수 있도록 연동하는 과정
  3. server 생성
    3a) navigator에서 마우스 오른쪽 클릭 -> new > server
    3b) 기본적으로 과정2c-2)에서 세팅해둔 runTime이 잡혀있을 것; server name만 변경 가능
    3c) finish
    3d) 'servers' tab에 만들어진 서버 double click -> 생성된 서버 수정 -> ctrl+s로 수정 사항 저장 -> 'servers' tab 서버 republish로부터 'synchronized'로 변함
    3d-1) 포트 번호 재설정: http/1.1의 기본값으로 잡혀있는 8080 포트가 오라클 포트와 동일하므로 충돌이 발생할 수 있음 -> 8080을 8888로 변경
    3d-2) ☆☆중요☆☆ 화면 왼쪽 하단 Server Options에서 serve modules without publishing 체크 -> 이걸 안 하면, 컴파일된 파일들이 output folder에 잘 안 가는 경우가 생길 수 있으므로, 꼭! 체크
  4. dynamic web project(동적인 웹 어플리케이션) 만들기/생성
    4a) 프로젝트명 신중하게 작성 -> next
    4b) default output folder(=컴파일된 파일들을 어디에 저장할 것인가) 경로 WebContent/WEB-INF(이상 기본적으로 만들어지는 경로)/classes로 재 설정 -> next
    4c-1) context root: 이 어플리케이션만의 고유한 이름/별칭(으로 지어줄 것) != 프로젝트명; 가장 최상위단, 뿌리, 시작점; 기본값 = 프로젝트명 -> 보통 재정의함; 보안 상 어떤 프로젝트로 만들었는지 사용자들이 알면 안 되므로, 원래는 재정의 필수
    4c-2) content directory(실제로 배포되는/서버에 올라가는/최상위에 존재하는 폴더) 이름 지정: default output folder의 WebContent 폴더로 지정
    4c-3) 'generate web.xml deployment descriptor(배포 서술자)' 무조건 체크하기(기본적으로 체크 안 되어있음) -> web.xml = 해당 어플리케이션에 대한 기본적인 전체 (환경)설정 정보를 가지고 있는 파일; 서버 실행과 동시에 main page를 지정해줌
    4d) finish
  5. 새롭게 만들어진 project 확인
    5a) 프로젝트 > WebContent > WEB-INF > classes 폴더가 잘 만들어졌는지 확인 vs 잘 안 만들어졌다면 과정4b)에서 오타 쓴 것
    5b) 프로젝트 > WebContent > WEB-INF > web.xml 문서가 잘 만들어졌는지 확인
    5c) 꼭 WebContent 폴더 내부에 index.html 파일(welcome file) 만들기
  6. 생성해둔 서버에 어플리케이션 올리기: 'servers' tab의 서버 오른쪽 클릭 -> add and remove -> 올리고자 하는 어플리케이션 선택 후 add 버튼 누르기 -> finish
  7. server start('servers' tab 우측 상단의 초록색 'start the server' 버튼 클릭) 후 웹 어플리케이션 요청(request; 현재 어플리케이션의 경우 브라우저 주소창에 http://localhost:8888/1_Servlet 입력/접속)해서 index가 잘 열리는지 확인

 

🌿 Servlet 개요

🌱 web.xml

  • 배포 서술자(DD, deployment descriptor)

xml = extensible(확장) mark-up language -> 마크업 언어의 일종 -> html 문서처럼 생김

  • 해당 웹 어플리케이션의 기본적인 전체 (환경)설정을 위해 작성하는 파일/설정 정보를 가지고 있는 파일
  • 서버 실행과 동시에 main page를 지정해줌 <- 해당 웹 어플리케이션을 구동시키는 서버가 start 시 제일 먼저 읽혀지는 파일 cf. Java 프로그램 실행 시 entry point = main() 메소드
  • 개발자가 web.xml 파일을 수정하지 않고도 개발 및 운영이 가능하지만, 규모가 커지고 다양한 API들을 사용하게 되면 직접 수정해야 하는 경우도 생김
  • welcome-file: 처음에 url로 해당 이 어플리케이션 루트(root, 뿌리, 시작점) 요청 시 제일 처음 보여지게 되는 main page를 지정해놓는 것 + 반드시 WebContent 폴더 안에 위치해야만 함 e.g. index.html

dynamic web project 새로 만들 때 context root = 이 어플리케이션만의 고유한 별칭 → 어떤 프로젝트로 만들었는지 사용자들이 알면 안 되므로, 원래는 재정의 필수

  • http://구동 중인 서버의 ip주소(pc/컴퓨터마다 가지고 있는 주소):포트 번호(포트 번호 따로 안 적으면 기본적으로 80(웹서비스) 포트로 감)/
    e.g. http://localhost(현재 내 컴퓨터의 주소):8888(내 컴퓨터의 서버의 포트 번호)/1_Servlet(context/어플리케이션 루트 = 시작점) -> 브라우저 주소창에 이 주소를 입력 = Tomcat 서버에 요청을 보냄

🌱 Servlet

  • 웹 서비스를 위한 'Java 클래스'(를 하나 만들어둔 것) -> Java를 이용해서 웹을 만들기 위해 필요한 기술
  • 사용자의 요청을 받아서 처리하고, 그에 해당되는 응답 페이지를 만들어 다시 사용자에게 전송해주는 역할을 하는 Java 클래스; JDBC의 controller
  • 웹에서 동적인 페이지를 Java로 구현할 수 있게 해주는 서버 측 프로그램; WAS에서 구동됨
  • 웹페이지 구현을 위해 최소한으로 필요한 것 = html -> Servlet의 역할 = Java 클래스에서 웹페이지 구현을 위해 html을 구현할 수 있음

✔️ 사용자가 요청을 보내는 방식

  1. url -> 웹서버가 welcome page를 보내줌
  2. form 태그 = action 속성(요청할 Servlet에 mapping할 값) + method 속성(get/post)

🌱 get 방식 요청 test

  • 특징
  1. get 방식으로 요청하는 건 url의 header 영역에 데이터를 포함시켜서 요청함 -> 사용자가 입력한 값/데이터가 url에 노출됨 -> 보안에 취약함 -> 로그인, 회원 가입 등의 경우 get 방식은 부적합함
  2. header 영역은 전송하는 데이터의 길이에 제한이 있음 -> 방대한 데이터를 담았을 경우 초과된 데이터는 절단되어/잘려서 넘어감 -> 게시판 작성 등의 경우 get 방식은 부적합함
  3. url 데이터가 노출되기 때문에 즐겨찾기/bookmark 기능(url을 저장/즐겨찾기 해두었다가, 필요할 때 클릭하면 해당 그 url 재요청/이동 가능) -> 검색 기능의 경우 get 방식이 가장 적합함
  • Servlet 클래스: get 방식으로 요청했으면 doGet() 메소드가 호출됨
    • 첫번째 매개변수 HttpServletRequest request에는 요청 시 전달된 내용들(사용자가 입력한 값 e.g. form 태그 key+value 세트, 요청 전송 방식(get/post), 요청한 사용자의 ip 주소 등)이 담김
    • 두번째 매개변수 HttpServletResponse response는 요청 처리 후 응답을 할 때 사용하는 객체
  • 요청 처리 과정
  1. 요청을 처리하기 위해, 요청 시 전달된/사용자가 입력한 값들(request의 parameter 영역 안에 존재하며, key(name 속성 값)-value(value 속성 값) 세트로 담겨있음)을 뽑음
    • request.getParameter("키 값") -> 그에 해당하는 value 값; 반환형 = String; 무조건 문자열 형으로 반환되기 때문에, 다른 자료형으로 변경하려면 파싱해야 함
    • request.getParameterValues("키 값") -> 그에 해당하는 value 값; 반환형 = 문자열 배열 String[]; 하나의 key 값으로 여러 개의 values를 받는 경우(e.g. checkbox) 문자열 배열형으로 반환 가능
  2. 뽑아낸 값들을 가지고 (그냥 넘기거나 ou 가공해서) 요청 처리함(service -> DAO -> DB)
  3. 처리 결과에 따른 성공/실패 페이지 응답 <- 요청 페이지(x) view에 보여줄 내용(o)을 돌려주는 것
- JSP가 나오기 전(옛날에 사용하던 방식 = Servlet이 먼저 나왔기 때문에 Servlet만 이용) Java를 이용해서/Java 코드 안에 html 코드(+css, script도 가능)를 넣어서 응답 페이지 넘기기
- 장점: Java 코드 내에서 작성하기 때문에, 반복문, 조건문, 유용한 Java 메소드들 활용 가능
- 단점: 아주 복잡함 + 혹시라도 html을 수정하고자 할 때, Java 코드 내에서 수정이 이루어지기 때문에 수정된 내용을 다시 반영시키려면 서버를 restart(해당 어플리케이션을 사용하던 사람들의 사용도 한 번 끊김)해줘야 함 + 유지/보수 어려움

 

좋은 코드 = business logic과 presentation logic(보여지는 것)의 분리 vs 이 방식은 분리 안 됨

💻 예시 - 개인 정보 입력 Form

  • form 태그 내의 제출(submit) 버튼 클릭 시, form 태그의 속성 중 action에 작성된 url(=요청할 Servlet에 mapping할 값)로 요청/제출됨 = controller(Servlet) 호출
  • Servlet 요청의 경우, 반드시 그 요청 값이 현재 웹 어플리케이션의 context path(/context root/ 뒤에 붙는 경로) 형식으로 지정해줘야 함
    e.g. http://localhost:8888/1_Servlet/test1.do(Servlet의 url mapping 값)
  • form 태그로부터 넘길 자료 = key(name 속성의 값) + value(value 속성의 값)

경로 지정 방식

  1. 절대 경로 방식(/로, 또는 더 엄밀히 말하자면 root부터, 시작): /context root/요청할 url
    e.g.
  2. 상대 경로 방식(test1.do): 요청할 url; 나를 기준으로

- 자주 보는 오류 -> 오류는 고치면 되므로 + 공부(문제가 왜 발생했고, 어떻게 해결하는지 정리/숙지) 기회가 되므로, 오류 발생을 담담하게 받아들이자(화/짜증 날 수는 있음)(o) 무서워하기(x)
- 404: 파일이나 Servlet을 못 찾았을 때 발생 <- 경로가 잘못되었거나, 또는 파일명에 오타
- 500: server단 Java 소스코드 상의 오류(예외 발생 등) e.g. null pointer, file(properties 파일 등) not found, sql exceptions..

📗 homework: JavaScript 평가 준비