[Django로 배우는 쉽고 빠른 웹개발(기초편)] 01 웹 프로그래밍의 이해

Django로 배우는 쉽고 빠른 웹개발(기초편)

Chapter 01 - 웹프로그래밍의 이해

 

나의 경우 장고를 활용한 프로젝트 경험이 다수있다.
하지만 기초적인 curd와 몇개의 aws 사용경험, 장고에 내장되어있는 기본적인 orm과 sqlLite정도만 사용할 수 있기에 해당책의 기초편과 실전편을 정독하면서 다시한번 제대로 기초를 다져보려고 한다.
또한 다른분들의 면접후기를 들어보면서 내가 서버개발자를 희망하지만 해당 용어들을 잘 모른다는 것을 알았다. 내가 할줄아는 내용도 해당 용어를 모르니 면접에서 물어보면 제대로 대답을 하지 못할 것 같다.
현재 하나의 개인 장고 프로젝트를 진행하고 있는데 그 프로젝트와 이 책을 병행하면서 다소 복잡한 웹구조를 만들어 보려고 한다.
챕터마다 정리하면서 일주일에 한권씩 완독하고 방학을 끝내보자.

 

책의 실습환경: Django 2.0, Python 3.6, Window 10

나의 실습환경: Django 3.0, Python 3.8.6, Window 10

 

장고 3에서도 구동 가능한 소스코드라하니 상관은 없을듯 하다.

 

장고 공식 홈페이지: https://docs.djangoproject.com/

이 책의 예제 소스

http://www.hanbit.co.kr/src/10104

https://www.hanbit.co.kr/src/10104

디렉토리명	소스 내용
RedBook	2장부터 5장, 부록 A 소스, 윈도우 실습 소스
pyBook	7장~9장 소스코드, 리눅스 실습 코드

 

---

웹 프로그래밍이란?

• HTTP(S) 프로토콜로 통신하는 클라이언트-서버를 개발하는 것

웹 클라이언트 요청종류

1. 웹 브라우저를 사용하여 요청
2. 리눅스 CURL 명령을 사용하여 요청
3. Talnet을 사용하여 요청
4. 직접 만든 클라이언트로 요청

1) 웹 브라우저를 사용하여 요청

웹 브라우저를 열고 주소창에 접속하고자 하는 웹 서버의 URL 입력

HTTP 요청(웹 브라우저) -> URL 결과 응답(웹 서버) -> HTML 해석해서 화면(웹 브라우저)

 

2) 리눅스 CURL 명령을 사용하여 요청

HTTP/HTTPS/FTP 등 여러 가지 프로토콜을 사용하여 데이터 송수신

쉘 프로프트에서 curl 명령

나의 경우 git bash를 사용함

curl 명령: 인자로 넘어온 url로 http요청을 보내는 웹 클라이언트 역할을 수행

 

3) Telnet을 사용하여 요청

리눅스의 telent 프로그램 사용 -> HTTP 요청

 

4) 직접 만든 클라이언트로 요청

notepad 텍스트 에디터 -> 두 개의 문장을 입력

나의경우 - vscode

웹 서버 응답

즉, 어떤 방법을 사용하는지와 상관없이 웹 서버는 동일한 요청을 받을 경우 동일한 응답을 줌

 

---

HTTP(Hypertext Transfer Protocol) 프로토콜이란?

• TCP/IP 프로토콜에서 작동하는 웹 서버와 클라이언트 사이에서 데이터를 주고받기 위해 사용하는 통신 방식
• 웹을 이용하기 위해서는 필수적인 IP주소를 가져야 함
• HTML, XML과 같은 하이퍼텍스트뿐만 아니라 이미지,음성,동영상,자바스크립ㅌ,PDF,오피스 도큐먼트 파일 등 컴퓨터가 다를 수 있는 모든 데이터 전송 가능

HTTP 메시지의 구조

• 스타트라인(Start Line) - 요청라인(요청시) or 상태라인(응답시)
• 헤더(Header) - 생략 가능
• 빈 줄(Blank Line) - 헤더의 끝을 빈 줄로 식별
• 바디(Body) - 생략 가능

요청 메시지

첫 번째 줄의 요청라인: 요청방식(method), 요청url, 프로토콜 버전

두 번째 줄(헤더): 이름: 값, 여러 줄도 가능, HOST 필수 표시, URL에 Host를 표시하면 Host헤더는 생략 가능

 

※ 바디가 없는 요청 메시지

GET http://www.example.com:8080/book/shakespeare HTTP/1.1

 

응답 메시지

첫 번째 줄의 상태라인: 프로토콜 버전, 상태 코드, 상태 텍스트

 

URI	URL
Uniform Resource Indentifier의 약자 URL + URN(Uniform Resource Name)을 포함하는 좀 더 넓은 의미	Uniform Resource Locator

※ 웹 프로그래밍에서는 URI와 URL을 동일한 의미로 사용해도 무방함

 

HTTP 메소드 종류

메소드명	의미	CURD와 매핑되는 역할
GET	리소스 취득	Read(조회)
POST	리소스 생성, 리소스 데이터 추가	Create(생성)
PUT	리소스 변경	Update(변경)
DELETE	리소스 삭제	Delete(삭제)
HEAD	리소스의 헤더(메타데이터) 취득
OPTHONS	리소스가 서포트하는 메소드 취득
TRACE	루프백 시험에 사용
CONNECT	프록시 동작의 터널 접속으로 변경

※ DELETE 요청에 대한 응답은 바디를 반환하지 않음 

 

GET vs POST 메소드

GET	POST
URL의 ? 뒤에 이름=값 쌍으로 이어붙여 보냄	요청의 메시지의 바디에 넣음
URL의 길이 제한으로 많은 양의 데이터를 보내기 어려움	장고의 폼의 데이터는 POST 방식만을 사용
전달되는 데이터가 웹 브라우저의 주소창에 노출된다는 보안 측면에서의 단점	폼안에 파라미터가 들어가게되어 노출 방지

 

상태 코드 분류

메소드명	의미	CURD와 매핑되는 역할
1xx	Informational(정보 제공)	임시적인 응답으로, 현재 클라이언트의 요청까지 처리되었으니 계속 진행하라는 의미 HTTP 1.1 버전부터 추가
2xx	Success(성공)	클라이언트의 요청이 서버에서 성공적으로 처리됨
3xx	Redirection(리다이렉션)	완전한 처리를 위해서 추가적인 동작을 필요로 하는 경우 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니, 그 주소로 다시 시도해보라는 의미
4xx	Client Error(클라이언트 에러)	없는 페이지를 요청하는 것처럼 클라이언트의 요청 메시지 내용이 잘못된 경우
5xx	Server Error(서버 에러)	서버 측 사정에 의해서 메시지 처리에 문제가 발생한 경우 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우

 

자주 사용되는 상태 코드

상태 코드	상태 텍스트	응답 문구	서버 측면에서의 의미
2xx	Success	성공	클라이언트가 요청한 동작을 수신하여 이해했고, 승난했으며 성공적으로 처리함
200	OK	성공	서버가 요청을 성공적으로 처리함
201	Created	생성됨	요청이 처리되어서 새로운 리소스가 생성됨 응답 헤어 Location에 새로운 리소스의 절대 URI를 기록함
202	Accepted	허용됨	요청은 접수했지만 처리가 완료되지 않음 클라이언트는 응답 헤더의 Location, Retry-After를 참고하여 다시 요청을 보냄
3xx	Redirection	리다이렉션	클라이언트는 요청을 마치기 위해 추가적인 동작을 취해야 함
301	Moved Permanently	영구 이동	지정한 리소스가 새로운 URI로 이동함 이동할 곳의 새로운 URI는 응답 헤더 Location에 기록함
303	See Other	다른 위치 보기	다른 위치로 요청하라
307	Temporary Redirect	임시 리다이렉션	임시로 리다이렉션 요청이 필요함 요청한 URI가 없으므로, 클라이언트는 메소드를 그대로 유지한 채 응답해서 Location에 표시된 다른 URI로 요청을 재송신할 필요가 있음
4xx	Client Error	클라이언트 에러	클라이언트 요청에 오류가 있음
400	Bad Request	잘못된 요청	요청의 구문이 잘못됨
401	Unauthorized	권한 없음	지정한 리소스에 대한 엑서스 권한이 없음
403	Forbidden	금지됨	지정한 리소스에 대한 액세스가 금지됨
404	Not Found	찾을 수 없음	지정한 리소스를 찾을 수 없음
5xx	Server Error	서버 에러	클라이언트의 요청은 유효한데, 서버가 처리에 실패함
500	Internal Server Error	내부 서버 오류	서버쪽에서 에러가 발생함
502	Bad Gateway	불량 게이트웨이	게이트웨이 or 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받음
503	Service Unavailable	서비스 제공 불가	현재 서버에서 서비스를 제공할 수 없음 보통 서버의 과부하나 서비스 점검 등 일시적인 상태

 

---

URL 설계

• 웹 애플리케이션을 개발할때 요구사항이 정리되면 먼저 디자인 측면에서는 화면 UI를 설계하고, 프로그램 로직 측면에서는 URL을 설계함
• 전체 프로그램 로직을 생각하면서 차후에 로직이 변경되더라도 url 변경은 최소화할 수 있도록 유연하게 설계하는 것이 중요

http://www.example.com:80/service?category=2&kind=patents#n10 

• URL 스킴 : URL에 사용된 프로토콜을 의미
• 호스트명 : 웹 서버의 호스트명, 도메인명 or IP 주소
• 포트번호 : 웹 서버 내의 서비스 포트번호, 생략 시에는 디폴트 포트번호-> http는 80, https는 443
• 경로: 파일이나 애플리케이션 경로
• 쿼리스트링 : 질의 문자열, 앰퍼샌드(&)로 구분된 이름=값 쌍 형식으로 표현
• 프라그먼트 : 문서 내의 앵커 등 조각을 지정

URL을 바라보는 측면

API(Application Programming Interface)는 두 가지로 분류 가능함

RPC(Remote Procedure Call)	REST(Representational State Transfer)
클라이언트가 네트워크상에서 원격에 있는 서버가 제공하는 API 함수를 호출하는 방식	REST 방식: 웹 서버에 존재하는 요소들을 모두 리소스라고 정의하고, URL을 통해 웹 서버의 특정 리소스를 표현한다는 개념
URL 설계와 API 설계를 동일하게 고려하여 URL의 경로를 API 함수명으로, 쿼리 파라미터를 함수의 인자로 간주함	리소스는 시간이 지남에 따라 상태가 변할 수 있기 때문에 클라이언트-서버 간에 데이터 교환을 리소스 상태의 교환으로 간주함
URL 경로의 대부분이 동사가 됨	리소스에 대한 조작을 HTTP 메소드로 구분함 GET, POST, PUT, DELETE
ex) http://blog.example.com/search?q=test&debug=true	ex) http://blog.example.com/search/test - (GET 메소드 사용)

 

간편 URL

• REST 방식의 URL 개념을 기반으로 간단하면서도 사용자에게 친숙하게 URL을 표현하고자 함
• 쿼리스트링 없이 경로만 가진 간단한 구조의 URL
• 검색 엔진 친화적 URL, 사용자 친화적 URL

ex) 기존 URL vs 간편 URL

기존 URL	간편 URL
http://exanple.com/index.php?page=foo	http://example.com/foo

 

파이썬의 우아한 URL

• 파이썬 프레임워크에서는 처음부터 간편 URL 체계를 도입함
• 정규표현식(Regular Expression)을 추가적으로 사용가능
• 파이썬에서는 간편한 URL을 우아한(Elegant URL)이라고 부르기도 함
• 장고에서 urlpatterns = []부분에 정규표현식으로 URL을 좀 더 구체적으로 표현함

(wow 나도 저렇게 있어보이게 코드 작성해보고싶다ㅋㅋ (책에 코드있음))

---

구분	역할	프로그램 명
웹 서버	웹 클라이언트의 요청을 받아서 요청을 처리하고, 그 결과를 웹 클라이언트에게 응답	Apache httpd, Nginx, lighttpd, IIS 등
	주로 정적 페이지인 HTML, 이미지, CSS, 자바스크립트 파일을 웹 클라이언트에 제공할 때 사용
	만약 동적 페이지 처리가 필요하다면 웹 애플리케이션 서버에 처리를 넘김
웹 애플리케이션 서버	웹 서버로부터 동적 페이지 요청을 받아서 요청을 처리하고 그 결과를 웹 서버로 반환	Apache Tomcat, JBoss, WebLogic, WebSphere, Jetty, Jeus, mod_wsgi, uWSGI, Gunocirn 등
	주로 동적 페이지 생성을 위한 프로그램 실행과 데이터베이스 연동 기능을 처리함

 

 

CGI(Common Gateway Interface) 규격

• 별도의 프로그램과 웹 서버 사이에 정보를 주고받는 규칙을 정의 한 것
• 정적, 동적이란 용어는 사용자가 페이지를 요청하는 시점에 페이지의 내용이 유지되는가 또는 변경되는가를 구분해주는 용어
• 동적 페이지에는 프로그래밍 코드가 포함되어 있어서 페이지 요청 시점에 HTML 문장을 만들어 내는 것
• 초창기의 정적인 페이지 열람 목적에서 점차 동적 페이지에 대한 요구사항이 생기고 이에 따라 웹 서버(정적인 페이지를 보여주는 것이 주된 역할이었음)와는 다른 별도의 프로그램이 필요하게 됨

CGI 방식의 단점

• 근본적인 문제점 : 각각의 클라이언트 요청에 대하여 독립적인 별도의 프로세스가 생성된다는 것
• 요청이 많아질수록 프로세스가 많아지고, 프로세스가 많아질수록 비례적으로 프로세스가 점유하는 메모리 요구량도 커져서 시스템에 많은 부하를 주는 요인이 됨
• 현재는 CGI 방식을 거의 사용하지 않음

CGI 방식의 대안 기술

1번째 방식)

• 별도의 애플리케이션을 Perl, PHP 등의 스크립트 언어로 작성
• 스크립트를 처리하는 스크립트 엔진(인터프리터)을 웹 서버에 내장시켜서 CGI 방식의 단점이었던 별도의 프로세스를 기동시키는 오버헤드를 줄이는 방식
• ex) 아파치 웹 서버의 mod_perl 이나 mod_php 모듈
• ex) 파이썬 mod_wsgi 모듈

2번째 방식)

• 애플리케이션을 처리하는 프로세스를 미리 데몬은로 기동시켜 놓은 후, 웹 서버의 요청을 데몬에서 처리하는 것
• 프로세스 생성 부하를 줄이는 방법
• ex) 파이썬 mod_wsgi 모듈
• 기술이 점차 발전함에 따라 스레드 처리가 보강되고 객체 지향 기술이 반영되면서 애플리케이션 전용 데몬인 애플리케이션 서버 방식으로 발전함
• ex) JSP(Java Server Page), ASP(Active Server Page)

※ 파이썬에서 웹 서버와 연동용으로 사용하는 mod_wsgi, uwsgi, gunicorn 프로그램들이, 웹 서버 프로그램인 httpd, nginx와는 별개로 애플리케이션 전용 데몬으로 동작한다는 점에서 웹 애플리케이션 서버라고 얘기할 수 있음

 

※ 데몬(Deamon) : 특정 서비스를 위해 백그라운드 상태에서 계속 실행되는 서버 프로세스

    일반적으로 각 서비스가 사용하는 port를 관리하는 데몬이 존재함

    데몬은 서버가 부팅될 때 메모리에 로딩이 되고 서버가 죽을 때까지 계속 자원을 할당받고 있음

 

 

애플리케이션 서버 방식

• 웹 애플리케이션 서버는 애플리케이션 프로그램의 실행 결과를 웹 서버에 전달해주며, 웹 서버는 웹 애플리케이션 서버로부터 전달받은 응답 결과를 웹 클라이언트에 전송함

애플리케이션 서버 방식의 요청 처리

ㅐ플리케이션 서버 방식에서의 서버 간 구성도

웹 서버

• 정적 페이지를 웹 클라이언트에게 제공하는 것이 주 역할
• 그 외 캐시 기능, 프록시 기능 등의 추가적인 기능과 다수의 클라이언트로부터 동시에 요청을 받아 처리해야 하기 때문에 동시에 접속을 허가하는 클라이언트 수의 제한 및 처리 프로세스의 관리, 요청 및 응답에 관한 로그의 기록, 안정성 확보를 위한 인증 제어 및 암호화 처리 등 HTTP/HTTPS의 제어에 필요한 여러 가지 기능을 제공함

웹 애플리케이션 서버

• 웹 서버와의 연동 규격을 잘 따르기만 하면 임의의 언어 플랫폼을 사용해서 애플리케이션 프로그램을 작성하고 실행시킬 수 있음
• ex) 자바 계열의 Tomcat, 루비 계열의 Unicon, 파이썬 계열의 uWSGI 애플리케이션 서버

 

※ 웹 서버와 웹 애프리케이션 서버 프로그램은 함께 필요함