HTTP01

in Web on Web, Http


HTTP

HyperText Transfer Protocol

거의 모든 형태의 데이터 전송 가능 서버간에 데이터를 주고 받을 때도 대부분 http 사용 html, text, image, 음성, 영상, json, xml 등

특징

  • 클라이언트 서버 구조
  • 무상태 프로토콜(Stateless), 비연결성
  • HTTP 메시지
  • 단순함, 확장 가능

클라이언트 서버 구조

  • Request Response 구조
  • 클라이언트는 서버에 요청을 보내고, 응답을 대기한다.
  • 서버가 요청에 대한 결과를 만들어서 응답

무상태 프로토콜(Stateless)

  • 서버가 클라이언트의 상태를 보존하지 않는다.
  • 장점 : 서버 확장성이 높다
  • 단점 : 클라이언트가 추가 데이터 전송

Sateful VS Stateless

Stateful
• 고객: 이 노트북 얼마인가요?
• 점원: 100만원 입니다. (노트북 상태 유지)
• 고객: 2개 구매하겠습니다.
• 점원: 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?
(노트북, 2개 상태 유지)
• 고객: 신용카드로 구매하겠습니다.
• 점원: 200만원 결제 완료되었습니다. (노트북, 2개, 신용카드 상태 유지)
Stateless
• 고객: 이 노트북 얼마인가요?
• 점원: 100만원 입니다.
• 고객: 노트북 2개 구매하겠습니다.
• 점원: 노트북 2개는 200만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?
• 고객: 노트북 2개를 신용카드로 구매하겠습니다.
• 점원: 200만원 결제 완료되었습니다.
  • 상태 유지 : 중간에 다른 점원으로 바뀌면 안된다. 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.
  • 무상태 : 중간에 다른 점원으로 바뀌어도 가능하다.
    • 갑자기 고객이 증가해도 점원을 대거 투입 가능
    • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 가능하다.
    • 무상태는 응답 서버를 쉽게 바꿀 수 있다.
    • 무한한 서버 증설 가능

비연결성

  • HTTP는 기본이 연결을 유지하지 않는 모델
  • 일반적으로 초 단위 이하의 바른 속도로 응답
  • 서버 자원을 매우 효율적으로 사용할 수 있다.
    • 연결상태를 끊으므로 자원소모를 줄인다.

HTTP 구조

  • Start Line

    • 요청메시지와, 응답메시지의 구조가 살짝 다르다.
    • HTTP 전소에 필요한 모든 부가정보 포함 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보 등
    • 필요시 임의의 헤더 추가 가능
      • hello: hihi
          field-name: (OWS) field-value (OWS)
  (OWS: 띄어쓰기 허용)
  Host: www.google.com
  Content-type: text/http;charset=utf-8

  • message body

    • 실제 전송할 데이터 HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능 ```html
    ...

    ``` —

    HTTP Request Message

Start Line

method (SP) request-target (SP) HTTP-version (CRLF) GET /search?q=hello HTTP/1.1

  • HTTP 메서드(GET, POST)
  • 요청 대상 (/serach?q=hello)

  • HTTP Version (HTTP/1.1)

    HTTP Response Message

Start Line

HTTP-version (SP) status-code (SP) reason-phrase (CRLF) HTTP/1.1 200 OK

HTTP 메서드

주요 메서드

  • GET: 리소스 조회
  • POST: 요청 데이터 처리, 주로 등록에 사용
  • PUT: 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH: 리소스 부분 변경
  • DELETE: 리소스 삭제

GET

GET /search?q=hello&hi=ko HTTP/1.1
HOST: www.google.com
  • 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

POST

POST /members HTTP/1.1
Content-Type: application/json
{
 "username": "hello",
 "age": 20
}
  • 요청 데이터 처리
  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

PUT

PUT /members/100 HTTP/1.1
Content-Type: application/json
{
 "username": "hello",
 "age": 20
}
  • 리소스를 대체
    • 리소스가 있으면 대체
    • 리소스가 없으면 생성
    • 덮어쓰기!
  • 클라이언트가 리소스를 식별
    • 클라이언트가 리소스 위치를 알고 URI 지정

PATCH

PATCH /members/100 HTTP/1.1
Content-Type: application/json 
{
 "age": 50 
}
  • 리소스 부분 변경

DELETE

  • 리소스 제거

HTTP 메서드 속성

  • 안전(Safe Methods)
  • 멱등(Idempotent Methods)
  • 캐시가능(Cacheable Methods)

안전

  • 호출해도 리소스를 변경하지 않는다.

멱등

  • f(f(x)) = f(x)
  • 한 번 호출하든 여러 번 호출하든 결과가 동일하다.
  • 멱등 메서드
    • GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
    • PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
    • DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
    • POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
  • 활용
    • 자동 복구 매커니점
    • 서버가 timeout 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 에 대한 판단 근거

캐시가능

  • 응답 결과 리소스를 캐시해서 사용해도 되는가?
  • GET, HEAD, POST, PATCH 캐시가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용



© 2019.04. by salmon2

Powered by theorydb