프로가 되기 위한 웹 기술 입문

감상평

도서관에서 가볍게 볼만한 책을 찾다가 읽게 되었습니다.
280 페이지 정도의 분량이지만, 일본책 답게 적절한 삽화가 포함되어 있으며 포괄적인 내용을 담고 있어서
3~4시간 정도면 정독하실 수 있습니다.

책은 WEB의 발전에 따른 기술 사항을 차근차근 설명하고 있습니다.
개인적으로 1994년에 모자이크로 WWW을 접한 이후, 2000년부터 웹개발을 시작했기 때문에 책 내용을 보면서 지난 10년의 회고되는 느낌을 받았습니다.
번역서로서 2012년에 초판이 출시되었지만, 책 내용은 2010년까지의 웹 기술을 다루고 있습니다.
대표적으로 요즘 가장 hot한 Spring Framework에 대한 얘기가 없지요. 대신 Struts를 다루고 있습니다.

그동안 조각난 개념들로 알고 있던 WEB 기술들을 시간의 흐름에 따른 발전에 맞춰 서술하고 있으므로,
웹 개발자들은 가볍게 읽어보셔도 좋을듯합니다.

소스코드 : http://wikibook.co.kr/webtext/

2014-08-20 21.41.49

목차

Lesson 0 프롤로그

  • 웹 애플리케이션 개발 기술은 어디서 배우는가?
  • 왜 여러분은 웹 애플리케이션 개발 기술을 배우지 못하는 것일까?
  • 대상 독자
  • 이 책을 읽을 때 필요한 사전 지식
  • 가장 효율적으로 기술을 배우는 방법

Lesson 1 웹 애플리케이션이란 무엇인가?

  • 1.1 데스크톱 애플리케이션
  • 1.2 웹 애플리케이션
  • 1.3 정리
  • 데스크탑 애플리케이션 : PC에서 동작, OS에서 표시, 설치 필요
  • 웹 애플리케이션 : 서버에서 동작, 웹브라우저에서 표시, 설치 불필요

Lesson 2 웹은 어떻게 발전했는가?

  • 2.1 WWW의 탄생과 보급
    • 전 세계의 컴퓨터를 연결하는 인터넷
    • 인터넷 보급의 견인차 월드 와이드 웹과 모자이크
    • WWW의 탄생
    • 현대 웹 브라우저의 시조인 NCSA 모자이크
  • 2.2 웹을 뒷받침하는 기술의 발명
    • 웹 서버와 웹 클라이언트
    • 왜 클라이언트와 서버로 나누는가?
    • ‘그 리소스는 어디에 있지?’ – URL
    • HTTP
  • 2.3 CGI의 탄생
    • 동적인 콘텐츠에 대한 요구
    • CGI의 탄생
    • 웹의 폭발적인 보급
  • 2.4 서블릿의 등장
    • CGI를 둘러싼 문제점
    • 자바/서블릿의 탄생
    • 자바로 애플리케이션을 개발할 때의 이점
  • 2.5 JSP의 탄생
    • 서블릿의 문제점
    • 발상의 전환! JSP의 탄생
  • 2.6 웹 애플리케이션 프레임워크의 시대
    • 서블릿과 JSP의 문제점
    • 웹 애플리케이션 프레임워크의 탄생
  • 2.7 정리
  • ARPANET 네트워크 : 1969년, 미 국방성의 연구/조사 목적, 인터넷의 원형
  • WWW : 1989년, 버너스 리, HTML의 하이퍼 링크 구조
  • NCSA 모자이크 : 1993년, 문자와 그림을 표현할 수 있는 웹 브라우저
  • 웹서버 & 웹 클라이언트 구조
  • URL : 리소스의 위치를 지정, http:(스킴)//www.kimstar.kr(호스트명)/index.html(경로명)
  • CGI : 동적 컨텐츠에 대한 요구 발생, C / Perl, 웹서버가 필요시 C/Perl 프로그램을 실행
  • Java Servlet : CGI의 문제(성능), 웹 컨테이너 안에서 서블릿이 실행되므로 매번 새로운 프로세스 기동할 필요 없음, Java로 개발하여 특정 OS/HW 비 종속적
  • JSP : Servlet은 java로 html 코드 생성, JSP는 html 안에 java코드(Scriptlet,스크립트릿) 삽입
  • 웹 애플리케이션 프레임워크 : 대규모 시스템, 재활용성

Lesson 3 HTTP를 이해하자

  • 3.1 왜 HTTP를 알아야 하는가?
  • 3.2 웹 브라우저와 웹 서버의 통신을 엿보자
    • 피들러 설치
    • HTTP 통신을 엿보자
    • HTTP 요청을 엿보자
    • HTTP 응답을 엿보자
    • HTTP에서는 한 번에 리소스 하나를 취득한다
    • 파일명을 생략했을 경우의 요청
  • 3.3 정보는 어떻게 인터넷의 대해를 건너는가?
    • 인터넷상의 주소-IP 주소
    • IP 주소에 의지해 정보를 보내는 TCP/IP
    • IP 주소는 누가 결정하는가?
    • 글로벌 IP 주소와 사설 IP 주소
    • 호스트명을 IP 주소로 변환하는 DNS
    • DNS는 어떻게 구현되는가?
    • 호스트 내의 수신처를 결정하는 포트 번호
  • 3.4 웹 서버에 요청을 어떻게 전달하는가?
    • GET 메서드를 이용한 매개변수 전달
    • 애플리케이션 측의 매개변수 받기
    • POST 메서드를 이용한 매개변수 전달
    • GET과 POST 중 어느 쪽을 사용해야 할까?
    • 한글은 어떻게 전달해야 하는가?
  • 3.5 정리
  • NanumGothicBold 피들러(fiddler) : 무료 웹 디버깅 툴, http://www.telerik.com/fiddler
  • URN은 리소스가 이사함을 대비하여 통일된 이름을 정하기 위해 나왔으나 잘 사용되고 있지 않으므로, URI가 거의 URL과 같은 의미로 사용된다.
  • 요청 헤더 : GET(메서드) http://kimstar.kr(URI) HTTP/1.1(HTTP버전)
  • 응답 헤더 : HTTP/1.1(HTTP버전) 200(상태코드) OK(응답구문)
  • http 안에 img가 있으면, img에 대한 URL에 대해 다시 요청한다.
  • HTTP 통신은 TCP/IP 기반으로 패킷으로 나뉘어 전송됨 : IP 주소, DNS, DNS 서버, 포트번호
  • GET 메소드로 매개변수 전달 : URL 뒤에 쿼리문자열 전달(?arg1=123&arg2=456), 매개변수 길이 제한 있을 수 있음. 즐겨찾기에 용이. 부작용이 없음이 기대된다.(같은 요구를 반복해도 항상 같다)
  • POST 메소드로 매개변수 전달 : 요청 메시지 본문에 전달 (arg1=123&arg2=456), 매개변수 길이 제한 없음. 매개변수가 URL 로그에 남지 않음. 부작용이 없음이 기대되지 않는다.
  • 퍼센트 인코딩 : URL에서 사용할 수 있는 문자 제한으로, 한글은 문자코드를 16진수로 변환하여 표시

Lesson 4 CGI에서 웹 애플리케이션으로

  • 4.1 배달 피자 주문 사이트를 만들자
  • 4.2 화면 구성
  • 4.3 화면 모형
  • 4.4 로그인 인증 기능
    • PHP로 인증 기능을 만들자
    • 인증 기능의 동작을 확인하자
    • 리다이렉트 동작의 HTTP 통신을 확인하자
  • 4.5 로그인 상태를 어떻게 기억할 것인가?
    • 상태 유지 프로토콜과 무상태 프로토콜
    • 무상태인 HTTP상에서 상태를 어떻게 표현할 것인가?
    • 쿠키를 이용해 상태를 보존한다
    • 실제 쿠키 이용을 확인한다
  • 4.6 안전하게 상태를 보존하기 위한 기술 -세션
    • 쿠키를 둘러싼 문제점
    • 은행의 창구 업무를 통해 세션을 이해하자
    • 계좌 개설 업무의 진행 상황을 어떻게 관리하는가?
    • 세션으로 처리 진행 상황을 관리한다
    • 세션의 상태를 어디에 보존할 것인가?
    • HTTP에서의 세션 ID 전달 방법
    • 실제 웹 애플리케이션에서의 세션 ID 활용
    • 세션 ID를 이용한 사용자 식별
  • 4.7 피자 펜토미노의 완성
  • 4.8 정리
  • 리다이렉트 : 브라우저가 302응답을 받으면 메시지 본문의 Location에 표시된 URL로 다시 요청한다.
  • PHP엔진은 아파치(웹서버)의 모듈(mod_php5)의 형태로 탑재되어 별도의 프로세스를 기동할 필요없이 빠르게 실행된다.
  • HTTP는 무상태 프로토콜이다. 이전 상태를 기억하기 위해서는 쿠키를 이용한다. (Cookie: user=kimstar; pass=1234). 쿠키를 받은 브라우저는 요청시 같은 서버에서 받은 쿠키를 전달한다.
  • 쿠키 : 넷스케이프에서 사용한 기술. 다른 브라우저에서도 채용되었고, RFC2695로 표준화됨. 쿠키는 브라우저에서 최종적으로 파일로 보존하므로 보안 문제가 있다.
  • 세션 : 세션ID 기반으로 정보를 서버의 메모리에 저장한다 –> 세션ID를 쿠키로 브라우저에 전달한다 –> 브라우저는 세션ID를 저장한 쿠키를 요청시 건넨다 –> 서버는 세션ID 기반으로 동작.
  • Form 인증(form으로 구성하여 다양한 항목의 인증 가능) / Basic 인증(http 규격의 일부, 이름과 비밀번호만 입력, 브라우저마다 디자인이 다르게 표시)

Lesson 5 웹 애플리케이션의 구성 요소

  • 왜 웹 애플리케이션의 구성을 이해해야 하는가?
  • 5.1 웹 서버와 웹 클라이언트의 시대
    • WWW의 여명기
    • CGI의 시대
  • 5.2 데이터베이스 서버의 등장
    • 대량의 정보를 어떻게 관리할 것인가?
    • 데이터베이스 관리 시스템의 등장
    • 데이터베이스에 대한 조작
    • 데이터베이스를 이용한 정보의 관리
    • 데이터베이스에서 정보를 추출한다
    • 필요한 정보를 SQL로 데이터베이스에 전달한다
    • 데이터베이스와 클라이언트의 관계
    • 데이터베이스 서버의 분리
    • 웹 애플리케이션과 데이터베이스의 통신
  • 5.3 애플리케이션 서버의 등장
    • 서블릿이나 JSP는 어디에서 작동하는가?
    • 서블릿/JSP를 작동시키기 위한 애플리케이션 서버
    • 웹 서버와 애플리케이션 서버의 연동
    • 웹 서버와 애플리케이션 서버의 분담
    • 웹 서버와 애플리케이션 서버 연동의 이점
    • 여러 톰캣에 전송하기
    • 웹 서버의 기능을 가진 애플리케이션 서버
  • 5.4 웹 시스템의 삼층 구성
    • 최소 구성의 웹 시스템
    • 일반적인 구성
    • 웹 시스템의 삼층 구성
  • 5.5 정리
  • 정적 컨텐츠 : 웹서버만 필요
  • 동적 컨텐츠 : CGI로 별도의 프로세스를 구동하여 html 생성
  • 대량 정보 필요 : 데이터베이스로 CRUD처리, DBMS는 별도의 프로세스로 동작하며, DB서버로 물리적으로 분리하기 시작
  • 애플리케이션 서버 : JSP/서블릿을 작동. 웹서버(apache)에서 애플리케이션 서버(tomcat)과 연동모듈(mod_jk)를 사용하여 연동(ajp13 프로토콜, TCP/IP기반)
  • 서버의 분리 : 웹서버는 정적 컨텐츠 처리(요청횟수 많음, 가벼운 처리), 애플리케이션 서버는 동적 컨텐츠 처리(요청회수 적음, 무거운 처리)
  • 단순한 구성 : 애플리케이션 서버(tomcat)에서 웹서버 기능을 가지고 있어 단독으로 처리 가능. 소규모 웹시스템 / 테스트 환경
  • 삼층 구조 (일반적인 구성) : 브라우저 <-> 웹서버 <-> 애플리케이션 서버 <-> DB 서버, 웹 서버/ 애플리케이션 서버/ DB 서버는 물리적으로 분리되거나 함께 있을 수 있음

Lesson 6 웹 애플리케이션을 효율적으로 개발하는 방법

  • 6.1 서블릿/JSP만으로는 부족한가?
    • 웹 애플리케이션 개발의 표준 – 자바
    • 서블릿과 JSP의 연동
  • 6.2 서블릿/JSP를 이용한 피자 펜토미노의 로그인 처리 구현
    • JSP를 통한 로그인 화면 표시
    • 서블릿의 호출
    • 로그인 서블릿의 처리
    • 포워드와 리다이렉트의 차이
    • 요청 스코프에서의 정보 전달
    • JSP의 요청 스코프에서 정보를 꺼내기
    • 왜 요청 스코프가 필요한가?
    • 세션 스코프와 요청 스코프의 차이
  • 6.3 웹 애플리케이션의 아키텍처
    • 로직과 디자인의 분리
    • 소프트웨어의 건축 양식
    • 피자 펜토미노의 구조를 살펴보자
    • MVC 모델에 따른 웹 애플리케이션의 아키텍처
    • MVC 모델에서의 처리 흐름
  • 6.4 프레임워크를 통한 아키텍처의 구현
    • 프레임워크란 무엇인가?
    • 스트러츠를 이용한 MVC 모델의 구현
    • 스트러츠를 이용한 피자 펜토미노의 로그인 처리
    • JSP에서의 로그인 처리 액션 호출
    • 로그인 처리 액션에서의 로그인 확인 처리
    • 상품 목록 화면으로 이동
  • 6.5 레이어 패턴에 따른 데이터 액세스 계층의 분리
    • 모델을 어떻게 구현할 것인가?
    • JDBC를 이용해 데이터베이스에서 정보를 가져온다
    • 레이어 패턴에 따른 데이터 액세스 계층의 분리
    • DAO 패턴을 이용한 데이터 액세스 레이어의 구현
  • 6.6 O/R 매핑 프레임워크를 이용한 데이터 액세스 레이어 구현
    • O/R 매핑 프레임워크의 필요성
    • RDB와 객체의 임피던스 불일치
    • 아이바티스를 이용한 O/R 매핑의 실제
    • 데이터 매퍼와 SQL 맵 파일을 이용한 O/R 매핑 처리
    • Dao 프레임워크를 이용한 DAO의 작성
  • 6.7 프레임워크 이용의 장점과 단점
    • 프레임워크 이용의 장점
    • 프레임워크 이용의 단점
  • 6.8 정리
  • JSP는 HTML 표시 담당, 애플리케이션 처리는 서블릿에서 담당
  • 서블릿 호출 : 웹서버에서 URL(login.do)을 서블릿(LoginServlet)으로 호출하기 위해서는 매핑을 web.xml에 정의하여야 한다.
  • forward / redirect : redirect는 브라우저가 다시 요청(2번 요청 2번 응답), forward는 서버 내부에서만 이동처리한다. (1번 요청 1번 응답)
  • 요청 스코프 (Request Scope) : 브라우저에서 GET/POST로 전달한 요청값을 1회 동안 저장하여 처리.
  • 세션의 문제점 : 세션이 더이상 사용되지 않음을 정확히 서버에 알리기 힘듬. 서버에서는 마지막 사용한 세션 시간을 기록하고 일정시간 경과하면 삭제한다. (Session Timeout)
  • 세션 스코프 (Session Scope) : 세션의 시작/종료는 애플리케이션 서버의 PHP와 같은 실행엔진에서 처리. 로그인/장바구니 등에 사용.
  • 세션 ID 구현방법 : 애플리케이션 서버마다 다름. 쿠키를 사용하거나(쿠키에 세션ID 저장) GET의 매개변수를 사용하거나 (PHP에서는 PHPSESSID 매개변수를 요청하도록 form 태그가 자동 작성), 필요시 두개를 혼용
  • MVC 패턴 : 로직과 디자인의 분리. M(Model : 애플리케이션 처리만 담당, 화면처리 안함), V(View : 화면의 처리만 담당, 애플리케이션 처리 안함), C(Controller : 전체의 흐름을 제어, 뷰와 모델을 연결)
  • Struts : 프레임워크는 공통된 뼈대. Struts는 웹 애플리케이션 프레임워크이며 아키텍처로 MVC 모델을 채용.
    • 컨트롤러 : http 요청을 액션 서블릿이 한꺼번에 담당(struts-config.xml 정의에 따라). 액션 폼 빈을 생성하여 액션을 호출
    • 모델 : 자바 클래스, EJB 등
    • 뷰 : JSP 등
  • 레이어드 아키텍처 : 적절한 계층화가 필요
    • 프리젠테이션 레이어 (Controler, View) : 사용자 인터페이스 담당. 사용자 입력을 로직 레이어에 전달. 로직 레이어의 처리 결과를 브라우저에 전달
    • 비지니스 로직 레이어 (Model) : 애플리케이션이 구현할 고유 업무 처리
    • 데이터 액세스 레이어 (Model) : 데이터베이스 처리. DAO(Data Access Object, 다오, J2EE 디자인 패턴 중 하나)를 사용하여 재사용성과 유지보수성 향상
  • ORM : 객체와 관계형 DB를 대응. MyBatis
    • 애플리케이션 –> DAO 프레임워크 (doa.xml 참조) –> 데이터 매퍼(sqlMapConfig.xml 참조) –> 데이터베이스
  • 프레임워크 이용시
    • 장점 : 설계 및 개발 공수 절감, 품질 향상, 테스트 공수 절감
    • 단점 : 학습 비용 증대, 설계의 자유도 저하, 장기적인 기술력 저하

Lesson 7 보안을 확보하기 위한 방법

  • 7.1 왜 보안을 확보해야 하는가?
    • 웹 애플리케이션이 지켜야 할 보안
  • 7.2 웹 애플리케이션에 대한 대표적인 공격 수법과 그 대책
    • SQL 인젝션
    • 크로스 사이트 스크립팅(XSS)
    • 세션 하이재킹
    • 크로스 사이트 요청 위조
    • 강제 브라우징
    • 디렉터리 접근 공격
  • 7.3 설계ㆍ실행의 실수에 기인한 오작동이나 보안 문제를 막기 위한 대책
    • 뒤로 가기 버튼 대책
    • 이중 폼 제출 대책
    • hidden 매개변수를 이용할 때의 주의점
    • 디버그 정보를 출력하지 않는다
    • 전역 변수에 정보를 담지 않는다
  • 7.4 정리
  • 웹 애플리케이션에서의 보안 : 기밀성(제3자에 정보유출 방지), 완전성(제3자에 의한 정보 수정 방지), 가용성(적절한 권한을 가진 사람이 적절한 정보를 이용)
  • 공격 수법과 대책
    • SQL 인젝션 : 패스워드 입력에 “‘aaa’ or ‘1’=’1′”을 입력. Prepared Statement 또는 ORM을 사용하여 방지
    • 크로스 사이트 스크립팅(XSS) : html안에 악의적 javascript 심는 방법. 문자열 출력시 새너타이징(Sanitizing, 소독)하여 특정 문자열 제거 또는 변환
    • 세션 하이재킹 : 세션 ID는 쿠키나 GET요청을 통해 전달. 방지하기 위해서는 XSS 대책/통신 경로 암호화(SSL)/세션 타임아웃/세션 ID 랜덤화
    • 크로스 사이트 요청 위조 (CSRF) : 공격자가 날조한 폼에서 정보를 제출. 방지하기 위해 일회용 토큰(SHA-1과 같은 해시함수 사용)을 폼에 심어서 자신이 생성한 토큰인지 확인
    • 강제 브라우징 : 브라우저에 URL을 직접 입력. 방지하기 위해서는 로그인 상태 확인
    • 디렉터리 접근 공격 : pssswd와 같은 파일을 읽을 수 있다. 방지하기 위해 새너타이징으로 / 또는 \를 삭제하거나 파일시스템 접근 권한을 설정
  • 다이제스트 인증
    • 웹서버는 nonce 생성하여 브라우저에 전달
    • 브라우저는 사용자 ID, 비밀번호에 nonce, cnonce를 합친 문자열의 메시지 다이제스트 작성하여 웹서버에 전달
    • 웹서버는 메시지 다이제스트를 작성해 웹 브라우저로부터 받은 값과 비교하여 인증
  • 설계ㆍ실행의 실수에 대한 대책
    • 뒤로 가기 버튼 대책 : 뒤로 가서 주문하기 기능이 2번 실행될 수 있음. 브라우저 캐시 무효화(Cache Control), 일회용 토큰 사용
    • 이중 폼 제출 대책 : 2번 주문하기 버튼을 누를 수 있음. javascript로 버튼 눌러졌는지 확인하기. 일회용 토큰 사용
    • hidden 매개변수를 이용할 때의 주의점 : CSRF에 악용가능. 매개변수 확인, 일회용 토큰 사용
    • 디버그 정보를 출력하지 않는다 : 에러 정보는 로그 파일등으로 출력
    • 전역 변수에 정보를 담지 않는다 : 동시 접속한 다른 사용자에게 정보가 전달될 수 있다. 발견하기 힘듬. 정보는 세션스코프나 요청스코프를 사용.

Lesson 8 맺음말

  • 감사의 말
  • 제5쇄 증쇄에 즈음해

Lesson 9 부록

  • 9.1 참고 서적ㆍ사이트

Notice

  • 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스
  • 저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.
  • 댓글에 대한 답변은 늦을 수도 있습니다.
  • 댓글 남기기