Spring 입문!

 

 

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

• 인터넷 네트워크 환경에서 어떤 정보를 수신하고 송신하는 통신에 대한 규약
• IP 주소를 이용해서 각 기기간 통신을 식별
• 인터넷 통신 시에는 지정한 IP주소에 데이터를 packet이라는 단위로 전달
• Packet 구성
  • 헤더 : 출발지 IP, 목적지 IP
  • 페이로드 : 실제로 전송할 데이터
  • 트레일러 : 수신여부 포함

  • 

• Ip 의 문제점
  • 애플리케이션 구분
    • 대상 컴퓨터의 어떤 프로그램에 사용될 데이터인지 구분 불가
  • 비 연결성
    • 수신 대상의 현재 상태와 상관없이 데이터 전송
  • 비 신뢰성
    • 패킷이 소실되는 경우가 발생
    • 패킷의 손실 여부를 수신 및 송신 측에서 알 수 없음
    • 패킷의 순서가 뒤죽박죽이 되어 들어오는 경우가 발생

위의 문제점을 해결하는 것이 TCP 프로토콜

 

---

TCP 프로토콜

• 서버와 클라이언트 간에 데이터를 신뢰성 있게 전달하기 위한 프로토콜
• 3 Way HandShake
  • SYN 접속 요청
  • ACK 요청 수락
  • ACK와 함께 데이터 전송

• 데이터 전송 여부 보장
• 패킷의 순서 보장
• 하지만 속도가 느림

 

UDP 프로토콜

• IP와 같이 비연결성 비신뢰성 전송 프로토콜
• 장점은 아주 빠른 속도
• 온라인 게임, 실시간 스트리밍 서비스 등
• 실시간 보장 중요
• IP 와의 차이점으로 PORT 존재
• 체크섬 변수로 데이터 무결성 검사 가능

 

PORT

• 같은 IP 내에 프로세스 구분을 하기 위해서 사용
• 0~65535 할당 가능
• 0~1023 이미 사용 <- 사용하지 않는게 좋음
• SSH - 22
• HTTP - 80
• HTTPS - 443

 

DNS (Domain Name System)

• 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환해주는 역할 수행

 

URI(UniForm Resource Identifier)

• 데이터를 식별하는 통일된 방식
• URL (Locator)과 URN (Name)을 포함
• URL
  • 자원의 위치를 의미
  • 일반적으로 도메인 주소로 알려져 있음
  • 프토로콜 포함
  • 자원의 위치를 변경하면 기존 URL은 사용 불가능
• URN
  • 자원의 이름을 의미
  • 위치가 변경되어도 이름으로 리소스를 찾는다.
  • 프로토콜 포함 x
  • 대중화 X
• 현재는 대중화된 URL을 사용하고 그로인해 URI = URL이라고 생각한다.

 

• URL 구조

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

• scheme
  • 주로 프로토콜을 사용
• host
  • 도메인명 또는 IP주소를 직접 사용
  • 포트는 일반적으로 생략
• [/path]
  • 리소스의 경로
  • 계층 구조로 구성
• [?query] 
  • key = value 형태로 구성
  • 쿼리 파라미터, 쿼리 스트링이라고도 한다.
  • ? 로 시작하고 &으로 구분
• [#fragment]
  • html 내부 북마크 등에 사용

 

---

용어 정리

Casing 

• snack_case 
  • Python, DB Table 에서 사용
  • 문자와 문자 사이를 _ 언더바로 연결
• camelCase
  • Java, JavaScript, TypeScript 등에서 변수,함수,메서드 이름을 만들때 사용
  • 문자와 문자 사이를 대문자로 연결
• PascalCase
  • 대부분의 언어에서 클래스 이름 지정시 사용
  • 모든 문자의 맨 앞 글자는 대문자
• kebab-case
  • 문자와 문자 사이를 - 대시로 연결
  • 모든 문자는 소문자

 

 

JSON

• 클라이언트와 서버, 서버와 서버가 통신할 때 사용하는 데이터 양식
• 용량이 작다.
• key = value 형태로 구성

 

Json 직렬화 / 열 직렬화

• 직렬화란
  • 외부의 시스템에서도 사용할 수 있도록 바이트 형태로 데이터를 변환
• 역직렬화
  • 바이트 형태의 데이터를 내부에서 사용할 수 있도록 데이터를 변환
• Ex ) JSON.parse() 역직렬화 , JSON.stringify()  직렬화

 

Scale up & Scale out

• 서버 성능 향상을 위한 방법
• Scale up
  • 수직적 확장
  • 단일 서버의 하드웨어의 사용을 높힘
  • 비용이 높아질 수록 성능도 상승 but 엄청 비용이 기하 급수적으로 상승
• Scale Out
  • 수평적 확장
  • 같은 사양의 서버를 여러 대 배치
  • 동시에 더 많은 사용자 요청을 처리 가능
  • 비용과 성능이 비례해서 상승

 

 

Stateful & Stateless

• Stateful (상태 유지)
  • 클라이언트의 상태를 유지
  • 클라이언트의 전 요청들을 기억하여 다음 요청의 처리가 가능
• Stateful의 문제점
  • 같은 서버가 유지되어야함
  • but 서버는 다양한 이유로 동작하지 않을 수 있으며 요청 트래픽이 몰리면 처리가 느려진다.
• Stateless (무 상태)
  • 클라이언트의 상태를 유지 하지 않는다.
  • 같은 서버를 유지할 필요가 없다.
  • Scale Out 수평 확장성이 높다.
• Stateless의 문제점
  • 클라이언트가 데이터를 추가적으로 전송해야한다. 

 

• 웹 애플리케이션을 만들 때 서버의 확장성을 고려하여 최대한 stateless 하게 만들어야 한다
• 하지만 로그인과 같은 기능 처럼 상태를 유지해야 할 땐
• Cookie Session Token 등을 활용하여 이러한 한계를 극복해야 한다.

 

Connection & Connectionless

• 클라이언트와 서버 간의 연결을 유지 하느냐 마느냐에 따라 갈림
• 연결을 유지하려면 자원을 소모
• 하지만 수많은 사람들이 서비스를 이용해도 실제 서버에서 동시에 처리하는 요청을 적다.
• Connection
  • 장점
    • 새로운 연결 과정을 거치지 않아도 된다.
    • 그만큼 응답 속도가 빨라진다.
  • 단점
    • 연결을 유지하기 위한 자원이 낭비
• Connectionless
  • ex ) TCP/ IP 연결 
    
    • 최소한의 자원만을 사용 
  • 단점
    • 요청이 추가적으로 오면 연결을 새로 해야함
    • 느림
    • 정적 자원을 모두 다시 다운로드 해야한다.
    • 현재는 HTTP지속연결 (Persistent Connections) 로 문제 해결

 

---

HTTP 

HTTP (HyperText Transfer Protocol)

• 다양한 형태의 데이터가 전송되는 프로토콜
• HTTP에도 버전이 존재
• 대부분 HTTP/1.1(TCP) 사용
• 요즘에는 HTTP/2, HTTP/3(UDP) 사용량이 증가하는 추세

 

HTTP 동작 순서

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

 

HTTP 특징

인터넷 상에서 불특정 다수의 통신 환경을 기반으로 설계

1. 클라이언트 - 서버 구조
2. 무상태 (Stateless)
3. 비연결 (Connectionless)

 

 

HTTP Message 구조

• Request Message
  • Start Line
    • 예시) GET / event HTTP/1.1
    • HTTP Method
      • GET / POST / PUT / DELETE 
    • Path
      • HTTP Request가 전송되는대상
      • 쿼리 스트링에 해당하는 값도 포함
    • HTTP Version
      • 1.1 버전이라는 점을 나타낸다.
  • Header
    • Host : ~~~.kr
      • field-name : field-vale 구조
      • 대소문자 구분 X
      • 임의의 헤더 추가 가능
      • 요청의 추가 정보들을 보유
        • Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
  • Empty Line
    • 공백 한줄
    • 필수 값
  • Message Body
    • 실제 전송하는 데이터가 담겨 있는 부분
    • 요청 시 GET은 Message Body를 사용하지 않아 잘 사용하지 않는다. 

 

• HTTP Response Message
  • Start Line
    • 예시 HTTP/1.1 200 OK
    • HTTP Version
    • Status code : 요청이 성공 했는지 실패 했는지 나타내는 코드
    • Status Text : 코드와 함께 전달되는 메시지
  • HEADER 
    • Response에서만 사용되는 Header 값들이 존재
    • Content_Type, Content_Length 등
  • Empty Line
    • 공백 한줄
    • 필수 값
  • Message Body
    • 실제 전송하는 데이터가 담겨 있는 부분
    • 데이터가 없다면 공백으로 존재

 

HTTP Method

 

• POST
  • 리소스 생성 즉 CREATE
  • 주로 HTML FORM에 사용
  • 요청 데이터를 처리하는 방식에 정해진 것은 x
  • Message Body를 통해 요청 데이터를 전달
• GET 
  • 리소스 조회 read
  • 서버에 추가적인 데이터 전송을 해야한다면 Message Body가 아닌 Query String을 이용해서 데이터 전달
• PUT
  • 리소스 덮어 쓰기 UPDATE
  • 기존 리소스가 있다면 덮어쓰기
  • 만약 name 과 age 가 있는 값에 age 값을 덮어 쓰면 name 값은 소멸
  • 없다면 생성
• PATCH
  • 리소스 부분 수정 
  • PUT에서 불가능 했던 부분 수정이 가능
  • 필요한 부분만 골라서 수정
• DELECT
  • 리소스 삭제 

 

메서드 별 특징

1. 안정성

• 안전하다라는 뜻은 데이터를 변환하지 않는다 라는 뜻
• GET 메서드는 안전
• 그외 나머지는 안전 x 

2. 멱등성 (Idempotent)

• 한번을 호출하거나 수천번을 호출해도 항상 결과는 같다
• GET -> 같은 결과가 계속 조회
• PUT -> 수정해서 대체된 후의 결과는 계속 같다.
• DELETE -> 같은 요청을 여러번 해도 삭제된 결과는 같다.
• POST -> 멱등성 보장 X
• 요청이 실패한 경우 재시도 하기 위해 필요!!
• 복귀 매커니즘에 사용

3. 캐시 가능성

• 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
• GET, HEAD,POST 메소드는 캐시 가능

 

HTTP 상태 코드

• 2XX (성공)
  • 200 OK 성공
  • 201 Created 새로운 리소스 생성
  • 202 Accepted 요청이 수신되었으나 처리가 완료되진 않음
  • 204 No Content 요청은 성공했지만 응답 데이터 x
• 3XX (리다이렉션)
  • 요청을 완료하려면 추가 행동이 필요한 상태
  • 종류
    • 301 Moved Permanently 주소가 영구적으로 바뀌었을 경우 POST가 GET으로 변경됨
    • 308 Permanent Redirect  주소가 영구적으로 바뀌었을 경우 요청 메서드와 본문이 유지
    • 일시 리다이렉션
      • URI가 일시적으로 변경된 경우
      • PRG 패턴 POST -> REDIRECT - > GET
    • 304 Not Modified 캐시 목적으로 사용 
  • 4XX (클라이언트 에러) 
    • 400 Bad Request 클라이언트가 HTTP 요청을 수정 후 보내야 함
    • 401 Unauthorized 클라이언트가 인증이 필요한 경우 주로 로그인
    • 403 Forbidden 서버가 요청을 받았지만 승인 거부, 주로 권한이 없는 경우
    • 404 Not Fount 요청한 리소스가 서버에 없는 경우
  • 5XX (서버 에러)
    • 서버 오류
    • 500 Internal Server Error : 대부분 이것으로 처리
    • 503 Service Unavailable : 서비스 이용불가

 

 

HTTP  API 설계 방법

• HTTP API는 설계 시 항상 리소스 식별을 기준으로 삼아야 한다.
• URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장 board - > boards
• URL에 동사를 사용하지 않는다.
• HTTP Method의 역할을 URL에 포함 x

 

HTTP Header

• 표현 헤더
  • 실제 데이터를 전송할 때는 특정 형식으로 변환하여 전송
  • 종류
    • Content-Type : 형식
    • Content-Encoding : 압축 방식
    • Content-Language : 언어
    • Content-Length : 길이
• 컨텐츠 협상
  • 클라이언트가 선호하는 표현을 요청
  • 요청시에만 사용
  • 우선 순위가 존재 0 ~ 1  , 1일 수록 높음
  • 종류
    • Accept : 선호하는 미디어 타입
    • Accept-Charset : 선호하는 문자 인코딩
    • Accept-Encoding : 선호하는 압축 인코딩
    • Accept- Language : 선호하는 언어
• 일반 정보
  • 종류
    • From 클라이언트 이메일 정보
    • Referer : 현재 요청된 페이지의 이전 웹 페이지 주소
    • User-Agent : 클라이언트 애플리케이션 정보
    • Server : 요청을 처리하는 서버의 정보
    • Date : HTTP 요청이 발생한 시간 정보
• 특별 정보
  • Host : 요청한 도메인 정보, 필수 포함
  • Location : 생성된 리소스 URI, 리다이렉트 주소
  • Allow : 허용 가능한 HTTP Method 
  • Retry-After : 다음 요청까지 대기 해야하는 시간
• 인증
  • Authorization : 클라이언트 인증 정보
  • WWW-Authenticate : 리소스에 필요한 인증 방법
• 쿠키
  • Set- Cookie : 서버에서 응답시 클라이언트로 쿠키 값 전달! 만료 기간, 사용될 위치를 설정, 개인정보 저장 X
  • Cookie : : 클라이언트가 서버에서 받은 쿠키를 쿠키 헤더를 통해 전송
  • Secure : 해당 헤더가 적용되면 HTTPS 인 경우에만 쿠키 전송
  • HttpOnly : http 전송에만 사용
  • sameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송
• 캐시
  • cache_control : 응답 시 사용하는 헤더
    • max -age : 캐시 유효 시간
    • no-cache : 캐시 가능한 데이터 but 서버에 검증하고 사용
    • no-store : 보안에 민감한 데이터 캐시 x
  • if-modified-since : 캐시로 저장된 데이터 최종 수정일 , 요청 시 사용
  • last-Modified : 데이터가 마지막으로 수정된 시간, 응답 시 사용
  • ETag : 캐시용 데이터에 날짜 시간이 아닌 이름으로 지정

 

 

Restful API

• Rest를 기반으로 서비스 API를 구현한 것
• REST
  • 자원을 명시하고 HTTP 메서드를 통해 해당 자원에 대한 CRUD Operation을 적용하는것
• 성숙도 모델
  • REST의 제약 조건에 따라 API 등급화
  • Level 0 : 웹서비스를 제공하기 위해 URL만 매핑
  • Level 1 : 의미 있는 URL, 메서드 별로 서비스 구분 X, 대부분 GET or POST를 사용
  • Level 2 : 우리가 최소한 해야 할 레벨 메서드 별로 서비스를 정확히 구분한 단계
  • Level 3 : HATEOAS 즉 어떤 작업을 할 수 있는지 상태 정보를 함께 넘겨 준다.

 

Restful API 설계 시 고려해야 할 사항들

• Consumer first : 개발자 중심 보다 소비자 입장에서 간단하고 직관적인 API 설계
• Make best use of HTTP
• Request methods : 성숙도 모델 2레벨로는 사용해야함
• Response Status : 각각의 API 요청에 따라서 적절한 상태 코드 전달
• No secure info : 사용자 정보 포함 X
• use plurals : 단수가 아닌 복수 형태 사용
• user nouns for resuorces : 모든 리소스는 가능한 동사가 아닌 명사 형태 표시
• for exceptions - define a consistent approach - 일괄적인 엔드포인트를 사용하는 것이 좋다