Web/HTTP

01. HTTP 정리

연어조아 2021. 9. 14. 21:43
728x90

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

02. HTTP 구조

  • Start Line
    • 요청메시지와, 응답메시지의 구조가 살짝 다르다.
  • header
    • 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> <body>...</body> </html>

01) 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)

02) HTTP Response Message

Start Line

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

  • status-code : 02. http 문서 참조
  • reason-phrase : 일반적으로 상태 코드와 함께 서버에 의해 전송되는 이유 구문을 가져오거나 설정한다.

03. 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

  • 리소스 제거

04. HTTP 메서드 속성

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

안전

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

멱등

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

캐시가능

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

05. 참고자료