Web이 발전하면서
규모가 커지면서 코드량이 늘어나고 확장성과 유지보수를 위해 자연스럽게 Front-end와 Back-end가 분리되었다.
Frontend : 서비스를 편하게 이용할 수 있도록 사용자 인터페이스를 다룬다.
Backend : 사용자들이 실질적으로 원하는 정보 또는 데이터를 관리하거나 제공한다.
분리된 서버에서 데이터를 주고 받기위해 HTTP 통신은 필수가 되었다.
HTTP 특징
클라이언트는 서버에게 Request를 보내고 서버는 클라이언트의 요청을 Response하는 단방향 통신이라고 들어봤다고 생각한다.
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성
- HTTP 메시지
- 단순함, 확장 가능
왜 HTTP의 특징이 Stateless인지 알아보고 단순하고 확장 가능한 이유는 무엇인지 알아보자 (CSR과 SSR에 대해서는 다음에)
Stateful
사용자의 요청에 이전 상태를 저장한다.
클라이언트: 이 후드티 얼마인가요?
서버: 35,000원 입니다.
클라이언트: 2개 주세요.
서버: 7만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?
클라이언트: 신용카드로 구매하겠습니다.
서버: 7만원 결제 완료되었습니다.
상태를 기억하던 서버가 한 클라이언트에 요청에 대해서 지금까지 내용을 전부다 기억한다.
- 서버쪽에서 부담이 많이 가고 서버가 죽을 경우 클라이언트는 다시 처음부터 요청을 해야하는 문제가 발생한다.
- 서버가 여러개면 싱크(sync) 즉 데이터 동기화를 맞추는 비용이 발생한다.
Stateless
사용자의 요청 상태를 저장하지 않는다.
클라이언트: 이 후드티 얼마인가요?
서버: 35,000원 입니다.
클라이언트: 이 후드티 2개 주세요.
서버: 7만원 입니다. 신용카드, 현금중에 어떤 걸로 구매 하시겠어요?
클라이언트: 이 후드티 2개 신용카드로 구매하겠습니다.
서버: 7만원 결제 완료되었습니다.
하나의 요청으로 모든 상태정보를 보낸다는 것은 Stateful에 비해서 많은 데이터를 HTTP 통신을 통해서 전송해야 되는 문제가 있다.
- TCP/IP통신이기 때문에 3 Way-Handshake를 통해서 패킷이 목적지에 온전하게 도달하도록 보장하는데 패킷 순서, 데이터 손실등을 파악하기 위해 통신이 무거워질 수 있다.
친구목록에서 친구를 제거할 때 친구목록이라는 통상적으로 큰 데이터는 보통 DB에 저장되어 있고 제거할 친구 목록(작은 데이터)이기 때문에 Request Body에 실어서 보낸다고 큰 문제는 없다고 생각합니다.
- 대용량 데이터 처리를 위한 기술들(JDK21 Virtual Thread, WebFlux등)이 계속해서 발전하고 있기 때문에... ㅜㅜ 공부할게 많아서 좋네요
HTTP의 특징이 Stateless일까?
클라이언트에서 서버로 Request를 보내면 그 요청에 맞춰서 Response해야 된다고 말했습니다.
- 클라이언트는 자신의 요청에 맞는 응답만 받을 수 있다면 서버가 MSA로 구축하거나 어떤 언어와 프레임워크를 사용했든 아무 신경을 쓰지 않는다는 것입니다. 즉, 서버가 추상화되어 있기 때문에 쉽게 Scale-out이 가능하다.
특히 선착순 이벤트, 명절 KTX 예약, 수강 신청등 대용량으로 동시 요청으로 들어오는 경우 Stateless를 생각해서 서버를 늘려서 대응할 수 있다.
항상 Stateless를 사용할 수 없습니다.
사용자가 로그인을 하면 로그인 상태를 유지해야 하며, 동영상을 시청하다가 1분 30초에 종료하고 다시 재생할 때 1분 30초부터 시작되는 것처럼 사용자 경험을 위해서 Stateful한 데이터도 있어야 합니다.
- 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지 (세션, 토큰등)
- 일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
- 상태 유지는 최소한만 사용
연결을 유지하는 모델
Tcp/Ip로 서버가 여러 개의 클라이언트와 연결이 유지되는 경우
연결을 맺을 수 있는 개수는 서버 스팩에 따라서 제한이 되는 문제가 있기 때문에 여러 개의 클라이언트 중에서 데이터를 전송하지 않고 놀고 있는 클라이언트 개수만큼 자원을 효율적으로 사용하지 못하는 문제가 있다. (우리의 일꾼 쓰레드와 비슷한 느낌)
- 이것도 어떤 기능을 만들어야 되는지에 따리서 달라지기 떄문에 Connection을 강제로 종료시킨다거나 최적화에 대해서 공부해보는게 맞는거 같다.
비 연결성 (connectionless)
클라이언트가 서버에게 TCP/IP로 서로 연결을 하고 데이터를 보낸 다음에 응답이오면 바로 연결을 끊어버리는 방식이다.
- 요청을 주고 받을 때만 연결이 되어있기 때문에 자원을 효율적으로 관리하고, 수 많은 클라이언트의 요청에도 대응할 수 있다.
동시에 접근하는 사용자가 많아지면 연결을 유지하는 모델과 같아진다.
- 1시간 동안 수천명이 서비스를 사용했을 때 동시에 처리하는 요청은 수십개 이하로 매우 작다.
비 연결성 (connectionless) - 한계와 극복
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드 된다.
모든 리소스에 대해 개별로 연결-응답-종료(3 Way-Handshake)를 하다 보니 불필요한 connection을 맺는 과정이 생겼다.
- 3 Way-Handshake 최적화되어서 3번째 클라이언트가 서버로 ack 보낼 때 데이터도 같이 보내기도 한다.
지금은 HTTP 지속 연결 (Persistent COnnections)로 문제 해결하면서 HTTP/2로 최적화를 하고 HTTP/3에서 UDP 프로토콜을 사용해서 연결 속도도 성능 개선까지 이루어지고 있다.
- HTTP 지속 연결로 연결 후 모든 리소스를 다움 받고 종료함으로써 성능 개선 가능
'Web' 카테고리의 다른 글
| 실시간, 양방향 데이터 통신 (0) | 2024.01.06 |
|---|---|
| OAuth2(Open Authorization) (0) | 2023.04.08 |
| Redis(Remote Dictionary Server) (0) | 2023.03.30 |
| JWT(Json Web Token) (0) | 2023.03.23 |
| HTTP 메소드 (0) | 2022.12.29 |
