참고사이트
[Network 04] Persistent Connection을 위한 기술 01 - Keep Alive (TCP, HTTP)
Nginx 의 keep-alive 를 조정하여 성능을 개선해보자!
(https://velog.io/@realsnoopso/Stateless-와-Connectionless-의-차이)

1. Stateless와 Connectionless에 대해 설명해 주세요.

Stateless

• 서버가 클라이언트의 상태정보를 저장하지 않는 구조
• 클라이언트의 요청마다 독립적으로 처리되며, 각각의 요청때마다 필요한 모든 정보가 포함되어 전달되어야 함

Connectionless

• 서버와 클라이언트가 통신할 때 연결을 유지하지 않는 구조
• 한번 요청 및 응답이 끝나면 연결을 종료시켜버림(매번 연결을 새로 맺어야 함)

2. 왜 HTTP는 Stateless 구조를 채택하고 있을까요?

• 확장성, 단순성, 데이터일관성 때문
• 각 요청은 서로 독립적이어야 함. 서버에 요청에 대한 정보를 기억할 필요가 없으므로 개발과 유지 보수가 더 단순해짐.
• 서버가 각 클라이언트의 상태를 추적할 필요가 없으므로 수천 또는 수백만 사용자를 처리하는 대규모 서비스에 적합함. 상태 정보를 저장하고 관리하지 않아도 되므로, 서버 자원을 효율적으로 사용할 수 있고, 로드 밸런싱이 쉽게 구현됨.
• 각 요청과 응답이 독립적이므로, 여러 서버가 동일한 요청을 처리할 수 있음. 이는 분산 시스템에서 매우 중요
• 클라이언트 상태를 유지할 필요가 없으므로 서버는 빠르게 응답을 보낼 수 있음, 또 여러 서버 사이에서 데이터 일관성 문제가 발생할 가능성이 줄어듦.

왜 HTTP는 connectionless를 채택했을까?

• 서버의 자원 효율적 관리
• 수 많은 클라이언트의 요청에도 대응할 수 있게 하기 위해서
• 수 천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수 십개 이하로 작음

3. Connectionless의 논리대로면 성능이 되게 좋지 않을 것으로 보이는데, 해결 방법이 있을까요?

HTTP 성능의 한계

• 매번 TCP/IP 연결을 새로 맺어야 하므로 3-way handshake에 따른 시간이 추가됨
• HTML을 받기 위해 연결/끊기, JS파일 받기 위해 연결/끊기..

해결

• HTTP1.1에는 keep-alive옵션, HTTP/2 부터는 서버푸시로 최적화 함
  • keep-alive: 여러개의 파일을 송수신할 수 있음
    
  • 서버푸시: HTML보내고, 서버가 바로 CSS, JS파일 보낼 수 있음
    

전체적으로 필요한 부분에는 커넥션 유지를 하는 듯

• HTTP 지속 연결(Persistent Connections)으로 문제 해결

📌keep-alive

4. TCP의 keep-alive와 HTTP의 keep-alive의 차이는 무엇인가요?

TCP keep-alive

• TCP 수준에서 연결이 활성상태인지 확인하기 위해 사용되는 기능
• 일정시간동안 데이터 교환이 없을 경우 Keep-alive 패킷을 송수신해 연결 유효성 검사
• 연결을 유지하기 위해 사용(like healthcheck)

HTTP Keep-alive

• HTTP 프로토콜 수준에서 동작
• 얼마동안 연결을 유지할 것인지가 목적
• Http Header를 통해 전달
• 클라이언트-서버간 여러 HTTP 요청/응답을 하나의 TCP 연결로 처리할 수 있도록 함
• HTTP/1.0+ 에서는 persistent connection을 위해서 헤더에 명시를 했어야함
• HTTP/1.1 부턴 기본값으로 지원