TCP/IP연결같은 경우에는 기본적으로 연결을 유지를 한다 .
예를들어 클라이언트 1이 TCP/IP를 연결후 요청을하고 응답을 받는다.
그리고 클라이언트 2가 똑같이 요청하고 응답을 한다 . 이때도 1번은 연결이 유지되고 있고. 똑같이 3번이 요청하고 응답할때도 1,2둘다 연결이 유지되고있다.
그러면 연결을 유지하는 서버의 자원이 계속 소비가 되는것이다.
이것의 단점은 클라이언트 1,2가 놀고있어도 계속 서버가 연결을 유지해야하는것이다.
연결을 유지하지 않는 모델
같은 상황이라도 클라이언트 1이 요청을하고 서버가 응답을 하면 그 뒤로 연결을 종료시켜버린다. 마찬가지로 2,3이 요청을 하고 응답을 하면 똑같이 연결을 끊어버린다.
이렇게 하면 서버입장에서는 현재 요청을 주고 받을때만 연결을하고 뒤에는 끊어서 서버가 유지하는 자원을 최소한으로 줄이게 되는것이다.클라이언트가 수만대라면 최소한의 자원으로 서버를 유지할수가 있다.
비 연결성
- HTTP는 기본이 연결을 유지하지 않는 모델
- 일반적으로 초 단위 이하의 빠른 속도로 응답
- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
- 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.수천명이 동시에 검색을 하지 않는다. 초단위로 나누면 몇명없다!
- 서버 자원을 매우 효율적으로 사용할 수 있음
비 연결성 한계와 극복
- TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
- 예를 들어 중간에 뭘 보다가 다른 페이지로 넘어가면 TCP/IP를 새로 연결해야함
- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트 , css ,추가 이미지 등등 수 많은 자원이 함께 다운로드
- 연결할때마다 자원을 받고 너무 비효율 적이다.
- 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
- 지속연결을 기본적으로 사용
- HTTP/2 ,HTTP3에서 더 많은 최적화
스테이스리스를 기억하자 서버 개발자들이 어려워하는 업무
- 정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽
- 예) 선착순 이벤트 , 명절 KTX 예약 , 학과 수업 등록
- 예) 선착순 1000명 할인 이벤트 -> 수만명이 동시에 요청을 보냄
- 보통의 이벤트 처리 설계는 첫페이지는 로그인도 필요없는 정적 페이지를 뿌린다 아무 상태가 없는 순수한 HTML을 뿌리고 그 안에서 사람들이 정보를 보거나 확인하게 하고 버튼을 누르게하여 시간을 좀 다르게 한다.
무상태로 갈수있는것은 최대한 무상태로 가고 어쩔수 없는 부분에 한해서만 상태유지를 하도록 잘 분리해서 설계하는것이 중요하다
개린이