지크의 IT field

웹프로그래밍을 배우려고 책을 구매했다. 웹서비스의 구조를 알고 간단하게 구현을 할 줄 알게 된다면 웹취약점 진단을 할 때에도 유용할 것이라고 판단했다.

http://books.11st.co.kr/product/SellerProductDetail.tmall?method=getSellerProductDetail&prdNo=2137705845

11번가에서 쿠폰 할인을 받으니 정가 19800원보다 저렴하게 살 수 있었다.

실전편도 있는데 제대로 배우고자 하는 마음에 기초라고 생각되는 녀석부터 샀다.

물론 1장은 대부분 알고 있는 내용이었다. 나중에 잘 정리하고 내 것으로 만들어 교육 자료로 만들 수 있도록 해야겠다.

1.1 웹 프로그래밍이란?
 HTTP(S)프로토콜을 이용해 통신하는 서버와 클라이언트의 개발을 총칭. 둘 중 하나 혹은 둘 다 개발 가능.
 파이썬의 경우에는 장고라는 웹프레임워크를 이용해 웹 서버를 개발하는 경우가 많음.

동작 방식
요청자    프로토콜 응답자
웹 -> HTTP  -> 웹
클라이언트 <- HTTPS <- 서버

*클라이언트
 IE, Chrome, Firefox 등 웹 서버로 자원을 요청하고 받은 자원을 출력

1.2 웹 클라이언트의 종류
 - 웹 브라우저를 사용해 요청
 - 리눅스 curl 명령어를 이용 ex)curl http://www.example.com
 - telnet을 이용해 요청 ex)'$telnet www.example.com 80' 연결 후 'GET / HTTP/1.1 -> Host: www.example.com
 - 직접 만든 클라이언트로 요청

1.3 HTTP 프로토콜
Hypertext Transfer Protocol의 약자. 서버-클라이언트간 통신을 위한 약속.
TCP/IP로 동작함. 즉, 웹을 이용할 때에는 서버와 클라이언트 모두 IP를 가져야 함.
이름과 달리 컴퓨터로 다루는 거의 모든 데이터를 전송 가능.

 1) HTTP 메시지 구조

 스타트라인에서 요청의 경우 요청라인, 응답의 경우 상태라인이라 칭함.
 헤더의 문장 끝에는 CRLF(Carriage Return Line Feed)가 있음. 
 빈 줄을 통해 헤더와 바디를 구분함.
 바디에는 텍스트 외 바이너리 데이터도 들어갈 수 있으며, 생략도 가능

- 바디가 없는 요청 메시지 예시 
 GET /test/example HTTP/1.1
 Host: www.example.com:8080

 1행 - 요청 방식, 요청 URL, 프로토콜 버전으로 구성
 2행 - 이름:값 형식으로 표현 

- 헤더를 생략한 요청 메시지 
 GET http://www.example.com:8080/test/example HTTP/1.1

- 응답 메시지  

 1행 - 프로토콜 버전, 상태 코드, 상태 텍스트로 구성 . 서버에서 처리하 결과를 상태라인에 표시해줌. 200 ok는 정상 처리됨
 2행 - 헤더. 3행을 빈 줄로 구분하여 4행의 바디 본문과 구분지음


 2) HTTP 처리 방식
 클라이언트가 원하는 처리 방식을 서버에 전달하는 역할. 8가지 중 GET, POST, PUT, DELETE가 많이 사용됨.
 *데이터 조작의 기본인 CRUD(Create, Read, Update, Delete)와 매핑되는 처리를 함.
 
 GET - 지정한 URL의 정보를 가져오는 메소드. 가장 많이 사용. 
 POST - 리소스를 생성. 블로그나 게시판 등에 글을 등록하는경우
 PUT - 리소스를 변경. 블로그나 게시판의 작성자를 변경하거나 내용을 업데이트 하는 경우
 DELETE - 리소스 삭제. 응답값 반환하지 않음
 * PUT 메소드도 리소스 생성에 사용 가능. 리소스의 결정권이 았으면 POST, 클라이언트에 있으면 PUT 사용. 


 3) GET과 POST
 GET의 데이터 전송 방식
  GET http://example.com/documents/search/?q=forms HTTP/1.1
URL의 끝에 ?가 붙어 데이터와 URL을 구분해줌. ? 뒤에는 이름=값으로 전송
 
 POST의 데이터 전송 방식
  POST http://example.com/documents/search/ HTTP/1.1
  Content-type: application/x-www-form-urlencoded

  q=forms
바디 GET에서 ?이후에 해당하는 파라미터 부분을 바디에 넣어서 전송

 GET은 URL 길이 제한(255자)의 제약을 받음. POST는 제한 없음
 데이터가 주소창에 노출되는 보안상의 문제도 있으나 단점을 해결할 수 있다면 사용해도 문제 없음
 
 
 4)상태 코드
 서버에서 처리한 결과를 표시하는 세자리 숫자. 첫번 째 자리가 응답 종류, 2, 3번째는 세부내용 구분
 1xx - 정보 제공
 2xx - 성공
 3xx - 리다이렉션
 4xx - 클라이언트 에러
 5xx - 서버 에러

1.4 URL 설계
 1) URL 바라보는 측면
 RPC와 REST 방식.
 클라이언트가 웹서버에 호출 시 URL은 웹서버에 존재하는 애플리케이션의 API라고 할 수 있다.
 RPC - 클라이언트가 원격지에 있는 서버가 제공하는 API함수를 호출하는 방식.
       대부분의 URL경로는 동사로 이루어짐

 REST - 웹 서버에 존재하는 모든 요소를 리소스라 정의, URL을 통해 웹서버의 리소스를 표현한다는개념

 2) 간편 URL
  쿼리스트링 없이 경로만 가진 간단한 구조의 URL. 검색 엔진과 사용자에 친화적인 URL이라 부른다.

 3) 우아한 URL
  장고에서는 간편 URL을 기본적으로 사용함. 종종 우아한 URL이라 표현함. 정규식 추가를 통해 URL을 표현하기도 함

  
1.5 웹 애플리케이션 서버
 서버측 장비를 웹 서버와 웹 애플리케이션 서버로 세분화 할 수 있다.
 #웹 서버
- 요청을 받고,  처리하고 돌려줌. HTML, 이미지, CSS, Javascript파일을 제공할 때 등 정적인 페이지를 처리할 때 사용함. 동적 페이지 처리가 필요할 경우 웹 애플리케이션 서버로 전송

 #웹 애플리케이션 서버
- 웹 서버에게 동적 페이지 요청을 받아 처리하고 결과를 웹 서버로 반환함. 동적 페이지 생성을 위한 프로그램 실행 및 DB 연동 기능 처리.

 1) 정적페이지 vs 동적 페이지 
 #정적페이지
- 누구나 아무 때나 요구하더라도 항상 같은 내용을 표시하는 웹 페이지.
- 동일 URL 요청에 동일한 내용의 페이지를 반환. HTML, Javascript, CSS, 이미지만으로 이루어진 페이지

 #동적페이지
- 동일한 리소스의 요청이라도 요청자, 요청시기 및 방법에 따라 다른 내용이 반환되는 페이지를 말함.
- ex)현재 시각, 사용자별 회원정보페이지, 장바구니 등
- 프로그래밍 코드가 포함되어 있어 요청시점에 HTML문장을 만들어낸다.

 #CGI
 초기 웹은 하이퍼링크로 연결하여 보여주는 것이 목적(정적) -> 동적 페이지 요구사항 증가 및 데이터베이스 처리 요구 증가로 웹 서버 외에 별도의 프로그램을 필요로하게 됨. 프로그램-웹서버 간 정보를 주고받는 규칙

 2)CGI 방식의 단점
 프로그래밍 언어나 스크립트가 서버-프로그램 간 정보 통신 규격이며 규격을 준수하면 어떤 언어를 사용해도 개발 가능.
 전통적 CGI 방식: CGI프로그램을 직접 호출하여 개별 프로세스를 생성
 각 클라이언트의 요청마다 독립적인 별도의 프로세스를 생성하므로 시스템 자원 소모 및 부하를 유발하여 현재는 거의 사용하지 않음.

 3)CGI방식의 대안
 - CGI의 역할을 하는 별도의 애플리케이션을 스크립트언어로 작성하고 스크립트를 처리 엔진을 웹 서버에 내장시켜 기존 방식의 단점인 별도 프로세스를 가동시키는 오버헤드를 줄임. 아파치 mod_perl, mod_php 모듈 등이 있다.
 파이썬은 mod_pytion -> mod_wsgi모듈로 옮겨감.
 

 - 앱 처리 프로세스 데몬으로 사전 기동 -> 웹 서버 요청을 데몬에서 처리하여 프로세스 생성 부하 감소. 파이썬은 mod_wsgi 모듈도 데몬 방식으로 실행 가능 -> 데몬 방식이 애플리케이션 서버 방식으로 발전
 현재는 JSP와 ASP에서 애플리케이션 서버 방식을 사용.

 4)애플리케이션 서버 방식
 클라이언트 요청 -> 웹서버가 동적페이지 처리 요청 -> 웹 애플리케이션 서버가 처리 후 전달 -> 웹서버가 클라이언트에게 전달
 

메모리 소모 비교 시 동적페이지 처리가 정적 처리 대비 수 배~수십 배 많은 메모리를 소모함. 따라서 정적 처리에 특화된 웹서버가 정적을 담당하고 웹 애플리케이션 서버는 동적 처리만 하도록 역할을 분담하면 더 많은 요청을 처리할 수 있다.

 웹 서버는 정적 페이지 처리 및 제공 외에 캐시와 프록시 기능 등을 추가로 제공하며 클라이언트 수 제한, 프로세스, 로그 관리, 인증 제어 및 암호화 처리 등의 기능도 제공.

 웹 애플리케이션 서버는 웹 서버보다 기능도 다양하며 웹 서버 기능도 제공하지만 성능과 안정성 측면에서 부적함하므로 대규모 사이트에서는 사용하지 않음.

 5) 웹 서버와의 역할 구분
 웹 애플리케이션 서버는 하드웨어 측면의 용어를 의미하기도 한다. 웹 서버와 애플리케이션 서버가 위치하는 곳을 각각의 박스라고 명명. 이 둘을 하나의 하드웨어 박스에 구성하면 운용 관리 측면에서 간편하다.
 웹 서버와 웹 애플리케이션을 분리하여 각각의 하드웨어 박스에 구성한다면 메모리 효율을 높일 수 있다. 두 장비간 메모리 사이즈 비율을 조절할 수 있기 때문. 이 때 정적/동적 페이지 요청 건수 비율을 분석해야 함. 따라서 웹 사이트는 하드웨어 증설로 처리 용량을 늘리는 작업이 용이하도록 분리 구성하는 것이 보통. 이 때 L4, L7 스위치 및 리버스 프록시 도입을 고려하여 구성한다.

파이썬을 공부해야겠다고 마음먹은 건 2017년부터였지만 실제로 했던 건 기초 책을 한 권 읽고 따라한 정도 뿐이었다.

코딩만큼은 책만으로 내 것이 되지 않는다는 걸 깨달았다.

그래서 예제를 통한 연습과 실제 프로그래밍을 통해 이것저것 뚝딱거리며 만든 결과물을 올려보고자 한다.

자료형이나 문법 등에 대한 내용은 이미 구글에 검색만 하면 수 없이 많이 나오므로 생략. 나는 구글링을 통해 얻은 자료를 통해 내가 목표로 한 것들을 만들어 올리는 데 집중해보려 한다.

일단 목표를 설정해볼까?...

연말에는 웹서버를 직접 만들어 나만의 웹페이지를 만들어보자!

더 빨리 만들 수 있다면 좋겠지?

깃허브 사용법부터 익혀야겠다.

대부분의 예제는 프로그래머스에 나오는 문제이다.