기초 Spring 1주차

study/summary

기초 Spring 1주차

으녕오리 2024. 11. 2. 19:38

<수업 목표>

Spring Framework 전, 필수 네트워크 지식들을 숙지
Web 구조 전반

<우리가 배울 것, 준비하기>

서버 : 사용자의 요청에 대한 응답을 수행하는 프로그램
HTTP : 클라이언트와 서버가 데이터를 주고받는 통신 방법
프로토콜 : 컴퓨터끼리 데이터를 주고받기 위하여 정한 통신규약
개발 IDE(IntelliJ 혹은 Eclipse) 코드 편집기를 사용한다.
Git
- 협업, 코드의 버전 관리
- Branch(분기점)에 일정 시점의 코드를 Commit(저장)할 수 있다.
- 커밋을 하면 동그라미 하나가 생성된다.
- remote 저장소 = 원격 저장소
- push, pull, Checkout(Branch 전환), Merge

Chapter 1: 네트워크

인터넷 : TCP/IP 기반 컴퓨터 네트워크 통신망
IP(인터넷 프로토콜)
- 인터넷에서의 정보 송수신에 대한 규약
- IP 주소에 데이터를 Packet 단위로 전달한다.
- Packet
  - 소스 IP(출발지), 대상 IP(도착지), 소스 PORT, 대상 PORT 를 포함하고 있다.
  - Packet의 트레일러 영역(★수신여부 포함 = 데이터를 주고, 받고, 응답한다.)

IP 방식의 문제점
- 애플리케이션 구분 x : 패킷을 어느 프로그램에 사용?
- 비연결성 : 대상이 꺼져 있을 때도 전송됨
- 비신뢰성 : 패킷 소실, 손상여부, 순서 오류
- 위와 같은 문제점이 발생해도 데이터 재전송은 하지 않는다.
- 해결 -> TCP 프로토콜
TCP
- 서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜
- IP 방식의 문제점들을 극복한 프로토콜
- 3 way handshake
  - 물리적x, 논리적 연결
  - 속도가 느리다.
- 데이터 전송 여부와 패킷 순서를 보장한다.
UDP
- 비연결형, 비신뢰성
- 빠르다, 실시간성 보장 중요
- IP 방식과 거의 비슷하지만 UDP와 TCP는 ★ PORT가 존재
- 체크섬(데이터 무결성 검사)를 포함
PORT
- 패킷의 도착지를 식별해준다.
- 이미 사용되고 있는 포트 : HTTP - 80(TCP), HTTPS - 443(TCP)
- 실제 개발 시에는 사용되고 있지 않은 포트를 사용하여 개발한다.

Chapter 2: Web 기초

DNS
- IP 주소 <-> 도메인 이름(사람이 읽을 수 있음)
- DNS 등장 이유 : 통신을 위해서는 IP주소가 필요한데, IP는 변경되는 주소여서
- 동작 순서
  1. 도메인(https://sparta~ 형식)구매 후 DNS 서버에 등록
  2. 도메인명 입력 시 DNS는 IP주소를 반환
- 우리는 도메인 형태로 웹에 접속하므로, IP주소가 바뀌어도 상관 없다.
- URL이 DNS를 활용한 예이다.
URI(URL과 비슷한 의미로 사용한다.)
- 인터넷 자원(데이터)을 식별할 수 있는 방식
- URI = URL + URN
- URL
  - 자원의 위치를 의미 ex)튜터가 있는 곳은 사무실
  - 일반적으로 도메인주소로 알려져 있다.
  - 프로토콜(https)을 포함
  - 자원의 위치(URL)이 변경되면 접근이 어려움 -> URN 등장
URN
- 자원의 이름을 의미 ex) 튜터
- 리소스의 위치가 변경되어도 됨
- 프로토콜 포함 x
- 대중화 x
URL(Uniform Resource Locator)
- 프로토콜을 포함한 '자원의 위치'
- scheme : https, http
- user[:password] : URL은 보안에 취약해서 사용 x
- [/path] : 계층구조(/뒤는 ~에 속한다는 의미)
- [?query]
  - key=value 형태
  - Query Parameter, Query String 이라고도 한다.
  - ?로 시작 &으로 구분

Chapter 3: 용어 모음집

명명규칙
- snake_case : 문자와 문자 사이를 _로 이어준다, 모든 단어는 소문자이거나 대문자
- camelCase
- PascalCase : 클래스 이름

JSON
- 클라이언트와 서버가 통신할 때 사용하는 데이터 양식
- 데이터 양식, 언어에 관계 없이 통일된 데이터를 주고받을 수 있다.
- 용량 작다
- 영어와 같은 Web 세계의 공통어
- snake_case, camelCase 사용 가능
- key-value 형태
- 다양한 형태의 데이터 타입(string, array, boolean 등) 사용 가능
Scale Up과 Scale Out (서버 성능 향상을 위한 방법)
- Scale Out
  - 수직적 확장, 단일서버
  - 처리를 빠르게 해줌
  - 성능과 비용이 기하급수적으로 증가
- Scale Out
  - 수평적 확장, 서버 여러대
  - 동시에 더 많은 사용자 요청을 처리
  - 성능과 비용이 비례적으로 증가
Stateful(상태 유지) : 요청들을 '기억'
Stateless(무상태, 상태 유지 x)
- 이전 내용들까지 매번 재요청한다.
- 수평 확장성이 높다(Scale Out)
  -> 웹 애플리케이션을 만들 때 최대한 Stateless 하게 만들어야 한다.
- 로그인과 같이 상태 유지가 필요한 경우가 있음
  -> Cookie, Session, Token으로 한계 극복
Connection(연결 유지)
Connectionless(연결 유지 x) : 임시저장(캐시, 브라우저캐싱), HTTP 지속연결로 문제를 해결한다.
- HTTP 지속연결 : 하나의 요청에 필요한 요청들이 모두 응답될 때 까지 연결을 유지한다.

Chapter 4: HTTP

HTTP
- JSON과 같은 형태의 데이터가 HTTP를 통해 전송된다.
- 대부분 HTTP/1.1(TCP)를 사용
HTTP 특징
- 클라이언트와 서버가 독립된 구조
- Stateless(무상태) : cookie, session, token 으로 한계 극복
- Connectionless(비연결) : 캐시, 브라우저 캐싱, HTTP 지속연결로 한계 극복
HTTP Message 구조 : 요청, 응답 두 가지가 있다.
- < HTTP 요청 메세지 >
  - [start line]
    - HTTP Method
      - Create - POST
      - Read - GET
      - Update - PUT, PATCH
      - Delete - Delete
    - path : ★ Query String(= Query Parameter)에 해당하는 값을 포함한다.
    - HTTP Version
  - [header] : ★ 요청의 추가 정보들을 가지고 있다.
  - [empty line]
  - [message body] : GET의 경우 사용 x
- <HTTP 응답 메세지>
  - [start line] : HTTP Version, Status Code(요청 성공, 실패 여부), Status Text
  - [header] : ★ Response에서만 사용되는 Header 값들이 따로 존재한다.
  - [empty line]
  - [message body] : 실제 전송하는 데이터가 담겨 있다.
HTTP Method : 데이터를 전송하는 방식
- POST
  - 리소스 생성
  - 주로 HTML FORM(회원가입, 게시글 작성)에 사용된다.
  - Message Body를 통해 요청 데이터를 전달
- GET
  - 리소스 조회
  - 추가적인 데이터 전송이 필요한 경우
    -> Message Body x, Header에 Query String을 사용한다.
- PUT
  - 리소스 덮어쓰기
  - POST와는 다르게 클라이언트 측에서 리소스를 식별(식별자를 제공)하여 URI를 지정한다.
- PATCH : 리소스 부분수정
- DELETE
HTTP Method 속성
- 안전성 : GET은 조회이므로 데이터 변환이 없어서 안전하다.
- 멱등성
  - POST는 멱등성 x
  - 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
  - 요청이 실패한 경우 재시도 하기 위해 필요하다.
- 캐시가능성 : 데이터 임시 저장, GET, HEAD 정도만 캐시로 사용
HTTP 상태 코드 : HTTP Response Message / Start Line / Status Code에 위치한다.
- 2xx : 성공
- 3xx : 리다이렉션
- 4xx : 클라이언트 에러
- 5xx : 서버 에러
HTTP API 설계(방법)
- 리소스 식별을 기준으로 삼아야 한다. 예를 들어 리소스는 일정 관리 앱의 '일정'
- 리소소는 복수 형태로, 동사 사용 x
- ex) 게시글 생성
  - POST
  - /boards
  - 성공시 2xx
  - 실패시 4xx or 5xx
- 이후에 Restful API
HTTP Header : 부가적인 정보를 전송할 수 있게 된다.
- 표현 헤더 : 요청, 응답에 모두 사용됨
- 컨텐츠 협상
- 일반 정보
- 특별 정보
- 인증
- 쿠키
- 캐시
Restful API : REST를 잘 준수하는 API
- REST : URI를 통해 자원(Resorce)를 명시하고, HTTP Method(POST, GET, PUT, DELETE, PATCH)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것
- Maturity Model(성숙도 모델) : 최소한 level2(CRUD)는 지켜줘야 한다.

Chapter 5: Web Application

Web Server : 정적 리소스(HTML, CSS, JS, 이미지 등)을 제공한다.
WAS(Web Application Server)
- Web Server 기능 + 'Application 로직 '수행, DB와 상호작용 하여 '동적 컨텐츠' 생성
- ex)Tomcat
- Web Server와 WAS의 차이점 : Java에서는 Servlet Container기능을 제공하면 WAS이다.
실제 Web System 구성 : Web Server(정적 자원, 오류 발생 거의 없음) + WAS(Application 로직)
Servlet
- HTTP 프로토콜 기반 요청 및 응답을 '처리'하는데 사용되는 객체
- Java에서 Servlet은 HttpServlet 클래스를 상속받아 구현된다.
- Servlet을 지원하는 WAS를 사용하면 서버에서 처리해야 하는 작업 과정 중 '비지니스 로직'만을 처리하면 된다.
Servlet 동작 순서
- 개발자가 하는 일
  1. Request 객체에 담겨져있는 HTTP 요청 정보를 통해 필요한 기능(비즈니스 로직)을 수행한다.
  2. 생성된 Response 객체에 HTTP 응답 정보를 입력한다.

Servlet Container
- Servlet을 지원하는 WAS 내부에는 서블릿 컨테이너가 있다.
- 서블릿 컨테이너는 서블릿을 관리하는 역할을 한다.
- 서블릿 ⊂ 서블릿 컨테이너 ⊂ WAS(Multi Thread를 지원)
  ∴ WAS가 종료될 때 Servlet도 함께 종료된다.
- Servlet 객체를 '싱글톤'으로 관리한다.
  - 싱글톤
    - 객체를 하나만 생성하여 생성된 인스턴스를 공유하여 사용하는 것
    - ★ 공유 변수 사용을 주의해야 한다.
- WAS는 동시 요청에 대한 처리를 위해 Multi Thread를 지원한다.
Thread
- 한 번에 하나의 코드라인만 수행한다. -> 동시 처리 필요하면 여러개의 Thread가 필요
- WAS로 전달된 HTTP Request를 Servlet 객체에 전달해준다.
- Thread는 요청을 처리한 후 반환된다.
Multi Thread
- WAS는 Multi Thread를 지원한다.
- ***Multi Thread 환경이므로 싱글톤 객체(Servlet, Spring Bean)는 주의해서 사용해야 한다.
- 요청마다 새로운 Thread를 생성 -> Context Switching 비용 발생
  ∴ Thread Pool을 사용한다.
SSR(Server Side Rendering)
- 서버에서 동적으로 HTML을 만들어 클라이언트에게 제공하는 기술, 백엔드 영역
- 서버에서 완전히 렌더링된 HTML을 반환하기 때문에 첫 페이지 로딩이 빠르다.
- 검색 엔진 크롤러가 완전한 HTML을 즉시 수집할 수 있어 SEO(검색 엔진에서 상위에 노출될 수 있도록 최적화하는 과정)에 유리하다.
CSR(Client Side Rendering)
- 클라이언트 측에서 동적으로 HTML을 생성해서 적용하는 기술, 프론트엔드 영역
- HTTP API 통신으로 얻은 결과를 통해 브라우저에서 동적으로 화면을 출력한다.
- 클라이언트 측에서 렌더링하므로 사용자 인터렉션(상호작용)에 빠르게 반응할 수 있다.
- 초기 로딩에는 시간이 걸리지만, 초기 로딩 후에는 빠르다.
- SEO에 불리하다.