TIL-Spring 기초 1주차 (25.03.17)

1주차(17강/17강)
2주차(7강/7강)
3주차(7강/7강)

1주차

• 네트워크 -> 인터넷/ 인터넷 프로토콜(IP)/ IP 방식의 문제점 / TCP(Transmission Control Protocol) / UDP (User Datagram Protocol) / PORT
  • 인터넷 ... 인터넷 프로토콜 스위트(TCP/IP) 기반 컴퓨터 네트워크 통신망
  • IP ... 인터넷이 통하는 네트워크에서 어떤 정보를 수신하고 송신하는 통신에 대한 규약. 인터넷 통신 시 지정한 IP주소(소스 IP와 대상 IP)에 데이터를 Packet이라는 단위로 전달함. 데이터를 주기만 하는 것이 아닌 받고 응답함!
  • IP 방식의 문제점 ... 1) 애플리케이션 구분 2) 비연결성 3) 비신뢰성 -> TCP 프르토콜이 이런 문제를 해결.
  • TCP ... 서버와 클라이언트 간 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜. 3 Way HandShake. C -> S (SYN) / S -> C (SYN, ACK) / C -> S (ACK) 의 세 단계 악수. SYN: 접속 요청 ACK: 요청 수락. / 패킷이 나눠져 와도 순서를 보장함.
  • UDP ... IP와 비슷하지만 3 way handshake 안 함(비신뢰성). 추가 기능 X, IP와 달리 Port 존재. Checksum으로 데이터 무결성 검사함
  • PORT ... 0~65535할당 가능. 0~1023은 사용하지 않는 것 권장. 실제 개발 시 사용되지 않는 나머지 포트 사용하여 개발하면됨.
• Web 기초 -> DNS (Domain Name System) / URI (Uniform Resource Identifier) / URL (Uniform Resource Locator)
  • DNS ... IP주소를 외우기 힘들다! IP주소 변경 시 새로운 IP에 접근할 수 없다! (IP는 변경되는 주소임)
  • URI ... 인터넷 자원(Resource)을 나타내는 고유 식별자. 현재는 URL와 같은 의미로 사용.
  • URL ... 프로토콜을 포함한 자원(Resource)의 위치를 나타냄. URL 구조는 알아두면 좋을 듯. 아래 별첨.
• 용어 모음 -> Casing, JSON, Scale UP, Scale Out // Stateful, Stateless, Connection, Connectionless
  • Casing -> 프로그래밍 명명규칙 ... snake_case(Python, DB Table, Column) / camelCase(Java) / PascalCase / kebab-case
  • JSON -> C <-> S 통신 시 사용하는 데이터 양식. C와 S에서 사용하는 언어에 관계 없이 통일된 데이터를 주고받을 수 있도록 만들어줌. key-value 형태로 구성. null, number, string, array, object, boolean 형태의 데이터 사용 가능.
  • Scale UP(수직적 확장), Scale Out(수평적 확장)
  • Stateful(C-S 통신 상태 유지), Stateless(C-S 통신 상태 유지X). Stateless 방식이 수평 확장성이 높음. WebApplication을 만들 때 서버의 확장성을 고려해 최대한 Stateless하게 만들어야 함. 실제로는 로그인과 같은 상태를 유지해야하는 경우가 발생하는데, Cookie, Session Token 등을 활용해 이러한 한계 극복 가능! 상태 유지를 최소화 시키자!
  • Connection(C-S 연결 TCP/IP 연결 유지), Connectionless(C-S TCP/IP 연결 유지X) ... 현재는 Connectionless + Persistent Connections로 connectionless의 단점을 해결함!
• HTTP -> 특징, 구조, 메서드, 메서드 속성, 상태 코드, API 설계, Header, Header 모음, Restful API ...
  • HTTP : (C) Request -> (S) Response
  • HTTP 특징 : 1. 서버와 클라이언트 구조 > C와 S가 구분돼 C에서 UI, S에서 데이터, 비즈니스 로직 담당. 각각 독립적으로 발전 / 2) 무상태(Stateless) > 서버는 클라이언트의 상태를 보존X / 3) 비연결 > HTTP는 연결을 유지하지 않는 모델임. 캐시, 브라우저 캐싱, Persistent Connections로 문제 해결
  • HTTP Message 구조:
    • Requset 1) Start Line (HTTP Method, path, Version) 2) Header (Host, field-name) 3) Empty Line (공백 한 줄. 필수값) 4) Message Body(실제 전송하는 데이터가 담겨 있는 부분/ HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.)
    • Response 1) Start Line (HTTP Version, Status Code-요청 성공/실패, Status Text-코드와 함께 전달될 메세지) 2) Header 3) Empty Line 4) Message Body
  • HTTP Method ... POST(C), GET(R), PUT/PATCH(U), DELETE(D) ... Start Line 처음에 기재. 이외 HEAD, OPTIONS, CONNECT, TRACE Method도 있음. 마지막 두 개는 잘 안 쓴다고.
  • HTTP Method 속성 ... Safe(GET외엔 안전하지 않다. 데이터를 바꾸니까), Idempotent(POST는 멱등성 보장X. 예) 계좌 송금 두 번 한다면?, 게시판 글쓰기, 회원가입), Cacheable(GET, HEAD 정도만 캐시로 사용)
  • HTTP 상태 코드 ... 1xx (정보) , 2xx(성공), 3xx(리다이렉션), 4xx(클라이언트 에러), 5xx (서버 에러)
  • HTTP API 설계 ... 리소스 식별 기준으로 / 동사 사용 안 함 / HTTP Method의 역할을 URL에 포함하지 않기
  • HTTP Header ... C/S가 Request/Response로 부가적인 정보(Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등)를 전송할 수 있도록 만들어줌. field-name: 띄어쓰기 허용. 대소문자 구문 X . 개발자도구(F12) → Network 탭 클릭 → Fetch/XHR 탭 클릭 → 우측 Header 정보에서 HTTP Header 확인 가능.
  • HTTP Header 모음집 ... Representation / Content Negotiation/ 일반 정보/ 특별 정보 / 인증 / Cookie / Cache
  • Restful API ... REST를 잘 준수하는 API. REST(Representational State Transfer)는 URI로 자원(Resource)을 명시하고, HTTP MEthod로 자원에 대한 CRUD Operation을 적용하는 것. / RESTful API 설계 시 고려사항은 숙지하면 좋을 듯. 아래 별첨
• Web Application -> Web Server, WAS(Web Application Server), Web System 구성, Servlet, Servlet 동작 순서, Servlet Container, Thread, Multi Thread, SSR(Server Side Rendering), CSR(Client Side Rendering)
  • Web Server ... HTTP 기반 동작. 정적 리소스(HTML, CSS, JS, 이미지 등)를 제공
  • WAS(Web Application Server) ... HTTP 기반 동작. 웹 서버 기능 포함. 추가 코드를 실행해 Application 로직을 수행하고, DB와 상호작용하여 동적 컨텐츠를 생성. Tomcat이 대표적.
  • Web System 구성 ... Web Server에서 정적 리소스를 처리하고, WAS에서 Application 로직이 필요한 요청만을 WAS에 전달 -> 리소스를 효율적으로 관리하고, 오류 화면을 제공할 수 있음(Web Server는 오류 발생 확률이 낮음. WAS는 오류 발생 확률이 높고 장애 자주 발생. DB와 상호작용 하기에 DB 문제 시 문제 발생)
  • Servlet ... HTTP 프로토콜 기반 Request / Response 처리에 사용. JAVA에서 Servlet은 HttpServlet 클래스를 상속받아 구현되며, 웹 애플리케이션 개발의 핵심 기술 중 하나. C<->S HTTP 통신 시 아래의 작업 처리가 필요함. 하지만 Servlet을 지원하는 WAS를 사용하면, 비즈니스 로직만 실행하면 됨.
  • Servlet 동작 순서 ... 1) WAS가 HTTP 요청 메시지 기반으로 새로운 Request, Response 객체 생성 2) WAS는 만들어진 Request, Response 객체를 서블릿 컨테이너에 넘겨주며 ExampleServelt 객체 호출 3) ExampleServelt에서 비즈니스 로직 처리 4) 응답에 필요한 정보를 개발자가 입력 5) WAS는 Response 객체 정보(개발자가 입력한 정보)로 HTTP 응답 메세지 생성 -> 개발자는 a) Request 객체에 담겨져 있는 HTTP 요청 정보를 꺼내서 사용 b) 생성된 Response 객체에 HTTP 응답 정보 입력
  • Servlet Container ... Servlet을 초기화, 생성, 관리, 호출, 종료 역할 수행. Servlet을 지원하는 WAS 내부에 있음. WAS 종료 시 Servlet도 함께 종료. 개발자가 직접 인스턴스화 해 사용하는 것이 아님. 코드만 작성하면 Servlet Container가 생성함. Servlet 객체를 싱글톤으로 관리하고, 동시 요청에 대한 처리를 위해 Multi Thread를 지원함. (*싱글톤: 객체를 하나만 생성해 생성한 인스턴스를 공유해 사용하는 것. 특정 클래스의 인스턴스가 여러개 생성되지 않도록 하여 자원의 낭비를 방지하고, 인스턴스를 공유해 상태를 일관되게 유지하기 위함. 공유 변수 사용 주의해야 함.)
  • Thread ... Application Code를 하나하나 순차적으로 실행하는 것. Java에서 main method를 실행하면 main이라는 이름을 가진 Thread가 실행됨. 하나의 Thread는 한번에 하나의 코드라인만 수행. C에서 Request가 전달되면 Thread가 Servlet 객체를 호출함. Thread가 하나면, 여러 개의 요청이 줄을 서야함 -> MultiThread 활용
  • Multi Thread ... 여러 개의 Thread를 생성해 사용. WAS는 MultiThread를 지원. Thread Pool이 있고, 요청이 들어오면 Pool에서 Thread를 받아 사용. 사용 완료 후 Pool에 반납. 모두 사용중이라면 Thread가 생길 때까지 대기하거나 거절 가능.
  • SSR ... S에서 동적으로 HTML을 만들어 C에게 제공하는 기술. 백엔드 개발자 영역에 속함. Java에서는 JSP, Thymeleaf가 대표적으로 사용됨.
    동작흐름: 1) 서버(WAS)에 HTML을 요청 2) 서버(WAS)에서 로직을 거친 후 DB를 조회 3) 조회 결과를 기반으로 HTML을 동적으로 생성 4) 생성된 HTML을 응답
    • 장점 1) 초기 페이지 로드 시 서버에서 완전히 렌더링된 HTML을 반환해 첫 페이지 로딩이 빠르고 2) 검색 엔진 크롤러가 완전한 HTML을 즉시 수집할 수 있어 SEO(검색 엔진에서 상위에 노출될 수 있도록 최적화하는 과정)에 유리 ex) 전자상거래 사이트, 뉴스 사이트
    • 단점 1) 모든 요청에 대해 서버가 페이지를 렌더링해야 하므로, 높은 트래픽 상황에서 서버의 부하가 크게 증가할 수 있음 2) 초기 페이지 이외의 페이지들도 렌더링 후 반환되기 때문에 속도가 느림.
  • CSR ... 웹 브라우저에서 JS를 사용해 동적으로 HTML을 생성하서 적용하는 기술. 웹을 모바일 앱처럼 부분 부분 변경할 수 있게 해줌.
    동작 흐름 1) HTML을 요청 -> 비어있는 HTML을 응답 받음. JS가 존재하는 주소 링크를 응답 2) JS(클라이언트 로직, 렌더링 포함)를 요청 3) HTTP API 요청을 하고 화면에 필요한 데이터를 JSON 형태(JSON이 아니어도 됨)로 응답 받음 4) 응답받은 JSON 데이터로 HTML을 동적으로 그림
    • 장점: 1) C에서 렌더링하므로 사용자 인터랙션(상호작용)에 빠르게 반응 / 2) 초기 로딩 후에는 서버와의 통신 없이 빠르게 페이지 간 전환 가능 ex) Google Map, SNS Application
    • 단점: 1) 초기 로딩 시 필요한 모든 JS 파일을 다운로드하고 실행해야 하므로, 초기 로딩 시간이 김. 2) 검색 엔진 크롤러가 JS를 제대로 실행하지 못하면 SEO에 불리할 수 있음

1주차 꼭 기억할 것

1. 네트워크 통신은 HTTP로 이루어짐
2. HTTP는 무상태 프로토콜이며 비연결성 특징을 가짐
3. HTTP Message 구조는 a) HTTP Method(CRUD 외) b) 상태코드 c) HTTP Header로 구성됨
4. HTTP API는 Restful 하게 설계해야 함. 최소 성숙도레벨 2를 지켜야(설계 가이드는 별첨 참고하자)
5. Servlet은 Java에서 Request, Response를 쉽게 다루게 해주는 객체 -> 개발자는 비즈니스 로직만 수행하면 됨!
6. Servlet Container는 Servlet 객체를 싱글톤으로 관리
7. WAS는 다중 요청 처리를 위해 Multi Thread를 지원
8. SSR 방식은 서버에서 동적인 페이지를 완성하여 응답한 것을 브라우저 화면에 출력. SEO에 유리. ex) 포탈, 뉴스, 쇼핑몰 등
9. CSR은 HTTP API 통신으로 얻은 결과를 통해 브라우저에서 동적으로 화면을 출력 -> 클라이언트와 상호작용이 빠름 ex) Google Map, 메신저 앱 등에 활용

2, 3주차는 다음 게시글에서

별첨) URL 구조

• scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]
  https://www.google.com:443/search?q=스파르타+코딩클럽
• scheme
  • 주로 프로토콜을 사용한다. 웹에서는 http, https, ftp를 주로 사용한다.
  • 참고 : http**s**는 http에 보안(Secure)을 추가한 것.
• user[:password]
  • 사용자 정보
  • URL은 보안에 취약하여 사용하지 않는다.
• host[:port]
  • 호스트명 : 도메인 명(www.google.com) 또는 IP 주소를 직접 사용한다.
  • http : 80, https : 443 포트 사용
  • 포트는 일반적으로 생략한다.
• [/path]
  • 리소스의 경로
  • 계층 구조로 구성되어있다.
    ex) 프로토콜://쇼핑몰주소/products/macbookPro
    ex) https://nbcamp.spartacodingclub.kr/backend
• [?query]
  • key=value 형태로 구성된다.
  • Query Parameter, Query String 이라고도 한다.
    • 두 가지 모두 같은 말입니다. 자주 혼용되는 단어이니 잘 기억해주세요.
  • ?로 시작되고 &으로 구분된다.
    ex) ?key1=value1**&**key2=value2**&**key3=value
• [#fragment]
  • html 내부 북마크 등에 사용한다.
    - 전달받은 URL로 접속 시 특정 위치(fragment)로 이동할 수 있음
    ex) http://www.google.com/index.html#image

별첨) RESTful API 설계 시 고려사항

1. Consumer first

• 개발자 중심의 설계방식보다 해당 API의 소비자 입장에서 간단하고 직관적인 API를 설계 해야한다.
• 위에서의 소비자는 엔드유저가 아닌 API를 사용 하고있는 또다른 시스템, 개발자 등을 얘기한다.

2. Make best use of HTTP

• HTTP Method와 Request, Response, Header와 같은 HTTP의 장점을 살려서 개발 해야한다.
  3. Request methods
• 최소한 성숙도 모델 Level2로는 사용하여야 한다.

4. Response Status

• 각각의 API 요청에 따라서 적절한 HTTP 상태코드가 전달되어야 한다.
• 성공했다, 실패했다가 아닌 왜 실패하고 성공 하였는지 함께 반환 시켜주어야 한다.

5. No secure info in URI

• URI에는 사용자의 정보를 포함해서는 안된다.

6. Use plurals

• 제공하는 데이터에 대하여 단수가 아닌 복수형태로 쓰는것이 일반적이다.
• 특정 유저를 찾고자 한다면 엔드포인트에 값을 추가한다.
  ex) /user -> /users
  ex) /users/1

7. User nouns for resources

• 모든 리소스는 가능하면 동사가 아닌 명사형태로 표시한다.
• API URI만 보고도 어떠한 API인지 파악할 수 있는것이 좋다.

8. For exceptions - define a consistent approach

• 일괄적인 엔드포인트를 사용하는것이 좋다.