반응형
1. 클라이언트 - 서버 모델 기초
기본 아키텍처
클라이언트 (요청자) 서버 (응답자)
- 웹 브라우저 - 웹 서버 (Apache, Nginx)
- 모바일 앱 - 애플리케이션 서버 (Tomcat)
- 데스크톱 앱 - 데이터베이스 서버
통신 흐름
1. 클라이언트가 서비스 요청
2. 서버가 요청 처리
3. 서버가 응답 반환
4. 클라이언트가 응답 수신
2. TCP 통신의 기본 원리
TCP 3-Way Handshake
클라이언트 서버
| |
|─── SYN ─────────────────→| (연결 요청)
|←── SYN + ACK ───────────| (연결 수락 + 확인)
|─── ACK ─────────────────→| (최종 확인)
| |
|<── 데이터 통신 가능 ───→|
TCP 연결의 전체 생명주기
1. 연결 설정(3-Way Handshake)
2. 데이터 통신
3. 연결 종료(4-Way Handshake)
4-Way Handshake 는 왜 4단계 인가 ?
TCP 는 ***전 이중 통신 (Full Duplex)** 이기 때문입니다.
- 양방향으로 동시에 데이터 전송 가능
- 예) 전화,TCP , 현대 이더넷
클라이언트 ←────── 양방향 통신 ──────→ 서버
↑ ↑
독립적인 송신 독립적인 송신
독립적인 수신 독립적인 수신
연결 종료 시 각 방향을 독립적으로 닫아야합니다.
Step 1 : 클라이언트가 보내고 종료
클라이언트 : "나는 더 이상 데이터 보낼 게 없어" (FIN)
Step 2: 서버가 확인
서버: "알겠어, 너는 더 안 보내는구나" (ACK)
(하지만 서버는 아직 클라이언트에게 보낼 데이터가 있을 수 있음)
Step 3: 서버도 보내기 종료
서버: "나도 이제 보낼 게 다 끝났어" (FIN)
Step 4: 클라이언트가 최종 확인
클라이언트 :"알겠어, 완전히 연결 종료하자" (ACK)
클라이언트 서버
| |
|─── FIN ─────────────────→| (종료 요청)
|←── ACK ─────────────────| (종료 수락)
|←── FIN ─────────────────| (서버 측 종료)
|─── ACK ─────────────────→| (최종 확인)
만약 , 4-way 가 아닌 , 2-way 로 종료하게 된다면 데이터 손실이 이뤄지고 만다.
클라이언트 서버
파일 요청 ──────────────────────→
←────────────────────────── 파일 전송 시작 (큰 파일)
"충분해" ──────────────────────→ (클라이언트가 중간에 멈추고 싶음)
←────────────────────────── 파일 전송 계속 중... (서버는 아직 전송 중)
결론: 독립적으로 닫아야 하는 이유는 전이중 통신에서 각 방향이 서로 다른 역할과 타이밍을 가지기 떄문입니다. 한쪽이 보내기를 끝냈다고 해서 다른 쪽도 즉시 끝나는 것이 아니라, 각자의 작업을 완료할 시간이 필요로 합니다.
반응형