kakasoo

저번에 이어서 이야기해보자. 저번에 bin 폴더의 www에 app이 올라간다는 이야기를 했었다. 그러면 이 페이지는 어디서 나오는 걸까? app.js const express = require("express"); const path = require("path"); const cookieParser = require("cookie-parser"); const logger = require("morgan"); const indexRouter = require("./routes/index"); const usersRouter = require("./routes/users"); const app = express(); app.use(logger("dev")); app.use(express.json()); a..

Express로 서버 만들기 Express-generator로 서버 생성 $ npm install express-generator -g $ express --no-view myAppName 위 라이브러리를 설치하고 사용하는 것만으로도 이미 웹 서버를 만들 수 있다. express 뒤에 들어간 --no-view는 option이다. pug나 jade 같이 서버 사이드 렌더링을 도와줄 view를 설정할 수도 있지만, 이제는 클라이언트와 서버를 분리하는 게 당연한(?) 일인 만큼, view는 없애도록 했다. 나는 이 상태로 개발을 시작했다. 굳이 pug과 jade를 쓸 필요 없이, 클라이언트는 분리해서 React로 만들고자 했다. 이번에는 간단한 수준에서 Express를 설명하고자 한다. 필요하다면 다른 글에서..

서론 앞선 글에서 스왑 메모리는 근본적인 해결이 될 수 없음을 밝혔다. 당연히 더 요금을 내면 해결할 수 있는 일이다. 하지만 웹을 배포하려는 내 목적 상, 다른 사람들처럼 사용하는 시간 대에만 켜고 사용하지 않을 때는 끄는 식으로는 운용할 수가 없다. 애초에 귀찮으니 만큼 그렇게 번거롭게 하고 싶지 않았다. 어떻게든 1GB의 메모리로 해결해보려고 했으나, 지인에 의해서 라즈베리파이4를 사용해 해결할 수 있었다. 현재 서버는 공용으로 사용되고 있기 때문에, 내 소유가 아니지만, 그 때의 경험으로 인해 내 공구(?) 상자에서 숙면을 취하던 라즈베리파이4를 깨우기로 결정했다. 이번 글에서는 라즈베리파이를 사용해서 서버를 구축하는 과정을 보이고자 한다. 일단 라즈베리파이의 SD 카드에 ubuntu의 최신 버전..

사실 메모리가 부족해서 build가 실패했다는 것을, 에러 발생 시 바로 알아내기도 힘들 것이다. 나의 경우에는 aws에서 프리티어로 발급 받은 서버로 클라이언트, 서버를 모두 배포하고 있었는데, npm run build를 할 때마다 모든 소프트웨어가 중단되는 것을 발견했다. 매번 build에 소요되는 시간도 길었거니와 한 번씩 팅기기라도 하면 시간이 너무 오래 걸려서 제대로 된 프로그래밍이 불가능했다. 사실, 이 글에서 메모리 부족을 해결할 수 있는, 완벽한 방법을 제공해줄 수는 없다. 말 그대로 메모리가 부족한 것이기 때문에 하드웨어적인 해결 방법 말고는 근본적인 해결책이 될 수 없다. 다만, 메모리를 일시적으로 할당해서 문제를 우회할 수는 있다. 이 방법은, 하드 디스크의 공간을 메모리처럼 사용하여..

PUT VS PATCH PUT은 멱등하고, PATCH는 비(非)멱등한 메서드라고 말한다. 여기서 멱등하다는 것은 여러 번 요청해도 결과가 동일하다는 것이고, 비멱등하다는 것은 여러 번 요청하면 그 결과가 누적되서 나온다, 즉 동일하지 않다는 것을 의미한다. 예컨대 GET으로 조회하는 것은 멱등하다. 새로고침을 여러 번 한다고 해서 페이지가 바뀌는 경우는 없다. DELETE도 멱등하다. 처음에 삭제를 하고, 두번째에서는 삭제할 게 없어서 삭제된 것처럼 표시된다. 세번째 네번째도 역시 삭제할 게 없으니 아무것도 바뀔 게 없다. 하지만 PUT, PATCH와 같이 수정을 위한 메서드는 어떨가? 이 멱등, 비멱등에 대한 구분은 결국 서버 측에서 API를 만드는 개발자가 구현해야 한다. 그렇다면 수정에 대한 멱등과..

나는 aws에서 프리티어로 제공된 ubuntu 서버를 사용하고 있었다. 나중에 메모리 부족으로 인해서 -어떤 문제였는지는 다른 글에서 설명하도록 하고- 결국 라즈베리파이로 옮기긴 했으나, 기본적인 골자는 똑같기 때문에 aws 기준으로 설명을 한다. 문제 배경 1 local에서 작업을 한다. github에 push를 한 직후, ssh 또는 putty로 aws에 들어간다. * 여기부터는 local이 아니다. 이후 git fetch, git pull 등의 명령어로 새로운 코드 및 파일들을 가져온다. 새로이 배포를 한다. npm install npm run build pm2로 만든 서버라면 NODE_ENV=production pm2 restart 0 나의 경우에는 nginx를 써서 배포했기 때문에 클라이언트는 ..

HTTP 완벽 가이드 3장, HTTP 메시지 안전한 메서드 9.1.1 Safe Methods Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the convention has been established that the GET and HEAD methods SHOULD ..

여기의 글은 성공과 실패를 결정하는 1%의 네트워크 원리 책을 읽고 스터디한 내용의 결과물이다. 이 장에서 배우는 내용 케이블과 리피터, 허브 속에서 신호가 흘러가는 모습 스위칭 허버의 패킷 중계 동작 라우터의 패킷 중계 동작 라우터의 부가 기능 01. 케이블과 리피터, 허브 속을 신호가 흘러간다 1. 하나하의 패킷이 독립된 것으로 동작한다 컴퓨터에서 송신된 패킷은 허브나 라우터라는 중계장치에 의해 목적지를 향해 진행한다. 이 때, 중계 장치들은 데이터를 보지 않고 중계하는 역할만 한다. 내용을 보지 않으므로 애플리케이션의 데이터나 TCP 프로토콜의 제어 정보를 운반하므로, 담고 있는 데이터가 전송에 영향을 주는 일은 없다. 실제 가정에서는 여러 기기들이 하나로 통합된 단일 기기를 사용하는 경우가 많지만..

05. IP와 이더넷의 패킷 송수신 동작 1. 패킷의 기본 TCP 담당 부분은 접속, 송수신, 연결 끊기의 각 단계에서 통신 상대와 대화할 때 IP 담당 부분에 의뢰하여 데이터를 패킷의 모습으로 만들어 상대에게 보낸다. 패킷은 헤더와 데이터의 두 부분으로 구성된다. 헤더에는 수신처를 나타내는 주소 등 제어 정보가 들어있고, 데이터에는 의뢰처에서 의뢰한 데이터가 들어있다. 먼저 패킷의 송신처가 되는 기기가 패킷을 만드는데, 헤더에는 적절한 제어 정보를 기록하고, 데이터 부분에 일정 크기의 데이터를 넣은 후 가장 가까운 중계 장치로 전송한다. 가장 가까운 중계 장치에 도착한 이후, 도착한 패킷의 정보를 조사하여 패킷의 목적지를 판단한다. 이 판단 과정에서, 수신처가 어느 방향에 있는지에 대한 정보를 기록한 ..

이 글은 성공과 실패를 결정하는 1%의 네트워크 원리를 읽고, 스터디한 결과를 토대로 작성했다. 03. 데이터를 송수신한다 1. 프로토콜 스택에 HTTP 리퀘스트 메시지를 넘긴다 socket connect 이후 write를 호출하여 데이터 송수신 단계로 이행한다. 프로토콜 스택은 데이터를 바이너리 데이터가 1바이트 단위로 이어져 있다는 것만 알 뿐 데이터의 내용은 알지 못한다. 프로토콜 스택은 일단 데이터를 버퍼 메모리 영역에 저장한다. 그 이유는, 데이터의 길이는 애플리케이션의 종류나 만드는 방법에 따라 결정 ( 데이터를 한 번에 보내는지, 몇 분할을 해야 하는지, 애플리케이션에서 결정 ) 하기 때문이다. 만약 데이터 저장 없이 바로 보낸다고 한다면 만약을 대비하여 짧은 길이로 나누어 보내야 하는데, ..

이 글은 성공과 실패를 결정하는 1%의 네트워크 원리를 읽고, 스터디한 결과를 토대로 작성했다. 이 장에서는 OS에 내장된 프로토콜 스택이 어떻게 송신을 의뢰하는지에 대해서 설명한다. ( 1장에서 OS에 의뢰한다고 설명했던 것을 더 세세히 분석한다. ) 01. 소켓을 작성한다. 1. 프로토콜 스택의 내부 구성 OS에 내장된 네트워크 제어 용 소프트웨어 ( 프로토콜 스택 ) 과 네트워크 용 하드웨어 ( LAN 어댑터 ) 가 브라우저에서 받은 메시지를 서버에 송출하는 동작을 한다. 계층의 최상위에는 애플리케이션 계층이 있다. 여기부터 아래로 향하여 데이터 송수신 등의 일을 의뢰한다. 애플리케이션에는 Socket 라이브러리가 있는데, 다시 이 안에는 리졸버가 내장되어 있다. 애플리케이션 계층 아래는 OS를 나..

이 글은 성공과 실패를 결정하는 1%의 네트워크 원리를 읽고, 스터디한 결과를 토대로 작성했다. 03. 전 서계의 DNS 서버가 연대한다 1. DNS 서버의 기본 동작 DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회의 내용에 응답하는 형태로 정보를 회답하는 일이며, DNS 서버의 이런 과정 역시 프로토콜이라고 할 수 있다. 조회 메시지에는 이름, 클래스, 타입 의 세 가지 정보가 포함되어 있다. 이름에는 서버나 메일의 배송 목적지 ( 메일 주소에서는 @ 기호 뒤의 문자열 ) 를 나타내며, 클래스에서는 인터넷을 나타내며 기호는 IN , 타입에는 어떤 종류의 정보가 지원되는지를 나타낸다. 2개의 타입만 설명하자면, 타입이 A면 IP 주소를, MX면 메일 서버의 이름을 제공하게 되어 있다. ..