Search
🌍

bc1.1_1. title: 데이터베이스 응답은 빠른 속도가 중요하므로, 연결을 끊어버리면 매번 TCP 핸드셰이크와 DB 핸드셰이크를 다시 해야 한다는 문제가 있다. 그래서 전송 계층으로 HTTP이 상태 유지가 기본인 TCP 프로토콜에 의존하고, 커넥션 풀을 이용해 한 번 맺어둔 TCP 연결을 재사용한다.

생성
prev summary
🚀 prev note
next summary
🚀 next note
관련 임시노트
9 more properties
TCP 연결을 유지하는 이유는 TCP 연결 과정에서 발생하는 오버헤드 데이터베이스 연결을 새로 생성하는 과정에서 발생하는 오버헤드를 줄이기 위함이다.
1.
보안 암호화 핸드셰이크(SSL/TLS): 클라이언트와 서버가 안전하게 통신하기 위해 암호화 방식을 협상하고 공개키를 교환하는 과정. 이 과정은 여러 번의 데이터 패킷 교환(Round Trip)을 필요로 하므로, 특히 지리적으로 멀리 떨어진 데이터베이스에 연결할 때 상당한 지연 시간의 원인이 됨.
2.
데이터베이스 프로토콜 핸드셰이크: 서버와 클라이언트 간 프로토콜 버전 협상. "저는 PostgreSQL 클라이언트 버전 X이고, 프로토콜 v3을 지원합니다." 와 같은 대화가 오가는 단계를 의미함.
3.
인증 과정: 사용자 자격 증명 검증. 아이디와 비밀번호 같은 자격 증명을 서버로 보내고, 서버는 이를 내부 사용자 정보와 대조하여 인증을 수행함.
4.
세션 초기화: 해당 연결에서 사용할 타임존(timezone), 문자 인코딩(client_encoding), 트랜잭션 격리 수준(transaction_isolation) 등 세션 파라미터 설정. 세션 컨텍스트(Session Context)를 설정함.
로컬 환경에서는 이 과정이 1-2ms 정도지만, 원격 서버의 경우 RTT가 50ms라면 전체 연결 과정에 100-300ms가 소요될 수 있다.
parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료을 보관해 두는 영역입니다.
1.
None
from : 과거의 어떤 원자적 생각이 이 생각을 만들었는지 연결하고 설명합니다.
1.
TCP 연결의 핵심 특징은 연결이 명시적으로 종료되기 전까지 지속된다는 점이다. 운영체제나 네트워크 장애가 발생하지 않는 한, 한 번 맺어진 TCP 연결은 수 시간에서 수 일까지도 유지될 수 있다. 어떻게 가능한지는 앞의 메모를 참고하자.
2.
keep-alive(HTTP1.1) 도입에도 역사적으로 HTTP는 비상태 프로토콜로 시작했다. 애초에 목적과 방향성이 다른 프로토콜이기 때문에, 어느정도 호환은 되겠지만 적절한 프로토콜이라고 볼 수 없다.
Gemini는 이렇게 설명했다.
HTTP/2, HTTP/3가 아무리 효율적이라도 웹 환경에 필요한 기능(헤더, 캐싱, 다양한 메서드 등)을 위한 최소한의 오버헤드는 존재합니다. 초당 수만 개의 작은 쿼리를 처리해야 하는 데이터베이스 환경에서는 이 작은 차이가 큰 성능 저하로 이어질 수 있습니다. 데이터베이스 통신은 단순 요청/응답을 넘어섭니다.
3.
실시간성이 크게 중요하지 않은 경우에는 충분히 감당 가능한 오버헤드이겠지만, 데이터베이스에는 적합하지 않을 수 있다.
supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는지 연결합니다.
1.
None
opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는지 연결합니다.
1.
None
to : 이 문서에 작성된 생각이 어떤 생각으로 발전되거나 이어지는지를 작성하는 영역입니다.
ref : 생각에 참고한 자료입니다.
1.
None