1장, 2장 웹 어플리케이션의 이해& 웹 프로그래밍 기초 다지기

부록1

1.1 메인 프레임의 시대

예전에는 메인 프레임이라는 거대한 컴퓨터에 여러 대의 터미널을 물려서 사용함

특징

• 중앙 집중형
• 소프트웨어의 유지보수 용이(기능 추가나 변경 시 메인 프레임에만 배포하면 됨)
• 보안 용이(메인 프레임에 연결된 터미널을 통하지 않고서는 시스템을 사용할 수 없음)

개발도구

• 3세대 언어(Cobol, Fortran, PL/1, C 등)
• 개발 프로세스(절차적 프로그래밍, 구조적 개발 방법론, Top-down 방식, Function 중심 등)

단점

• 하드웨어 증설에 한계(사용자나 사용량이 계속해서 증가하는 상황이라면 하드웨어 교체에 따른 유지보수비가 많이 드는 구조)

1.2 클라이언트/서버의 시대

하드웨어 사양이 좋아지면서 예전의 메인 프레임 급 수준의 서버용 컴퓨터를 저렴하게 구축할 수 있게 되었음

PC 사양이 높아지면서 메인 프레임은(비즈니스 로직, 데이터 로직) 프리젠테이션 로직은 PC가 담당하게 됨

서버 쪽은 데이터 처리를 위해 메인 프레임 대신 워크스테이션급 소형 서버가 담당하게됨

이런 애플리케이션 구동 환경을 C/S(Client&Server)환경이라 부르게 됨

특징

• 윈도우 프로그래밍
• 인터넷의 보급
• 서버 구축 및 운영비 절감
• CGI프로그래밍

개발도구

• 윈도우 프로그래밍을 위한 4세대 개발 도구의 사용(C/S 환경에 맞추어 서버 쪽은 DBMS가 설치되어 운영되었고, 클라이언트 쪽은 델파이, 비주얼 베이직 등 4세대 개발 도구로 만든 윈도우 애플리케이션이 구동됨)
• Perl, PHP, ASP 등의 CGI 스크립트(CGI초기에는 C언어가 사용되었지만, 문자열 처리가 어렵고, 기능 변경이 잦은 상황에서 인터프리터 방식으로 동작하는 언어가 주류로 떠오름)
• 개발프로세스(데이터 중심 정보 공학 방법론 사용, 경영 정보 개념 도입, CASE도구를 활용한 개발 자동화 시작함)

단점

• 소프트웨어 갱신 및 재배포가 불편(PC에 애플리케이션을 설치하는 방식이라 기능 추가 변경시 프로그램을 제거하고 다시 설치해야 하는 불편함이 있음)
• 데이터베이스 접근 보안에 취약(클라이언트에서 DBMS 서버에 직접 접근하기 때문에, 접근 아이디와 암호 노출시 위험)

1.3 웹의 시대

1990년대부터 보금되기 시작한 인터넷은 언제 어디에라도 접근할 수 있다는 특징 때문에 글로벌 비즈니스 경향과 맞물려 산업 전반에 걸쳐 업무용으로 사용되기 시작함.

특징

• 글로벌 비즈니스의 가속화로 인한 시스템의 잦은 변경(글로벌 비즈니스 가속화, 기업들의 무한경쟁, 제품이나 서비스의 출시 주기가 짧아지면서 업무를 지원하는 시스템이 더 자주 변경됨)
• 애플리케이션 서버의 도입(업무 변화가 잦은 상황에서 PC가 처리하던 일을 다시 서버로 이전하게 되었음. 예전의 메인 프레임 시대와 달리 하나에서 모든 것을 처리하지 않고 여러 대의 소형 서버로 그 역할을 분산 배치함. 데이터 처리는 C/S환경과 동일하게 별도의 DBMS 서버에서 처리하고, 비즈니스 로직은 전용 서버에서 처리함. 비즈니스 로직을 처리하는 서버를 애플리케이션 서버(Application Server)라고 부름
• 웹 기술의 활용(웹 서버와 연동하여 작업을 수행하는 애플리케이션 서버를 웹 애플리케이션 서버(WAS)라 부름)
• 웹 애플리케이션과 웹 브라우저(웹 애플리케이션은 클라이언트의 요청을 처리하고, 그 결과를 웹 브라우저가 이해할 수 있는 HTML로 만들어 보냄, 웹 브라우저는 웹애플리케이션이 만들어서 보낸 HTML을 화면에 출렴함)

웹 기술이 개발자에게 가져다준 이점

• 네트워크 프로그래밍으로부터 탈출(PC와 서버 간의데이터 전송은 웹 서버와 웹 브라우저가 담당)
• 멀티 프로세싱, 멀티 스레딩 처리의 위임(웹 서버가 클라이언트와의 연결을 처리)
• OS에 독립적인 UI생성(HTML, CSS, JavaScript와 같은 표준 웹 기술을 사용하면 웹 브라우저가 설치되어 있는 어떠한 OS에서도 실행 가능함)
• 애플리케이션 배포가 용이(기능이 추가되거나 변경 시 서버에만 배포하면 됨)

웹 애플리케이션의 그늘

• 네트워크 오버헤드 증가(중앙 처리 방식이므로 매번 서버에서 화면 데이터를 받아와야해서 동시 사용자가 많을 수록 네트워크에 부하가 많이 걸려 속도가 급격히 떨어짐)
• 화면 전환이 불편(페이지 단위로 화면이 전환되기 때문에 화면 전체가 깜박거리는 현상이 발생

개발 도구

• 서버 측 개발(PHP, Python, ASP Servlet/JSP, SPRING 등을 사용하여 개발
• 클라이언트 측 개발(HTML, CSS, JavaScript, DOM API, AJVAX 등 사용하여 개발)
• jQuery, Ext JS(이런 자바스크립트 라이브러리를 이용하면 좀 더 편리하게 DOM과 AJAX를 다룰 수 있음

개발 프로세스

• OOP->CBD(객체 중심 개발에서 컴포넌트 중심 개발로 진화함)
• UML을 활용한 분석, 설계와 MDA 방법론(UML로 모델링 한 후 소스 코드를 자동 생성하는 모델 주도 아키텍처 방법론이 등장함)
• Waterfall Model -> UP/RUP(소프트웨어 개발 프로세스가 폭포수 모델에서 반복적, 점증적 개발 프로세스인 UP 또는 RUP로 전환됨)
• Agile 방법론의 대두(Pair Programming, TDD(테스트 주도 개발) 등 도입)
• 분산 컴퓨팅(C/S시대에서는 RPC, CORBA라는 분산 기술 사용 -> 웹시대에 이르러 RMI, EJB, 웹 서비스 기술로 발전(SOAP 프로토콜 기반 웹 서비스는 순수 HTTP 프로토콜에 기반을 둔 RESTful 웹 서비스로 전환됨)
• POJO 컨테이너(시스템 구축시 EJB와 같은 무거운 기술 대신 POJO(Plain Old Java Object)처럼 작고 가벼운 방법으로 자바 컴포넌트를 만들과 관리하는 방법이 떠오름, 프레임워크 기반으로 시스템을 구축하는 것이 유행을 타게됨. 대표적인 POJO기반 프레임워크는 SPRING프레임워크)

1.4 N-스크린과 클라우드의 시대

다양한 종류의 스마트 디바이스가 등장함에 따라 N-스크린 시대가 도래함. SAAS, PAAS와 같이 하드웨어를 구축하지 않고 임대하여 사용하는 방식이 인기를 끌게 됨.

특징

• 리치 인터넷 애플리케이션(페이지 단위의 화면 전환 대신, 화면의 일부분만 바꾸는 식으로 발전함. 사용자 행위에 대해 역동적이고 기민한 반응을 제공하는 웹 애플리케이션을 RIA(Rich Internet Application)라고 부름(ActiveX, Flash, 최근에는 HTML5)
• N-스크린(기기에 상관없이 일관성 있는 사용자 인터페이스를 제공하는 것이 중요해짐)
• 클라우드 스토리지(구글드라이브, 드롭박스 등)
• 클라우드 서비스(소프트웨어를 제공하는 서버에 접속하여 사용(SaaS), EX:구글독스 / AWS 등)
• 네이티브 앱과 하이브리드 앱

개발도구

• HTML5(HTML, CSS3, JavaScript, DOM API, AJAX 등의 기술을 통치하는 의미로도 사용, 다양한 하드웨어와 운영체제가 구동되는 상황에서는 최적의 프로그래밍 도구)
• DOM API와 AJAX(DOM API를 사용하면 실행 중에 웹 페이지를 변경할 수 있음. AJAX를 이용하면 서버에 비동기 요청을 수행할 수 있음)
• 안드로이드 SDK, IOS 코코아 터치 프레임워크
• 제이쿼리 모바일, 센차 터치, 폰갭, 타이타늄

2.1 HTTP 프로토콜의 이해

HTTP는 웹 브라우저와 웹 서버 사이의 데이터 통신 규칙이다.

위키에 너무 설명이 잘 되어있다.

https://ko.wikipedia.org/wiki/HTTP

HTTP 요청 헤더 종류(여기도 참고 : http://www.httpdebugger.com/http/http_header.html)

-일반 헤더(General-header) - 요청이나 응답 모두에 적용할 수 있음

-요청 헤더, 응답 헤더(Request-header/Response-header) - 요청 또는 응답 둘 중 하나에만 적용할 수 있음

-엔티티 헤더(Entity-header) - 보내거나 받는 본문 데이터를 설명

HTTP요청

웹 브라우저는 요청 데이터의 라인을 구분하기 위해 각 문자열 끝에 CRLF를 붙여 웹 서버에 보냄

Request Line은 메서드와 요청하는 자원, 프로토콜 버전으로 구성됨

Request Headers는 서버가 요청을 처리할 때 참고하라고 클라이언트에서 웹에게 알려주는 정보

message-body는 요청 헤더의 끝을 표시하는 공백 라인, GET요청은 공백 라인으로 끝남, POST요청은 공백 라인 다음에 서버에 보낼 데이터(message-body)가 온다.

이미지 출처 : http://stackoverflow.com/questions/40571109/can-two-http-request-come-together-if-it-can-how-nodejs-server-handles-it

이미지 출처 : http://www.httpdebugger.com/http/http_header.html

HTTP응답

웹브라우저가 요청하면 웹 서버는 그에 대한 작업을 수행한 후 응답 데이터를 보냄

Status-Line은 응답 결과에 대한 상태 정보임. 프로토콜 버전과 상태 코드, 설명으로 구성됨

Response Headers은 응답 데이터를 처리할 때 참고하라고 웹 브라우저에게 알려 주는 정보, 특히 Content-Type 헤더는 서버가 웹 브라우저에게 보내는 데이터의 형식을 나타냄, Content-Length는 웹 브라우저에게 보내는 데이터(message-body)의 크기(Byte)임.

아래 그림의 Entity Headers와 Message Body 사이에 공백은 이 둘을 구분하기 위한 공백 라인임

HTTP 응답 상태 코드

이미지 출처 : http://tosbourn.com/http-status-codes-for-seo/

P.S 프로토콜의 종류

2.2 GET 요청

특징

• URL에 데이터를 포함->데이터 조회에 적합
• 바이너리 및 대용량 데이터 전송 불가
• 요청라인과 헤드 필드의 최대 크기
• HTTP사양에는 제한사항 없음
• 대용량 URL로 인한 문제 발생 -> 웹 서버에 따라 최대 크기 제한
• Microsoft IIS+ : 16KB
• Apache 웹서버 : 8KB

GET요청 방법

• 웹 브라우저 주소창에 URL을 입력하는 경우
• 링크를 클릭하는 경우
• 입력 폼의 method 속성값이 get인 경우

GET 요청의 데이터 전달 형식

• '?'문자는 서비스 주소와 데이터를 구별하는 구분자
• '&'문자는 데이터들을 구별하는 구분자
• '='문자는 매개변수 이름과 값을 구별하는 구분자

GET 요청의 쓰임새

• 그대로 사용가능
• 결과 화면을 다른 사람과 쉽게 공유할 수 있다.

문제점과 개선방안

• 보안에 좋지 않다.
• 바이너리 데이터를 전송할 수 없다.(이미지나 동영상과 같은 바이너리 파일은 URL에 붙여서 보낼 수 없음)

2.3 POST 요청

특징

• URL에 데이터가 포함되지 않음 -> 외부노출 방지
• 메시지 본문에 데이터 포함 -> 실행 결과 공유 불가
• 바이너리 및 대용량 데이터 전송 가능

POST 요청의 장점 - 입력값을 URL에 노출하지 않는다., 보안이 좋다. 대용량 파일 전송 가능

POST 요청의 단점 - 요청 결과를 공유할 수 없다.

문제점과 개선방안

GET 메서드와 마찬가지로 POST도 데이터를 전달할 때 '이름=값&이름=값' 형태를 사용하는데 이미지나 동영사오가 같은 바이너리 데이터를 보낼 때 문제가 발생할 수 있다.(바이너리 데이터 안에 '='이나 '&'이 포함 될 수 있기 때문

HTML <form> enctype Attribute

Value	Description
application/x-www-form-urlencoded	모든 문자 인코딩 하지 않음( (spaces are converted to "+" symbols, and special characters are converted to ASCII HEX values)
multipart/form-data	인코딩 하지 않음, 파일 업로드
text/plain	공백만 '+'로 변환, 특수문자 인코딩 하지 않음

표 참고한 곳 : https://www.w3schools.com/tags/att_form_enctype.asp 및 윤형원

멀티파트 방식의 POST 요청 프로토콜 분석

멀티 파트 전송 방식의 Content-Type 헤더

Content-Type : multipart/form-data; boundary=----Web......PyZ

엔티티 헤더     미디어 타입            파트 구분자('&' 처럼 각 매개변수를 구분할 boundary 값

멀티 파트 전송의 데이터 형식

바이너리 데이터를 함께 전송할 때는 '&'을 사용하여 매개변수들을 구분할 수 없다. 바이너리 데이터에 '&'문자에 해당하는 코드 값이 포함되는 경우 웹 서버에서 매개변수 값을 분리할 때 문제가 발생할 수 있기 때문이다. 이 때문에 데이터 파일을 첨부할 때는 매개변수를 정확히 구분하기위해 구분자를 사용한다. Content-Type 헤더의 boundry 값을 구분자로 사용한다. 웹브라우저에서 임의로 생성하고 이 구분자를 사용하여 메시지 본문에서 매개변수를 분리하고 해석한다.

참고: http://stackoverflow.com/questions/913626/what-should-a-multipart-http-request-with-multiple-files-look-like

POST /cgi-bin/qtest HTTP/1.1
Host: aram
User-Agent: Mozilla/5.0 Gecko/2009042316 Firefox/3.0.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://aram/~martind/banner.htm
Content-Type: multipart/form-data; boundary=----------287032381131322 //구분자
Content-Length: 514

------------287032381131322//구분자
Content-Disposition: form-data; name="datafile1"; filename="r.gif"
Content-Type: image/gif

GIF87a.............,...........D..;
------------287032381131322//구분자
Content-Disposition: form-data; name="datafile2"; filename="g.gif"
Content-Type: image/gif

GIF87a.............,...........D..;
------------287032381131322//구분자
Content-Disposition: form-data; name="datafile3"; filename="b.gif"
Content-Type: image/gif

GIF87a.............,...........D..;
------------287032381131322//구분자