[HTTP] HTTP 기본 -1

HyperText Transfer Protocol

 

 

모든 것이 HTTP

 

HTTP 메시지에 모든 것을 전송

• HTML, TEXT
• Image, 음성, 영상, 파일
• JSON, XML (API)
• 거의 모든 형태의 데이터 전송 가능
• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

 

HTTP 역사

• 그 전은 생략
• HTTP/1.1 1997년: 가장 많이 사용. 가장 중요한 버전
  • RFC2068 (1997) > RFC2616 (1999) > RFC7230 ~ 7235 (2014)
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행중: TCP 대신에 UDP 사용. 성능 개선

 

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3
• 현재 HTTP/1.1 주로 사용
  • HTTP/2, HTTP/3 도 점점 증가.
  • TCP는 3 way-handshake, 데이터도 많기도 해 기본적으로 속도가 빠른 메커니즘이 아니다. 따라서 성능 개선을 위한 HTTP/2, HTTP/3이 개발된다.

 

프로토콜 확인 예시

브라우저의 F12(개발자 도구)를 켠 뒤 네이버에 '최대한' 검색했을 때 사용 중인 프로토콜을 확인할 수 있다.

 

 

 

 

---

 

클라이언트 서버 구조

 

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

클라이언트와 서버를 개념적으로 분리한다음 비즈니스 로직과 데이터 같은 것들은 모두 서버에 밀어넣고 클라이언트는 UI/UX 구현 등에 집중을 한다. 그렇게 된다면 클라이언트는 복잡한 비즈니스 로직과 데이터 처리를 할 필요가 없고 서버도 해당 기능만 수행하면 되므로 클라이언트와 서버가 각각 독립적으로 진화할 수 있다. 

 

 

---

 

무상태 프로토콜 Stateless

서버가 클라이언트의 상태를 보존하지 않는다.

 

예시) 노트북을 구매하러 간 시나리오

Stateful에서 직원이 바뀔 경우

 

Stateless에서 직원이 바뀔 경우

 

상태 유지 - Stateful

• 중간에 다른 점원으로 바뀌면 안된다.
• 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.
• 항상 같은 서버가 유지되어야 한다.
• 중간에 서버가 장애나면? 답 없다.

무상태 - Stateless

• 중간에 다른 점원으로 바뀌어도 된다.
• 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
  
  • 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입 할 수 있다.
• 무상태는 응답 서버를 쉽게 바꿀 수 있다. -무한한 서버 증설 가능
• 아무 서버나 호출해도 된다.
• 중간에 서버가 장애나면? 같은 기능을 하는 다른 서버와 통신하면 된다.
• 스케일 아웃 - 수평 확장 유리

 

Stateless 실무 한계

• 무상태
  • 예) 로그인이 필요없는 단순한 소개 화면
• 상태 유지
  • 예) 로그인
• 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
• 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
• 상태 유지는 최소한만 사용하자

 

---

비연결성 Connectionless

 

 연결을 유지하는 모델

• 서버는 클라이언트1, 2, 3과 연결을 계속 유지.
• 서버 자원 소모

연결을 유지하지 않는 모델

1. 클라이언트1 요청
2. 서버 응답
3. 클라이언트1과 서버의 TCP/IP 연결 종료
4. 클라이언트 2 요청
5. 2-3 반복

 

• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위의 이하의 빠른 속도로 응답
• 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
• 서버 자원을 매우 효율적으로 사용할 수 있음

 

단점

• TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 이미지 파일 등 수 많은 자원이 함께 다운로드됨.
• 지금은 HTTP 지속 연결 (Persistent Connections)로 문제 해결
• HTTP/2, HTTP/3에서 더 많은 최적화

 

HTTP 초기 - 연결, 종료 낭비

 

HTTP 지속 연결 (Persistent Connections)

 

---

 

HTTP 메시지

 

시작라인

• 시작 라인 = request-line / status - line
• HTTP 메서드 (GET: 조회)
• 요청 대상 (/search?q=hello&&hl=ko)
• HTTP version
• HTTP 상태 코드: 200 OK, 404: Not Found 등

 

HTTP 헤더

• field-name (대소문자 구분 없음)
• HTTP 전송에 필요한 모든 부가 정보
  • 예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트 정보, 서버 애플리케이션 정보, 캐시 관리 정보... 등
  • 필요시 임의의 헤더 추가 가능

 

HTTP 메시지 바디

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

 

 

---

 

HTTP 메서드

 

요구사항

회원 정보 관리 API를 만들어라

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

 

API URI 고민 Uniform Resource Identifier

• 리소스의 의미는?
  • 회원을 등록하고 수정하고 조회하는게 리소스가 아님
  • 예) '미네랄'을 '캐라' > 미네랄이 리소스
  • 회원이라는 개념 자체가 '리소스'
• 리소스를 어떻게 식별할까?
  • 회원을 등록, 수정, 조회하고 삭제하는 것을 모두 배제
  • 회원이라는 리소스만 식별하면 된다.
    • 회원 리소스를 URI에 매핑
• URI는 리소스만 식별!
• '리소스'와 '해당 리소스를 대상으로 하는 행위'를 분리
  • 리소스: 회원
  • 행위: 조회, 등록, 삭제, 변경
  • 행위는 어떻게 구분할까.

 

---

HTTP 메서드 - GET, POST

• GET: 리소스 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH: 리소스 부분 변경
• DELETE: 리소스 삭제
• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)

 

GET

• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)을 통해서 전달
• 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

---

POST

• 메시지 바디를 통해 서버로 요청 데이터 전달
• 서버는 요청 데이터를 처리
  • 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

1. 새 리소스 생성 (등록)

• 서버가 아직 식별하지 않은 새 리소스 생성

2. 요청 데이터 처리

• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
• 예) 주문에서 결제완료 - 배달시작- 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
  • 예) POST/order/{orderId}/start-delivery (컨트롤 URI)
  • 위와 같이 orderId에게 배달을 시작한다는 URI를 설정하는 경우도 있을 수 있음.

3. 다른 메서드로 처리하기 애매한 경우

• 예) JSON으로 조회 데이터를 넘겨야 하는데,  GET 메서드를 사용하기 어려운 경우
• 애매하면 POST 사용

사실, POST는 메세지를 내부에 담아서 하는 모든 것을 할 수 있다. 하지만 조회할 때는 GET이 유리하다.
서버끼리는 GET으로 오면 캐싱을 하겠다는 약속을 해둔다. POST로 캐싱을 하기에는 상당히 어렵다.
따라서 조회는 GET, 데이터가 변경되거나 프로세스가 진행되거나 정말 어쩔 수 없는 경우에 POST를 사용하면 된다.

---

 

PUT

• 리소스를 대체
• 리소스가 없으면 생성
  • 즉, 덮어버림!
• 클라이언트가 리소스를 식별
  • 클라이언트가 리소스 위치를 알고 URI 지정 (POST와 차이점)

members/100에 age를 50으로 수정하고 싶어서 PUT 연산을 한다.

 

PUT 실행 후

기존것을 지우고 통째로 갈아치워버린다.

 

 

PUT은 수정의 용도로 사용하는 것이 아니다.

---

 

PATCH

 

부분적으로 리소스의 데이터를 수정하고 싶을 때,

 

HTTP에서 PATCH지원이 안될 때, POST를 사용하면 된다!

 

---

DELETE

 

리소스 제거

 

---

 

HTTP 메서드의 속성

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

 

안전

• 호출해도 리소스를 변경하지 않는다.
  • 리소스가 변하는 POST, PUT, DELETE 등은 당연히 안전하지 않다.

멱등

• 몇번을 호출하든 결과가 같아야한다.
• 멱등 메서드
  • GET: 몇 번 조회하든 같은 결과가 조회된다.
  • PUT: 결과를 대체한다. 따라서 최종 결과가 같다.
  • DELETE: 결과를 삭제한다. 따라서 삭제된 결과는 똑같다.
  • POST: 멱등이 아님!! 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.

활용

• 자동 복구 메커니즘
• 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는지의 판단 근거가 된다.

멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다. 동일한 사용자의 같은 요청에 대해서만 고려한다.

 

 

캐시가능 Cacheable

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
  • 캐시를 하려면 키가 맞아야 한다. POST는 본문에 데이터를 보내는데 이것까지 고려하기 너무 복잡해서 대부분 구현이 안돼있다.

 

 

 

[출처] 모든 개발자를 위한 HTTP 웹 기본 지식, 김영한님