[Spring] 정리(2)

1. Network

1.1 IP

1.1.1 IP(인터넷 프로토콜) 란

• IP(Internet Protocol)란 인터넷에 연결되어 있는 모든 장치들(컴퓨터, 서버 장비, 스마트폰 등)을 식별할 수 있도록 각각의 장비에게 부여되는 고유 주소이다.

1.1.2 IP 특징

• 지정한 IP 주소에 데이터 전달

• 패킷이라는 통신 단위로 데이터 전달

• 비연결성 & 비신뢰성

• 프로그램 구분 X

1.2 TCP

• 연결 지향 - TCP 3 way handshake

• 데이터 전달 보증

• 순서 보장

• 신뢰할 수 있는 프로토콜

UDP
IP 거의 같다 + PORT & 체크섬 정도만 추가

1.3 PORT

• 같은 IP내에서 프로세스 구분

1.4 DNS (Domain Name System)

• 도메인 명을 IP 주소로 변환

1.5 URI (Uniform Resource Identifier)

• Uniform : 리소스 식별하는 통일된 방식
• Resource : 자원, URI로 식별할 수 있는 모든 것
• Identifier : 다른 항목과 구분하는데 필요한 정보

1.5.1 URL & URN

• URL - Locator : 리소스가 있는 위치를 지정
• URN - Name : 리소스에 이름을 부여 (보편화X)
• URI = URL

1.5.2 URL 전체 문법

• scheme://[userinfo@]host[:port][/path][?query][#fragment]
• https://www.google.com:443/search?q=hello&hl=ko

• 프로토콜 (https)
• 호스트명 (www.google.com)
• 포트 번호 (443)
• 리소스 경로 (/members, /members/100)
• 쿼리 파라미터 (q=hello&hl=ko)

2. HTTP

2.1 HTTP 특징

• 클라이언트 서버 구조
• 무상태(스테이스리스), 비연결성
• 단순함, 확장 가능

• HTTP 메세지
  

2.2 HTTP 메서드

2.2.1 API URI

• GET/members (회원 목록 조회)
• GET/members/{id} (회원 조회)
• POST/members/{id} (회원 등록)
• PUT&PATCH/members/{id} (회원 수정)
• DELETE/members/{id} (회원 삭제)

2.2.2 POST

• 클라이언트가 리소스 위치를 모르고 서버가 Location으로 지정

2.2.3 PUT

• 리소스를 완전히 대체
• POST와 다르게 클라이언트가 리소스를 식별

2.2.4 PATCH

• 리소스 부분 변경

2.2.5 정리

• HTTP API - 컬렉션
  • POST 기반 등록
  • 서버가 리소스 URI 결정

• HTTP API - 스토어
  • PUT 기반 등록
  • 클라이언트가 리소스 URI 결정

2.3 상태 코드

클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

• 1xx (Informational): 요청이 수신되어 처리중
• 2xx (Successful): 요청 정상 처리
• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
  
  • PRG : Post/Redirect/Get
• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

2.4 header

2.4.1 표현

• Content-Type : 표현 데이터의 형식
• Content-Encoding : 표현 데이터의 압축 방식
• Content-Language : 표현 데이터의 자연 언어
• Content-Length : 표현 데이터의 길이

2.4.2 Accept

• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

• 요청 시에만 사용

2.4.3 Cache (Last-Modified, If-Modified-Since)

• 단점
  • 1초 미만 단위로 캐시 조정이 불가능
  • 날짜 기반의 로직 사용
    • 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우

2.4.4 Cache (ETag, If-None-Match)

• 진짜 단순하게 ETag만 서버에 보내서 같으면 유지, 다르면 다시 받기
• 캐시 제어 로직을 서버에서 완전히 분리

2.4.5 Cache-Control (캐시 무효화)

• Cache-Control : no-cache
  • 데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용
• Cache-Control : no-store
  • 데이터에 민감한 정보가 있으므로 저장하면 안됨
• Cache-Control : must-revalidate
  • 캐시 만료 후 최초 조회 시 원 서버에 검증해야함
  • 원 서버 접근 실패시 반드시 오류가 발생함 (504)