WebMaster

쿠키의 정보는 노출되고 수정되는 위험이 있음(개발자 도구에서 변경할 수 있다) 세션 중요한 정보는 서버에서 관리하고 클라이언트에는 세션 키만 제공한다 서버에 세션 객체(session) 생성 후, uniqueInt(키)를 만들어 속성명으로 사용한다 속성 값에 정보 저장하고 uniqueInt를 클라이언트에 보낸다 브라우저는 의미없는 키를 가지고 있고, 서버에서 해당 키를 통해 사용자의 정보를 가지고 있는다 실 서버에서는 세션을 직접 구현하지 말자 6장에서 나오는 express-session 사용하자

쿠키의 필요성 요청에는 한 가지 단점이 있음 누가 요청을 보냈는지 모른다(IP 주소와 브라우저 정보 정도만 알 수 있다) 로그인을 구현하면 된다(누가 요청 한지 알기 위해서) 쿠키와 세션이 필요하다 쿠키: 키=값의 쌍 ex) name=zerocho 매 요청마다 서버에 동봉해서 보내면 된다. 서버는 쿠키를 읽어 누구인지 파악할 수 있다. 쿠키 서버 만들기 writeHead: 요청 헤더에 입력하는 메서드 Set-Cookie: 브라우저에게 쿠키를 설정하라고 명령 쿠키 : 키 = 값의 쌍( name=zerocho) 매 요청마다 서버에 동봉해서 보냄 req.headers.cookie: 쿠키가 문자열로 담겨있음 req.url: 요청 주소 요청이 전송되고 응답이 왔을 때 쿠키가 설정됨 favicon.ico는 브라우저..

RestAPI 서버에 요청을 보낼 때는 주소를 통해 요청의 내용을 표현한다 /index.html이면 index.html을 보내달라는 뜻이다 항상 html을 요구할 필요는 없다(추상적인것도 가능하다) 서버가 이해하기 쉬운 주소가 좋다(서버가 주도권을 가지고 있기 때문에 클라이언트는 서버가 정해주 주소로 접속해야한다) REST API(Representational State Transfer) 서버의 자원을 정의하고 자원에 대한 주소를 지정하는 방법이다(예측을 할 수 있어 구조파악은 쉽지만, 해킹에 취약한 단점이 있다) /user이면 사용자 정보에 관한 정보를 요청하는 것이다 /post면 게시글에 관련된 자원을 요청하는 것이다 HTTP 요청 메서드 GET: 서버 자원을 가져오려고 할 때 사용한다 POST: 서..

문자열이 HTML인지 문자열인지 구분 못하는 브라우저가 있기 때문에(사파리) html인 것을 지정해서 전달해 주어야 한다 포트 번호를 8081로 바꿔서 실행했다 server1.js를 종료했다면 8080번 포트를 계속 써도 되지만, 종료하지 않았기에 8081로 새로 띄었다 종료하지 않은 경우 같은 포트를 쓰면 충돌이 나 에러 발생하고, 서버가 띄어지지 않는다 write와 end에 문자열을 넣는 것은 비효율적이다. fs 모듈로 html을 읽어서 전송하는 것이 html 파일을 관리하고, 유지 보수하기 용이하다 write가 버퍼도 전송 가능하다. async를 사용했으므로 반드시 try-catch로 예외를 처리하여 주자

서버와 클라이언트 클라이언트가 서버로 요청(request)을 보냄 서버는 요청을 처리 처리 후 클라이언트로 응답(response)을 보냄 요청 - 응답은 대부분 http 프로토콜을 이용해서 통신을 한다 노드로 http 서버 만들기 http 요청에 응답하는 노드 서버 req 객체는 요청에 관한 정보가, res 객체는 응답에 관한 정보가 담겨 있다 createServer로 요청 이벤트에 대기한다 res 메서드로 응답 보낼 수 있다. write로 응답 내용을 적고 end로 응답 마무리(내용을 넣어도 됨)한다. listen(포트) 메서드로 특정 포트에 연결한다 localhost와 포트 localhost는 컴퓨터 내부 주소이다 (외부에서는 접근 불가능) 포트는 서버 내에서 프로세스를 구분하는 번호 기본적으로 ht..

예외(Exception): 처리하지 못한 에러 노드 프로세스/스레드를 멈춤 노드는 기본적으로 싱글 스레드라 스레드가 멈춘다는 것은 프로세스가 멈추는 것 에러 처리는 필수 try-catch 기본적으로 try catch문으로 예외를 처리 에러가 발생할 만한 곳을 try catch로 감쌈 노드 비동기 메서드의 에러는 따로 처리하지 않아도 됨 콜백 함수에서 에러 객체를 제공하기 때문에 따로 에러 처리를 하지 않아도 된다. 에러를 잡지 않아도 프로그램이 멈추지 않는다 에러를 log로 남겨 어떤 오류가 발생했는지는 파악해야한다. 프로미스의 에러는 따로 처리하지 않아도 됨 promise에 오류가 발생하면 지저분한 로그가 위와 같이 써진다 노드 버전이 올라가면 동작이 바뀔 수 있다(지금은 종료되지는 않는다) 어떻게 될..

스레드풀 fs, crypto, zlib 모듈의 메서드를 실행할 때는 백그라운드에서 동시에 실행됨 스레드풀을 직접 컨트롤할 수는 없지만 개수 조절은 가능 맥, 리눅스라면 UV_THREADPOOL_SIZE=개수 윈도우라면 터미널에 SET UV_THREADPOOL_SIZE=개수 이벤트 events 모듈로 커스텀 이벤트를 만들 수 있음 스트림에 쓰였던 on(‘data’), on(‘end’) 등과 비교 on(이벤트명, 콜백): 이벤트 이름과 이벤트 발생 시의 콜백을 연결해줍니다. 이렇게 연결하는 동작을 이벤트 리스닝이라고 부릅니다. event2처럼 이벤트 하나에 이벤트 여러 개를 달아줄 수도 있습니다. addListener(이벤트명, 콜백): on과 기능이 같습니다. emit(이벤트명): 이벤트를 호출하는 메서드..

스트림 사이에 pipe 사용하기 pipe로 여러 개의 스트림을 이을 수 있다. 스트림 사이 사이에 다른 연산을 할 수 있다. zlib으로 압축을 할 수 있다. Stream VS Buffer 비교하기 Buffer와 Stream을 비교하였을 때 메모리 사용량을 비교해 보면 많은 차이가 나는 것을 확인할 수 있다. Buffer 방식은 사용자가 몇명만 오버되더라도 많은 자원을 요구하기에 금방 서버가 오류가 발생할 것이다. Stream 방식은 비교적 작은 용량만 사용해 데이터를 전달받아 처리하기 때문에 접속자가 많아도 문제없이 파일 전송을 할 수 있다 따라서 Stream 방식을 파일 전송을 지향한다. 기타 fs 메서드 fs.access(경로, 옵션, 콜백): 폴더나 파일에 접근할 수 있는지를 체크합니다. 두 번째..

버퍼: 일정한 크기로 모아두는 데이터 일정한 크기가 되면 한 번에 처리 버퍼링: 버퍼에 데이터가 찰 때까지 모으는 작업 스트림: 데이터의 흐름 일정한 크기로 나눠서 여러 번에 걸쳐서 처리 버퍼(또는 청크)의 크기를 작게 만들어서 주기적으로 데이터를 전달 스트리밍: 일정한 크기의 데이터를 지속적으로 전달하는 작업 버퍼 사용하기( 스트림이 더 효율적이다) node에서는 Buffer객체를 사용 from(문자열): 문자열을 버퍼로 바꿀 수 있습니다. length 속성은 버퍼의 크기를 알려줍니다. 바이트 단위입니다. toString(버퍼): 버퍼를 다시 문자열로 바꿀 수 있습니다. 이때 base64나 hex를 인자로 넣으면 해당 인코딩으로도 변환할 수 있습니다. concat(배열): 배열 안에 든 버퍼들을 하나로..

fs 파일 시스템에 접근하는 모듈 파일/폴더 생성, 삭제, 읽기, 쓰기 가능 웹 브라우저에서는 제한적이었으나 노드는 권한을 가지고 있음 파일 읽기 예제(결과의 버퍼는 뒤에서 설명함) fs Promise 콜백 방식 대신 프로미스 방식으로 사용 가능 require(‘fs’).promises 사용하기 훨씬 더 편해서 프로미스 방식을 추천함 fs 파일 만들기 fs.writeFile을 사용하게 되면, file을 쓸 수 있다. 동기 메서드와 비동기 메서드 노드는 대부분의 내장 모듈 메서드를 비동기 방식으로 처리 비동기는 코드의 순서와 실행 순서가 일치하지 않는 것을 의미 일부는 동기 방식으로 사용 가능 위 코드의 콜백 함수는 비동기로 동작하기 때문에 어떤 것을 먼저 출력할지 예측할 수 없다(운영체제만 실행 순서를 ..