생각의 흐름

쿠키와 세션을 사용하는 이유는 HTTP의 connectionless(비연결성)과 stateless(비상태성)라는 특징 때문

클라이언트가 요청(request)을 보냈을 때 그 요청에 맞는 응답(response)을 보낸 후 연결을 끊고, 서버는 클라이언트에 대한 상태 정보를 유지하지 않는다.

 

쿠키의 생성과 저장은 구현에 따라 다르지만 원리는 동일

1. 서버가 클라이언트로부터 요청을 받았을 대, 클라이언트에 관한 정보를 토대로 쿠키를 구성

2. 서버는 클라이언트에게 보내는 응답의 header에 쿠키를 담아 보낸다.

3. 클라이언트가 응답을 받으면, 브라우저는 쿠키를 쿠키 디렉터리에 저장한다.

 

쿠키는 클라이언트(브라우저) key-value 쌍으로 로컬에 저장되는 데이터 파일. 유효시간 내에서는 브라우저가 종료되어도 계속 유지된다. 서버에서 response header에 set-cookie 속성을 사용해서 클라이언트에 쿠키를 만들고, 사용자가 따로 작업을 하지 않아도 브라우저가 쿠키를 request header에 담아서 서버에 전송한다.

 

세션은 기본적으로 쿠키를 이용하여 구현이 된다. 클라이언트를 구분하기 위해 각 클라이언트에게 session ID를 부여하고 클라이언트는 쿠키에 session ID를 저장해 둔다. 사용자 정보를 브라우저에 저장하는 쿠키와 달리 세션은 서버측에 저장하여 관리한다. 세션은 유효시간을 두어 일정시간 응답이 없다면 끊을 수 있고, 브라우저가 종료될 때까지 인증상태를 유지할 수 있다.

 

사용자 정보를 서버에 두기 때문에 쿠키보다 보안은 좋지만 서버 자원을 차지하기 때문에 서버에 과부하를 줄 수 있고 성능 저하의 요인이 될 수 있다.

 

캐시도 사용자 데이터를 저장한다. 리소스 파일들의 임시 저장소. 다시 사용될 확률이 있는 데이터들을 빠르게 접근 가능한 저장소에 저장한다. 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 되어 페이지 로딩 속도 개선이 가능하지만 보안에 취약하다.

 


 

 

한 줄 정리

쿠키와 세션 사용 이유
HTTP의 비연결성과 비상태성이라는 특징 때문에 쿠키와 세션을 사용합니다.
클라이언트가 요청(request)을 보냈을 때 요청에 맞는 응답(response)을 보낸 후 연결을 끊고, 서버는 클라이언트에 대한 상태 정보를 유지하지 않습니다. 따라서 페이지 이동시마다 로그인을 유지하거나 팝업창의 다시 보지 않기 설정 등을 하기 위해서는 쿠키나 세션이 필요합니다.

 

쿠키 vs 세션
쿠키는 클라이언트(브라우저)에 정보를 저장하고 text 형식입니다. 브라우저가 종료되어도 유지가 가능하고 세션보다 빠르나 보안에 취약합니다.
세션은 웹서버에 정보를 저장하고 object 형식입니다. 브라우저 종료 시 삭제되고, 쿠키보다 느리나 보안이 좋습니다.

 

쿠키 사용 이유
세션이 웹서버에 정보를 저장하기 때문에 보안에는 좋지만, 서버 자원을 차지하기 때문에 서버에 과부하를 주어 성능저하의 요인이 될 수 있어 쿠키를 사용합니다.

 

세션 vs 캐시
사용자 데이터를 저장하는 역할을 합니다.
캐시는 사용자 컴퓨터에 데이터를 저장하고 서버 요청 시 서버에 전달합니다. 로딩 속도 개선이 가능하지만 보안에 취약합니다.
세션은 서버에 저장하고 캐시에 비해 보안성이 좋습니다.
728x90

'이론 > CS공부' 카테고리의 다른 글

컬렉션 프레임워크  (0) 2022.11.02
추상화  (0) 2022.11.02
MVC패턴  (0) 2022.11.02
Servlet vs JSP  (0) 2022.10.27
JAVA  (0) 2022.10.26

의식의 흐름대로 정리

클라이언트의 요청은 기본적으로 정적인 요청이다. 따라서 웹서버에서 동적인 요청을 수행 할 수 있도록 만들어진 프로그램이 Servlet

Servlet : 자바 언어로 웹 개발을 하기 위해 만들어졌음. 컨테이너가 이해할 수 있게 순수 자바 코드로만 구성됨. 자바 코드 안에 HTML 태그가 삽입됨

서블릿 컨테이너는 웹서버로 요청이 들어왔을 때 init(), service(), distroy() 메소드 등을 이용해 서블릿을 관리하는 역할을 한다.

JSP (Java Server Page) : html 기반에 자바 코드를 블록화하여 삽입한 것. Servlet을 좀 더 쉽게 접근할 수 있도록 만들어짐

서블릿에서 HTML 코딩이 어렵고 불편해서 단점을 보완하고자 만든 서블릿 기반의 스크립트 기술이다.

 

초기의 자바 웹개발은 서블릿을 이용한 개발이었고, 이후 JSP가 개발이 되면서 JSP를 이요한 개발이 유행했다. 지금에 와서는 각각의 역할을 나누어 Servlet+JSP 형태의 개발이 이루어지고 있다.

MVC 패턴에서 모델1 방식은 JSP만 이용한 개발이고, 모델2는 서블릿과 JSP를 동시에 사용하여 개발하는 방식이다. JSP는 HTML 태그 사용이 용이하고 자바코드 사용이 불편하기 때문에 view를 담당하고, Servlet은 자바모드 작성이 편리하기 때문에 주로 화면과 통신하여 자료를 받아 가공하고, 가공한 자료를 다시 화면에 전달하는 Controller 역할을 하고 있다.

Model에는 비즈니스 로직을 처리하는 모든 것이 모델에 속한다. 컨트롤러로부터 특정 로직에 대한 처리 요청이 들어오면 이를 수행하고 수행 결과를 컨트롤러에 반환한다.

 

JSP를 구동하기 위해 서버를 구축하는 과정

자바 인스톨, JDK 인스톨(JRE는 JDK를 설치하면 설치되므로 따로 설치할 필요 없음)

환경변수 세팅

JSP를 웹으로 변환해 줄 수 있는 톰캣 설치

 

서블릿의 실행과정

서버에 클라이언트의 요청을 받으면, 컨테이너는 연결 요청 정보를 담고 있는 Request 객체와 연결 응답 정보를 담고 있는 Respose 객체를 생성하고, 사용자의 요청을 처리하기 위해 스레드를 생성 후 service() 메서드에 인자 값을 담아 호출. 들어온 요청 방식에 따라 get방식은 doGet() 메소드, post 방식은 doPost() 메소드를 호출하여 처리함. response 객체에 정보를 담아 클라이언트에게 결과를 보여줌. 요청을 처리하기 위해 생성한 스레드는 소멸됨

 

서블릿에서 데이터를 처리하는 방법

GET

  • 서버에 있는 정보를 가져오기 위해 설계되었고, 240바이트까지 전달 할 수 있음
  • POST 방식에 비해 속도가 빠르고 검색 엔진에서 검색 단어 전송에 많이 이용
  • URL 노출로 보안성이 요구되는 경우엔 사용할 수 없음

POST

  • 서버로 정보를 올리기 위해 설계됨
  • URL에 파라미터가 표시되지 않음
  • 내부적으로 데이터가 이동함
  • GET 방식에 비해 속도가 느리고 데이터 크기에 제한이 없음

 

JSP에서 페이지 이동 방법

Forward 방식

  • url이 바뀌지 않음
  • 요청 객체와 응답 객체가 유지됨
  • 속도가 빠르며 요청 객체에 소속되어 있음
  • 요청이 들어오면 서블릿이 받고, 요청에 알맞은 페이지를 찾음. 알맞은 페이지가 있다면 응답하고 없다면 요청객체와 응답객체를 포함해 포워딩 방식으로 알맞은 페이지로 넘긴다.
  • 클라이언트와 통신 없이 서버에서만 처리되는 것이어서 리다이렉트보다 좋은 성능을 보여준다.

Redirect 방식

  • 요청에 알맞은 페이지를 찾고 알맞은 페이지가 있다면 응답
  • 알맞은 페이지가 없다면 알맞은 페이지로 다시 요청하게끔 응답을 보냄
  • 클라이언트는 응답을 받고, 다시 그 요청의 맞는 url로 요청함
  • Request와 Response 객체가 새롭게 생성된다
  • 추가적으로 발생하는 처리에 의해 포워딩보다 성능이 느리다.

 

 


 

 

한 줄 정리

클라이언트의 요청이 웹서버에 들어왔을 때 자바 언어로 동적인 처리를 하기 위해 개발된 것이 Servlet입니다.

 

서블릿은 HTML in Java

 

서블릿에서 HTML 코딩이 어렵고 불편해 단점을 보완하고자 나온 것이 JSP(Java Server Page) 입니다.

 

JSP는 Java in HTML. 자바를 기반으로 하는 스크립트 언어입니다.

 

MVC 모델1 방식에서는 JSP가 View와 Controller의 역할을 모두 수행합니다.

 

MVC 모델2 방식에서는 HTML 작업이 편리한 JSP가 View의 역할을 하고, Servlet은 자바 작성이 편리하기 때문에 뷰단과 통신하여 자료를 받고 다시 화면에 전달하는 Controller의 역할을 합니다.
참고로 Model에는 비즈니스 로직을 처리하는 모든 것이 속합니다. 컨트롤러로부터 특정 로직에 대한 처리 요청이 들어오면 이를 수행하고 결과를 다시 컨트롤러에 반환합니다.

 

MVC 패턴은 애플리케이션을 크게 Model, View, Controller로 구분하여 영역 간의 결합도를 최소화한 패턴입니다.
비즈니스로직과 프레젠테이션로직이 분리됨으로써 작업의 분업화를 할 수 있으며, 유지보수에도 용이합니다.
개발에 소요되는 시간을 현저하게 줄여줍니다.

Model : 데이터의 처리와 접근 담당
View : 사용자에게 보여지는 화면 담당
Controller : Model과 View 사이를 연결하고 정보를 교환

 

Request 전송방식의 종류(서블릿에서 데이터를 처리하는 방법)에는 Get, Post, Put/Patch, Delete가 있습니다.

 

Get 방식
- 주로 웹 브라우저가 서버에 데이터를 요청할 때 사용됩니다.
- url에 데이터를 같이 전달하므로 데이터 길이에 제한이 있고 보안에 취약합니다. Post 방식에 비해 빠릅니다.

Post 방식
- 주로 웹 브라우저가 서버에 데이터를 전달할 때 사용됩니다.
- 헤더에 데이터를 전달하는 방식으로 데이터 길이 제한이 없고 보안에 유리하지만 다소 느립니다.

Put/Patch 방식
- Restful에서 수정 작업을 할 때 주로 사용됩니다. Put은 전체 수정, Patch는 일부 수정에 사용됩니다.

Delete 방식
- Restful에서 삭제 작업을 할 때 주로 사용됩니다.

 

Restful : Rest의 규칙을 지켜 제공하는 웹 서비스 방식으로, Rest는 url만 보더라도 어떤 작업을 하는 지 알 수 있도록 데이터의 이름으로 상태를 구분하여 전송하는 방식입니다.

 

Rest의 원칙
1. Unifrom Interface : url만 보고도 데이터의 전송 방법과 방식을 구분 가능하게 해야 한다.
2. Client Server : 클라이언트와 서버는 반드시 분리되어야 한다.
3. Stateless : HTTP 프로토콜을 따르기 때문에 같은 특징을 갖는다. 상태를 저장하지 않으며, 요청에 모든 정보가 담겨 한 번에 전송되어야 한다.
4. Cacheable : 요청을 통해 보내는 자료들은 저장되어야 한다.(저장된 자료를 주고받으며 속도 향상의 장점이 있다) 
5. Layered System : 요청된 정보를 검색하는데 계층 구조로 분리되어 있어야 한다. 중간 서버 등을 둬 서버 확장성을 보장한다
6. Code on Demand : 보통 서버는 XML이나 JSON으로 응답하지만, 필요한 경우 코드 자체를 데이터로 클라이언트에 전달 할 수 있다.

 

Restful한 서비스 제공을 위한 url 네이밍 규칙
- 명사 사용
- 복수형 사용
- 소문자 사용
- 구분자는 '-(하이픈)' 사용
- url 마지막에 슬래쉬를 포함하지 않는다.
- 파일 확장자는 포함하지 않는다.
728x90

'이론 > CS공부' 카테고리의 다른 글

컬렉션 프레임워크  (0) 2022.11.02
추상화  (0) 2022.11.02
MVC패턴  (0) 2022.11.02
Cookie vs Session  (0) 2022.10.31
JAVA  (0) 2022.10.26

의식의 흐름대로 정리

Java는 네트워크 상에서 쓸 수 있도록 미국의 썬 마이크로 시스템즈가 개발한 객체 지향 프로그래밍 언어

 

Java의 특징

  1. 자바가상머신(JVM)만 설치하면 컴퓨터의 운영체제(OS)에 상관없이 작동하기 때문에 운영체제에 독립적이다.
    - JVM(Java Virtual Machine) : 컴파일된 자바 바이트 코드를 실행시켜주는 소프트웨어

  2. 객체 지향 프로그래밍 언어이다. > 캡슐화, 상속, 다형성의 특징을 갖는다. > 코드의 재사용 및 유지보수에 용이하다.
    - 객체 지향 프로그래밍(OOP; Object-Oriented Programming) : 데이터를 객체로 취급하여 프로그램에 반영한 것으로, 기존의 절차 지향 프로그래밍과 다르게 객체의 상호작용을 통해 프로그램이 동작한다.
    - 객체 지향 프로그래밍과 절차 지향 프로그래밍 차이 : 절차 지향 프로그래밍은 순차적인 처리가 중요하며, 대표적으로는 C언어가 있다. 컴퓨터의 처리 방식과 유사하기 때문에 객체 지향 언어보다 처리 속도가 더 빠르다. 하지만 실행 순서가 정해져 있어 코드의 순서가 바뀌면 동일한 결과를 보장하기 어려워 유지보수가 어렵다. 또 디버깅이 어렵다. 객체 지향 프로그래밍은 코드의 재활용성이 높고 절차지향보다 코딩이 간편하다. 디버깅이 쉽다. 반면에 처리속도는 절차 지향 언어보다 느리며, 설계에 많은 시간이 소요된다. 절차 지향 언어는 실행 순서, 절차가 더 중점이고 객체 지향 언어는 필요한 객체들의 종류와 속성 등에 더 중점을 두고 프로그래밍 된다. 즉, 절차 지향과 객체 지향은 서로 프로그래밍 되는 방식이 다를 뿐, 반대되는 성질이 아니다.
    - 캡슐화 : 관련된 데이터와 메서드를 하나의 단위로 묶어 정보를 은닉하는 것(외부 객체에서 구현 방식은 알 수 없다). 클래스 필드 값에 권한을 설정할 수 있다(public, private, protected, default). getter/setter를 통해 접근하도록 가능하다.
    - public : 접근 제한 없음
    - private : 같은 클래스에서만 사용 가능(접근 권한이 가장 적음)
    - public > protected > default > private
    - 상속 : 부모 클래스에 자식이 접근할 수 있도록 물려받는 방식
    - 다형성 : 부모 타입의 참조 변수로 자식 타입의 객체를 다루는 것. 오버로딩과 오버라이딩이 있다.
    - 오버로딩 : 상속이 아닌 하나의 클래스 내에서 이름이 같은 여러 개의 메서드를 정의하는 것. 매개변수의 수, 배치(순서), 타입이 달라야 한다.
    - 오버라이딩 : 부모에게서 상속받은 것들을 새롭게 재정의 하는 것을 뜻함. 재정의 한 것은 자신의 클래스 내부에서만 영향을 끼치며 부모에게는 영향을 끼치지 않는다.

  3. Garbage Collector를 통해 자동적으로 메모리를 관리한다.
    - 시스템에서 더 이상 사용하지 않는 동적 할당된 메모리 블럭을 찾아 자동으로 다시 사용 가능한 자원으로 회수하는 것을 Garbage Collection이라고 하고, Garbage Collection을 수행하는 부분을 Garbage Collector라고 부른다.
    - 자바 메모리는 Method Area, Heap, Stack, PC Register, Native Method Stack 영역으로 나눈다.
    - Method Area는 JVM이 실행되면서 생기는 공간으로 모든 스레드가 공유하는 영역이다.
    - 런타임 상수풀(runtime constant pool), 필드(field) 데이터, 메소드(Method) 데이터 등을 분류하고 저장한다.
    - Heap 영역은 객체와 배열이 생성되는 영역이며, 힙 영역에 생성된 객체와 배열은 Stack 영역의 변수나 다른 객체의 필드에서 참조
    - 참조하는 변수나 필드가 없는 의미없는 객체는 Garbage Collector가 자동으로 제거한다.
    - 그래서 개발자는 객체를 제거하기 위한 별도의 코드를 작성할 필요가 없다.
    - Stack 영역은 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 할당된다.
    - 메소드를 호출할 때마다 push 되고 메소드가 종료되면 제거(pop)된다. Last In First Out 방식이다.
    - PC Register는 스레드가 생성되면서 생기는 공간으로, 스레드가 처리하고 있는 명령어의 주소를 등록한다.
    - JVM이 실행하고 있는 현재 위치를 저장하는 역할
    - Native Method Stack은 Java가 아닌 다른 언어(C, C++)로 구성된 메소드 실행이 필요할 때 사용되는 공간이다.

  4. Multi thread를 지원
    - thread는 한 process 내에서 실행되는 동작(기능 function)의 단위
    - 각 thread는 속해 있는 process의 스택 메모리를 제외한 나머지 메모리 영역을 공유할 수 있다.
    - multi thread는 하나의 process가 동시에 여러 개의 일을 수행할 수 있도록 해주는 것.
    - 즉, 하나의 process에서 여러 작업을 병렬로 처리하기 위해 multi thread를 사용한다.
    - process는 프로그램이 메모리에 적재되어 CPU를 할당받아 실행되는 것
    - 예를 들어 유튜브를 실행하면 한 개의 프로세스가 실행되는 것.
    - 2개 이상의 process가 동시에 실행되면 multi process라고 한다.
    - cpu core가 1개라면 여러 프로세스를 짧은 시간 동안 번갈아 연산을 하는 동시성을 갖는다.
    - cpu core가 여러 개 라면 각각의 core가 각각의 process를 연산하는 병렬성을 갖는다.
    - multi process와 multi thread는 동시에 여러 작업을 수행한다는 측면에서 유사한 면이 있다.
    - 적용할 시스템에 따라 두 방법의 장단점을 고려하여 적합한 방식을 선택해야 한다.
    - multi thread는 multi process보다 적은 메모리공간을 차지하고 Context Switching이 빠르다.
    - 컴퓨터는 다양한 업무를 처리하기 위해 task를 번갈아 가며 실행하는데, 이 때 현재 진행하고 있는 task(process, thread)를 저장하고 다음 실행할 task의 상태를 읽어 적용하는 과정을 Context Switching이라고 한다.
    - multi process는 multi thread보다 많은 메모리 공간과 CPU 시간을 차지한다.
    - multi thread는 동기화 문제나 하나의 thread 장애로 전체 thread가 종료될 위험이 있다.
    - 동기화 문제란, 서로 다른 thread가 메모리 영역을 공유하기 때문에(자원을 공유하기 때문에) 여러 thread가 동일한 자원에 동시에 접근하여 엉뚱한 값을 읽거나 수정하는 문제이다.
    - multi process는 하나의 process가 죽더라도 다른 process에 영향을 주지 않아 안정성이 높다.
    - 메모리 구분이 필요할 때는 multi process가 유리하고, Context switching이 자주 일어나고 데이터 공유가 빈번한 경우, 자원을 효율적으로 사용해야 하는 경우에는 multi thread가 유리하다.


 

 

한 줄 정리

Java는 객체지향 프로그래밍 언어로써 캡슐화, 다형성, 상속의 특징을 갖습니다. 또 JVM(자바 가상 머신) 위에서 실행이 되기 때문에 운영체제에 독립적입니다.

 

객체지향 프로그래밍(OOP; Object-Oriented Programming)은 데이터를 객체로 취급하여 프로그램에 반영한 것으로, 기존의 절차지향 프로그래밍과 다르게 객체의 상호작용을 통해 프로그램이 동작합니다.

 

절차지향 프로그래밍은 순차적인 처리가 중요하며 대표적으로는 C언어가 있습니다. 컴퓨터의 처리 방식과 유사하기 때문에 객체지향보다 처리 속도가 빠릅니다. 하지만 실행 순서가 정해져 있어 코드의 순서가 바뀌면 동일한 결과를 보장하기 어렵고, 따라서 유지보수가 어렵습니다.
객체지향 프로그래밍은 코드의 재활용성이 높고, 절차지향보다 코딩이 간편합니다. 반면에 처리속도는 절차지향보다 느리며, 설계에 많은 시간이 소요됩니다.
절차지향은 실행 순서, 절차가 더 중점이고 객체 지향 언어는 필요한 객체들의 종류와 속성 등에 더 중점을 두고 프로그래밍을 합니다. 즉, 절차지향과 객체지향은 서로 프로그래밍 되는 방식이 다를 뿐, 반대되는 성질은 아닙니다.

 

캡슐화는 변수와 함수를 하나의 클래스로 묶어 정보를 은닉화하는 것으로, 외부객체에서 구현 방식을 알 수 없습니다. 접근 권한을 설정할 수 있으며, getter/setter를 통해 접근할 수 있습니다.

 

접근 권한에는 권한 순으로 public, protected, default, private이 있고, 접근 제한이 없는 public과 같은 클래스 내에서만 사용 가능하여 접근 권한이 가장 적은 private가 주로 쓰입니다.

 

다형성은 부모 타입의 참조 변수로 자식 타입의 객체를 다루는 것을 뜻합니다. 오버로딩과 오버라이딩 등이 있습니다.

 

오버로딩은 하나의 클래스 내에서 같은 이름의 메소드를 여러 개 정의하는 것으로, 매개 변수의 개수나 변수 타입이 달라야 합니다.

 

오버라이딩은 부모 클래스에서 상속 받은 것들을 재정의하는 것입니다. 재정의된 메서드는 같은 클래스 내에서만 영향을 끼치며, 부모에게는 영향을 주지 않습니다.

 

상속은 부모 클래스에 자식이 접근할 수 있도록 물려받는 것입니다. 기존 클래스의 기능을 유지하면서 추가적인 기능을 추가하여 클래스를 만들고 싶을 때 사용합니다. 상속은 코드를 간결화하며, 재사용성을 높일 수 있습니다.

 

JVM(Java Virtual Marchine)은 컴파일된 소스 코드를 실행시켜주는 소프트웨어입니다. JVM이 있어 운영체제에 상관없이 자바를 실행할 수 있습니다. JRE(Java Runtime Environment)는 자바 실행환경으로, 라이브러리 등 개발 되어있는 것을 실행합니다. JDK(Java Development Kit)는 개발을 위해 필요한 도구들을 포함하고 있어 개발 및 실행이 가능합니다.

 

자바의 메모리 영역은 Method Area, Heap, Stack, PC Register, Native Method Stack으로 나뉩니다.

 

Method Area는 JVM이 실행되면서 생기는 공간으로 모든 스레드가 공유하는 영역으로, 컴파일되어 들어온 코드를 분류하여 저장합니다.

 

Heap 영역에서는 Stack 영역의 변수나 다른 객체의 필드에서 참조하는 객체와 배열이 생성됩니다. 더 이상 참조하지 않게 되는 의미없는 객체는 Garbage Collector에 의해 제거됩니다. 

 

Stack 영역은 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 할당됩니다. 메소드를 호출할 때마다 push되고 종료되면 마지막 메소드부터 제거(pop)됩니다(Last In First Out)

 

스레드(thread)는 한 프로세스(process) 내에서 실행되는 동작의 단위이고, 프로세스는 CPU를 할당받아 실행되는 프로그램을 뜻합니다. 예를 들어 유튜브를 키면, 한 개의 프로세스가 실행되는 것입니다.

 

PC Register는 스레드가 생성되면서 생기는 공간으로, JVM이 실행되고 있는 현재 위치를 저장하는 역할을 합니다.

 

Native Method Stack은 자바 외의 언어로 구성된 메소드 실행이 필요할 때 사용되는 공간입니다.

 

자바는 멀티 스레드를 지원합니다. 멀티 스레드란, 하나의 프로세스에서 여러 개의 작업을 병렬로 처리하는 것을 말합니다.

 

프로세스도 두 개 이상의 프로세스가 동시에 작동할 때 멀티 프로세스라고 합니다. CPU core를 한 개만 사용할 때는 여러 프로세스를 짧은 시간 동안 번갈아 연산하는 동시성을 갖습니다. CPU core가 여러 개라면, 각각의 코어가 각각의 프로세스를 연산하는 병렬성을 갖습니다.

 

멀티 스레드와 멀티 프로세스는 동시에 여러 작업을 한다는 측면에서 유사하지만, 장단점이 다릅니다.
멀티 스레드는 멀티 프로세스보다 적은 메모리 공간을 차지하고, Context Switching이 빠릅니다. 반면 멀티 프로세스는 멀티 스레드보다 많은 메모리 공간과 CPU 시간을 차지합니다.
멀티 스레드는 동기화 문제나 하나의 스레드 장애로 전체 스레드가 종료될 위험이 있지만, 멀티 프로세스는 하나의 프로세스가 죽더라도 다른 프로세스에 영향을 주지 않아 안정성이 높습니다.

 

메모리 구분이 필요할 때는 멀티 프로세스가 유리하고, Context switching이 자주 일어나고 데이터 공유가 빈번한 경우, 자원을 효율적으로 사용해야 하는 경우에는 멀티 스레드가 유리합니다.

 

Context switching은 컴퓨터가 task를 번갈아 가며 실행할 때, 현재 진행하고 있는 task를 저장하고 다음 실행할 task의 상태를 읽어 적용하는 과정입니다.

 

동기화 문제란, 서로 다른 스레드가 메모리 영역(자원)을 공유하기 때문에, 동일한 자원에 동시에 접근하여 엉뚱한 값을 읽거나 수정하는 문제 입니다.

 

728x90

'이론 > CS공부' 카테고리의 다른 글

컬렉션 프레임워크  (0) 2022.11.02
추상화  (0) 2022.11.02
MVC패턴  (0) 2022.11.02
Cookie vs Session  (0) 2022.10.31
Servlet vs JSP  (0) 2022.10.27

+ Recent posts