Bansanka

TCP 3-way handshake 쉽게 이해하기

웹 페이지가 열리고, 앱이 API를 호출하고, 서버가 DB에 연결하는 과정 뒤에는 대부분 TCP connection이 있습니다.개발자는 보통 HTTP 요청, SQL Query, socket read/write 같은 application level을 먼저 보지만, 실제 통신이 시작되기 전에는 TCP 3-way handshake가 먼저 일어납니다.그리고 통신이 끝난 뒤에도 connection은 바로 사라지지 않고 TIME_WAIT 같은 상태로 잠시 남을 수 있습니다. TCP 3-way handshake는 양쪽이 통신 가능한 상태인지 확인하고, TIME_WAIT은 닫힌 connection 주변의 늦은 packet을 안전하게 정리하기 위한 상태입니다. 이번 글에서는 TCP connection이 어떻게 만들어지는..

DB Index를 처음 배우면 이런 생각을 하기 쉽습니다.“Index를 만들었으니 이 Query는 빨라질 것이다.”하지만 실무에서는 Index가 있는데도 Query가 느린 경우를 자주 만납니다.이때 문제를 제대로 보려면 Index 존재 여부가 아니라, Optimizer가 실제로 어떤 Execution plan을 선택했는지를 확인해야 합니다. Index는 “만들면 무조건 쓰이는 장치”가 아니라, Optimizer가 Cost를 계산해 선택할 수도 있고 선택하지 않을 수도 있는 Access path입니다. 이번 글에서는 DB Index가 있어도 Query가 느려지는 이유를 Selectivity, Composite index, 함수로 감싼 컬럼, Execution plan 관점에서 정리해보겠습니다. Ind..

멀티스레드와 운영체제를 공부하다 보면 race condition이라는 표현을 자주 만나게 됩니다.한국어로는 보통 경쟁 상태라고 부릅니다.말 그대로 여러 실행 흐름이 같은 데이터나 자원을 두고 경쟁하면서, 실행 순서에 따라 결과가 달라지는 문제입니다.프로세스와 스레드, 데드락을 이해했다면 그다음으로 반드시 짚고 넘어가야 하는 동시성 개념입니다. Race condition은 여러 작업이 공유 자원에 동시에 접근하고, 그 접근 순서가 결과를 바꿀 때 발생하는 동시성 버그입니다. 이번 글에서는 race condition이 무엇인지, 왜 재현하기 어려운지, C++ 코드와 DB 예시에서는 어떻게 나타나는지, 실무에서는 어떤 기준으로 예방해야 하는지 정리해보겠습니다. 1. Race condition은 무엇인가?Rac..

동시성 문제를 공부하다 보면 race condition 다음으로 자주 만나는 개념이 데드락입니다.데드락은 단순히 프로그램이 느려지는 문제가 아니라, 여러 작업이 서로를 기다리다가 아무도 앞으로 나아가지 못하는 상태입니다.운영체제, 멀티스레드 프로그래밍, DB 트랜잭션, 서버 장애 분석에서 모두 등장하는 개념이라 면접에서도 자주 묻습니다. 데드락은 자원을 가진 작업들이 서로 다른 자원을 기다리면서 무한 대기 상태에 빠지는 문제입니다. 이번 글에서는 데드락이 발생하는 조건, 실제 코드와 DB 상황에서 어떻게 나타나는지, 실무에서는 어떻게 예방하고 추적하는지 정리해보겠습니다. 1. 데드락은 무엇인가?데드락은 여러 실행 주체가 서로 자원을 기다리면서 더 이상 진행하지 못하는 상태입니다.여기서 실행 주체는 프로세..