ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 🤖 웹 프로그래밍의 이해
    프로그래밍/Django & Flask 2020. 10. 22. 14:23
    반응형

    웹 프로그래밍의 이해

     


    - 웹 프로그래밍이란?

    HTTP 프로토콜로 통신하는 클라이언트와 서버를 개발하는 것을 의미한다. 

    보통은 웹 서버를 개발하는 경우가 많아 파이썬 웹 프로그래밍이라고 하면 장고와 같은 웹 프레임워크를 사용하여 웹 서버를 개발하는 것을 떠올린다.

    브라우저를 띄워 네이버에 접속하는 것 = 브라우저(웹 클라이언트), 네이버 서버(웹 서버)

     

    - 웹 서버에 요청을 보내는 웹 클라이언트

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

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

    3) Telet을 사용하여 요청

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

     

    - HTTP 프로토콜

    HTTP는 웹 서버와 웹 클라이언트 사이에서 데이터를 주고받기 위해 사용하는 통신 방식으로 TCP/IP 프로토콜 위에서 동작한다.

    <순서>

    1. 웹 브라우저에 네이버 입력 > 웹 클라이언트와 웹 서버 사이 HTTP 연결

    2. 웹 클라이언트가 웹 서버에게 HTTP 요청 메세지를 보냄

    3. 웹 서버는 요청에 따른 처리를 진행한 후 그 결과를 HTTP 응답 메세지로 보냄

     

    * HTTP 메세지의 구조

    클->서로 보내는 요청 메시지와 서->클로 보내는 응답 메세지가 있다.

    스타트라인 -요청/상태라인
    헤더 - 생략가능
    빈 줄 - 헤더의 끝을 빈 줄로 식별
    바디 - 생략가능

    EX 1.

    GET /book/shakespeare HTTP/1.1 --> 요청라인

    Host: example.com:8080 --> 헤더 

    =

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

     

    EX 2. 

    HTTP/1.1 200 OK --> 상태라인, OK는 처리 결과. 

    Content-Type: application/xhtml+xml; charset=utf-8 --> 헤더라인

    --> 빈줄

    <html> --> 바디

     

    * HTTP 처리 방식

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

    HTTP 메소드는 8가지로 정의 되어 있는데 GET, POST, PUT, DELETE가 많이 쓰이며, CRUD와 매핑되는 처리를 한다.

    메소드명 의미 CRUD와 매핑되는 역할
    GET 리소스 취득 Read
    POST 리소스 생성, 리소스 데이터 추가 Create
    PUT 리소스 변경 Update
    DELETE 리소스 삭제 Delete

    GET 방식은 지정한 URL의 정보를 가져오는 메소드이고, POST 방식은 리소스를 생성하는 것으로, 블로그에 글을 등록하는 경우가 해당된다.

    PUT은 리소스를 변경하는데 사용된다. 블로그에서 글을 업로드한 작성자를 변경하는 경우가 그 예다.

    (PUT 메소드도 리소스 생성이 가능하다. 새롭게 생성한 리소스에 대한 URL 결정권이 서버에 있으면 POST, 클라이언트에 있으면 PUT을 사용한다. 예를 들어 트위터에 글을 포스팅하면 그 글에 대한 URL는 서버에서 결정하므로 PUT을 사용, 위키처럼 클라이언트가 결정한 타이틀이 그대로 URL가 되는 겨우는 PUT을 사용한다.)

    DELETE는 리소드를 삭제한다. 일반적으로 DELETE 요청에 대한 응답은 바디가 없다.

     

    * GET과 POST 메소드

    폼에서 사용자가 입력한 데이터들을 서버로 보낼 때, GET과 POST는 차이가 있다.

     

    GET은 url 부분의 ? 뒤에 키=값 쌍으로 이어붙여 보낸다

    GET http://docs.djangoproject.com/search/?q=forms&release=1 HTTP/1.1 

     

    POST는 요청메세지의 바디에 넣는다 

    POST http://docs.djangoproject.com/search/ HTTP/1.1

    Content-Type: application/x-www-form-urlencoded

    (빈줄)

    q=forms&release=1

     

    GET 방식을 사용하면 많은 양의 데이터를 보내기 어렵다. URL는 길이 제한이 있기 때문이다. 

     

    * 상태코드

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

    첫번째 숫자는 HTTP 응답의 종류를 구분하고, 나머지 두개의 숫자는 세부적인 응답 내용의 구분을 위한 번호이다.

     

    출처-https://yunyoung1819.tistory.com/16

    - URL 설계

     

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

     

    URL 스킴(http://) - url에 사용된 프로토콜을 의미한다.

    호스트명(www.example.com) - 웹 서버의 호스트명으로, 도메인명 또는 ip 주소로 표현된다.

    포트번호(80) - 웹 서버 내의 서비스 포트번호. 생량식에는 디폴트 포트번호, http:80, https:443

    경로(services?) - 파일이나 애플리케이션 경로를 의미

    쿼리스트링(category=2&kind=patentes) - 질의 문자열로, 앰퍼샌드(&)로 구분된 키=값 쌍 형식으로 표현한다.

    프라그먼트(n10) - 문서 내의 앵커 등 조각을 지정

     

    * URL을 바라보는 측면

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

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

    1) RPC 

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

    URL 설계와 API 설계를 동일하게 고려하여 URL의 경로를 API 함수명으로, 쿼리 파라미터를 함수의 인자로 간주.

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

    RPC방식: http://blog.example.com/search?q=test&debug=True 

    2) REST

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

    클라이언트와 서버 간에 데이터의 교환을 리소스 상태의 교환으로 간주한다.

    REST 방식: http://blog.example.com/search/test 

     

    * 간편 URL

    쿼리스트링없이 경로만 가진 간단한 구조의 URL

    겸색 엔진 친화적 URL, 사용자 친화적 URL 이라고 부르기도 한다. 

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

     

    - 웹 애플리케이션 서버

    웹 클라이언트의 요청을 받아서 처리하는 서버를 통칭하여 웹 서버라고 부른다.

    웹 서버 웹 클라이언트의 요청을 받아서 요청을 처리하고, 그 결과를 웹 클라이언트에게 응답한다. 주로 정적 페이지를 웹 클라이언트에 제공할 때 사용 Apache httpd, Nginx 등
    웹 애플리케이션 서버 웹 서버로부터 동적 페이지 요청을 받아서 요청을 처리하고, 그 결과를 웹 서버로 반환한다. Apache Tomcat, JBoss 등 

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

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

    동일한 리소스의 요청에 대해서는 항상 동일한 내용의 페이지를 반환.

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

    예를 들면 현재 시각을 보여주는 페이지나 온라인 쇼핑 사이트에서 사용자마다 다른 카트 내용을 보여주는 페이지 등이 있다.

     

    * CGI 방식의 단점

    동적 페이지에 대한 요구사항과 데이터 베이스 처리에 대한 요구가 많아짐에 따라 웹 서버와는 다른 별도의 프로그램이 필요하게 되었다. 이러한 별도의 프로그램과 웹 서버 사이에 정보를 주고받는 규칙을 정의한 것이 바로 CGI 규격이다

     

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

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

     

    * CGI 방식의 대안 기술

    1) 별도의 애플리케이션을 PHP, Perl 등의 스크립트 언어로 작성하고, 스크립트를 처리한느 스크립트 엔진을 웹 서버에 내장시킨다. 

    2) 애플리케이션을 처리하는 프로세스를 미리 데몬으로 기동시켜 놓은 후, 웹 서버의 요청을 데몬에서 처리한다. 이는 애플리케이션 전용 데몬인 애플리케이션 서버 방식으로 발전하였다. 

    * 데몬 - 계속 살아있는 독립 어플리케이션, 백그라운드에서 실행되는 어플리케이션

     

    * 애플리케이션 서버 방식

    웹 서버가 직접 프로그램을 호출하기 보다는 웹 애플리케이션 서버를 통해서 간접적으로 웹 애플리케이션 프로그램을 실행한다. 

    출처:https://m.blog.naver.com/PostView.nhn?blogId=jysaa5&logNo=221854587760&proxyReferer=&proxyReferer=https%3A%2F%2Fwww.google.com%2F

    * 웹 서버와의 역할 구분

    웹 서버 및 웹 애플리케이션 서버라는 용어는 SW 측면의 서버 프로그램을 의미한다.

    HW 측면의 용어는 웹 서버 박스 및 웹 애플리케이션 서버 박스라는 용어를 사용한다.

     

     

    더보기

    내용출처: 김석훈, Django로 배우는 쉽고 빠른 웹 개발, 한빛미디어(2015)

    반응형

    댓글

Designed by Tistory.