HTTP (2) | Network

October 25, 2023

HTTPNetwork

이 글은 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 듣고 정리한 내용입니다.

HTTP 기본

HTTP (HyperText Transfer Protocol)
모든 것이 HTTP이다! HTML뿐만 아니라 거의 모든 것을 전송할 수 있도록 바뀌었다.

모든 것을 HTTP 메세지에 담아 전송한다.

HTML, TEXT
IMAGE, 음성, 영상, 파일
JSON, XML (API)
거의 모든 형태의 데이터를 전송할 수 있다.
서버간에 데이터를 주고 받을 때도 대부분 HTTP를 사용한다.

HTTP의 역사

...
HTTP/1.1 1997년 : 가장 많이 사용, 우리에게 가장 중요한 버전
HTTP/2 2015년 : 성능 개선 위주
HTTP/3 진행중 : TCP 대신에 UDP 사용, 성능 개선 위주

기반 프로토콜

TCP : HTTP/1.1, HTTP/2
UDP : HTTP/3
현재는 HTTP/1.1을 주로 사용
- HTTP/2, HTTP/3도 점점 증가하는 추세이다.

HTTP/1.1의 스펙을 학습하면 그 이후 버전은 성능을 개선한 것이기 때문에 이해하기에 큰 문제가 되지 않을것이다.

HTTP 특징

HTTP의 특징은 다음과 같습니다

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

1. 클라이언트 서버 구조

클라이언트는 서버에 request하고 response를 대기한다.
서버는 요청한 request에 대한 결과를 만들어 response 한다.

클라이언트와 서버를 분리했다는 점이 중요하다.

비지니스 로직과 데이터는 서버에 넣는다.

클라이언트는 UI, 사용성에 집중한다.

서로의 역할에 집중해, 독립적으로 진화할 수 있다.

2-1. 무상태 프로토콜 (Stateless)

HTTP는 무상태 프로토콜을 지향한다. 서버가 클라이언트의 상태를 보존하지 않는다는 의미이다.

장점 : 서버 확장성 높음(스케일 아웃)
단점 : 클라이언트가 추가 데이터 전송

Stateful vs Stateless

Stateful

서버가 클라이언트의 이전 상태를 보존한다.
- 단점: 대화를 하고 있던 점원이 중간에 바뀌면? 문맥을 잃기 때문에 에러가 발생한다.
- 이전의 대화 내용을 모르는 점원이 오게 되면 에러가 발생한다.
- 즉, 항상 같은 서버가 유지되어야 한다.

Stateless

서버가 클라이언트의 이전 상태를 보존하지 않는다.
- 고객이 필요한 정보를 점원에게 다 넘겨주기 때문에 중간에 점원이 바뀌어도 상관이 없음 -> 무상태로 설계하면 엄청난 확장성을 갖는다.
- 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
- 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
- 즉, 상태를 보관하지 않기 때문에 아무 서버나 호출해도 된다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한 서버 증설 가능

Stateless의 실무한계

모든것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.
무상태로 설계할 수 있는 경우
- 예) 로그인이 필요없는 단순한 서비스 소개 화면
상태유지를 하고 설계해야 하는 경우
- 예) 로그인
로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지해야한다.
일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지한다.
상태유지는 최소한만 사용해야한다. 꼭 필요한 경우에만 사용해야한다.
단점: 클라이언트가 한 번에 많은 데이터의 양을 보낸다.

2-2. 비연결성 (connectionless)

연결을 유지하는 모델

여러 클라이언트에서 서버에 요청을 보낼 때 클라이언트에게 응답 후에도 연결을 계속 유지하고, 서버 자원을 소모한다.

연결을 유지하지 않는 모델

서버는 클라이언트에게 받은 요청에 대해 응답을 하면 연결을 유지하지 않고 끊는다.
HTTP는 기본이 연결을 유지하지 않는 모델이다
일반적으로 초 단위 이하의 빠른 속도로 응답한다.
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다
- 예) 웹브라우저에서 계속 연결해서 검색 버튼을 누르지는 않는다.
서버자원을 매우 효율적으로 사용할 수 있음

단점

TCP/IP 연결을 맺는 과정을 반복해야한다. - 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면, HTML뿐만아니라 JS, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드된다
지금은 HTTP 지속연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP/3에서 더 많은 최적화

3. HTTP 메세지

HTTP 요청 메세지 예시

GET /search?q=hello&hl=ko HTTP/1.1 
Host: www.google.com

HTTP 응답 메세지 예시

HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

<html>
  <body>...</body>
</html>

공식 스펙

HTTP-message = start-line           시작라인  
               *(header-field CRLF) 헤더    
               CRLF empty line      공백 라인  
               [message body]

HTTP 메서드

HTTP API를 만들어 보자

요구 사항 - 회원 정보 관리 API를 만들어라.

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

API URI 설계

좋은 URI 설계는 ?? 가장 중요한 것은 Resource 식별

회원이라는 개념 자체가 바로 Resource이다!

회원이라는 Resource만 식별하면 된다. -> 회원 Resource를 URI에 매핑!

회원 목록 조회 /members
회원 조회 /members/id -> 어떻게 구분하지?
회원 등록 /members/id -> 어떻게 구분하지?
회원 수정 /members/id -> 어떻게 구분하지?
회원 삭제 /members/id -> 어떻게 구분하지?

리소스와 행위를 분리하자

가장 중요한 것은 리소스를 식별하는 것!

URI는 리소스만 식별!
리소스와 해당 리소스를 대상으로 하는 행위를 분리
- 리소스 : 회원
- 행위 : 조회, 등록, 삭제, 변경
리소스는 명사, 행위는 동사
행위(메서드)는 어떻게 구분? -> HTTP 메서드가 구분해준다 !

HTTP 주요 메서드 정리

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

최근 스펙은 리소스라고 하기보다는 Representation이라고 한다.

HTTP 기타 메서드

HEAD : GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 수행

GET, POST

GET

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

리스소를 조회
서버에 전달하고 싶은 데이터는 query를 통해 전달
메세지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

클라이언트가 /members/100를 달라고 요청한다.

GET /members/100 HTTP/1.1
Host: localhost:8080

서버가 응답 데이터를 만들어서 클라이언트에게 보낸다

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34

{
  "username": "young",
  "age": 20
}

POST

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

클라이언트가 리소스 등록 메세지를 전달한다.

POST /members HTTP/1.1
Content-Type: application/json

{
  "username": "young",
  "age": 20
}

서버에서 신규 리소스 식별자를 생성하고, 신규 리소스를 생성한다.

{
  "username": "young",
  "age": 20
}

서버가 클라이언트에게 응답 데이터를 보낸다

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100 (자원이 생성된 경로이다.)

{
  "username": "young",
  "age": 20
}

POST - 요청 데이터를 어떻게 처리한다는 의미일까

스펙: POST메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다.
예를 들어 POST는 다음과 같은 기능에 사용이된다.
- HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
  - 예) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용
- 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메세지 게시
  - 예) 게시판 글쓰기, 댓글달기
- 서버가 아직 식별하지 않은 새 리소스 생성
  - 예) 신규 주문 생성
- 기존 자원에 데이터 추가
  - 예) 한 문서 끝에 내용 추가
정리 : 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야함 -> 정해지 것이 없음

POST 정리

새 리소스 생성(등록)

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

요청 데이터 처리

단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값을 변경을 넘어 프로세스의 상태가 변경되는 경우
POST의 결과로 새로운 리소스가 생성되지 않을 수 있음
예) POST /orders/orderId/start-delicery (컨트롤URI)

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

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

PUT, PATCH, DELETE

PUT

/members/100

{
  "username": "young",
  "age": 20,
}

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
  "age": 50,
}

/members/100

{
  "age": 50,
}

리소스를 대체
- 리소스가 있으면 완전히 대체
  - username과 age를 둘다 갖고 있는 리소스에 age만 설정하고 PUT을 날리면 username 필드가 사라진다.
  - 기존 리소스를 삭제하고 완전히 대체한다.
- 리소스가 없으면 생성
- 쉽게 이야기해서 덮어버림
중요! 클라이언트가 리소스를 식별
- /members/100 -> 클라이언트가 리소스 위치를 알고 URI를 지정
- POST와 차이점
  - POST는 100번에 만들어질지 200번에 만들어질지 알 수 없다.

PATCH

/members/100

{
  "username": "young",
  "age": 20,
}

PATCH /members/100 HTTP/1.1
Content-Type: application/json

{
  "age": 50,
}

/members/100

{
  "username": "young",
  "age": 50,
}

리소스 부분 변경

DELETE

리소스 제거

HTTP 메서드의 속성

안전 Safe

호출해도 리소스를 변경하지 않는다.
Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면?
A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다. 해당 리소스가 변하냐 변하지 않느냐만 고려한다.

멱등 Idempotent

한 번 호출하든 두 번 호출하든 결과가 똑같아야한다.
멱등 메서드
- GET: 한 번 조회하든, 두번 조회하든 결과는 같다.
- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번해도 최종결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다. 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.
활용
- 자동 복구 매커니즘
Q: 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지 고려하지 않는다.

캐시가능 Cacheable

캐시가능 : 웹 브라우저가 내부에 이미지를 저장하고 있을수 있냐 없냐?
- 처음에 웹 브라우저에 이미 요청했으면 그 다음에 또 똑같은 리소스를 요청할 필요는 없다.
응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD, POST, PATCH 캐시 가능
실제로는 GET, HEAD 정도만 캐시로 사용
- POST, PATCH는 본문 내용까지 캐시키로 고려해야하는데, 구현이 쉽지 않음