냠냠쩝쩝

로그인 --> 내가 사용자라는 것을 인증한다. 

쿠키를 헤더에 넣어서 보낸다. 세션을 위한 쿠키를 세션 쿠키라고 한다. (의미를 가지고있지는 않다.)

1970년1월1일 0시가 기준이다. (타임스태프) (유닉스시간) (Y2K버그)

타임스태프는 int 형이다.  

(자료형참고)

쿠키와 세션의 차이 

쿠키 : 클라이언트 --> 세션쿠키가 세션에 대응되는 값 이 저장되어있다. 

세션 : 서버 --> 

쿠키 탈취로 치명적인 것은 개인정보 탈취이다. 따라서 개인정보 확인시에 비밀번호를 한번더 입력해서 방지할 수 있다. 

쿠키로 인증하는 것 뿐만 아니라 쿠키 + ip를 통해서 인증을 요구하는 곳도 있다. 

인증 & 인가 (Authentication & Authorization)

인증 : 클라이언트가 자신이 주장하는 사용자와 같은 사용자인지를 확인하는 과정 ( ID & PASSWORD )

인가 : 권한부여, 클라이언트가 하고자 하는 작업이 해당 클라이언트에게 허가된 작업인지를 확인 ( 글쓰기, 글삭제, )

인증 : 알고있는 것( ID & PASSWORD, PIN<비밀번호와 다른> ), 가지고있는거( 보안카드, OTP, 민증 ),  나 그 자체( 지문, 홍채 ) 

#주민증이 나와서 인증을 할 수는 있지만 인가가 없기 때문에 술 담배를 살 수 없다. 

오탐과 정탐에 대해 알아보자

서비스가 민감 할 수록 다양한 인증을 필요로한다. ( 은행 공인인증서 비밀번호로 공인인증서를 복호화 하는 과정에 속하게 된다. 한번더 할때 - 서명한다.)

OTP ( one time password )

서버가 클라한테 임의의 숫자를 주고 클라가 그거 인증해서 인증을 성립시킨다. 

-> 둘이 알고리즘 하나를 공유한다. (ex *10 /3이라는 알고리즘) 시간을 가지고 임의의 값을 나타내 줄 수 있다. 

-> 시간은 알고 있을 수 있지만 알고리즘은 알 수 가 없다. 

*쿠키는 시간이 알려지면 취약하지만 OTP는 알고리즘이 알려지면 취약하다고 말할 수 있다. (알고리즘을 알아내는 것은 알아내기가 더 어렵다.)

전신기(모스) -> 전화기(무선으로 보낸다.)

0,1로 된 아름다운 직선은 없다. 실제로는 노이즈가 섞인 데이터들이 전송, 전달된다. 

역치값을 설정해서 어느정도 이상이면 높다고 생각해 줄 수 있다.

패리티검사(패리티비트) // 확장 아스키코드 char = 1바이트 = 2^8 = 256가지  => 총 256가지 

  // 기존 아스키코드 127가지 

한비트가 비어있는 것은 패리티 비트로 사용하기 위해 남겨 졌다. 홀수짝수를 확인해서 맨 앞에 홀수패리티 짝수 패리티를 적어서 보내준다. 

> 현재는 거의 안한다. 교과서적으로는 다른 레이어에서 검사를 해줄 수 있는데  팩트로 기술이 좋아져서 필요성을 느끼지 못한다. 

카이사르 ,시져암호(알파벳 자리이동) < 율리우스 카이사르 (가이어스 쥴리어스 시져) > 

비즈네르 암호 < 빈도수 > 

RSA

굴리엘모 마르코니 

HASH암호(16진수로 나타냄, 2^4승)

해쉬암호화라고 하지말자

md5 sha-1

BASE64 알고리즘 찾아보고 특징 알아보기

강한 충돌 회피, 약한 충돌 회피 

RSA

ㅎ

해시 테이블 

라우터에 연결되어있는 mysql 연결 라우팅 하기

반복된걸을 모듈단위로 묶는다 재사용한다. 

묶을수 있으면 어지간하면 묶는다. 

exports로 connection을 빼준다.

mysql잘라내기해서 app.js같은곳에 db-con.js 새로 만들어 준다.

> 그곳에 넣어주고

> module.exports = connection; require했을때 connection 튀어나옴

> 소스코드 자체를 가져옴

const connection =require('./db-conn'); -> conncetion을 가져온다. 

---

따로 가져오면 

exports.connection = connection;

>const connection = require(./db-conn).connection

-----------------------------------------------------------------------

const connection = require(;./mysql;).connection

두번 다 해서

AJAX

새로고침 안되고 받아와서 뽑아내준다.  --> 자동완성(ajax)으로 구현했다.  // 젤 중요한거 : 새로고침을 하지 않아도 데이터를 받을수 있다. 

ajax로 요청한 데이터를 뒤로가기로하면 다없어지고 홈페이지 들어오기 전에 상태로 들어옴.(push state로 한다. PJAX<explorer사용불가>)

쿠키랑 세션이랑 사용하는게 HTML에서 연결을 끊어내기 때문이다. (요청하고 응답하고 나면 끝이기 때문이다.)

iframe 은 창 안에 새롭게 또 띄워주는 것 

데이터 베이스 보기 

SHOW DATABASES;

데이터베이스에서 내가 작업할 것 선택하기 

USE (데이터베이스);

데이터베이스에서 테이블 보기

SHOW TABLES;

데이터베이스 지우기 

DROP DATABASES (데이터베이스);

테이블 안에 내용 보기

desc (테이블);

테이블 생성 

CREATE TABLE (테이블명) (

ex) > name varchar(20) not null,

ex) > phone varchar(20) not null);

테이블 안에 값 확인해보기 

select *from (테이블명);

테이블 값 집어 넣기

insert into (테이블명) (칼럼1,칼럼2) values (칼럼1값, 칼럼2값);

Node.js서버에서 express를 사용해서 route해보기

우선 npm install express --save 을 해서 express모듈을 사용 할 수 있도록 만들어준다음에 

서버로 들어가는 app.js 파일에 아래 코드 추가

const express = require('express'); 
// express의 라우터를 사용하기 위해서 정의
const router = express.Router(); 

... 이후에

//로그인창 라우팅 명시 < url의 루트(/)이고 라우팅 위치는 현재디렉토리의 routers/login >
app.use('/',require('./routes/login').router);
//회원가입창 라우팅 명시 < url의 /signin이고 라우팅 위치는 현재디렉토리의 routers/singin >
app.use('/singin',require('./routes/signin').router);



각 js로 이동해서 살펴보면

위와 같은 express사용위한 코드를 작성하고

//라우팅 하여서 html파일의 위치를 명시해주면된다. 
// root에 있다는 것을 표현
router.get('/', function(req, res) {
  fs.readFile('login.html',(err,data)=>{
    if(err){
      console.log(err);
    }else{
      res.writeHead(200,{
        'Content-Type':'text/html'
      });
      res.end(data);
    }
  });
});

마지막에 라우터를 빠져나가는 코드 추가한다. 

exports.router = router;

node.js에서 라우터 나누기 

exports을 하면 require하는 순간 인자로 들어간다.

랜더링 : jade 문자열 자체를 넣을 수 있다.

__dirname --> 실행시킨 경로가 나온다.

URL에 대문자를 넣으면 안된다.

required 

<label> male 

label for ""

value id ="label name"

radio margin

1. url 시멘틱하게 만들어야한다. 동사는 x

2. 

CRUD 

GET   -> READ

POST -> CREATE 

PUT -> update

DELETE -> DELETE

url은 변하지 않는다. 다만 메소드만 가지고 구분한다. 

postman을 통해서 요청보낼수있다.

mysql깔아오기 

데이터 받은 것을 저장해보기

앞으로의 계획

글목록 -> 글쓰기

    | 

   글 -> 댓글

./을 통해 현재디렉토리라는 것을 표현한다.

app.js

-router = express.router            router ==""  

-require('/a') router          <----- export.router== router

----------

framework express

npm install express -g

express -h

npm install

우리가 사용할 익스프레스 설정가능

express에서 탬플렛 지정해준다.

.on 이벤트를 등록하는 것.

-------

SET NODE_ENV=production 을 통해 환경변수설정가능 오류메시지 안되게

SET NODE_ENV=               을 통해 환경변수를 

express를 통해 만들어서 거기서 만들어서 사용한다.

미들웨어 바디파서 , 쿠키파서는 찾아보자

ajax써서 레스트하게 만드는것이 목표다

stack(변수)

heap(동적할당)

I/O-bound process : I/O작업하는게 많을 때 (process가 실행되는게아니라 요청을 하는거)

CPU-bound process : CPU 계산을 더 많이 할 때 (ex.채굴)

프로세스 상태

Diagram of Process State

New: 만들어진 상태(실행되기 위해)

running: 실행되고 있는 상태

waiting: 아직 실행되지 않았고 실행할 예정이 아닐 수 있고 

ready: 실행될 준비가 되어서 준비중, 잠시 중지 (리눅스 ctrl+z)

terminated: 프로세스 종료되어 없어지기 직전인 상태

# waiting에서 바로 running으로는 가지 않는다.

PCB: Process control Block (구조체형태로 저장하는것이 PCB다)

Switch from Process to Process (스위치할때 저장해야할 값을 말한다.)

(idle 휴면상태)

Process scheduling queue

- job queue    

- ready queue    : CPU실행되길 기다리고

- Device queue   : 하드에서 읽고 쓰길 기다리는 것

queue(줄)

Scheduler

DISK -> Program

MEMORY -> Process

CPU -> TASK(실행)

 -> JOB (처리 대기)

Long-term scheduler    (Job Scheduler) :  Process에서 어떤거를 JOB으로 올릴지 결정한다.

Short-term scheduler    (CPU Scheduler) : JOB들중 어떤거를 CPU에 올릴지 결정한다.

Medium-term scheduler :  I/O랑 CPU사용이 어느정도 균일해져 사용되어야 System busy를 줄일수있다.

Long-> 메모리에서 CPU로 올리니까 길다고 생각

Short -> CPU에서 CPU니깐 상대적으로 짧다 메모리에서 CPU로 가는 것보다, 이렇게 생각하자

Context switch 

time is overhead(과부화) -> 하드웨어에 따라 달라진다. 

Process Creation(cont.)

fork() - 프로세스 복제 (부모와 자식으로 나눠져간다, 분기를 나눈다. ex)소켓프로그래밍)

fork의 리턴값이 0이면 자식이다.  -1(<0)은 오류(실패, 더이상 시스템의 리소스가 없을때).  

IPC: Inter-Process Communication (프로세스 사이에 의사소통 수단)

Shared memory

Message passing

//Producer-Consumer (공급과 소비자)

//Message Passing

Communications in client-Server Systems

Sockets

Remote Procedure Call

Pipes

소켓에 관한 고찰: 소켓이 포트에 매핑되는거지만 소켓과 포트는 다르다는 것. (제대로 정리해놓자)

프로그램(프로세스)에 포트번호가 있다, 2^16의 포트번호 0~65535

Thread에 관한 고찰

Context switch

preemptive VS nonpreemptive

SFJ Scheduling

>preemptive는 BurstTime이 작은것이 우선적으로 가져간다. 

Priority Scheduling

RR Scheduling 동일하게 

1. HTML 5 버전에서  선언문으로는

<!DOCTYPE html>

을 사용한다.

2. 문서 호환성 선언

<meta http-equiv="X-UA-Compatible" content="IE=edge">

문서 호환성 개념인 document compatiblilty 개념을 도입해 IE버전을 지정하도록 했다.

예를 들어 이렇게 사용할 수 있다.

InternetExplorer 9 표준버전 : <meta http-equiv="X-UA-Compatible" content="IE=9">

InternetExplorer 8 표준버전 : <meta http-equiv="X-UA-Compatible" content="IE=8">

3. 모바일로 최적화된 사이트를 만들기위해 뷰포트 설정해준다.

<meta name="viewport" content="width=device-width, initial-scale=1">

content의 width는 크기를 조정하는데 width=600 이런식으로 특정하게 조정할 수도 있고, 

device-width처럼 특정한 값을 사용할 수도 있다. (device-width는 100%스케일에서 CSS 픽셀들로 계산된 화면의 폭을 의미한다.

(뷰포트의 높이에 따라 크기와 위치가 변하는 요소들로 이루어진 페이지의 경우 상응하는 height와 device-height값들이 유용하게 사용될 수 있다.)

intial-scale을 통해 초기 확대값을 나타낼 수 있다.

AJAX 페이지는 그대로 결과를 페이지 수정한다.

요청발생은 클라이언트 ---> 서버

 ex) 채팅서버 

서버  ----- 클라

|    |    |

클라  클라

 웹에서는 적용하기 어려웠다.

--------------------------------------

polling 클라가 서버에게 계속 물어보다. 자주 반복되면 좋음(트래픽낭비문제)

comet --> iframe 을 통해 창을 똑같이 넣어준다.

페이지에 iframe을 넣어서 요청을 안끊는다. (에러가 나면 죽는다.)

AJAX를 보안하기위해 웹소켓을 구현해서

소켓을 web위에 올린다. 이를 통해 서버와 클라이언트가 서로 상호작용할수있다.

원래의 웹은 클라가 요청을 해야만 했는데 소켓을 통해 서버도 요청보내줬다. 

언어별로 구별하는 방법이 다르다. 

JSP 

PYTHON 

node.    ----> socket.io를 통해  구현

REST API 를 이용해 서버를 구현하면 (최근에도 REST API)를 구성하는게 좋다.

클라이언트                 서버

프론트엔드                백엔드 

템플릿 사용시 프론트 백엔드 다알아야한다. 여기서 문제가 발생

프론트엔드 백엔드 나눠서 하는게 좋다. 

분리하는 목적으로 REST API가 생겨났다. 

서버는 클라한테 HTML만준다. // WAS를 없앤다(?) 동적인 것은 처리안한다.

환율을 표시할때 데이터가 매번 바껴야한다.

클라가 요청한 HTML에서 페이지를 스크립트없는 것을 보여주고

아래에 넣는데 AJAX를 통해서 서버에게 날리고 WAS를 통해서 DB가 XML(-->JASON으로 바꿔서씀) 전달해준다. 

//데이터를 들어넣어 주는것은 

처음요청, 웹페이지 WAS를 거치지않은것 그리고나서 동적인 데이터를 받아온다.

그다음 스크립트를 통해 동적인 데이터를 

AJAX는 HTML문서가 아니다. 

cf) 어플리케이션 만들때 xml로 하고 중간의 값을 AJAX 처럼 받아올 수 있다. 

REST API Server를 통해 주고 받을 수 있다

프론트엔드와 백엔드를 나눌수있다. 

HTML은 프론트엔드만 하면된다. REST API 는 서버 개발하면서 하면된다. 

모바일용 페이지랑 웹 페이지에서 데이터 주고받을때 REST API를 같이 동시에 사용할 수 있어서 좋다.

시메틱하게 만들어야한다. HTML GET PUT POST

Node.js. Express-POST방식을 통한 정보 전달

get방식을 통해서 정보를 가져왔다. 

요청을 하고 get방식을 통해 가져온다는 것

post : 사용자의 정보를 서버로 전송할때는 post를 사용해서 처리한다.

GET vs POST

GET방식 으로 사용해 보자. 

GET으로 보내면 URL에 쿼리스트링 방식으로 전달한다.

doctype html
html
  head
    meta(charset='utf-8')
  body
    form(action='/form_receiver' // method='get')
      p
        input(type='text' name='title')
      p
        textarea(name='description')
      p
        input(type='submit')

app.get('/form_receiver', function(req,res){
var title = req.query.title;
var descrpition = req.query.description;
res.send(title+','+description);
});

POST방식 으로 사용해 보자.

doctype html
html
  head
    meta(charset='utf-8')
  body
    form(action='/form_receiver' method='post')
      p
        input(type='text' name='title')
      p
        textarea(name='description')
      p
        input(type='submit')

app.post('/form_receiver', function(req,res){
var title = req.body.title;                // 문제발생을 해결하기 위해 body-parser설치 필요
var descrpition = req.body.description;
res.send(title+','+description);
});

body-parser 를 사용해야한다. <설치>

npm install body-parser --save

// var bodyParser = require('body-parser')
// qpp.use(bodyParser.urlencoded({extended: false}))

미들웨어 를 통해서 body-paser가 post를 통해 전달된 내용을 사용할 수 있게 해준다.

req.body.title. body를 사용할 수 있게 되었다.

언제 GET방식을 쓰고 언제 POST방식을 사용해아 하는 것일까?

사용자 정보를 GET방식으로 보내면 POST방식을 사용해서 보내야 

URL상에 사용자 정보가 입력되어 나타나지 않게 된다. POST지향

URL에 쿼리스트링을 사용하는데 데이터 길이가 너무 길면 GET방식을 사용하는데에 제약이 될 수 있다.

많은 데이터 전송시 POST지향

링크를 걸어서 이동하는 경우(게시판) 같은 경우에는 GET방식 사용도 괜찮다.

Node.js Express-URL을 통한 정보 전달

쿼리스트링이란?

URL PATH뒤에 ?하면서 붙는 것이 PATH를 통해서 보여주는 정보를 다르게 보여 줄 수있다.

ex) http://hpitos.tistory.com/10?id=1 처럼 ? 뒤에 붙는 것을 query string이라고 할 수 있다.

쿼리스트링 적용해보기 및 query 객체를 사용해보기

app.get('/topic',function(req,res){
res.send(req.query.id);
})

Express reference에서 properties에서 변수의 값으로 어떤것이 들어오는 지 알아야한다. 

app.get('/topic',function(req,res){
res.send(req.query.id+','+req.query.name);
})

query 객체의 활용하기

app.get('/topic',function(req,res){
var topics = [
'JavaScript is...',
'Node.js is ...',
'Express is ...'
];
var output = `
<a href="/topic?id=0">JavaScrpit</a><br>
<a href="/topic?id=1">Node.js</a><br>
<a href="/topic?id=2">Express</a><br><br>
${topics[req.query.id]}
`
res.send(output);
})

시멘틱URL사용하기 (query가 아닌 params 사용한다.)

app.get('/topic/:id',function(req,res){ // 토픽다음 :id를 사용해서 적용가능하다.
var topics = [
'JavaScript is...',
'Node.js is ...',
'Express is ...'
];
var output = `
<a href="/topic?id=0">JavaScrpit</a><br>
<a href="/topic?id=1">Node.js</a><br>
<a href="/topic?id=2">Express</a><br><br>
${topics[req.params.id]}        // 시멘틱은 Params를 통해 나태낼수있다.
`
res.send(output);
})

-------------------------------------------------------------------------------
// 하나더 추가해서 사용도 가능하다.
app.get('/topic/:id/:mode', function(req,res){
res.send(req.params.id+','+req.params.mode)
})