TCP/IP 연결은 기본적으로 유지를 한다.
먼저 연결을 유지하는 모델에 대한 예시를 보자.
클라이언트 A가 서버에 TCP/IP 소켓을 연결하고 요청을 보내고 응답을 하면 연결이 유지가 될 것이다.
마찬가지로 클라이언트 B와 C도 연결이 되어있다고 가정을 하자.
이렇게 여러 클라이언트가 연결이 되어 있는 동안 서버의 자원은 소모가 되는 것이다.
위 모델의 단점은 클라이언트 A가 요청하는 동안 클라이언트 B가 놀고 있더라도 연결을 유지해야하는 것이 단점이다.
연결을 유지하지 않는 모델의 예시를 보자.
클라이언트 A가 서버에 TCP/IP 소켓을 연결하고 요청을 보내고 응답을 받으면?
그러면 즉시 TCP/IP 연결을 종료시킨다.
마찬가지로 클라이언트 B와 C가 각각 요청을 보내고 응답을 받으면, 연결을 종료시킨다.
이렇게 되면, 장점은 서버의 자원을 요청을 주고 받을때만 유지하고 연결을 끊어버리기 때문에,
최소한의 자원으로 유지가 가능하다.
두 모델의 예시를 봤으니, 비 연결성에 대해서 더 살펴보자.
HTTP는 기본적으로 연결을 유지하지 않는 모델이다. 일반적으로 초 단위 이하의 빠른 속도로 응답을 하고.
그렇기 때문에 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.
예를 들면, 웹 브라우저에서 계속해서 검색 버튼을 누르지 않는 것과 같다.
그렇기 때문에 서버 자원을 매우 효율적으로 사용할 수 있다.
비 연결성도 단점으로는,
TCP/IP 연결을 새로 맺어야 한다는 단점이 있다.
중간에 보다가 다음 페이지로 넘어가면 연결을 새로 맺어야 하기 때문에, 3 way handshake 시간이 추가가 된다.
또한, 웹 브라우저로 요청을 하면 HTML 뿐만 아니라, 자바스크립트, css, 이미지 등
많은 자원들이 함께 다운로드가 된다.
이렇게 자원을 받을 때마다 계속 연결을 끊었다가 연결했다가 하면 비효율적이기 때문에,
지금의 HTTP는 지속 연결(Persistent Connection)을 써서 문제를 해결한다.
그리고 이러한 연결이 HTTP/2, HTTP/3에서는 최적화가 잘 되어 있다.
HTTP 초기의 연결을 살펴보면,
클라이언트가 연결을 해서 HTML만 응답하고 연결을 종료를 한다.
또, 연결해서 요청하고 자바스크립트를 응답하면 또 연결을 종료를 한다.
이런식으로 계속 자원을 요청할 때마다 연결하고 연결을 종료를 하고를 반복하기 때문에,
시간이 많이 소요되는 단점이 있다.
반면에, HTTP 지속 연결을 하면, 연결을 하고, 요청을 하면 HTML 응답을 한다.
계속해서 요청을 하고, 자바스크립트를 응답 받는다.
이런 식으로 연결이 유지가 되면서 HTML 페이지를 다 받을때까지는 연결을 유지를 하고,
다 받고 나서야 연결을 종료한다.
실무 관점에서 살펴보면, 서버 개발자들이 어려워 하는 업무는
특정 시간대에 대용량 트래픽이 발생하는 경우!
예를 들면, 저녁 6시 선착순 1000명 치킨 할인 이벤트.
이렇게 되면 수만명이 동시에 요청을 하기 때문에 비연결성이 의미가 없어진다.
그렇더라도 최대한 Stateless 하게 설계하는 것이 중요하다.
이렇게 대용량 트래픽이 발생할 때, 서버를 늘려서 대응을 할 수 있는 부분이 많아지게 된다.
그래서 예를 들어서, 이벤트 설계할 때는, 첫 페이지는 로그인이 필요없는 정적 페이지를 하나 뿌린다.
그 페이지는 순수한 html 이기 때문에 아무 상태가 없다.
그 이후에, 사람들이 그 안에서 잠시 어떤것을 보게 한 다음에, 이벤트 참여 버튼을 누르게 한다든지.
이런식으로 설계를 할 수 있다.
이렇게 설계할 때는, 최대한 무상태로 가도록 하고
어쩔수 없을 때만 상태를 유지하도록 잘 분리하여 설계하는 것이 중요하다.
댓글