[Django] 파이썬 웹 프로그래밍 - 웹 프로그래밍의 이해

[Django] 파이썬 웹 프로그래밍 - 웹 프로그래밍의 이해

-

책을 읽으며 Remind 하는 내용, 핵심 내용, 모르던 내용을 정리한 것입니다. 예문 및 자세한 설명은 책을 구매하여 보세요~

< 1.1. 웹 프로그래밍이란? >

< 1.2. 다양한 웹 클라이언트 >

* 1.2.1. 웹 브라우저를 사용하여 요청

* 1.2.2. 리눅스 curl 명령을 사용하여 요청

-

curl 명령은 HTTP/HTTPS/FTP 등 여러 가지의 프로토콜을 사용하여 데이터를 송 수신할 수 있는 명령이다.

* 1.2.3. Telnet 을 사용하여 요청

-

telnet 명령은 터미널 창에서 입력하는 내용을 그대로 웹 서버에 전송한다.

telnet 명령모드에서 나가려면 아래 두 라인을 입력해야 한다.

^]  ( Ctrl + ] )

quit

* 1.2.4. 직접 만든 클라이언트로 요청

-

import urllib2

print (urllib2.urlopen(“http://www.example.com”).read())

< 1.3. HTTP 프로토콜 >

* 1.3.1. HTTP 메시지의 구조

-

스타트라인(Start Line) # 요청라인(request line, request시) or 상태 라인(status line, response시)

헤더(Header) # 생략 가능

빈줄 (Blank Line) # 헤더의 끝을 식별하기 위함

바디(Body) # 생략 가능

ex)

GET /book/shakespeare HTTP/1.1 # Request line

Host: example.com:8080 # Header

ex2)

HTTP/1.1 200 OK # Status line

Content-Type: application/xhtml_xml; charset=utf-8 # Header

...

* 1.3.2. HTTP 처리 방식

-

HEAD : 리소스의 헤더(메타데이터) 취득

OPTIONS : 리소스가 서포트하는 메소드 취득

TRACE : 루프백 시험에 사용

CONNECT : 프록시 동작의 터널 접속으로 변경

* 1.3.3. GET 과 POST 메소드

* 1.3.4. 상태 코드

-

1xx / informational(정보제공) / 임시적인 응답으로, 현재 클라이언트의 요청까지 처리되었으니 계속 진행하라는 의미

2xx / Success(성공)

3xx / Redirection / 완전한 처리를 위해 추가적인 동작을 필요로 하는 경우. 주로 바뀐 주소로 재시도하라는 의미

4xx / Client Error / 없는 페이지를 요청하는 것처럼 클라이언트의 요청 메시지 내용이 잘못된 경우

5xx / Server Error / 서버측 사정에 의해 메시지 처리에 문제가 발생한 경우. 서버의 부하, DB 오류, 서버 프로그래밍 에러 등의 이유

-

201 / Created / 요청이 처리되어 새로운 리소스가 생성되었다. Header 의 Location 에 새로운 리소스의 URI 을 기록

202 / Accepted / 요청은 접수했지만 처리가 완료되지 않았다. Header 의 Location, Retry-After 를 참고하여 다시 요청해야 한다.

-

301 / Moved Permanently / 지정한 리소스가 새로운 URI 로 이동했다. Header 의 Location 에 새 위치를 기록한다.

303 / See Other / 다른 위치로 요청하라. 요청에 대한 처리 결과를 Header 의 Location 에 표시된 URI 를 GET 으로 호출해 얻을 수 있다. 브라우저의 폼 요청을 POST 로 처리하고 그 결과 화면으로 리다이렉트시킬 때 자주 사용하는 코드이다.

307 / Temporary Redirect / 임시로 리디렉션 요청이 필요하다. Header 의 Location 에 표시된 다른 URI 로 요청한다. 클아이언트는 향후 요청 시 원래 위치를 계속 사용해야 한다. 

-

400 / Bad Request / 요청의 구문이 잘못되었다.

401 / Unauthorized / 지정한 리소스에 대한 엑세스 권한이 없다. Header 의 WWW-Authenticate 에 필요한 인증 방식을 지정한다.

403 / Forbidden / 지정한 리소스에 대한 엑세스가 금지되었다. 401 인증 처리 이외의 사유로 리소스에 대한 엑세스가 금지되었다. 리소스의 존재 자체를 은폐하려면 404 를 사용한다.

404 / Not Found / 지정한 리소스를 찾을 수 없다.

-

500 / Internal Server Error / 서버쪽에 에러가 발생했다.

502 / Bad Gateway / 게이트웨이 또는 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받았다.

503 / Service Unavailable / 현재 서버에서 서비스를 제공할 수 없다. 보통은 서버 과부하나 서비스 점검 등 일시적인 상태

< 1.4. URL 설계 >

* 1.4.1. URL 을 바라보는 측면

-

API 명명 규칙을 정하는 방법을 두 가지로 분류할 수 있다.

하나는 URL 을 RPC (Remote Procedure Call)로서 바라보는 방식이고, 다른 하나는 REST(Representational State Transfer)로 바라보는 방식이다.

-

RPC 방식은 API 를 함수명으로, 쿼리 파라미터를 함수 인자로 간주한다.

RPC 방식은 URL 경로가 대부분 동사가 된다.

웹 초기부터 사용된 방식, REST 가 나오면서 사용 빈도가 줄어드는 추세이지만, 아직 많이 사용됨.

-

REST 방식은 웹 서버에 존재하는 요소들을 모두 리소스라고 정의하고, URL 을 통해 웹 서버의 특정 리소스를 표현한다는 개념이다.

리소스는 시간이 지남에 따라 상태(State)가 변할 수 있기 때문에 클라이언트와 서버 간의 데이터 교환을 리소스의 상태 교환(Representational State Transfer)로 간주한다.

리소스에 대한 조작을 GET, POST, PUT, DELETE 등의 HTTP 메소드로 매핑한다.

* 1.4.2. 간편 URL

-

기존 URL 방식에서 사용되는 문자 (?, =, &, #) 들은 웹 프로그래밍 언어 입장에서는 연산자나 특수용도 기호로 사용될 가능성이 높기 때문에 검색 엔진에서 이런 주소를 저장하고 표현하는 데 불편이 따랐다.

검색엔진 처리를 최적화하기 위해 생겨난 간편 URL 은 쿼리스트링 없이 경로만 가진 간단한 구조의 URL 을 말한다.

URL 을 입력하거나 기억하기 쉽다는 부수적인 장점도 있어 "검색엔진 친화적 URL (Search Engine Friendly URL)" 또는 "사용자 친화적 URL(User Friendly URL)"이라고도 한다.

ex) http://example.com/index.php?page=foo  ->  http://example.com/foo

* 1.4.3. 파이썬의 우아한 URL

-

파이썬 프레임워크에서는 처음부터 간편한 URL 체계를 도입.

그 외에도 URL 을 정의하기 위해 정규표현식(Regular Expression)을 추가적으로 사용하였다.

이를 파이썬에서는 "우아한 URL(Elegant URL)"이라고 부른다.

url(r’^articles/(\d{4})/(\d{2})/(\d+)/$’, views.article_detail),

r 은 escape 되지 않은 raw 스트링임을 표시

URL 이 /articles/2015/03/1 이라면 패턴에 매칭되고, views.article_detail(request, ‘2015’, ’03’, ‘1’) 을 호출한 결과를 넘겨줌

< 1.5. 웹 앱 서버 >

-

웹 클라이언트(보통 웹 브라우저)의 요청을 받아 처리하는 서버를 통칭하여 웹 서버라고 부르기도 하지만, 좀 더 세분화하면 웹 서버와 웹 앱 서버로 분류할 수 있다.

-

웹 서버

     웹 클라이언트의 요청을 받아 요청을 처리하고, 그 결과를 웹 클라이언트에게 응답한다.

     주로 정적 페이지인 HTML, 이미지, CSS, 자바스크립트 파일을 웹 클라이언트에 제공할 때 웹 서버를 사용한다.

     동적 페이지 처리가 필요하면 웹 앱 서버에 처리를 넘긴다.

     Apache httpd, Nginx, lighttpd, IIS 등이 있다.

웹 앱 서버

     웹 서버로부터 동적 페이지 요청을 받아 요청을 처리하고, 그 결과를 웹 서버로 반환한다.

     주로 동적 페이지 생성을 위한 프로그램 실행과 데이터베이스 연동 기능을 처리한다.

     Apache Tomcat, JBoss, WebLogic, WebSpere, Jetty, Jeus 등이 있다.

* 1.5.1. 정적 페이지 vs. 동적페이지

* 1.5.2. CGI 방식의 단점

-

CGI 자체는 정식 프로그래밍 언어나 스크립트가 아니라, 웹 서버와 독립적인 프로그램(프로세스)사이에 정보를 주고받는 규격을 의미한다.

이 규격을 준수하면 어떤 언어를 사용해도 CGI 프로그램을 개발할 수 있다.

전통적인 CGI 방식은 웹 서버가 C, C++, Perl, PHP 등으로 만들어진 CGI 프로그램을 직접 호출하여 개별 프로세스를 생성하는 방식이다.

-

CGI 의 근본적인 문제점은 각각의 클라이언트 요청에 대해 독립적인 별도의 프로세스가 생성된다는 것.

요청이 많아질수록 프로세스가 많아지고, 프로세스가 많아질수록 비례적으로 점유하는 메모리 요구량도 커져 시스템에 많은 부하를 준다.

그러한 이유로 현재는 CGI 방식은 거의 사용되지 않는다.

* 1.5.3. CGI 방식의 대안 기술

-

별도의 앱을 Perl, PHP 등의 스크립트 언어로 작성하고, 스크립트를 처리하는 스크립트 엔진(인터프리터)을 웹 서버에 내장시켜 CGI 방식의 단점이었던 별도의 프로세스를 가동시키는 오버헤드를 줄이는 방식이다.

-

아파치 웹 서버에서 사용하는 mod_perl 혹은 mod_php 모듈이 perl 이나 php 스크립트 엔진을 웹 서버에 내장시켜 앱의 처리를 고속화하기 위해 개발된 기술이다.

파이썬의 경우 예전 mod_python 모듈은 더 이상 사용하지 않고, 현재는 mod_wsgi 모듈을 사용한다.

-

또 다른 방식은 앱을 처리하는 프로세스를 미리 데몬으로 기동시켜 놓은 후, 웹 서버의 요청을 데몬에서 처리하는 것이다.

파이썬의 경우 데몬 방식에도 mod_wsgi 모듈을 사용한다.

mod_wsgi 모듈은 앞에서처럼 웹 서버 내장 방식으로도 실행이 가능하고, 별도의 데몬 방식으로도 실행이 가능하다.

-

별도 데몬으로 처리하는 방식은 기술이 점차 발전함에 따라, 스레드 처리가 보강되고, 객체 지향 기술이 반영되면서

앱 전용 데몬인 앱 서버 방식으로 발전했다.

현재 가장 많이 사용되고 있는 JSP(Java Server Page), ASP(Active Server Page) 기술에서 앱 서버 방식을 사용한다.

* 1.5.4. 앱 서버 방식

-

웹 서버와 웹 앱 서버를 분리함으로서, 정적 페이지 서버와 동적 페이지 서버 분기도 쉬워졌다.

정적 페이지에 반해 동적 페이지 처리가 수배에서 수십 배의 메모리를 더 많이 소비한다.

웹 서버는 정적 페이지만 처리하고, 웹 앱 서버는 동적 페이지만 처리하도록 하는 것이다.

-

웹 서버는 정적 페이지를 제공하는 것이 주 역할이지만,

그 외에도 캐시 기능, 프록시 기능 등의 추가적인 기능을 제공한다.

또한 다수 클라이언트로부터 동시 접속 허가하는 클라이언트 수의 제한 및 처리 프로세스의 관리, 요청 및 응답에 관한 로그 기록, 안전성 확보를 위한 인증 제어 및 암호화 처리 등 HTTP/HTTPS 의 제어에 필요한 여러 가지 기능을 제공한다.

-

웹 앱 서버는 웹 서버와의 연동 규격을 잘 따르기만 하면 임의의 언어 플랫폼을 사용해서 앱 프로그램을 작성하고 실행시킨 수 있다.

자바 계열의 Tomcat, Nginx, 루비 계열의 Unicorn, 파이썬 계열의 uWSGi 등이 대표적인 예이다.

대다수의 웹 앱 서버는 웹 클라이언트로부터 직접 요청을 받아 처리하는 웹 서버 기능을 제공한다.

그러나 성능과 안정성 측면에서 적합하지 않아 대규모 사이트에서는 잘 사용되지 않는다.

* 1.5.5. 웹 서버와의 역할 구분

-

웹 서버와 웹 앱 서버를 동일한 HW 에 구성할 수 있고,

다른 HW 에 구성할 수도 있다.

-

서비스 운용 관리 측면에서는 하나의 HW 박스에 구성하는 것이 좀 더 간단하다.

메모리 효율 측면에서는 따로 구성하는 것이 좋다.

어떤 방식으로 구성할까는 동적 요청과 정적 요청의 요청 건수 비율을 보고 구성하는 것이 좋다.

-

대형 웹에서는 HW 증설에 의해 웹 처리 용량을 높이는 작업이 용이하도록 별개의 HW 로 구성하는 것이 보통이다.

다음글 : [Django] 파이썬 웹 프로그래밍 - 파이썬 웹 표준 라이브러리

#, &, 1xx, 201, 202, 2xx, 301, 303, 304, 307, 3xx, 400, 401, 404, 4xx, 500, 502, 503, 5xx, =, ?, Accepted, Active Server Page, apache httpd, apache tomcat, api 명명 규칙, ASP, bad gateway, bad request, blank line, body, C, C++, cgi, cgi 방식의 단점, cgi 프로그램, client error, connect, created, css, Ctrl ], DB, DB 연동, db 오류, Delete, Django, dynamic page, elegant url, error code, Escape, Forbidden, geader, Get, HardWare, Head, header, HTML, HTTP, http 메시지 구조, HTTP 처리 방식, HTTP 프로토콜, https, HW, IIS, informational, Internal Server Error, java server page, jboss, jetty, jeus, js, jsp, lighttpd, Location, mod_perl, mod_php, mod_python, mod_wsgi, moved permanently, nginx, not found, Options, parameter, perl, php, Post, put, python, python web programming, query, Quit, r, raw 스트링, Read, redirection, Regular Expression, Remind, remote procedure call, representational state transfer, request, request line, Rest, retry-after, RPC, search engine friendly url, see other, server error, service unavailable, Start Line, state, static page, status line, Success, Telnet, temporary redirect, tomcat, Trace, tutorial, Unauthorized, unicorn, URI, url, url 설계, urllib2, urlopen, user friendly url, uWSGI, views.article_detail, weblogic, webspere, www-authenticate, [Django] 파이썬 웹 프로그래밍 - 웹 프로그래밍의 이해, ^], 간편 url, 객체 지향 기술, 검색엔진, 검색엔진 친화적 URL, 게이트웨이, 고속화, 과부화, 규격, 근본적인 문제, 다양한 웹 클라이언트, 대안 기술, 데몬, 데이터베이스 연동, 도사, 독립적인 별도의 프로세스, 독립적인 프로그램, 동시 접속, 동적 요청, 동적 페이지, 동적 페이지 처리, 루프백, 리눅스 curl, 리소스, 리소스 존재, 메모리 요구량, 메모리 효율, 메소드, 메타 데이터, 모듈, 바뀐 주소, 부하, 비율, 사용자 친화적 url, 상태, 상태 코드, 서버, 서버 부하, 서버 프로그래밍 에러, 서비스 점검, 서포트, 쉡 서버, 스레드 처리, 스크립트, 스크립트 엔진, 안전성 확보, 암호화 처리, 앱 서버 방식, 언어, 오버헤드, 요청, 요청 건수, 요청 메시지, 요청 응답 로그, 우아한 url, 웹 브라우저, 웹 서버, 웹 서버 내장, 웹 서버 내장 방식, 웹 앱 서버, 웹 클라이언트, 웹 프로그래밍의 이해, 웹 프로그래밍이란, 은폐, 이미지, 인증 제어, 인터프리터, 임시적인 응답, 자바스크립트, 재시도, 전송, 정규표현식, 정보 제공, 정적 요청, 정적 페이지, 진행, 처리, 추가 동작, 캐시, 쿼리스트링, 클라이언트, 클라이언트 수 제한, 터널, 특수용도 기호, 파이썬 웹 프로그램, 파이썬 프레임워크, 파이썬의 우아한 url, 패턴, 페이지, 폼 요청, 프로그래밍 언어, 프로세스, 프로세스 관리, 프록시, 하드웨어, 함수 인자, 함수명, 헤더