본문 바로가기
개발

[Node.js] 4장

by jwcs 2024. 2. 4.
728x90

4.1 요청과 응답 이해하기

Node.js에서 HTTP 요청(Request)와 응답(Response)은 클라이언트와 서버 간의 통신을 처리하는 데 사용된다. Node.js의 http 모듈은 이러한 통신을 구축하고 관리하기 위한 기본적인 인터페이스를 제공한다.

 

HTTP 요청(Request)

http 요청은 클라이언트가 서버에 정보를 요청하거나 서버의 상태를 변경하기 위해 보내는 메시지이다. Node.js에서 `http` 모듈을 사용하여 HTTP 서버를 만들 때, 요청 객체는 다음과 같은 주요 속성과 메서드를 포함한다.

  • req.url: 클라이언트가 요청한 URL의 경로와 쿼리 문자열을 포함한다.
  • req.method: HTTP 요청 메서드를 나타낸다(예: GET, POST)
  • req.headers: 요청 헤더를 포함하는 객체이다.
  • req.body: 요청의 본문을 포함하며, POST나 PUT 메서드에서 데이터를 전송할 때 사용된다.
  • req.on('data', callback): 요청의 본문에 들어있는 데이터를 스트림으로 읽을 때 발생하는 이벤트를 처리한다.
  • req.on('end', callback): 요청의 데이터 수신이 완료되었을 때 발생하는 이벤트를 처리한다.

HTTP 응답(Response)

http 응답은 서버가 클라이언트의 요청에 대해 보내는 메시지이다. 응답 객체는 클라이언트에게 상태 코드, 응답 헤더, 응답 본문 등의 정보를 전달한다. Node.js에서 응답 객체는 다음과 같은 주요 메서드를 포함한다.

  • res.statusCode: 응답의 HTTP 상태 코드를 설정한다.
  • res.setHeader(name, value): 응답에 특정 HTTP 헤더를 설정한다.
  • res.writeHead(statusCode[, statusMessage][, headers]): 응답의 상태 코드와 헤더를 한 번에 설정한다.
  • res.end([data][, encoding][, callback]): 응답 프로세스를 완료하고, 선택적으로 데이터를 클라이언트에게 전송한다.
  • res.write(data[, encoding][, callback]): 응답 본문에 데이터를 전송한다. res.end를 호출하기 전에 여러 번 호출될 수 있다.

사용 예시

Localhost

localhost는 호스트 이름의 일종으로, 현재 기기의 네트워크 인터페이스를 가리킨다. 일반적으로 IP 주소 `127.0.0.1`을 사용하여 컴퓨터의 네트워크 스택으로 바로 연결된다.

 

포트

네트워크 상의 호스트 내에서 특정 서비스를 구분하기 위한 논리적인 접점이다. 포트 번호는 일반적으로 HTTP 서버는 80, HTTPS 서버는 443, FTP는 21 등으로 알려진 표준 포트 번호를 사용한다. 개발 중에는 일반적으로 3000, 8000과 같은 비표준 포트를 사용한다.

 

포트 충돌

포트 충돌은 두 개 이상의 서비스가 동일한 포트 번호를 사용하려고 할 때 발생한다. 예를 들어, 만약 이미 3000번 포트에서 서버가 실행 중인데 다른 애플리케이션도 3000번 포트를 사용하려고 시도하면 포트 충돌이 발생한다. 이러한 충돌은 보통 `EADDRINUSE` 에러를 발생시킨다. 포트 충돌을 해결하기 위해서는 충돌이 발생한 포트를 사용하는 서비스 중 하나를 종료하거나 , 서버를 다른 포트 번호로 실행해야 한다.

 

HTTP 상태 코드

http 상태 코드는 서버가 클라이언트의 요청을 어떻게 처리했는지를 나타내는 코드이다. 이 코드들은 응답의 일부로 클라이언트에게 전송되며, 다음과 같은 범주로 나눌 수 있다.

  • 1xx (정보 응답): 요청을 받았으며 프로세스를 계속한다
  • 2xx (성공): 요청이 성공적으로 받아들여졌고 처리되었다
  • 3xx (리다이렉션): 추가 작업을 완료하기 위해 더 많은 조치가 필요하다
  • 4xx (클라이언트 에러): 요청에 오류가 있어 서버가 요청을 수행할 수 없다
  • 5xx (서버 에러): 서버가 유효한 요청을 완료하는데 실패했다

무조건 응답을 보내야 하는 이유

요청 처리가 성공했든 실패했든 응답값을 보내야한다. 응답을 보내지 않으면, 클라이언트는 응답값을 기다리다 timeout이 된다.

 

4.2 REST와 라우팅 사용하기

REST는 REpresentational State Transfer의 줄임말로, 웹 기수을 이용해 서버와 클라이언트 간의 상호작용을 구현하는 방법론이다. REST 아키텍처 스타일은 다음과 같은 여섯 가지 제약 조건을 기반으로 한다. REST 아키텍처를 사용하는 웹서비스를 `RESTful`이라고 부른다.

  • 클라이언트-서버 구조(Client-Server Architecture): 클라이언트와 서버는 서로 독립적으로 작동하며, 각각의 개발과 운영이 분리될 수 있다.
  • 무상태(stateless): 각 요청은 독립적이며, 서버는 클라이언트의 상태 정보를 저장하지 않는다. 모든 요청은 필요한 모든 정보를 포함해야 한다.
  • 캐시 처리 가능(Cachable): 클라이언트는 응답을 캐시하여 재사용할 수 있어야 하며, 이를 통해 상호작용을 효율적으로 만든다.
  • 계층화된 시스템(Layered System): 클라이언트는 자신이 직접 통신하는 서버가 최종 목적지 서버인지, 중간의 중계 서버인지 알 수 없다.
  • 코드 온 디맨드(Code on Demand, 선택적): 서버는 실행 가능한 코드를 클라이언트에 전송할 수 있어 클라이언트의 기능을 일시적으로 확장할 수 있다. 이는 선택적 제약이다.
  • 일관된 인터페이스(Uniform Interface): 일관된 인터페이스를 통해 시스템 간의 상호작용을 단순화하고, 독립적으로 진화할 수 있게 한다.

REST는 클라이언트와 서버간의 상호작용을 위해 리소스의 표현을 전송하는 것에 중점을 둔다. 이 표현 작업을 수행하기 위해 HTTP 메서드를 사용한다.

  • GET: 리소스를 조회할 때 사용된다. 서버의 데이터를 변경하지는 않는다.
  • POST: 새로운 리소스를 생성할 때 사용된다.
  • PUT: 기존 리소스를 수정하거나 대체할 때 사용된다.
  • DELETE: 리소스를 삭제할 때 사용된다.
  • PATCH: 리소스의 일부를 수정할 때 사용된다.

4.3 쿠키와 세션 이해하기

 

쿠키

 쿠키는 클라이언트 측에 저장되는 데이터다. 웹 서버는 HTTP 응답 헤더를 통해 쿠키를 설정할 수 있으며, 이후 클라이언트는 동일한 서버에 요청을 보낼 때마다 쿠키 정보를 HTTP 요청 헤더에 포함하여 서버로 다시 전송한다. 이를 통해 서버는 사용자의 상태를 유지하고 추적할 수 있다.

 쿠키의 주요 사용 사례로는 로그인 상태 유지, 사용자의 환경 설정 기억, 세션 관리 등이 있다. 쿠키는 만료 날짜나 시간을 설정할 수 있으며, 브라우저가 닫힐 때 삭제되도록 설정할 수도 있다. 보안을 위해 HttpOnly 플래그를 사용하여 자바스크립트 등의 클라이언트 사이드 스크립트가 쿠키를 접근하는 것을 제한할 수 있다.

 

세션

 세션은 서버 측에서 사용자의 상태 정보를 유지하는 방법이다. 세션은 서버 메모리나 데이터베이스에 저장될 수 있으며, 각 클라이언트에 고유한 세션 ID를 부여하여 구분한다. 사용자가 웹사이트에 방문할 때 세션 ID가 생성되고, 이 ID를 통해 사용자의 상태와 데이터를 관리한다.

 쿠키와 달리 세션 데이터는 서버에 저장되므로 민감한 정보를 다룰 때 더 안전할 수 있다. 그러나 모든 사용자 정보를 서버에 저장하므로 많은 양의 동시 접속자가 있을 경우 서버의 부하가 커질 수 있다.

 

쿠키와 세션의 차이점

  • 저장 위치: 쿠키는 클라이언트 측에 저장되고, 세션은 서버 측에 저장된다.
  • 보안: 세션은 쿠키보다 보안이 더 강력하다. 쿠키는 클라이언트에 저장되므로 취약할 수 있지만, 세션 정보는 서버에 있기 때문에 직접적인 접근이 더 어렵다
  • 수명: 쿠키는 만료 날짜를 설정할 수 있지만, 일반적으로 세션은 브라우저가 닫히면 종료된다.
  • 용량: 쿠키는 크기에 제한이 있으며, 각 클라이언트별로 저장해야 할 정보가 많을 경우 문제가 될 수 있다. 세션은 서버의 용량에 의존한다.

쿠키 예시

  • 쿠키이름=쿠키값: 쿠키의 기본적인 값이다
  • Expires=만료 시간: 쿠키의 만료 시간을 설정한다
  • Max-Age=3600: 쿠키의 수명을 3600초로 설정한다
  • Secure: 쿠키가 HTTPS를 통해서만 전송되도록 설정한다
  • HttpOnly: 자바스크립트와 같은 클라이언트 사이드 스크립트가 쿠키에 접근하는 것을 방지한다

세션을 보낼 때도 이와 비슷하다. 차이점이 있다면 쿠키에 이름을 보내는 대신 uniqueInt를 담아서 보낸다. 이 값으로 사용자 정보를 검색하여 제공한다.

 

4.4 https와 http2

 

HTTPS(Hyper Text Transfer Protocol Secure)

https는 http의 보안 버전이다. HTTP는 클라이언트와 서버 간에 데이터를 주고받는 프로토콜이며, HTTPS는 이 데이터 전송을 암호화한다. 이 암호화는 TLS(전송 계층 보안) 또는 SSL(보안 소켓 계층) 프로토콜을 사용하여 수행된다. HTTPS는 주로 웹 브라우저와 웹 서버 간의 통신에 사용되묘, 사용자의 데이터를 도청, 변조 및 위조로부터 보호하기 위해 사용된다.

 

HTTP/2

http2는 웹의 성능을 향상시키기 위해 설계된 HTTP 프로토콜의 두 번째 주요 버전이다. 주요 특징은 다음과 같다.

  • 이진 프레이밍: HTTP/2는 이진 프로토콜을 사용하여 더 효율적인 메시지 처리와 더 낮은 파싱 오버헤드를 제공한다.
  • 멀티플렉싱: 여러 요청과 응답을 동시에 같은 연결 위에서 보낼 수 있어서 여러 자원을 병렬로 빠르게 다운로드 할 수 있다.
  • 서버 푸시: 서버가 클라이언트에게 필요한 리소스를 클라이언트의 요청 없이 미리 보낼 수 있다.
  • 헤더 압축: HTTP/2는 헤더 메타 데이터를 압축하여 전송하여 대역폭을 절약한다.

멀티 플렉싱 예시

 

4.5 cluster

 cluster 모듈은 node.js가 싱글 스레드 모델을 사용한다는 사실을 보완하기 위해 도입되었다. 이 모듈을 사용하면 여러 CPU 코어를 활용할 수 있다. 즉, 하나의 Node.js 인스턴스를 여러 개의 프로세스로 분산시켜 동시에 실행할 수 있게 해주며, 이를 통해 애플리케이션의 처리량과 성능을 개선할 수 있다.

주요 기능과 작동 방식

  • 멀티프로세스 실행: cluster 모듈을 사용하면, 메인 프로세스가 여러 개의 워커 프로세스를 생성하고 관리할 수 있다. 각 워커는 동일한 서버 코드를 별도의 프로세스로 실행하며, 이를 통해 여러 CPU 코어를 효율적으로 사용할 수 있다.
  • 로드 밸런싱: Node.js는 내부적으로 로드 밸런싱을 지원하여, 들어오는 연결을 여러 워커 프로세스 사이에 균등하게 분배한다. 이는 클라이언트 요청을 더 빠르게 처리할 수 있게 해주며, 애플리케이션의 가용성과 확장성을 향상시킨다.
  • 오류 처리와 복구: 워커 프로세스가 실패하거나 예기치 않게 종료되는 경우, 마스터 프로세스는 이를 감지하고 새로운 워커 프로세스를 생성하여 교체할 수 있다. 이를 통해 애플리케이션의 안정성을 유지할 수 있다.

cluster 예시

 

728x90
반응형

'개발' 카테고리의 다른 글

[Node.js] 6장  (0) 2024.02.08
[Node.js] 5장  (0) 2024.02.07
[Node.js] 3장  (0) 2024.02.04
[Node.js] 2장  (0) 2024.02.02
[Node.js] 1장  (0) 2024.02.02