그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Network
Network

TCP 3-way handshake는 어떤 과정으로 연결을 수립하나요?

실무4/5
설계4/5
인간4/5
기초4/5

면접관의 질문 의도

패킷 이름 암기보다, 왜 3단계가 필요하고 2단계가 왜 불충분한지 논리적으로 설명할 수 있는지 확인하려는 질문이다.

큐레이션 답변

학습 자료

3-way handshake의 본질은 "연결 상태 합의"다. 클라이언트 SYN으로 연결 의사를 전달하고, 서버 SYN-ACK로 수신 가능 상태와 자신의 ISN을 함께 알린 뒤, 클라이언트 ACK로 이를 확인해야 양쪽이 서로의 송수신 준비 상태를 확정할 수 있다. 2-way만으로는 지연·중복 패킷 상황에서 상태 불일치가 남을 수 있어 3단계 확인이 필요하다. 이 비용(최소 1 RTT)은 신뢰성의 대가이며, 요구사항에 따라 keep-alive/pooling으로 연결 수립 오버헤드를 줄이거나 다른 전송 전략을 선택한다.

좋은 답변 구조

  1. 01핸드셰이크 목적을 상태 합의 관점으로 먼저 정의한다
  2. 02SYN/SYN-ACK/ACK 각각이 검증하는 정보를 설명한다
  3. 032-way의 한계(지연/중복 패킷)를 반례로 제시한다
  4. 04RTT 비용과 TCP/UDP 선택 트레이드오프로 마무리한다

자주 실수하는 포인트

3단계를 단순 절차로만 설명하고 설계 이유를 놓친다
2-way도 충분하다고 단정해 상태 불일치 가능성을 무시한다
프로토콜 선택을 속도만으로 단순 비교한다

실무 맥락

  • 실시간 기능에서 TCP/UDP 선택 검토
  • 초기 연결 지연(1 RTT) 영향 분석
  • 네트워크 프로토콜 기초 면접/설계 토론

본인 경험에 녹이는 힌트

초기 연결 비용 때문에 keep-alive/pooling을 도입한 경험을 말한다

요구사항에 따라 TCP 대신 다른 전송 전략을 검토한 근거를 설명한다

패킷 지연/중복 시나리오를 테스트해 상태 불일치를 검증한 사례를 공유한다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1왜 2-way handshake로는 상태 불일치 가능성이 남나요
Q2TCP Fast Open은 3-way 비용을 어떤 방식으로 줄이나요
Q3연결 수립 RTT 비용을 애플리케이션 레벨에서 줄이는 방법은 무엇인가요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문