[HTTP] 모든것이 HTTP / HTTP 메서드

🐷Jinie (juniorDeveloper)·2021년 5월 23일
3

HTTP웹 기본지식

목록 보기
2/2
post-thumbnail

1. 모든것이 HTTP

1-1. HTTP?

  • HyperText Transfer Protocol
  • HTML을 전송하는 프로토콜로 시작했다.
  • 지금은 거의 모든형태의 data를 전송한다.
  • 지금 가장 많이 쓰고있는 것은 HTTP/1.1 이고 HTTP/2 와 HTTP/3은 성능개선에 초점을 맞췄다.
  • HTTP는 단순하다! 메세지도 단순하다.
* 기반 Protocol *
- TCP/IP : HTTP/1.1, HTTP/2
- UDP    : HTTP/3 (애플리케이션 레벨에서 성능최적화)
  • 현재는 HTTP/2와 HTTP/3도 점점 증가하고 있다.
[ HTTP의 특징 ] 
1. 클라이언트-서버 구조
2. 무상태 Protocol (Stateless) / 비연결성
3. HTTP 메시지
4. 단순하고 확장이 가능하다.

1-2. 클라이언트-서버 구조

  • Request/ Response 구조
  • 클라이언트는 서버에 Request 후 응답을 대기한다.
    이후 서버에서는 요청에 대한 결과를 만들어 Response한다.
  • 클라이언트와 서버를 개념적으로 분리했다.
  • 비지니스로직과 데이터는 서버로 UI와 사용자의경험은 클라이언트로 분리하면서
    양쪽모두가 집중고도화가 가능해졌다.

1-3. Stateless 무상태프로토콜

  • 서버가 클라이언트의 상태를 보존하지 않는다.
  • Stateful 은 상태유지인데,
    Context를 유지해서 이미말한 데이터를 반복해서 전달하지 않아도된다.
    이 말만 보면 Stateful이 좋아보이는데 왜 Stateless 일까?
  • 같은 응답서버를 이용하면 이전상태를 보존하는것이 효율적일 수도 있겠다.
    하지만 응답서버가 변경된다면?
  • Context를 모르는 다른 서버가 응답을 하게되면 Stateful은 장애가 발생하게된다.
  • 하지만 상태를 보존하지 않기때문에 모든 데이터를 매번 가지고있는 Stateless 는 어떤 응답서버로 변경되고 추가되어도 장애발생이 없다. 즉, 의사소통에 문제가없다!
  • 따라서 클라이언트가 막 늘어나는 경우에도 무한증설이 가능해진다.
* 스케일 아웃 : 수평확장
  • Stateless는 완벽할까?
    Stateless에도 한계가 있다.
  • 일단, 알고있는 데이터까지 유지없이 매번 가지고 전달한다.
    -> 즉 데이터를 많이 먹는다.
  • 또한, 상태를 유지해야하는 경우
    예를 들어 로그인한 회원의 페이지를 회원이 계속 사용할 수 있도록 상태를 유지해야하는 경우가 생긴다면?
  • 이럴경우에는 일반적으로 쿠키와 세션을 이용해 상태를 유지하게된다
  • 단, 상태유지는 최소한만 사용하자.
  • 이런 단점에도 웹 어플리케이션 설계시에는 최대한 무상태로 설계하는 것을 권장한다.
    어쩔수 없는 경우에만 상태유지로 설계하자.

1-4. Connectionless 비연결성

  • TCP/IP는 연결을 유지한다.
  • HTTP는 기본적으로 비연결성의 특징을 가지고 있다.
  • 연결성을 유지할경우에는 사용하지 않는 서버와도 연결을 유지하기 때문에, 서버자원을 소모하는 단점이 있다.
  • 비연결성은 사용이 끝나면 연결을 끊어버리기때문에, 최소한의 자원만 유지할 수 있는 장점이있다.
  • 하지만, 기본적으로 비연결성 모델인 HTTP가 왜 요즘은 지속연결(Persistent Connections)로 이용되고 있을까?
  • 비연결방식에 단점이 있기때문이다.
  • 비연결방식은 사용이 끝나면 매번 연결을 종료하기 때문에, TCP/IP의 연결을 새로 맺어야한다.
    즉, 3-way handshake 를 또해야한다는 뜻이다. 이건 시간낭비다!
  • 또한, 웹 브라우저 사이트를 이용할때 HTML만 있는게 아니라 용량이 큰 data나, CSS 등 수많은 자원이 있는데 비연결식으로 이용하게 되면 매번, 매순간 다운로드를 해야한다.
  • 이런 단점때문에 현재의 HTTP는 Persistent Connections로 Connectionless의 문제를 해결하고 있다.

2. HTTP 메서드

2-1. HTTP 메세지

[ 구조 ]
시작라인    start-line

헤더       header

공백      empty-line (CRLF)   **필수!!!

메세지    message-body
2-1-1. Start-line
  • request-line (Request)
  1. HTTP 메서드
    ex) GET, POST, PUT 등
  2. 요청대상
  3. HTTP 버전
  • status-line (Response)
  1. HTTP 버전
  2. HTTP 상태코드
  3. 이유문구
2-1-2. Header
* OWS : 띄어쓰기 허용
  • field-name은 대소문 구분을 하지않는다.
  • HTTP 전송에 필요한 모든 부가정보
  • 임의의 헤더 추가가능
2-1-3. Message-body
  • 실제 전송할 데이터
  • byte로 표현할 수 있는 모든 data

2-2. HTTP API 만들기

  • URI는 리소스식별만 담당하도록하자
    예를들어, 학생목록조회라는 주제가 있으면 조회는 리소스가 아니다.
    리소스는 '학생'이다. 조회를 URI에 담지말자.
    행위는 메서드니까, HTTP Method를 활용하는걸 권장한다.
* 주요 HTTP Method *
1. GET 조회
   : query를 통해 전달한다.
     body 사용이 가능하지만, 지원하는 곳이 많지 않기때문에 권장하지 않는다.
     
2. POST 등록
   : body를 통해 전달한다.
     서버는 요청 데이터를 처리한다.
     신규 리소스를 등록한다.
     다른 메서드로 처리하기 애매한경우에 POST를 사용해본다.
     예를들어 JSON으로 조회데이터를 넘겨야하는데 GET을 사용하기는 어려운경우 사용한다.
     
3. PUT 대체/ 없으면 생성
   : 클라이언트가 리소스를 식별한다.
     단, 리소스를 완전히 대체하기 때문에 '수정'이라고 생각하기 쉬운데 수정보다는 '갈아치우기'에 가깝다.
     그래서, 원하는 부분만 수정할때 사용하기 어렵다.
     
4. PATCH 변경
   : PUT을 이용해서 만들기 어려운 부분수정에 사용된다.
     정말 '변경'이다.
     
5. DELETE 삭제
   : 제거기능을 수행한다.

2-3. HTTP 메서드의 속성들

  • 안전, 멱등, 캐시가능 ...

  • Safe 안전
    : 호출해도 리소스가 변경되지 않는가?
    무언가 바뀌는 순간 안전하지 않는것이다.
    GET Method는 안전하다.

  • Idempotent 멱등
    : 한번 호출하든 100번 호출하든 그 결과가 똑같은가?
    GET, PUT, DELETE 등이 해당된다.
    PUT과 DELETE가 왜 해당되는지 의문이 들었는데,
    중간에 Request가 변동되는것을 고려하지않고 동일한 Request를 여러번 던진다고 생각하면
    계속 삭제를 요청하던 변경을 요청하던 리소스에서의 최종결과는 동일하기 때문이다.
    단, POST는?
    POST는 던질때마다 생성될 수 있다. 따라서, 여러번 호출하면 중복적으로 여러번 생성되어있을 수 있다. 예를들어 결제를 POST하면 결제가 여러번 될 수 있다.
    멱등은 서버가 TIMEOUT등으로 정상응답을 못주었을 경우 클라이언트가 같은요청을 또 해도 되는지에대한 근거가 되기때문에 중요하다.

  • Cacheable 캐시가능
    : 응답결과 리소스를 캐시해서 사용해도 되는가?
    GET, HEAD, POST, PATCH가 있지만
    실제로는 GET, HEAD정도만 사용한다. POST와 PATCH는 복잡하기 때문이다.
    실무에서는 GET만 사용한다고 보면된다.


HTTP Method를 공부하면서,
실무에서 봤던 코드들이 잘못사용되고 있는 부분이 있다는 것을 느꼈다.
예를들어 목록조회의 URI를 /getlist로 사용하고 있다거나...
회원목록조회는 GET /members 로 사용할 수 있도록 염두해두어야겠다.

profile
ᴘᴇᴛɪᴛs ᴅᴇ́ᴠᴇʟᴏᴘᴘᴇᴜʀ. ᴘʀᴏɢʀᴀᴍᴍᴀᴛɪᴏɴ = ᴘʟᴀɪsɪʀ 💕

4개의 댓글

comment-user-thumbnail
2021년 5월 23일

안녕하세요. 글을 읽다가 질문이 생겼습니다. 만약에 스케일 아웃을 하여서 여러 서버가 동작하고 있을때, 세션은 어떻게 되나요? 매 통신마다 같은 서버로 리퀘스트된다는 보장이 없는데 각 서버마다 세션을 복사하는걸까요..?

1개의 답글