4월 5일 예정이었던 CPPG 시험이 연기되었다. 서서히 컨디션 끌어올리면서 부지런히 준비하고 있었는데, 보안기사에 이어 너마저... 취준생, 이직준비하는 분들에게는 답답한 소식이다. 아시아권에서 끝날 것 같던 코로나 사태가 세계적 대유행이 될 줄이야..
어쨌든 앞으로 60일 남았다. 시간은 충분하다. 지난 기간 동안 공부하면서 정리한 것들을 다시 한 번 보면서 준비하면 된다. 56점으로 떨어졌던 것을 생각하며 자만하지않되, 부족한 부분을 보강하는 데 중점을 두고 공부하면 충분히 가능하다. 이미 합격했다는 마음으로 준비해야겠다. 그래야 7월 보안기사 실기도 준비할 수 있다.
데이터 3법 개정으로 개보법과 망법의 내용이 다수 변경되기 때문에 이번에 최대한 합격해야 한다. 꾸준함이 가장 큰 무기다.
이직 준비를 하고 있다. 앞으로 보안 컨설턴트에 대한 글을 써보려 한다. 이미 니키님이나 다른 여타 블로그 등에서 자세히 설명이 되어 있으나 나만의 정리가 필요할 것 같다.
1.3 HTTP 프로토콜 Hypertext Transfer Protocol의 약자. 서버-클라이언트간 통신을 위한 약속. TCP/IP로 동작함. 즉, 웹을 이용할 때에는 서버와 클라이언트 모두 IP를 가져야 함. 이름과 달리 컴퓨터로 다루는 거의 모든 데이터를 전송 가능.
1) HTTP 메시지 구조
스타트라인
요청, 또는 상태라인
헤더
헤더는 생략 가능
빈 줄
헤더의 끝을 빈 줄로 식별
바디
바디는 생략 가능
스타트라인에서 요청의 경우 요청라인, 응답의 경우 상태라인이라 칭함. 헤더의 문장 끝에는 CRLF(Carriage Return Line Feed)가 있음. 빈 줄을 통해 헤더와 바디를 구분함. 바디에는 텍스트 외 바이너리 데이터도 들어갈 수 있으며, 생략도 가능
HTTP/1.1 200 OK Content-Type: application/xhtml+xml; charset=utf-8 <html> ... </html>
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 사용.
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 스위치 및 리버스 프록시 도입을 고려하여 구성한다.
