[Django] 웹 프로그래밍의 이해 (책 요약)

1. 웹 프로그래밍의 이해

 

1.1 웹 프로그래밍이란?

 

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

웹 클라이언트가 요청하고 웹 서버가 응답하는 클라이언트-서버 프로그램이 동작하는 것

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

- 리눅스 curl 명령을 사용하여 요청

- Telnet을 사용하여 요청

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

 

 

1.2 다양한 웹 클라이언트

 

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

 

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

->

웹 브라우저는 주소창에 입력된 문장을 해석하여 웹 서버에 HTTP 요청을 보내는 웹 클라이언트의 역할 수행

->

요청을 받은 도메인의 우베 서버는 그 결과를 웹 브라우저로 전송

->

웹 브라우저는 전송받은 결과를 사용자가 볼 수 있도록 HTML 텍스트를 해석하여 화면에 출력

 

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

 

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

 

쉘 프롬프트에 

$ curl "http://www.example.com"  입력

-> curl 명령은 인자로 넘어온 URL로 HTTP 요청을 보내는 웹 클라이언트의 역할을 수행

-> 요청을 받은 도메인의 웹 서버는 그 결과를 응답

 

3. Telnet을 사용하여 요청

 

리눅스의 telnet 플로그램을 사용하여 HTTP 요청을 보낼 수 있다. 

쉘 프롬프트에

$ telnet "http://www.example.com" 88 입력한 뒤 Enter를 두 번 입력

 

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

 

 

1.3 HTTP 프로토콜

 

HTTP(Hypertext Transfer Protocol)는 웹 서버와 웹 클라이언트 사이에서 데이터를 주고받기 위해 사용하는

통신 방식으로, TCP/IP 프로토콜 위에서 동작한다.

웹을 이용하려면 웹 서버와 웹 클라이언트는 각각 TCP/IP 동작에 필수적인 IP 주소를 가져야 한다는 의미

 

 HTTP는 컴퓨터에서 다룰 수 있는 데이터라면 무엇이든 전송할 수 있다.

 

1. HTTP 메시지와 구조

 

HTTP 메시지는 클라이언트에서 서버로 보내는 요청 메시지와 서버에서 클라이언트로 보내는 응답 메시지

2가지가 있다.

스타트라인은 요청 메시지일 때 요청라인(request line)이라고 하고, 응답 메시지일 때 상태라인(status line)

이라고 한다.

헤더는 각 행의 끝에 줄 바꿈 문자인 CRLF(Carriage Return line Feed)가 있으며, 헤더와 바디는 빈 줄로 구분

헤더와 바디는 생략 가능, 바디에는 텍스트뿐만 아니라 바이너리 데이터도 들어갈 수 있다.

 

첫 번째 줄은 요청라인으로, 요청방식(method), 요청 URL, 프로토콜 버전으로 구성

두 번째 줄은 헤더로, {이름: 값} 형식으로 표현하며 여러 줄도 가능, 또한 Host 항목은 필수로 표시해줘야 하는데,

Host 헤더로 표시할 수도 있고 요청라인의 UTL에 Host를 표시하면 Host 헤더는 생략할 수 있다.

 

첫 번째 줄의 상태라인은 프로토콜 버전, 상태 코드, 상태 텍스트로 구성된다. 서버에서 처리 결과를 상태라인에

표시하는데, 위 예시에서는 200 OK 이므로 정상적으로 처리되었음을 알 수 있다.

 

두 번재 줄부터 헤더, 바디와 줄바꿈으로 구분되어 있다. 바디에는 보통 HTML 텍스트가 포함되어 있다.

 

2. HTTP 처리 방식

 

HTTP 메소드를 통해서 클라이언트가 원하는 처리 방식을 서버에 알려준다. HTTP 메소드는 8가지로 정의

GET, POST, PUT, DELETE 4개의 메소드는 데이터 조작의 기본이 되는 CRUD(create, read, update, delete)와 

매핑되는 처리를 한다.

 

- GET 방식은 지정한 URL 의 정보를 가져오는 메소드로, 가장 많이 사용된다.

- POST의 대표적인 기능은 리소스를 생성하는 것으로, 블로그에 글을 등록하는 경우가 이에 해당된다.

- PUT은 리소스를 변경하는 데 사용된다.

- DELETE 는 이름 그대로 리소스를 삭제하는 메소드이다. 일반적으로 DELETE 요청에 대한 응답은 바디로 

반환하지 않는다.

 

3. GET과 POST 메소드

 

현실적으로 가장 많이 사용하는 메소드 2 가지

HTML의 폼에서 지정할 수 있는 메소드가 GET과 POST 밖에 없기 때문이기도 하다.

GET은 

예시처럼 ? 뒤에 이름 = 값 쌍으로 이어붙여 보낸다.

 

반면 POST는 GET에서 URL에 포함시켰던 파라미터들을 아래 예시처럼 요청 메시지의 바디에 넣는다.

파라미터를 보내는 방식의 차이로 인하여 GET 방식을 이용하면 많은 양의 데이터를 보내기 어렵다.

URL은 길이 제한이 있기 때문, 또한 전달되는 사용자의 데이터가 웹 브라우저의 주소창에 노출된다는 단점이

보안 측면에서도 불리

 

따라서 폼을 사용하거나 추가적인 파라미터를 서버로 보내늑 경우 GET보다 POST 방식을 많이 사용,

파이썬의 장고 프레임워크에서도 폼의 데이터는 POST 방식만 사용하고 있다.

 

 

4. 상태 코드

 

서버에서의 처리 결과는 응답 메시지의 상태라인에 있는 상태 코드를 보고 파악할 수 있다.

상태코드는 세 자리 숫자로 되어 있는데, 첫 번째 숫자는 HTTP 응답의 종류를 구분하는 데 사용,

나머지 두 개의 숫자는 세부적인 응답 내용의 구분을 위한 번호

 

 

 

5. URL 설계

 

URL의 설계는 웹 서버 로직 설계의 첫걸음이고, 사용자 또는 웹 클라이언트에게 웹 서버가 가지고 있는 기능을

명시해주는 중요한 단계이다. 전체 프로그램 로직을 생각하면서 차후에 로직이 변경되더라도 URL 변경은

최소화할 수 있도록 유연하게 설계하는 것이 중요하다.

1. URL을 바라보는 측면

 

URL은 웹 클라이언트에서 호출한다는 시점엗서 보면, 웹 서버에 존재하는 애플리케이션에 대한 API라고 할 수 있다.

이러한 API의 명명 규칙을 정하는 방법을 두 가지로 분류할 수 있따. 하나는 URL을 RPC(remote procedure call)로

바라보는 방식이고, 다른 하나는 REST(Representational State Transfer)로 바라보는 방식이다.

 

RPC 란 클라이언트가 네트워크상에서 원격에 있는 서버가 제공하는 API 함수를 호출하는 방식이다.

이 방식의 배경에는 URL 설계와 API 설계를 동이랗게 고려하여 URL의 경로를 API 함수명으로, 쿼리 파라미터를

함수의 인자로 간주한다. 그래서 웹 클라이언트에서 URL을 전송하는 것이 웹 서버의 API 함수를 호출한다고 인식

 

RPC 방식에서는 URL 경로의 대부분이 동사가 된다. 자바의 일반적인 함수나 메소드명이 동사인 것과 동일한 개념

 

REST 방식이란 웹 서버에 존재하는 요소들을 모두 리소스라고 정의하고, URL을 통해 웹 서버의 특정 리소스를 

표현한다는 개념

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

리소스 상태의 교환으로 간주하고 있다. 그리고 중요한 점은 리소스에 대한 조작을 GET, POST, PUT, DELETE 등의

HTTP 메소드로 구분한다는 점

웹 클라이언트에서 URL을 전송하는 것이 웹 서버에 있는 리소스 상태에 대한 데이터를 주고받는 것으로 간주

 

 

2. 간편 URL

 

최근에는 REST 방식의 URL 개념을 기반으로 간단하면서도 사용자에게 친숙하게 URL을 표현하려고 노력함

간편 URL은 쿼리스트링 없이 경로만 가진 간단한 구조의 URL을 말한다.

3. 파이썬의 우아한 URL

 

파이썬 프레임워크에서는 처음부터 간편 URL 체계를 도입하였다. 그 외에도 URL을 정의하기 위해 정규표현식을

추가적으로 사용할 수 있다. 

장고의 URL 표현 방식

유사한 의미의 URL을 정규표현식을 사용하여 아래처럼 표현할 수도 있다.

정규표현식을 사용하여 URL을 좀 더 구체적으로 표현

 

 

5. 웹 애플리케이션 서버

 

웹 클라이언트의 요청을 받아서 처리하는 서버를 통칭하여 웹 서버라고 부르기도 하지만 

웹 서버와 웹 애플리케이션 서버로 분류할 수 있다.

 

웹 서버 기술의 발전 과정

1. 정적 페이지 vs 동적 페이지

 

정적 페이지란 누가, 언제 요구하더라도 항상 같은 내용을 표시하는 웹 페이지를 말한다.

정적 페이지들은 해당 웹 서비스가 제공자가 사전에 준비하여 서버 측에 배치한 것으로, 동일한 리소스

(URL)의 요청에 대해서는 항상 동일한 내용의 페이지를 반환한다. HTML, 자바스크립트, CSS, 이미지 만으로

이루어진 페이지가 해당된다.

 

반면, 동적 페이지란 동일한 리소스의 요청이라도 누가, 언제, 어떻게 요구했는지에 딸라 각각 다른 내용이

반환되는 페이질를 말한다. 예를 들면 현재 시각을 보여주는 페이지나 온라인 쇼핑 사이트에서 사용자마다

다른 카트 내용을 보여주는 페이지 등을 말한다.

 

정적(static), 동적(dynamic)이란 용어는 사용자가 페이지를 요청하는 시점에 페이지의 내용이 유지되는가

또는 변경되는가를 구분해주는 용어이다. 즉, 동적 페이지에는 프로그래밍 코드가 포함되어 있어서 페이지

요청 시점에 HTML 문장을 만들어내는 것이다.

 

웹 페이지에 많은 요구사항이 생기면서 별도의 프로그램과 웹 서버 사이에 정보를 주고받는 규칙을 정의한 CGI(

Common Gateway Interface)규격이 생겨남.

 

2. CGI 방식의 단점

 

CGI 자체는 정식 프로그래밍 언어나 스크립트가 아니라, 웹 서버와 독립적인 프로그램 사이에 정보를 주고받는

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

CGI 방식은 프로그래밍 언어 등으로 만들어진 CGI 프로그램을 직접 호출하여 개별 프로세스를 생성하는 방식.

 

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

요청이 많아질수록 프로세스가 많아지고, 프로세스가 많아질수록 비례적으로 프로세스가 점유하는 메모리 요구량도

커져서 시스템에 많은 부하를 주는 요인이 된다. 이런 이유로 현재는 CGI 방식을 거의 사용하지 않는다.

 

 

3. CGI 방식의 대안 기술

 

CGI 방식의 대안 기술 중 하나는 별도의 애플리케이션을 Perl, PHP 등의 스크립트 언어로 작성하고, 스크립트를

처리하는 스크립트 엔진(인터프리터)을 웹 서버에 내장시켜서 CGI 방식의 단점이었던 별도의 프로세스를 가동시키는

오버헤드를 줄이는 방식

아파치 웹 서버에서 사용하는 mod_perl 혹은 mode_php 모듈이 Perl 이나 PHP 스크립트 엔진을 웹 서버에 내장시켜

애플리케이션의 처리를 고속화하기 위해 개발된 기술들이다.

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

 

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

데몬에서 처리하는 것이다. 

 

4. 애플리케이션 서버 방식

 

애플리케이션 서버 방식은 웹 서버가 직접 프로그램을 호출하기보다 웹 애플리케이션 서버를 통해서 

간접적으로 웹 애플리케이션 프로그램을 실행한다. 웹 애플리케이션 서버는 애플리케이션 프로그램의 실행

결과를 웹 서버에 전달해주며, 웹 서버는 웹 애플리케이션 서버로부터 전달받은 응답 결괄르 웹 클라이언트에

전송한다.

 

서버 간 구성도

 

웹 서버와 웹 애플리케이션 서버가 분리됨에 따라, 역할을 구분하여 사용하는 것이 좋다.

정적 페이지 보다 동적 페이지를 처리하는 경우의 메모리 소비 차이가 심하기 때문이다. 

정적 페이지에 특화된 웹 서버는 정적 페이지만 처리하고, 웹 애플리케이션 서버는 동적 페이지만 처리하도록

역학을 분담하는 것이 훨씬 더 많은 요청을 처리할 수 있다.

 

웹 서버는 정적 페이지를 웹 클라이언트에게 제공하는 것이 주 역할

그 외에도 캐시 기능, 프록시 기능 등의 추가적인 기능 제공, 동시에 접속을 허가하는 클라이언트의 수 제한,

처리 프로세스의 관리, 요청 및 응답에 관한 로그의 기록, 안정성 확보를 위한 인증 제어 및 암호화 처리 등

HTTP/HTTPS 의 제어에 필요한 여러가지 기능을 제공한다.

 

웹 애플리케이션 서버는 웹 서버보다 기능이 더 추가되고, 종류도 다양해지고 있다.

 

5. 웹 서버와의 역할 구분

 

 

정적 페이지를 처리하는 웹 서버 박스와 동적 페이지를 처리하는 웹 애플리케이션 서버 박스를 분리하는 것이

좋다. 

메모리 사이즈 비율을 조절할 수 있기 때문이다. 대형 웹 사이트에서는 HW 증설에 의해 웹 처리 용량을 높이는

작업이 용이하도록, 웹 서버를 탑재하는 HW 박스와 웹 애플리케이션 서버를 탑재하는 HW 박스를 분리하여ㅑ

구성하는 것이 보통이다.