비 연결성 ( Connectionless )

연결을 유지하는 모델일 경우

기본적으로 TCP/IP 는 소켓으로 연결하는데, 이 연결이 끊키지 않는다고 가정해보자

서버는 연결을 계속 유지하고, 서버 자원또한 계속 소모가 된다. ( 연산을 하고, 메모리를 할당하는등,,, )

이럴 경우 문제점이 무엇일까?

-> 다른 클라이언트가 아무것도 안하고 놀고 있더라도, 서버는 연결을 유지시켜야 한다.

 

연결을 유지하지 않는 모델일 경우 

서버는 자원을 요청을 연결하고 주고 받을때만 사용하고, 유지하는 자원을 최소한으로 줄인다.

이 상황이 만약 클라이언트가 10만명이었다고 가정한다면, 연결을 유지하는 서버라면 엄청난 과부하가 왔을 것이다.

 

비 연결성

- HTTP 는 기본이 연결을 유지하지 않는 모델

- 일반적으로 초 단위 이하의 빠른 속도로 응답

- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음

ex ) 웹 브라우저에서 연속해서 1시간 내내 검색 버튼을 누르지는 않는다.

- 서버 자원을 매우 효율적으로 사용할 수 있음.

 

비 연결성 한계와 극복

- TCP/IP 연결을 새로 맺어야 함 -> 3 way handshake 시간 추가
( 검색을 하다가 다음 페이지로 넘어갔다 가정한다면, TCP/IP 연결을 새로 맺어야함 )

- 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 등 수 많은 자원이 함께 다운로드 된다.

- 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결 

- HTTP/2, HTTP/3에서 더 많은 최적화

 

HTTP 초기 - 연결, 종료 낭비

대략 초기의 HTTP 는 위와 같은 형태의 통신을 하였다고 한다. 매번 연결과 종료 프로세스가 실행된다.

 

HTTP 지속 연결(Persistent Connections)

연결을 해둔채로 요청과 응답을 주고받는 것이 현재의 HTTP 통신이다.

몇 초동안 유지하는등의 내부 메커니즘이 있는데, 대부분 HTML 하나를 모두 받아질만큼의 시간동안 연결이 이루어져 있는것이다.

HTTP/2 , HTTP/3 에서는 이러한 부분들이 훨씬더 개선되어 나왔다. ( UDP 통신을 사용한 빠른 연결 등)

 

Stateless 를 기억하자

서버 개발자들이 어려워하는 업무

정말 같은 시간에 딱 맞추어 발생하는 대용량 트래픽

예) 선착순 이벤트, 명절 KTX 예약, 학과 수업 등록

예) 저녁 6:00 선착순 1000명 치킨 할인 이벤트 -> 수만명 동시 요청

 

이러한 경우 어떻게든 최대한 Stateless 하게 짜는것이 중요하다.

Stateless 하다면, 서버를 확 늘려버려서 대응하는것이 가능

-> 이런경우 자주 사용하는 방법은 첫 페이지는 로그인도 필요없는 단순한 페이지 ( 아무상태가 없는 ) 를 보여준다.

이곳에서 사람들을 놀게하고 시간을 보내게 한다음 이벤트 버튼같은것을 누르게 하는등의 방법을 많이 사용한다고 한다.
( 동일한 시간의 트래픽을 줄이는것 )