jyyoon

How will I serve the world?

4 분 소요

1. HTTP

  • 현재 인터넷에서는 거의 모든 Node들이 데이터를 주고받을 때 HTTP를 사용한다!

  • HTML TEXT IMAGE 음성 영상 파일 JSON XML CSV 거의 모든 형태의 데이터 전송 가능.

  • 가장 많이 사용하는 HTTP/1.1 버전은 1997년 개발됐고, 현재 계속 개선이 이루어지는 중.

  • google이나 naver와 같이 큰 서버들은 HTTP/1.1 뿐만 아니라 2, 3도 조금씩 섞어서 사용하는 추세.

    image-20221216144916021

  • HTTP의 가장 큰 특징, Stateless

    • 무상태 프로토콜.
    • 즉, 그 전에 어떠한 내용도 저장되지 않고 오로지 HTTP 요청에 모든 정보가 다 담겨있다. 서버에 상태를 저장하지 않는다.
    • 다시 말하면, 하나의 HTTP 요청에 필요한 정보가 다 있기 때문에 어떤 서버가 받아도 해당 요청에 대한 응답을 처리할 수 있다.
    • 장점
      • 서버의 Scale up이 용이해짐!!
      • 수 많은 요청 클라이언트와 연결을 유지하고 있지 않아도 되므로 서버의 트래픽 범위를 넓힐 수 있음.
    • 단점
      • HTTP 요청이 길어질 수 밖에 없다.
      • 매 요청 시 3 way handshack 연결작업 리소스가 낭비된다.
    • 보완
      • 때문에 상태 유지를 매우 오랫동안 유지해야하는 경우(ex, 로그인) 브라우저 쿠키와 서버 세션 등을 활용해서 상태를 저장하기도 한다.
      • 연결작업을 줄이기 위해 지금은 HTTP 지속연결(Persistent Connections)로 최적화를 더 함. (한번 연결 시 짧은 일정 시간동안 연결을 지속시킴)
    • 실무
      • 이벤트를 처리해야하는 경우, 순간 대용량 트래픽이 발생하게 되며, 이를 어떻게 분산하여 처리할 것인지에 대한 고민이 많이 필요해지고 가장 어려운 부분임. (ex, 티켓팅, 선착순 이벤트 등)
      • 수강신청과 같이 서버가 매번 터지는 이유는 로그인 상태를 계속 유지해야하기 때문! 서버가 모든 연결을 다 감당하고 있을 수 없기 때문에 대기가 생기는 등 이슈가 발생.
      • 어디에 어떻게 Stateless를 둘 것인지가 비즈니스에서의 핵심!!!

2. HTTP 메시지의 구조

image-20221216150303987

1. 요청 메시지

  1. HTTP 메서드
    • 서버가 수행해야 할 동작 지정 : GET, POST, PUT, DELETE, OPTIONS 등 다양함.
  2. 요청 대상
    • 경로 지정 : “/” 는 절대경로이며, http://~~처럼 전체 경로를 넣을 수도 있음.
  3. HTTP 버전
  4. HOST
    • 요청 대상의 IP 주소
  5. 공백라인
  6. HTTP 바디

2. 응답 메시지

  1. HTTP 버전
  2. HTTP 상태 코드
    • 요청 성공, 실패 등의 상태를 나타냄
    • 200 - 성공 / 400 - 클라이언트 요청 오류(잘못된 형태 등) / 500 - 서버 내부 오류(예외 등의 오류)
  3. HTTP 헤더
    • HTTP 전송에 필요한 부가정보
    • 바디의 내용, 크기, 압축, 인증, 브라우저 정보, 캐시정보 등등…..
    • 즉, 응답을 받은 클라이언트가 해당 HTTP 메시지를 받고 처리하기 위해 필요한 정보
  4. HTTP 바디
    • 실제 전송할 데이터
    • byte로 표현할 수 있는 모든 데이터 전송 가능

3. HTTP API

  • 요청을 받는 서버에서 요구하는 요청의 형태에 대한 문서라고 생각하면 됨
  • 즉, ‘이런 저런 정보를 받으려면 이렇게 저렇게 요청을 하시면 됩니다’
  • API 설계 시 일반적으로 통용되며 HTTP 메시지만 봐도 대략적으로 어떤 것을 요청하는 것인지 아는 것이 클라이언트와 서버 모두에게 효율을 가져다 줄 수 있음. 때문에 컨벤션이 존재하게 됨.

- API URI의 가장 중요한 요소는 리소스 식별

  • 리소스란? 회원정보 등록, 수정 시 회원이 리소스가 됨. -> 명사가 되겠군!

  • 그러면 등록, 수정 등의 행위는 어떻게 표현? -> HTTP Method로 표현. -> 동사가 되겠군!

    -> 이게 바로 우리가 아는 RESTful API

  • 물론 실무에서는 이론적인 부분과 괴리가 생길 수 있으며, 이렇게 표현이 불가능한 경우 컨트롤 URI를 사용하여 추가적인 표현을 함. (ex, POST 요청에서 /new, /delete와 같이 추가적인 컨트롤 URI을 붙여서 사용하게 되는 경우가 생김)

- HTTP 메서드의 종류

메서드 종류 설명
GET 리소스 조회
POST 데이터 처리 요청
PUT 리소스 대체 (해당 리소스가 없으면 생성)
PATCH 리소스 부분 변경
DELETE 리소스 삭제
HEAD GET에서 메시지 제외하고 헤더만 반환
OPTIONS 대상 리소스에 대한 통신 가능 옵션 설명(CORS에서 받을 수 있는 메서드 확인할때 사용)
기타 CONNECT(대상 자원으로 식별되는 서버에 대한 터널 설정)
TRACE(대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행)

1. GET

  • 리소스를 조회하는 메서드
  • 서버에 전달하고 싶은 데이터는 기본적으로 Query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
  • 바디를 사용할 수 있지만 지원하는 곳이 적어서 권장하지 않음!

2. POST

  • 데이터 처리를 요청하는 메서드
  • 메시지 바디를 통해 서버로 요청 데이터를 전달함
    1. 신규 리소스로 등록 할 때 POST 메서드를 사용
      • ex) 회원가입, 신규 주문 생성, 내용 추가하기 등
    2. 요청한 데이터 처리
      • ex) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어서 프로세스의 상태가 변경되는 경우
      • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
    3. 다른 메서드로 처리하기 애매한 경우에 사용하기도 함
      • ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

3. PUT

  • 리소스를 대체하는 메서드

    • 있으면 대체
    • 없으면 생성
    • 즉, 덮어쓰기

  • POST와 다른점

    • 클라이언트가 리소스의 위치를 알고 URI를 지정함.

      PUT /members/100 HTTP/1.1  <- 100번 member라고 특정하여 요청을 보냄
Content-Type: application/json
    
{
	"username" : "hello",
	"age" : 20
}

      *주의사항 - 리소스를 완전히 대체하는 것이다보니, 새로 보내는 자료에 기존 자료가 없다면 기존 자료도 없어진다!! (PATCH와 다른점)

4. PATCH

  • 리소스 부분 변경

    PATCH /members/100 HTTP/1.1  <- 100번 member라고 특정하여 요청을 보냄
Content-Type: application/json
  
{
	"age" : 20
}

    이렇게 보내게 되면 기존에 있던 데이터는 그대로 두고 age만 20으로 변경하게 된다.

5. DELETE

  • 리소스 제거

4. HTTP 메서드의 속성

  • 안전, 멱등, 캐시가능

    img

1. 안전

  • 호출해도 리소스가 변하지 않음.

2. 멱등

  • 여러번 호출해도 한번 호출한 것과 결과가 똑같다.
    • GET, PUT, DELETE는 멱등
    • POST는 멱등이 아님. ex) 게시글 등록 -> 계속 됨
  • 멱등을 가지고 자동 복구 메커니즘에 사용함. 서버가 TIMEOUT 등으로 정상응답을 못주었을 때, 클라이언트가 다시 같은 요청을 해도 되는가? 멱등이면 OK!

3. 캐시가능

  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH가 가능하지만 구현이 까다롭기 때문에 실제로는 GET, HEAD 정도만 캐시로 사용함

5. 데이터 전송(클라이언트 -> 서버)

1. 정적 데이터 조회

  • 일반적인 GET

2. 동적 데이터 조회

  • 필터를 건다던가, 정렬을 한다던가 하는 유저 요청에 따라 동적으로 바뀌는 것.
  • 이럴 경우 GET은 쿼리 파라미터에 & 체이닝을 사용하여 조건을 추가해서 전달함

3. HTML Form 데이터 전송

*GET, POST만 지원함!

- POST 전송

  • HTML

    <form action="/save" method="post">
	<input type="text" name="username" />
	<input type="text" name="age" />
	<button type="submit">전송</button>
</form>

  • HTTP 메서드

    POST /save HTTP/1.1
HOST: localhost:8080
Content-Type: application/x-www-form-urlencoded
  
username=kim&age=20

- multipart/form-data

  • multipart, 즉 여러 형태의 데이터를 섞어서 보내겠다는 것.

  • HTML

    <form action="/save" method="post" enctype="multipart/form-data">
	<input type="text" name="username" />
	<input type="text" name="age" />
   	<input type="file" name="file1" />
	<button type="submit">전송</button>
</form>

  • HTTP 메시지

    POST /save HTTP/1.1
HOST: localhost:8080
Content-Type: multipart/form-data; boundary=-----XXX
Content-Length: 10457
  
-----XXX
Content-Disposition: form-data; name="username"
  
kim
-----XXX
Content-Disposition: form-data; name="age"
  
20
-----XXX
Content-Disposition: form-data; name="file1"; filename="intro.png"
Content-Type: image/png
  
10259a9LWKl1i3waGalk113uif325lk <- 바이너리 데이터 전송
-----XXX

마지막 수정일시: 2022-12-16 22:43

카테고리:

업데이트:

댓글남기기

참고

SpringSecurity - 기본

3 분 소요

Spring Security는 Spring 프레임워크에서 제공하는 인증, 인가를 쉽게 처리할 수 있는 방식을 Filter를 활용하여 제공한다.