TIL 20 [ Spring( 네트워크, 용어, HTTP, Rest API ) ]

1. 학습내용

10:00 ~ 11:00 Spring 입문 발제 

16:00 ~ 17:00 Spring 스탠다드반 수준별 OT 

오늘부터 자바 챕터가 끝나고 스프링입문이 시작된다. 드디어 주특기 공부를 시작이 되었다 화이팅!!

네트워크

인터넷?

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

▶  인터넷을 활용해 멀리 있는 컴퓨터 간의 통신도 가능해짐 

▶  해저 광케이블, 인공위성등 유/무선 방식으로 World wide Web(WWW)가 구축됨

 

인터넷 프로토콜 IP

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

• 복잡한 인터넷 세상에서의 데이터 통신
• IP 주소 - 각 기기 간의 통신을 식별할 수 있는 전화번호
• 패킷(Packet) - 소스 IP, 대상IP를 포함하고 있어서 어떤 컴퓨터에 데이터를 전송할지 판별함.
  • 소스 IP(출발지) , 대상IP(도착지)를 포함하고 있어서 어떤 컴퓨터에 데이터를 전송할지 판별할 수 있음.
  • 패킷은 크게 헤더, 페이로드, 트레일러(수신여부)로 구분됨.
  • 데이터를 주기만 하는것이 아닌 받고 응답함.

※ IP 방식의 문제점

1. 애플리케이션 구분 

• 대상 컴퓨터의 어떤 프로그램에 사용될 데이터인지 구분 할수 없음.

2. 비연결성 

• 수신 대상의 현재 상태에 상관없이 데이터를 전송함.

3. 비신뢰성

• 패킷이 소실되는 경우가 발생한다.
• 패킷의 손상여부를 송신, 수신측 모두 알 수 없다.
• 패킷의 순서가 뒤죽박죽이 되어 섞여서 들어오는 경우가 발생한다.
  • 용량이 큰 데이터의 경우 패킷이 여러개로 나뉘어져 전송된다. → 패킷이 손실되거나, 오류가 발생하여도 데이터의 재전송을 진행하지 않습니다.

   위와같은 문제점들을 해결해주는 것이 바로 TCP 프로토콜 입니다.

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

• 3 Way HandShake

• 데이터 전송 여부→ TCP를 통해 통신하면 데이터를 잘 받았다는 응답을 반환해준다.
• 패킷 순서 → 패킷이 나뉘어져 올지라도 순서를 보장한다.

UDP ▶ 비연결형, 신뢰성이 없는 전송 프로토콜,  실시간 통신이나 스트리밍 애플리케이션에서는 빠른 전송이 중요했기 때문에 UDP는 이러한 요구를 충족하기 위해 개발

• UDP의 특징
  1. IP 방식과 거의 비슷하다.
     • 3 way handshake를 하지 않는다.
       • 데이터 전송, 응답, 순서를 보장하지 않는다.(비신뢰성)
  2. 추가적인 기능이 거의 없다.
     • 기능이 없고 연결을 하지 않는 대신 속도가 빠르다.
  1. IP와 차이점으로 PORT 가 존재한다.
     • TCP에도 PORT가 존재한다.
  2. 데이터 무결성 검사 → **체크섬(Checksum)**을 포함하고 있다.
     • 잘못된 데이터가 전송되지 않도록 만들어준다.

Port

• FTP - 20, 21 (TCP)
• SSH - 22 (TCP)
• 텔넷 - 23 (TCP)
• SMTP - 25 (TCP)
• DNS - 53 (TCP/UDP)
• DHCP - 67 (UDP)
• HTTP - 80 (TCP) ★
• HTTPS - 443 (TCP) ★
• RDP - 3389 (TCP/UDP)

Web 기초

DNS ▶ 사람이 읽을 수 있는 도메인 이름을 컴퓨터가 읽을 수 있는 IP 주소로 변환 ( 도메인 → IP주소 변환 )

• DNS가 나오게된 이유
  1. 컴퓨터 간의 통신을 위해선 IP 주소가 필요하다.
     • IP 주소는 사이트마다 특징도 없고 길어서 외우기가 힘들다.
     • IP 주소가 변경된다면 새로운 IP에 접근할 수 없다.
  2. IP는 변경되는 주소이다.
     • 일반적으로 가정집에서 사용되는 IP는 유동IP 입니다.
     • 만약 IP가 변경된다면 새로운 IP에 접근할 수 없습니다.

URI ▶ 인터넷 자원(Resource)을 나타내는 고유 식별자(Identifier)를 뜻

• 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으로 실제 리소스에 접근하는 방법은 대중화 되어있지 않다.

 💡 현재 대부분은 대중화된 URL을 사용하여, URI를 URL과 같은 의미로 사용한다.

URL ▶ 프로토콜을 포함한, 자원(Resource)의 위치를 나타낸다.

• 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

용어

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

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

• 클라이언트 to 서버의 통신에 JSON을 사용한다.
• 서버 to 서버의 통신에도 JSON을 사용한다.

# 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 형태의 데이터를 사용할 수 있다.

Scale Up ( 수직적 확장 )

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

Scale Out ( 수평적 확장 )

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

Stateful ( 상태 유지 )  ▶ 클라이언트의 상태를 유지

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

Stateless ( 무상태 )   ▶ 클라이언트의 상태를 유지 X

• 장점
  • 같은 서버를 유지할 필요가 없다.
  • Scale Out 수평 확장성이 높다.
    • 갑자기 요청량이 증가하여도 서버를 증설 하기 쉽다.
• 단점
  • 클라이언트가 데이터를 추가적으로 전송해야 한다.
    • 전송되는 데이터의 양이 많아진다.

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

Connection( 연결 )  

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

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

Connectionless ( 무연결 )

• 클라이언트와 서버는 연결을 유지하지 않는다.
• 서버는 최소한의 자원만을 사용한다.
• ex) 브라우저가 켜진 상태에서 인터넷이 종료되어도 홈페이지가 정상적으로 노출된다.

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

HTTP 지속연결(Persistent Connections)

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

HTTP

[CS/네트워크] - HTTP(http), 통신 방식

HTTP(http), 통신 방식

기존에 포스팅으로 다뤘던 HTTP 방식 참고

• HTTP Message 구조

• 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를 추가할 수 있다. (단, 서버가 값을 알고 있어야 함)
   • 요청의 추가 정보들을 가지고 있다.
   ex) Message Body 내용, 크기, 인증, 브라우저 정보, 서버 정보 등
3. Empty Line
   • 공백 한 줄
   • 필수 값
4. Message Body
   • 실제 전송하는 데이터가 담겨 있는 부분
     • HTML, 이미지, JSON 등 byte로 표현되는 모든 데이터 전송 가능.
   • 요청 시 GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

• HTTP 응답 메세지(Response Message) 

1. Start Line
   • HTTP Version
   • Status Code
     • 요청이 성공했는지, 실패했는지 나타내는 코드
   • Status Text
     • 코드와 함께 전달될 메세지
2. Header
   • Response에서만 사용되는 Header 값들이 따로 존재한다.
3. Empty Line
   • 공백 한줄, 필수값
4. Message Body
   • 실제 전송하는 데이터가 담겨 있는 부분
   • 만약 전송할 데이터가 없다면, Body가 공백으로 존재한다.

HTTP API 설계

• HTTP API 설계 방법
  1. HTTP API는 설계시 항상 리소스 식별을 기준으로 삼아야한다.
  2. 위 예시에서 리소스는 게시글이다.
  3. URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다. board → boards
  4. URL에 동사를 사용하지 않는다.
  5. HTTP Method의 역할을 URL에 포함하지 않는다.
• HTTP API 설계
  • 게시글 생성
    • POST
    • /boards
    • 성공시 상태코드 2xx
    • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
  • 게시글 1개 조회
    • GET
    • /boards/{id}
    • 성공시 상태코드 2xx
    • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
  • 게시글 목록 조회
    • GET
    • /boards
    • 성공시 상태코드 2xx
    • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
  • 게시글 수정
    • PUT or PATCH
    • /boards/{id}
    • 성공시 상태코드 2xx
    • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
  • 게시글 삭제
    • DELETE
    • /boards/{id}
    • 성공시 상태코드 2xx
    • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)

 

HTTP Header

• 대표적인 HTTP Header
  • 표현 헤더(Representation)
    • 실제 데이터를 전송할 때는 특정 형식으로 변환하여 보내게된다.
    • 리소스에 대한 표현 정보(어떤 데이터 형식으로 보낼지)를 나타낸다.
    • 요청, 응답에 모두 사용되는 Header이다.
    • 종류
      • Content-Type : 형식
        • 전송할 데이터의 미디어 타입, 문자 인코딩을 나타낸다.
        • text/html; charset=utf-8
        • application/json
      • Content-Encoding : 압축 방식
        • 데이터를 압축 후 Encoding 헤더를 추가하면, 읽는 쪽에서 해당 정보로 압축을 해제한다.
        • gzip
        • identity : 압축하지 않음을 나타낸다.
      • Content-Language : 언어
        • 데이터의 언어를 표현한다.
        ex) ko로 되어있으면 한글을 보여주고, en으로 되어있으면 영어로된 페이지를 보여줄 수 있다.
        • ko
        • en
      • Content-Length : 길이
        • 실제로는 표현 헤더가 아닌, 페이로드(Payload) 헤더이다.
        • byte 단위로 나타낸다.
  • 컨텐츠 협상(Content Negotiation)
    • 클라이언트가 선호하는 표현을 요청한다.
    • 요청시에만 사용되는 Header이다.
    • 우선 순위가 존재한다.
      • Quality Values 줄여서 q 값을 사용한다.
      • 0 ~ 1 사이의 값이 존재하며 1에 가까울수록 우선순위가 높다.
      • Value가 1인 경우 생략이 가능하다.
      ex) Accept-Language: ko-KR,en-US;q=0.9,en;q=0.8
    • → 서버에서 지원 가능하다면 우선순위를 기반으로 응답 데이터를 표현한다.
    • q가 생략되었다면 선언된 순서대로 우선순위를 가진다.→ application/json ⇒ text/plain ⇒ */*
    • ex2) Accept: application/json, text/plain, */*
    • 구체적으로 선언된 것이 우선순위가 높다.→ text/plain;format=flowed ⇒ text/plain ⇒ text/* ⇒ */*
    • ex1) Accpet: text/*, text/plain, text/plain;format=flowed, */*
    • 종류
      • Accept : 선호하는 미디어 타입
      • Accept-Charset : 선호하는 문자 인코딩
      • Accept-Encoding : 선호하는 압축 인코딩
      • Accept-Language : 선호하는 언어
  • 일반 정보
    • 단순한 정보들을 나타내는 Header 이다.
    • 종류
      • From : 클라이언트 이메일 정보
        • 잘 사용하지 않는다.
      • Referer : 현재 요청된 페이지의 이전 웹 페이지 주소
        • 유입 경로 파악 가능
        • 요청시 사용하는 Header
      • User-Agent : 클라이언트 애플리케이션 정보(PC, Mobile 브라우저)
        • 어떤 환경에서 주로 접속하는지 통계
        • 어떤 종류의 환경에서 장애가 발생하는지 파악 가능
        • 요청시 사용하는 Header
      • Server : 요청을 처리하는 ORIGIN 서버의 Software 정보
        • 응답에서 사용한다.
      • Date : HTTP 요청이 발생한 날짜와 시간
        • 응답에서 사용한다.
  • 특별 정보
    • 종류
      • Host : 요청한 도메인 정보
        • 필수적으로 포함해야하는 Header 이다.
        • 요청시 사용한다.
      • Location : 생성된 리소스 URI, 리다이렉트 주소
        • 응답코드 3xx와 함께 응답되면 리다이렉트 주소이다.
        • 응답코드 201(Created)와 함께 응답되면 생성된 리소스의 URI 이다.
      • Allow : 허용 가능한 HTTP Method
        • 405 (Method Not Allowed)와 함께 응답된다.
        ex) Allow: GET, POST
      • Retry-After : 다음 요청까지 대기 해야하는 시간
        • 503 (Service Unavailable)와 함께 서비스가 언제까지 사용이 불가한지 알려준다.
        • 초단위, 날짜단위 모두 표현이 가능하다.
  • 인증
    • 종류
      • Authorization : 클라이언트 인증 정보
        • 선택한 인증 방법에 따라 Value를 작성한다.
      • WWW-Authenticate : 리소스에 필요한 인증 방법
        • 401 (Unauthorized) 응답과 함께 사용된다.
  • Cookie
    • HTTP는 Stateless 특성을 가지고 있어서 상태를 매번 보내주어야 한다.
    • Cookie를 사용하여 모든 요청마다 상태를 전달한다.
    • 사용자 세션 관리, 광고 정보 트래킹에 많이 사용된다.
    • 종류
      • Set-Cookie : 서버에서 응답시 클라이언트로 Cookie 값 전달
        • 만료기간(expire, max-age), 사용될 위치(domain, path)를 설정할 수 있다.
        • 주의
          • 항상 서버에 전달되니 최소한의 정보만 사용하여 트래픽을 최적화 시켜야 한다.
          • 탈취 당하기 쉬우니 보안에 민감한 개인정보 등은 저장하지 않는다.
      • Cookie : 클라이언트가 서버에서 받은 쿠키를 Cookie 헤더를 통해 전송한다.
      • Secure : 해당 헤더가 적용되면 https인 경우에만 쿠키를 전송한다.
        • 기본적으로 http, https 구분하지 않고 쿠키를 전송한다.
        • HTTP + Secure 가 HTTPS 이다.
      • HttpOnly : http 전송에만 사용한다.
        • 자바스크립트에서 쿠키를 접근하지 못하게 만든다.
      • SameSite : 쿠키에 설정된 도메인이 같은 경우만 쿠키를 전송한다.
  • Cache
    • 캐시가 없다면 같은 요청에 대한 응답 데이터가 같아도 매번 데이터를 새로 다운로드 받는다.
    • 새로 다운로드 받는만큼 속도가 느려지고, 비용이 발생한다.
    • 종류
      • Cache-Control
        • 응답시 사용하는 헤더이다.
        • Cache-Control: max-age
          • 캐시 유효 시간(초)
          • 캐시 유효 시간이 지나면 다시 서버를 통해 데이터를 응답받고 캐시를 갱신한다.
        • Cache-Control: no-cache
          • 캐시 가능한 데이터지만, 서버에 검증하고 사용해야 한다.
        • Cache-Control: no-store
          • 보안에 민감한 데이터, 캐시하지 않는다.
      • if-modified-since : 캐시로 저장된 데이터 최종 수정일
        • 요청시 사용하는 헤더이다.
      • Last-Modified : 데이터가 마지막으로 수정된 시간
        • if-modified-since 요청이 오면 응답한다.
        • 304 (Not Modified) 상태코드와 함께 응답되면 수정되지 않았다는 의미
          • HTTP Message Body가 존재하지 않는다. 캐시 사용
        • 응답시 사용하는 헤더이다.
      • ETag : 캐시용 데이터에 날짜, 시간이 아닌 이름을 지정한다.
        • if-modified-since + Last-Modified 방식은 수정된 데이터가 같거나 캐시가 불필요한 경우를 구분하지 못한다.
        • 요청시 사용하는 헤더이다.

Restful API

[CS/네트워크] - API ,Restful API란 ?

API ,Restful API란 ?

2. 내일 학습 할 것 : 알고리즘, 스프링 입문 (~3주차)