잡학다식 개발일지

Stateful, Stateless

📌 클라이언트와 서버간의 통신 상태(state) 유지 여부에 따라 나뉘는 특성이다.

• Stateful(상태 유지)
  • 클라이언트의 상태를 유지한다.
  • 상담원은 수강생의 요청들을 기억(상태 유지)하여 다음 질문들에 대한 처리가 가능하다.

Stateful 방식의 문제점

• 같은 서버가 유지되어야 한다.
• 상태를 유지하고 있던 서버가 종료된다면?

• 서버는 다양한 이유로 동작하지 않을 수 있다.
  • 시스템 에러, 비지니스 로직 문제, 리소스 부족 문제 등
• 요청 트래픽이 몰리게되면 상태를 유지하는것에 Resource가 많이 소모된다.
  • 리소스가 버티지 못하면 서버가 종료되거나, 다음 요청에 대한 처리가 느려진다.

[1]  Stateless(무상태)

• 클라이언트의 상태를 유지하지 않는다.
• 클라이언트의 요청을 저장하지 않는다.

• 어떻게 서로 다른 상담원들이 수강생의 요청을 알 수 있을까요?

[2]  Stateless 방식의 실제 요청방식

• 강의를 신청하려는 수강생이 상담한 직원이 아닌 다른 직원이 와도 신청할 수 있게 되었다.

• 장점
  • 같은 서버를 유지할 필요가 없다.
  • Scale Out 수평 확장성이 높다.
    • 갑자기 요청량이 증가하여도 서버를 증설 하기 쉽다.

• 단점
  • 클라이언트가 데이터를 추가적으로 전송해야 한다.
    • 전송되는 데이터의 양이 많아진다.
• Stateless 방식의 한계점
  • WebApplication을 만들때 서버의 확장성을 고려하여 최대한 Stateless하게 만들어야 한다.
  • 하지만, 실제로는 로그인과 같은 상태를 유지해야하는 경우가 발생한다.
  • 추후에 배울 Cookie, Session, Token 등을 활용하여 이러한 한계를 극복한다.
    • 상태 유지를 최소화 시켜야 한다.

Connection, Connectionless

📌 클라이언트와 서버 간의 연결(Connection) 유지 여부에 따라 나뉘는 특성이다.

[1]  Connection(연결)

• 서버는 클라이언트와 연결을 유지하기 위해서 자원을 소모한다.
• 하지만, 수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청은 작다.
  • 클라이언트 2, 3이 아무런 요청이 없어도 연결을 유지한다.

• Connection 장단점
  • 장점
    • 새로운 연결 과정을 거치지 않아도 된다.
    • 그만큼 요청에 대한 응답 속도가 빨라진다.
  • 단점
    • 클라이언트가 지속적으로 요청을 보낼거라는 보장이 없다.
    • 즉, 연결을 위한 자원이 낭비된다.

[2]  Connectionless(비연결)

• 클라이언트와 서버는 연결을 유지하지 않는다.
• 서버는 최소한의 자원만을 사용한다.

ex) 브라우저가 켜진 상태에서 인터넷이 종료되어도 홈페이지가 정상적으로 노출된다.

ex) 브라우저가 켜진 상태에서 인터넷이 종료되어도 홈페이지가 정상적으로 노출된다.

• Connectionless 장단점
  • 장점
    • 서버 자원을 효율적으로 사용할 수 있다.
  • 단점
    • 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.
    • → 요청에 대한 응답 시간이 증가한다.
    • 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다.
    • → 캐시, 브라우저 캐싱로 해결한다. 쉽게 말해 임시저장 (추후 다룰 예정)
    • 현재는 **HTTP 지속연결(Persistent Connections)**로 문제를 해결한다.

[3]  HTTP 지속연결(Persistent Connections)

• 비 연결성의 한계 극복을 위해 생성됨
• 하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지한다.
• 연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다.
• → 그만큼 속도가 빨라졌다.

ex) HTML 요청 + CSS 요청 + JS 요청 + 이미지 요청

HTTP ( HyperText Transfer Protocol )

📌 HTTP는 웹에서 데이터를 전송하는 통신 프로토콜로, 클라이언트와 서버 간의 요청 및 응답을 관리하는 역할을 합니다.

• 웹 브라우저나 기타 클라이언트가 서버에 요청을 보내면, 서버는 요청에 대한 응답을 클라이언트로 보내는 방식으로 동작합니다. HTTP는 비상태성(stateless) 프로토콜로, 각 요청은 독립적으로 처리됩니다.

기반 프로토콜

•  TCP: HTTP/1.1, HTTP/2

• UDP: HTTP/3

• 현재 HTTP/1.1 주로 사용

• HTTP/2, HTTP/3 도 점점 증가

• HTTP 동작 순서
  • 클라이언트는 Request(요청)을 보내고, 응답을 기다린다.
  • 서버는 요청에 대한 처리를 수행 후 결과를 Response(응답)한다.

HTTP 특징

📌 HTTP는 인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계되었다. 만약 서버에서 다수의 클라이언트와 상태나 연결을 계속 유지해야 한다면 이에 따른 많은 서버의 리소스가 필요하다.

[1]  클라이언트와 서버 구조

• 기존에는 클라이언트, 서버가 구분되어있지 않았다.
  • 클라이언트는 UI(User Interface)에 중점을 두도록 만들었다.
  • 서버에서 데이터, 비지니스 로직을 담당하도록 만들었다.
• 결과적으로 클라이언트, 서버 각자 독립적으로 발전할 수 있게되었다.
• 컴퓨터의 직업이라 보면 된다. 사람이 의사, 판사의 직업을 갖는 것과 같다.

[2]  무상태 (Stateless)

• 서버는 클라이언트의 상태를 보존하지 않는다. 
• 클라이언트의 요청을 서버가 기록하지 않는다.

ex) 스파르타에 강의를 신청하는 수강생이 상담한 직원이 아닌 다른 직원이 와도 결제할 수 있다.

• 장점
  • Scale Out( 서버 확장 용이 ) 수평 확장성이 높다.
  • 갑자기 요청량이 증가하여도 서버를 증설 하기 쉽다.
• 단점
  • 클라이언트가 데이터를 추가적으로 전송해야 한다.
• 한계점
  • 무상태로 설계할 수 없는 경우가 있다.
  • 로그인은 어떻게 해야할까?
    • Cookie, Session, Token 등을 활용한다. → 추후 배울 내용

[3]  비연결 (Connectionless)

• HTTP는 연결을 유지하지 않는 모델이다.
• 장점
  • 서버 자원을 효율적으로 사용할 수 있다.
• 단점
  • 요청이 추가적으로 오게되면 연결(3 way handshake)을 새로 해야한다.
  • → 요청에 대한 응답 시간이 증가한다.
  • 웹 사이트의 HTML, CSS, JS, 이미지 등의 정적 자원 모두를 다시 다운로드 한다.
  • → 캐시, 브라우저 캐싱로 해결한다. 쉽게 말해 임시저장 (추후 다룰 예정)
  • 현재는 **HTTP 지속연결(Persistent Connections)**로 문제를 해결한다.
  • HTTP 지속연결(Persistent Connections)
    • 하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지한다.
    • 연결을 한번만 맺고 끊기 때문에, Connectionless 방식보다 연결 횟수가 적다.
    • → 그만큼 속도가 빨라졌다.
    ex) HTML 요청 + CSS 요청 + JS 요청 + 이미지 요청

HTTP Message 구조

📌 HTTP Message는 요청 메세지, 응답 메세지 두 가지 종류가 있고 구조가 각각 다르다.

• 거의 모든 형태의 데이터가 이 메시지에 담겨서 이동된다.

[1]  HTTP Message 구조

[2]  HTTP 요청 메세지(Request Message)

1. Start Line
   • HTTP Method
     • GET
     • 요청의 의도를 가진 GET, POST, PUT, PATCH, DELETE 등이 있다.
       • Create - POST
       • Read - GET
       • Update - PUT(전체), PATCH(일부)
       • Delete - DELETE
       • Request Target
   • path
     • /event
     • HTTP Request가 전송되는 대상, 절대 경로(”/”로 시작하는 경로)
     • 그냥 요청 대상
     • Query String(= Query Parameter) 에 해당하는 값도 포함한다.
     ex) /search?keyword=sparta
   • HTTP Version
     • 1.1
     • HTTP Version을 나타낸다.
2. Header
   • Host: spartacodingclub.kr
   • field-name: OWS field-value OWS (OWS : 띄어쓰기 허용) 구조를 가진다.
   • field-name은 대소문자 구분을 하지 않는다.
   • 임의의 Header를 추가할 수 있다. (단, 서버가 값을 알고 있어야 함 = 토큰같은 키나 데이터 일관성 보안문제)
   • HTTP 전송에 필요한 모든 부가정보
   ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
   
3. Empty Line
   • 공백 한 줄
   • 필수 값
4. Message Body
   • 실제 전송하는 데이터가 담겨 있는 부분
     • HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
   • 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

[3]  HTTP 응답 메세지(Response Message)

1. Start Line
   • HTTP Version
   • Status Code
     • 요청이 성공했는지, 실패했는지 나타내는 코드
     • 200: 성공 • 400: 클라이언트 요청 오류 • 500: 서버 내부 오류
   • Status Text
     • 코드와 함께 전달될 메세지, 상태 코드 설명
2. Header
   • Response에서만 사용되는 Header 값들이 따로 존재한다.
3. Empty Line
   • 공백 한줄, 필수값
4. Message Body
   • 실제 전송하는 데이터가 담겨 있는 부분
   • 만약 전송할 데이터가 없다면, Body가 공백으로 존재한다.
   • HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

데이터 전송 정리

GET https://example.com/api?name=John&age=25

POST https://example.com/api
Content-Type: application/json

{
  "name": "John",
  "age": 25
}

[1] 정적 데이터 조회

• 이미지, 정적 텍스트 문서
• 조회는 GET 사용
• 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능
• 데이터가 변하지 않거나, 클라이언트가 모든 데이터를 필요로 할 때 사용

[2] 동적 데이터 조회 

• 주로 검색, 게시판 목록에서 정렬 필터(검색어)
• 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
• 조회는 GET 사용
• GET은 쿼리 파라미터 사용해서 데이터를 전달
• 요청 자체를 원하는 것 일부만 요청하는 방식

[3] HTML Form 데이터 전송

HTML Form submit시 POST 전송

• 예) 회원 가입, 상품 주문, 데이터 변경

Content-Type: application/x-www-form-urlencoded 사용

• form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)
• 전송 데이터를 url encoding 처리
  • 예) abc김 -> abc%EA%B9%80

HTML Form은 GET 전송도 가능

Content-Type: multipart/form-data

• 파일 업로드 같은 바이너리 데이터 전송시 사용
• 다른 종류의 여러 파일과 폼의 내용 함께 전송 가능(그래서 이름이 multipart)

참고: HTML Form 전송은 GET, POST만 지원

[4] HTTP API 데이터 전송

서버 to 서버

• 백엔드 시스템 통신

앱 클라이언트

• 아이폰, 안드로이드

웹 클라이언트

• HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)
• 예) React, VueJs 같은 웹 클라이언트와 API 통신

POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송

GET: 조회, 쿼리 파라미터로 데이터 전달 

Content-Type: application/json을 주로 사용 (사실상 표준)

• TEXT, XML, JSON 등등

HTTP API 설계 예시

1. HTTP API - 컬렉션

• POST 기반 등록
  • 설명: 서버가 리소스를 관리하고, 리소스를 추가할 때 고유한 URI를 서버에서 자동 생성합니다.
  • 특징:
    • 클라이언트는 리소스를 추가하고 싶다는 요청만 보냅니다.
    • 리소스의 URI(주소)는 서버가 생성하고 반환합니다.
    • 이는 **컬렉션(collection)**에서 사용하는 방식입니다. 컬렉션은 여러 리소스를 포함한 그룹이므로, 서버가 새로 생성된 리소스의 URI를 관리합니다.
  • 예시:
    • 클라이언트 요청:

      POST /users
      Content-Type: application/json
      
      {
        "name": "John Doe",
        "email": "john.doe@example.com"
      }
      

    • 서버 응답:

      HTTP/1.1 201 Created
      Location: /users/123
      

    • 서버가 생성한 URI는 /users/123입니다.

2. HTTP API - 스토어

• PUT 기반 등록
  • 설명: 클라이언트가 리소스 URI를 미리 결정하고, 그 URI로 데이터를 전송해 리소스를 생성합니다.
  • 특징:
    • 클라이언트가 리소스의 URI를 지정합니다.
    • 이는 **스토어(store)**에서 사용하는 방식입니다. 스토어는 클라이언트가 URI를 알고 있으며, 리소스를 직접 관리할 수 있습니다.
  • 예시:
    • 클라이언트 요청:

      PUT /users/johndoe
      Content-Type: application/json
      
      {
        "name": "John Doe",
        "email": "john.doe@example.com"
      }
      

    • 서버 응답:

      HTTP/1.1 201 Created
      

    • 클라이언트가 /users/johndoe라는 URI를 지정했고, 서버는 이를 받아 생성했습니다.

3. HTML FORM 사용

• 순수 HTML + HTML form 사용
  • 설명: 순수 HTML에서는 주로 **HTML 폼(form)**을 사용하여 데이터를 서버로 전송하며, HTTP 메서드로 GET과 POST만 지원합니다.
  • 특징:
    • HTML 표준에 따라 PUT, DELETE와 같은 HTTP 메서드는 지원하지 않습니다.
    • 따라서 HTML form으로는 리소스를 수정하거나 삭제하는 기능을 구현할 수 없고, 오직 데이터 조회(GET)와 등록(POST)만 가능합니다.
  • 예시:
    • HTML form:

      <form action="/users" method="post">
        <input type="text" name="name" value="John Doe">
        <input type="email" name="email" value="john.doe@example.com">
        <button type="submit">Submit</button>
      </form>
      

    • 폼 제출 시 서버로 전송되는 요청:

      POST /users
      Content-Type: application/x-www-form-urlencoded
      
      name=John+Doe&email=john.doe%40example.com
      

요약 비교

URI (Uniform Resource Identifier)

URI는 인터넷 상의 리소스를 식별하는 문자열입니다. 즉, 웹의 특정 자원(예: 웹 페이지, 이미지, 동영상 등)을 나타내는 주소라고 할 수 있습니다. URI는 두 가지 형태로 나타납니다:

참고하면 좋은 URI 설계 개념

[1]  문서(document)

• 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
• 예) /members/100, /les/star.jpg
• (책 한 권)

[2]  컬렉션(collection)

• 서버가 관리하는 리소스 디렉터리
• 서버가 리소스의 URI를 생성하고 관리
• 예) /members
• (책 목록)

[3]  스토어(store)

• 클라이언트가 관리하는 자원 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• 예) /les
• (회원의 대출 기록)

[4]  컨트롤러(controller), 컨트롤 URI

• 문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
• 동사를 직접 사용
• 예) /members/{id}/delete
• (책 반납)

HTTP API - 컬렉션

📌 POST 기반 등록

•  예) 회원 관리 API 제공

클라이언트는 등록될 리소스의 URI를 모른다.

• 회원 등록 /members -> POST
• POST /members

서버가 새로 등록된 리소스 URI를 생성해준다.

• HTTP/1.1 201 Created
• Location: /members/100

컬렉션(Collection)

• 서버가 관리하는 리소스 디렉토리
• 서버가 리소스의 URI를 생성하고 관리
• 여기서 컬렉션은 /members

HTTP API - 스토어

📌 PUT 기반 등록

• 예) 정적 컨텐츠 관리, 원격 파일 관리

클라이언트가 리소스 URI를 알고 있어야 한다.

• 파일 등록 /les/{lename} -> PUT
• PUT /les/star.jpg

클라이언트가 직접 리소스의 URI를 지정한다.

스토어(Store)

• 클라이언트가 관리하는 리소스 저장소
• 클라이언트가 리소스의 URI를 알고 관리
• 여기서 스토어는 /files

HTML FORM 사용

📌 웹 페이지 회원 관리

• HTML FORM은 GET, POST만 지원
• AJAX 같은 기술을 사용해서 해결 가능 -> 회원 API 참고
• 여기서는 순수 HTML, HTML FORM 이야기
• GET, POST만 지원하므로 제약이 있음

컨트롤 URI

• GET, POST만 지원하므로 제약이 있음
• 이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
• POST의 /new, /edit, /delete가 컨트롤 URI
• HTTP 메서드로 해결하기 애매한 경우 사용(HTTP API 포함)

AJAX (Asynchronous JavaScript And XML)

 🐳 AJAX는 웹 페이지에서 동적으로 데이터를 가져오거나 서버와 통신을 할 수 있게 해주는 기술입니다. 페이지를 전체적으로 새로고침하지 않고도 서버와 데이터를 교환할 수 있어(비동기 통신), 더 빠르고 부드러운 사용자 경험을 제공합니다.

1. AJAX의 주요 특징

• 비동기적 통신: 서버와 클라이언트 간의 통신이 백그라운드에서 이루어지며, 페이지 전체를 새로고침하지 않고도 데이터를 업데이트할 수 있습니다.
• 빠른 응답 속도: 필요한 데이터만 가져오기 때문에 전체 페이지를 다시 로드하는 것보다 훨씬 빠릅니다.
• XML 또는 JSON 사용: 초기에는 XML을 주로 사용했지만, 현재는 가볍고 사용하기 쉬운 JSON이 더 많이 사용됩니다.
• 사용자 경험 개선: 인터페이스가 더 부드럽고 동적으로 동작하며, 응답 시간이 단축됩니다.

2. AJAX의 구성 요소

AJAX는 단일 기술이 아니라 여러 기술의 조합입니다:

1. HTML/CSS: 웹 페이지의 구조와 스타일 정의.
2. JavaScript: 비동기 요청을 수행하고, 데이터를 처리 및 업데이트.
3. XMLHttpRequest (XHR): 서버와 데이터를 교환하기 위한 브라우저 API.
4. 서버 측 언어 (PHP, Python, Node.js 등): 클라이언트의 요청을 처리하고 데이터를 반환.
5. 데이터 포맷 (JSON/XML): 서버와 클라이언트 간의 데이터 교환 형식.

3. AJAX 동작 방식

AJAX는 다음과 같은 방식으로 작동합니다:

1. 사용자 이벤트 발생
   버튼 클릭, 폼 제출, 스크롤 등 사용자가 이벤트를 트리거합니다.
2. AJAX 요청 생성
   XMLHttpRequest 객체 또는 fetch API를 사용해 서버에 요청을 보냅니다.
3. 서버 처리
   서버는 클라이언트의 요청을 처리하고 필요한 데이터를 반환합니다.
4. 응답 처리
   클라이언트는 서버로부터 받은 데이터를 처리하여 웹 페이지의 특정 부분을 업데이트합니다.

4. AJAX 코드 예제

(1) XMLHttpRequest 예제

const xhr = new XMLHttpRequest();
xhr.open('GET', 'https://api.example.com/data', true);

xhr.onload = function () {
  if (xhr.status === 200) {
    console.log('Response:', xhr.responseText);
  } else {
    console.error('Error:', xhr.status);
  }
};

xhr.send();

(2) Fetch API 예제 (추천)

fetch('https://api.example.com/data')
  .then(response => response.json())
  .then(data => {
    console.log('Data:', data);
  })
  .catch(error => {
    console.error('Error:', error);
  });

5. AJAX의 활용 사례

• 실시간 검색: 사용자가 검색창에 입력하면 결과를 실시간으로 가져옴.
• 무한 스크롤: 페이지를 끝까지 스크롤하면 추가 데이터를 자동으로 로드.
• 폼 검증: 데이터를 입력할 때 즉시 유효성을 검사.
• 대시보드 업데이트: 실시간 통계를 제공하는 대시보드.
• 채팅 애플리케이션: 메시지가 실시간으로 교환되는 채팅 시스템.

6. AJAX의 한계

• CORS 문제: 다른 도메인에서 데이터를 요청하면 보안상의 제한이 있을 수 있습니다.
• SEO 문제: AJAX를 사용한 데이터 로딩은 검색 엔진이 크롤링하기 어려울 수 있습니다.
• 브라우저 호환성: 일부 오래된 브라우저에서 완벽히 작동하지 않을 수 있음.

7. AJAX와 관련된 최신 기술

• Axios: Fetch API보다 사용하기 쉬운 AJAX 라이브러리.
• GraphQL: REST API 대신 사용하는 데이터 쿼리 언어.
• WebSocket: AJAX를 대체할 수 있는 양방향 통신 기술.

JSON

📌 JSON은 클라이언트와 서버가 통신할 때 사용하는 데이터 양식이다. 클라이언트와 서버가 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있도록 만들어준다.

• 과거 웹 초기 시절부터 사용된 XML 은 헤더와 태그 등의 여러 요소로 가독성이 떨어지고, 불필요한 용량을 잡아먹는다는 단점을 항상 지적받았다. 이에 대응해 간결하고 통일된 양식으로 각광을 받고 있는 것이 JSON이다.
• 키-값 쌍의 구조로 표현하는 텍스트 기반 데이터 형식이다.

요약

• JSON은 사람, 기계 모두 이해하기 쉬우며 용량이 작다.
• XML을 대체해서 데이터 전송 등에 많이 사용한다.
• 마치 전세계 공통어로 영어를 사용하는것처럼 Web의 세계에서는 JSON(JavaScript Object Notation)을 공통어로 사용한다.

[1]  JSON의 배달 비유:

1. JSON = 택배 상자
   • JSON은 데이터를 담아 보내는 포장 상자와 같습니다.
   • 상자 안에 다양한 데이터(키-값 쌍)가 들어있으며, 이 데이터를 꺼내기 위해 상자 구조를 이해해야 합니다.
2. 키 = 상자에 붙인 라벨
   • 키는 데이터의 이름표로, 택배 상자에 붙이는 "내용물 라벨"과 같습니다.
   • 예: "name": "Alice"는 "이름 라벨에 'Alice'라고 적음"과 같음.
3. 값 = 상자 속 물건
   • 값은 실제로 상자 안에 들어 있는 데이터입니다.
   • 예: "age": 25는 "라벨 'age'에 해당하는 물건은 25"라는 의미.
4. 배열 = 상자 속 묶음 물건
   • 배열은 상자 안에 같은 종류의 물건이 여러 개 담겨 있는 모습과 같습니다.
   • 예: "hobbies": ["reading", "coding"]는 "취미 물건 목록".

[2]  JSON의 구조:

{
  "user": [
    {
      "first_name": "wonuk",
      "last_name": "Hwang",
      "age": 100,
      "phone_agree": false,
      "hobby": ["Java", "Spring"]
    },
    {
      "firstName": "sparta",
      "lastName": "Team",
      "age": 200,
      "phone_agree": true,
      "hobby": ["React", "Spring", "Node"]
    },
  ]
}

• snake_case, camelCase 모두 사용이 가능하다.
  • 우리가 만드는 Application 내에서 변환해주는 무엇인가가 있다.
• key-value 형태로 구성되어 있다.
• null, number, string, array, object, boolean 형태의 데이터를 사용할 수 있다.

MSA ( MicroService Architecture )

📌 MSA는 애플리케이션을 독립적으로 배포 및 실행 가능한 작은 서비스 단위로 나누어 개발하는 소프트웨어 아키텍처 스타일입니다.

• 각 마이크로서비스는 특정 비즈니스 기능을 담당하며, 서로 독립적으로 배포, 수정, 확장할 수 있습니다.
• 소프트웨어를 작은 단위의 독립적인 서비스로 분리해 개발 및 운영 효율성을 높이는 구조입니다.
• 참고

Scale Up

📌 수직적 확장

• 단일 서버의 하드웨어의 사용을 높인다. (CPU, Memory 등의 스펙을 높인다)
• 요청에 대한 처리를 더욱 빠르게 할 수 있도록 만든다.

Scale Out

📌 수평적 확장

• 같은 사양의 서버(인스턴스)를 여러 대 배치한다.
• 동시에 더 많은 사용자 요청을 처리할 수 있도록 만든다.

프로그래밍 명명규칙(Casing)

📌 프로그래밍에서 변수, 함수, 클래스 이름 등을 작성할 때 일관성을 유지하기 위한 규칙입니다.

• 명명 규칙은 코드의 가독성을 높이고, 유지 보수를 쉽게 하기 위해 사용됩니다.

[1] 주요 명명 규칙과 특징:

1. 카멜 표기법(Camel Case):
   • 첫 단어는 소문자, 이후 단어는 첫 글자 대문자로 작성합니다.
   • 주로 변수명이나 함수명에 사용합니다.
   • 예: myVariableName, calculateTotal.
   💡 비유: 단어가 마치 낙타(Camel)의 등처럼 올라갔다 내려가는 모양.

1. 파스칼 표기법(Pascal Case):
   • 모든 단어의 첫 글자를 대문자로 작성합니다.
   • 주로 클래스명이나 타입명에 사용합니다.
   • 예: MyClassName, EmployeeDetails.
   💡 비유: 낙타와 비슷하지만, 항상 등 위로 올라간다는 느낌.

1. 스네이크 표기법(Snake Case):
   • 모든 단어를 소문자로 작성하고, 단어 사이를 밑줄(_)로 연결합니다.
   • 주로 변수명이나 상수명(특히 언어에 따라 다름)에 사용합니다.
   • 예: my_variable_name, total_sum.
   💡 비유: 단어들이 뱀처럼 구불구불하게 이어져 있음.

1. 대문자 스네이크 표기법(Screaming Snake Case):
   • 모든 단어를 대문자로 작성하고, 밑줄(_)로 연결합니다.
   • 주로 상수명에 사용합니다.
   • 예: MAX_VALUE, DEFAULT_CONFIG.
   💡 비유: 뱀이 "소리치는(Screaming)" 것처럼 대문자로 강조됨.

1. 케밥 표기법(Kebab Case):
   • 모든 단어를 소문자로 작성하고, 단어 사이를 하이픈(-)으로 연결합니다.
   • 주로 URL 경로나 파일 이름에서 사용합니다.
   • 예: my-variable-name, user-profile.
   💡 비유: 케밥 꼬치처럼 단어가 하이픈으로 연결되어 있음.

[2] 언어별 명명 규칙:

• Java:
  • 클래스: Pascal Case (MyClass)
  • 변수/메서드: Camel Case (myVariable, calculateSum)
  • 상수: Screaming Snake Case (MAX_COUNT)
• Python:
  • 변수/함수: Snake Case (my_variable)
  • 클래스: Pascal Case (MyClass)
  • 상수: Screaming Snake Case (PI_VALUE)
• JavaScript:
  • 변수/함수: Camel Case (myFunction)
  • 클래스: Pascal Case (MyClass)

프로젝트, 레파지토리, 클래스, 상수, 변수 뒷부분만 대문자 사용

DNS(Domain Name System)

📌 DNS는 도메인 이름과 IP 주소를 서로 매핑하는 역할을 수행한다. 즉, 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환한다.

• DNS는 도메인 이름과 IP 주소를 매핑해주는 시스템입니다.
  사람은 이해하기 쉬운 도메인 이름(예: www.example.com)을 사용하고, 컴퓨터는 IP 주소(예: 192.168.0.1)를 사용합니다.
• DNS는 이를 전화번호부처럼 변환해주는 역할을 합니다.
• 도메인 = IP는 기억하기 어렵고 변경되면 통신이 안된다. 그래서 그냥 IP에 별명을 붙인거다.
• DNS = IP 주소와 도메인 이름을 매핑
• 매핑 = 키(key) 역할을 하는 데이터와 값(value) 역할을 하는 데이터를 짝 지어(=연결 지어) 저장하는 데이터 구조

[1] DNS의 배달 비유:

1. 도메인 이름 = 가게 이름
   • DNS는 가게 이름(도메인 이름)을 입력하면 **주소(IP 주소)**를 찾아주는 서비스입니다.
   • 예를 들어, www.pizzashop.com이라는 가게 이름을 알려주면, DNS는 **정확한 위치(IP 주소)**를 찾아줍니다.
   💡 비유: "피자샵(가게 이름)"을 검색하면 "서울시 강남구 도산대로 123(주소)"를 알려줌.
2. IP 주소 = 가게의 정확한 위치
   • 컴퓨터는 IP 주소를 기반으로 데이터를 주고받기 때문에, 도메인 이름만으로는 실제 통신이 불가능합니다.
   • DNS가 이름을 **정확한 위치(IP)**로 변환해야 물건(데이터)을 배달할 수 있습니다.
   💡 비유: 피자 배달원이 "피자샵"이라는 이름만 보고는 어디로 가야 할지 모르지만, 주소를 받으면 정확히 찾아감.
3. DNS 서버 = 전화번호부
   • DNS 서버는 도메인 이름과 IP 주소의 매핑 정보를 저장하고 있습니다.
   • 사용자가 도메인 이름을 요청하면 DNS 서버가 이를 검색하고 해당 IP 주소를 반환합니다.
   • DNS 서버는 도메인 이름을 IP 주소로 변환하는 역할만 할 뿐, 일반적인 서버(예: 웹 서버, 애플리케이션 서버)처럼 데이터를 처리하거나 클라이언트와 직접 통신하는 기능은 수행하지 않습니다.
   • 이게 왜 있냐면, DNS로 보면 클라이언트도 서버 주소를 모른다... 그래서 전화번호부에서 서버의 주소로 변환한 것을 찾아서 통신한다는 것....
   💡 비유: 배달원이 "피자샵"을 검색하면 전화번호부에서 "서울시 강남구 도산대로 123"이라는 주소를 알려주는 것.

[2] DNS의 배달 비유:

• DNS 동작 순서
• 1. 원하는 이름의 도메인을 구매 후, DNS 서버에 등록한다.

• 2. 도메인 명을 입력하면 DNS 서버는 IP 주소를 반환한다.

• IP가 변경되면 DNS 서버에 등록된 IP 주소만 바뀌면 된다.
• 우리는 IP주소의 형태가 아닌 https://spartacodingclub.kr/ 의 도메인 이름 형태로 웹에 접속한다.
  • 일반적으로 URL이라 알고있는것이 바로 DNS를 활용한 예이다.

URI(Uniform Resource Identifier)

📌 인터넷 자원(Resource)을 나타내는 고유 식별자(Identifier)를 뜻한다.

• URI는 인터넷 상의 자원을 식별하거나 위치를 지정하는 표준 형식입니다.
• 쉽게 말해, 웹이나 네트워크 상에서 어떤 자원을 가리키는 "주소" 또는 "이름표"입니다.

• Uniform: 자원(Resource)을 식별하는 통일된 방식을 의미한다.
• Resource: 자원(페이지, 텍스트, 이미지, 동영상, 파일 등)을 의미한다. URI로 식별할 수 있는 모든 것(제한 없음)
• Identifier: 식별자를 의미한다. 항목과 구분하는데 필요한 정보
• = 자원 통합 식별자

[1]  URI  & URL & URN :

• URI(Uniform Resource Identifier)
  • 인터넷 자원(Resource)을 식별할 수 있는 문자열을 뜻한다.
  • URI는 Locator, Name 혹은 둘 다 추가로 분류될 수 있다.
• URL(Uniform Resource Locator)
  • 프로토콜을 포함한, 자원(Resource)의 위치를 나타낸다.  ex) 튜터가 있는곳은 사무실
  • 일반적으로 도메인주소로 알려져있다.
  • 프로토콜을 포함한다.(https://spartacodingclub.kr/)
• URL 방식의 한계
  • 자원(Resource)의 위치를 변경하면 기존 URL은 사용할 수 없다.
  • 브라우저 검색창에 스파르타 코딩클럽 홈페이지를 검색하면https://spartacodingclub.kr/ 사이트가 노출된다.
  • 만약 이 주소를 https://spartacodingclub2.kr/ 로 바꾼다면 기존 경로를 아는 사람들은 검색 페이지의 URL이 업데이트되지 않으면 페이지를 찾을 수 없다.
  • 이러한 한계를 극복하기 위해서 URN이 등장하게 되었다.
• URN(Uniform Resource Name)
  • 자원(Resource)의 이름(Name)을 의미한다. ex) 튜터
  • 리소스의 위치가 변경되어도 이름으로 리소스를 찾기 때문에 잘 동작한다.
  • 프로토콜을 포함하지 않는다.
  • URN으로 실제 리소스에 접근하는 방법은 대중화 되어있지 않다.
  • 안씀

[2]  URI의 배달 비유:

1. URI = 배달 주소
   • URI는 특정 자원을 정확히 식별할 수 있도록 주소와 이름표를 제공합니다.
   • 배달원에게 물건을 전달하려면 정확한 주소와 대상 이름이 필요하듯, 인터넷에서도 URI가 필요합니다.
   💡 비유: URI는 "서울시 강남구 도산대로 123, 김철수"처럼 배달을 위한 주소와 사람을 명확히 나타냄.
2. URL과 URN의 차이:
   URI는 두 가지로 나뉩니다.
   • URL (Uniform Resource Locator): 자원의 위치를 나타냄 (예: http://example.com/page).
   • URN (Uniform Resource Name): 자원의 고유 이름을 나타냄 (예: urn:isbn:1234567890).
   💡 비유:
   • URL: "서울시 강남구 도산대로 123 (위치)"
   • URN: "김철수라는 사람의 주민등록번호 (고유 식별자)"

[3]  URI의 구성 요소:

URI는 보통 스키마, 호스트, 경로, 쿼리 등으로 구성됩니다.

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko#getting-started-introducing-spring-boot

스키마(Scheme): 자원에 접근하는 방식 (예: http, https, ftp).
💡 비유: "택배 방식" (예: 택배, 등기, 퀵).

주로 프로토콜 사용

• 프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙

• 예) http, https, ftp 등등

• http는 80 포트, https는 443 포트를 주로 사용, 포트는 생략 가능

• https는 http에 보안 추가 (HTTP Secure)

호스트(Host): 자원을 제공하는 서버의 위치 (예: example.com).
💡 비유: "건물 주소".

•  URL에 사용자정보를 포함해서 인증 

• 거의 사용하지 않음 = URL은 보안에 취약하여 사용하지 않는다.

포트 번호: 서버내의 자원을 제공하는 프로세스의 식별 번호

💡 비유: "방 번호".

•  포트(PORT)

• 접속 포트

• 일반적으로 생략, 생략시 http는 80, https는 443

경로(Path): 서버 내에서 자원의 위치 (예: /path).
💡 비유: "건물 내부의 방 위치".

리소스 경로(path), 계층적 구조

• 예)

• /home/le1.jpg

• /members

• /members/100, /items/iphone12

쿼리(Query): 자원에 전달할 추가 정보 (예: ?query=value).
💡 비유: "배달 메시지" (예: "문 앞에 두세요").

•  key=value 형태

• ?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB

• query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태

fragment: html의 내부 북마크등에서 사용한다. 서버로 전송되는 정보는 아니다.

•  잘 안쓴다.

•   전달받은 URL로 접속 시 특정 위치(fragment)로 이동할 수 있음

웹 브라우저 요청 흐름

정리

1. 보낼 서버의 주소와 포트 번호를 생성한다.

2. 웹 브라우저가 HTTP 메시지를 생성한다.

3. Socket 라이브러리르 통해 전달한다 (TCP/IP연결 후 전달)

4. 클라에서 보낸 메시지는 여러 중계 서버를 거쳐 목표 서버에 전달된다.

5. 같은 방식으로 답장한다.

인터넷(Internet)

📌 인터넷(Internet)은 인터넷 프로토콜 스위트(TCP/IP)를 기반으로 하여 전 세계적으로 연결되어있는 컴퓨터 네트워크 통신망을 일컫는 말이다

• 대표적으로 해저에 직접적으로 깔려있는 광케이블과 인공위성을 통해서 모든 인터넷은 연결되도록 설계했는데
• 이렇게 전세계를 연결한 통신망을 World Wide Web(WWW)이라 한다.

인터넷 프로토콜 IP(Internet Protocol)

📌 인터넷 프로토콜은 인터넷이 통하는 네트워크에서 어떤 정보를 수신하고 송신하는 통신에 대한 규약(약속)을 의미한다.

• 우리가 흔히 알고 있는 192.168.0.1를 IP라고 부르지만 이는 IP주소라고 한다. 
• 즉 IP는 인터넷 통신법, IP주소는 전화번호라고 생각하면 된다. 전화번호를 제대로 입력하고 통화를 연결하지 않으면 안되는 일종의 법칙으로 IP에 포함된다 할 수 있다.

[1]   IP 주소

• IP 주소는 쉽게 말하면 각 기기 간의 통신을 식별할 수 있는 전화번호 입니다.
• 앞서 설명한 최소한의 규칙을 지킬 수 있는 이유는 여러분들이 잘 아시는 IP 주소 덕분입니다.
• 인터넷 통신 시에는 지정한 IP 주소에 데이터를 Packet 이라는 단위로 전달합니다

IP를 이용한 통신의 한계

• 비연결성
  - 패킷을 받을 대상이 없거나 대상이 서비스 불능 상태여도 전송을 해버립니다.

• 비신뢰성
  - 패킷소실 : 데이터 통신중 패킷이 사라질 가능성이 있습니다.

- 패킷 전달의 순서가 보장되지 않습니다.
ex) 클라이언트는 (Hellow) (world!)로 보냈으나 서버에는 (world!)(Hello)로 도착할 가능성이 있습니다.

• 프로그램 구분이 어렵습니다
  - 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이라면 구분이 어렵습니다.

Packet

📌 패킷(Packet)은 소스 IP, 대상 IP를 포함하고 있어서 어떤 컴퓨터에 데이터를 전송할지 판별할 수 있습니다.

• Packet은 크게 헤더( 주소 라벨 ), 페이로드( 배달하려는 물건 ), 트레일러( 검증 및 확인용 정보 )로 구분됩니다.
• 데이터를 주기만 하는 것이 아닌 받고 응답한다.(중요)

• 패킷 = 배달 상자 라고 보면 편하다. 인터넷 통신은 크게보면 쿠팡과 같은 배달 산업과 유사하다.
• 큰 사진 한장을 여러개의 패킷에 데이터를 분리해서 보관, 전송하는 방식을 패킷 교환 방식이라 한다.

[1]  헤더(Header):

배달물의 주소 라벨이라고 볼 수 있습니다.

• 보내는 사람과 받는 사람의 주소, 연락처 등 배송 정보를 포함합니다.
• 배달원이 어디로 가야 할지, 누구에게 전달해야 할지를 알려주는 역할을 합니다.

💡 예: 보내는 사람(발신지 IP), 받는 사람(목적지 IP), 패킷 번호(순서).

[2]  페이로드(Payload):

실제로 배달하려는 물건에 해당합니다.

• 네트워크에서 이는 전송하려는 실제 데이터입니다.
• 이메일 내용, 파일, 영상 스트림 등이 여기에 포함됩니다.

💡 예: 이메일 본문, 이미지 데이터, 파일 조각.

[3]  트레일러(Trailer):

검증 및 확인용 정보로, 배달물이 제대로 도착했는지 확인하는 용도로 쓰입니다.

• 데이터가 전송 중 손상되지 않았는지 확인하는 오류 검사 코드 등이 포함됩니다.
• 배달 과정에서 문제가 있으면 다시 발송을 요청하거나, 오류를 수정할 수 있습니다.

💡 예: 체크섬(오류 검출), 데이터의 종료 표시.

TCP(Transmission Control Protocol)

📌 서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜.

• IP방식에서는 패킷이 손실되거나 오류가 생겨도 데이터를 재전송 하지 않는 등의 문제가 있었습니다.
• 다만 TCP는 3Way HandSake를 통해 이를 해결하였습니다.
• IP의 문제점을 개선하기 위해 등장한 인터넷 프로토콜

• Ethernet frame 안에 IP안에 TCP 안에 HTTP(메시지)가 있다.

TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

• 연결지향 - TCP 3 way handshake (가상 연결) = 서버 연결 되었나 확인하고 데이터 전송

• 데이터 전달 보증

• 순서 보장

• 신뢰할 수 있는 프로토콜

• 현재는 대부분 TCP 사용

3-Way Handshake 순서 (네트워크 관점):

1. 송신자 → 수신자: SYN 패킷
   • 연결 요청.
2. 수신자 → 송신자: SYN-ACK 패킷
   • 요청 수락 및 연결 준비 상태 알림.
3. 송신자 → 수신자: ACK 패킷
   • 수락 확인 및 데이터 전송 준비 완료.

[1]  SYN (문 열기 요청)

• **송신자(A)**가 **수신자(B)**에게 배달 준비가 되었는지 묻는 단계입니다.
• 배달원(A)이 **“문 열어도 되겠습니까?”**라고 묻는 상황과 비슷합니다.
• 네트워크에서는 송신자가 SYN 패킷( SYN 플래그가 설정된 패킷 )을 보냅니다.

💡 비유: 배달원이 "지금 물건을 전달할 준비가 되셨나요?"라고 묻는 메시지.

[2]  SYN-ACK (문 열기 확인)

• **수신자(B)**는 SYN 요청을 확인하고, 동시에 자신의 준비 상태를 알립니다.
• 수신자가 배달원에게 **“네, 문 열렸습니다. 물건 주시면 됩니다!”**라고 대답하는 단계입니다.
• 네트워크에서는 수신자가 SYN-ACK 패킷을 보냅니다.

💡 비유: 수신자가 "알겠습니다. 저도 준비되었습니다!"라고 응답.

[3]  ACK (확인 완료)

• **송신자(A)**는 수신자의 응답(SYN-ACK)을 확인하고 마지막으로 연결이 성립되었음을 알림니다.
• 배달원이 **“좋습니다, 물건을 전달하겠습니다!”**라고 마지막 확인을 보내는 단계입니다.
• 서버는 클라이언트의 SYN 요청을 수락하며, 자신도 연결을 시작하고 싶다는 뜻을 담아 SYN 플래그와 함께 ACK 플래그가 설정된 패킷을 클라이언트에게 전송합니다다.
• 여기서 데이터를 같이 전송 가능하다.

💡 비유: 배달원이 "좋아요, 이제 물건을 전달하겠습니다!"라고 다시 확인.

+ 하나 착각하면 안되는게, 위에는 단순히 보기 편하라고 클라,서버만 통신을 하는 것 처럼 보이게 하였지만, 실제로는 클라-서버-서버-서버- *** - 목표 서버 로 이동하게 된다. 나만을 위한 전용 랜선이 된건 아니라는 

UDP(User Datagram Protocol)

📌 UDP는 비연결형, 신뢰성이 없는 전송 프로토콜이다. TCP의 신뢰성 보장 기능은 많은 애플리케이션에 유용했지만, 실시간 통신이나 스트리밍 애플리케이션에서는 빠른 전송이 중요했기 때문에 UDP는 이러한 요구를 충족하기 위해 개발되었다.

• 현대에서는 UDP를 많이 사용하는 추세이다. HTTP3 에서 채택한 방식, HTTP에도 버전이 있다!
• 특징 : 실시간성 보장 중요

[0] UDP 특징

사용자 데이터그램 프로토콜(User Datagram Protocol)

• 하얀 도화지에 비유(기능이 거의 없음)

• 연결지향 X - TCP 3 way handshake X

• 데이터 전달 보증 X

• 순서 보장 X

• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

• 정리

• IP와 거의 같다. +PORT +체크섬 정도만 추가

• 애플리케이션에서 추가 작업 필요

[1]  UDP의 특징

1. IP 방식과 거의 비슷하다.
   • 3 way handshake를 하지 않는다.
     • 데이터 전송, 응답, 순서를 보장하지 않는다.(비신뢰성)
2. 추가적인 기능이 거의 없다.
   • 기능이 없고 연결을 하지 않는 대신 속도가 빠르다.
3. IP와 차이점으로 PORT 가 존재한다
   • TCP에도 PORT가 존재한다.
4. 데이터 무결성 검사 → **체크섬(Checksum)**을 포함하고 있다 .
   • 잘못된 데이터가 전송되지 않도록 만들어준다.
   • 암호화라고 생각하면 편하다. 배달 물건에 박스 안에 담긴 물건의 무게가 5kg이라고 기록, 받는 사람이 제대로 왔는지 한번 더 확인하는 것

PORT

📌 포트(Port)는 네트워크에서 특정 프로그램이나 서비스와 연결을 식별하는 숫자로, 마치 한 주소에서 여러 방(포트 번호)을 통해 특정 사람이나 부서에 연결하듯, 포트를 사용하면 하나의 컴퓨터(IP 주소)에서 여러 서비스를 구분하고 접근할 수 있습니다.

• 현재 전송하고자 하는 패킷이 어떤 곳에 필요한 패킷인지 IP만으로는 해결이 되지 않습니다. 이때 프로그램을 구분하기 위해 사용되는 것이 바로 PORT입니다!
• 이미 국제 도메인 관리기구에 의해 사용되는 포트가 있는데 이게 0~1023포트이다. (0~65535 포트까지 존재)
• 이는 당연히 사용하지 않는게 좋다. 정부 소유 방에 들어가서 난장판을 칠건 아니니...
• 그냥 같은 IP 내에서 프로세스를 구분하는 식별 코드다.

실제 패킷 정보

[1] 포트의 배달 비유:

1. IP 주소 = 건물 주소
   • IP 주소는 배달을 보낼 목적지 건물에 해당합니다.
   • 그러나 건물에는 여러 세대나 방이 있을 수 있으므로, 단순히 IP 주소만으로는 정확한 대상을 특정하기 어렵습니다.
   💡 비유: 건물의 외부 주소(IP)만으로는 어느 세대(서비스)로 배달할지 알 수 없음.
2. 포트 번호 = 방 번호
   • 포트 번호는 특정 서비스를 나타내는 "방 번호"라고 볼 수 있습니다.
   • 예를 들어, 이메일 서비스(SMTP)는 25번 포트, 웹 서버(HTTP)는 80번 포트를 사용합니다.
   • 배달원은 **주소(IP)와 방 번호(포트 번호)**를 모두 알아야 물건을 정확히 전달할 수 있습니다.
   💡 비유: 건물 101호는 웹 서비스(80번 포트), 102호는 파일 전송 서비스(21번 포트) 등으로 나눔.
3. 패킷의 목적지 = 방 안 사람(서비스)
   • 포트 번호를 통해 데이터가 정확히 어떤 프로그램으로 전달될지 결정됩니다.
   • 예를 들어, IP 주소로 데이터를 보냈더라도 포트 번호가 없으면 잘못된 서비스로 전달될 가능성이 있습니다.
   💡 비유: 배달원이 "김철수 씨는 101호로 사는군요!"라고 확실히 알고 전달.

[2] 포트의 특징:

• 범위: 0~65535 (16비트 숫자)
  • 0~1023: 잘 알려진 포트(예: HTTP 80, HTTPS 443, FTP 21).
  • 1024~49151: 등록된 포트(특정 앱에서 사용).
  • 49152~65535: 동적/임시 포트(일시적인 연결에 사용).
• 역할: 하나의 IP 주소에서 다수의 서비스를 구분.

프로세스

📌 실행 중인 프로그램을 의미합니다. 프로그램을 실행하면 OS로부터 실행에 필요한 자원(메모리)를 할당받아 프로세스가 됩니다. 프로세스는 운영체제의 주요 관리 단위이며, 독립적으로 실행됩니다.

1. 프로세스의 구성 요소

• 코드 영역(Code Segment) 
  실행할 프로그램의 명령어가 저장된 영역. CPU는 여기서 명령을 읽어 실행합니다.
• 데이터 영역(Data Segment)
  전역 변수와 정적 변수가 저장되는 영역.
• 힙 영역(Heap Segment)
  실행 중 동적으로 할당된 메모리가 저장되는 영역. 예: malloc()이나 new를 통한 메모리 할당. (객체, 변수등 저장)
• 스택 영역(Stack Segment)ㄴ
  함수 호출 시 사용되는 메모리 영역으로, 지역 변수와 함수 호출 정보를 저장.(호출에 필요한 참조 정보 저장)

• 간단하게는, 자원 + 쓰레드 단수~복수로 이루어져 있다. 공장(프로세스)에서 월급(자원)받아 일하는 일꾼(쓰레드)

2. 프로세스의 상태

프로세스는 실행 중 다양한 상태를 가집니다. 대표적인 상태는 다음과 같습니다:

• New (생성): 프로세스가 생성되고 초기화 중인 상태.
• Ready (준비): 실행되기를 기다리는 상태. CPU가 사용 가능할 때 실행됨.
• Running (실행): CPU에서 명령어가 실행 중인 상태.
• Waiting (대기): I/O 작업 같은 이벤트를 기다리는 상태.
• Terminated (종료): 실행을 완료한 상태.

3. 프로세스와 쓰레드

• 프로세스는 프로그램 실행의 독립적인 단위이며, 다른 프로세스와 메모리 공간을 공유하지 않습니다.
• 쓰레드는 프로세스 내에서 실행되는 작업의 흐름으로, 같은 프로세스의 메모리 공간을 공유합니다. (멀티쓰레드를 사용하는 이유는 효율적인 자원 사용과 빠른 동작을 위함입니다.)
• 기본적으로 쓰레드는 같은 프로세스의 메모리 공간을 공유하지만, 스택은 예외적으로 스레드마다 독립적인 스택을 가집니다. (매개변수, 리턴 주소, 지역 변수 등)

4. 프로세스 간 통신 (IPC: Inter-Process Communication)

프로세스는 독립적이지만, 특정 경우 데이터를 공유하거나 협력하기 위해 통신합니다. 주요 방법은 다음과 같습니다:

• 파이프(Pipe): 한쪽에서 쓰면 다른 쪽에서 읽는 방식.
• 메시지 큐(Message Queue): 메시지를 보내고 받는 방식.
• 공유 메모리(Shared Memory): 프로세스들이 특정 메모리 공간을 공유.
• 소켓(Socket): 네트워크 통신 기반의 프로세스 간 통신.

5. 프로세스 관리

운영체제는 프로세스를 다음과 같은 방식으로 관리합니다:

• 프로세스 생성: fork() (UNIX 계열) 또는 CreateProcess() (Windows)를 통해 생성.
• 스케줄링: CPU 시간을 효율적으로 분배. 대표적인 알고리즘은 Round Robin, FIFO, Priority Scheduling 등이 있습니다.
• 프로세스 종료: 실행이 끝나거나 강제로 종료(kill, terminate).

6. 프로세스의 예시

1. 사용자가 웹 브라우저를 실행 -> 브라우저는 새로운 프로세스 생성.
2. 브라우저가 탭마다 새로운 프로세스를 생성 -> 충돌 방지 및 독립성 보장.

쓰레드

📌 프로세스 내에서 실행되는 작업의 단위입니다. 하나의 프로세스는 여러 쓰레드를 가질 수 있으며, 이를 통해 병렬 작업(멀티쓰레딩)을 수행할 수 있습니다. 쓰레드는 프로세스의 자원을 공유하면서 독립적인 실행 흐름을 가집니다.

1. 쓰레드의 특징

1. 독립적인 실행 흐름
   • 쓰레드는 프로세스 내에서 별도의 실행 흐름을 가집니다.
   • 운영체제는 각 쓰레드에 CPU 시간을 할당하여 동시에 실행되는 것처럼 보이게 만듭니다(멀티태스킹).
2. 메모리 공간 공유
   • 같은 프로세스 내 쓰레드는 코드, 데이터, 힙 영역을 공유합니다.
   • 하지만 각 쓰레드는 자신만의 스택(Stack) 공간을 가집니다.
3. 경량 프로세스
   • 쓰레드는 프로세스에 비해 생성, 스위칭, 종료가 더 빠르고 자원 소모가 적습니다.

2. 쓰레드의 메모리 구조

1. 공유되는 영역
   • 코드 영역: 실행할 명령어 공유.
   • 데이터 영역: 전역 변수 및 정적 변수 공유.
   • 힙 영역: 동적으로 할당된 객체 공유.
2. 독립적인 영역
   • 스택 영역: 각 쓰레드마다 고유한 스택을 가집니다. 함수 호출 시 매개변수, 지역 변수, 리턴 주소 등이 저장됩니다.

3. 쓰레드의 동작 방식

• 쓰레드는 운영체제의 스케줄러에 의해 실행 상태가 관리됩니다.
• 생성 → 실행 → 대기 → 종료 상태를 거칩니다.
• 같은 프로세스 내의 쓰레드는 자원을 공유하므로, 동시에 작업을 수행할 수 있지만 동기화가 필요할 때도 있습니다.

+ 다수의 쓰레드가 동시에 공유데이터에 접근하면 데이터가 훼손되는 문제가 생기기도 합니다. 이를 방지하기 위해 동기화라는 작업을 수행합니다. 

4. 멀티쓰레드의 장점과 단점

장점:

1. 병렬 처리: 여러 작업을 동시에 처리하여 성능 향상.
2. 자원 공유: 프로세스 자원을 공유하므로 효율적.
3. 빠른 생성과 종료: 새로운 프로세스를 생성하는 것보다 경량.

단점:

1. 동기화 문제: 자원 접근 시 충돌을 방지하기 위해 동기화가 필요 (예: 뮤텍스, 세마포어).
2. 디버깅의 어려움: 병렬 처리로 인해 버그를 재현하거나 추적하기 어려움.
3. 컨텍스트 스위칭 비용: 스케줄러가 쓰레드를 전환할 때 약간의 오버헤드 발생.

5. 쓰레드 생성 방법

1) Java에서의 쓰레드 생성

• Thread 클래스 상속
• Runnable 인터페이스 구현

위의 2개의 방식이 일반적이지만, Thread의 경우 엄연히 클래스임으로 Thread를 사용할 경우 다른 class를 상속할 수 없습니다.(자바는 다중 상속이 안되지만 C의 경우 가능합니다.) 그래서 일반적으로는 Runnable 인터페이스로 구현합니다.

// Runnable 인터페이스 구현
class MyRunnable implements Runnable {
    public void run() {
        System.out.println("Thread is running...");
    }
}

public class Main {
    public static void main(String[] args) {
        Thread t = new Thread(new MyRunnable());
        t.start();
    }
}

// Thread 클래스 상속
class MyThread extends Thread {
    public void run() {
        System.out.println("Thread is running...");
    }
}

public class Main {
    public static void main(String[] args) {
        MyThread t = new MyThread();
        t.start();
    }
}

6. 쓰레드와 동기화

• 멀티쓰레드 환경에서는 여러 쓰레드가 동시에 공유 자원에 접근할 때 문제가 발생할 수 있습니다.
• 동기화 기법:
  • 뮤텍스(Mutex): 한 번에 하나의 쓰레드만 자원 접근 허용.
  • 세마포어(Semaphore): 지정된 수의 쓰레드만 자원 접근 허용.
  • 모니터(Monitor): Java의 synchronized 키워드 사용.

7. 쓰레드와 프로세스의 차이

main 쓰레드

📌 프로그래밍에서 항상 사용하는 main메서드의 작업을 수행하는 쓰레드를 의미합니다.

• 아무리 짧은 프로그램이라도 일꾼이 있어야 프로그램이 돌아가는 만큼, 쓰레드가 존재합니다.