개발자는 단순히 개발만을 잘하면 되는 것이 아니라 항상 '왜' 라는 키워드와 함께 성장해야한다고 생각한다.
개발 기술면접 단골문제이자 프론트엔드 개발자가 필수적으로 알아야하 는 CRP(critical rendering path) 이전에 서버와 클라이언트가 연결되고 연결이 종료되는 과정인 3way handshake & 4way handshake에 대해 알아보자!
3-Way handshake는 TCP의 연결을 초기화 할 때 사용
양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기전에 한쪽이 다른 쪽이 준비되었다는 것을 알수 있도록 한다.
[STEP 1]
A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다.
이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태, B서버는 Wait for Client 상태이다.
[STEP 2]
B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고
A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.
[STEP 3]
A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다.
이때의 B서버 상태가 ESTABLISHED 이다.
위와 같은 방식으로 통신하는것이 신뢰성 있는 연결을 맺어 준다는 TCP의 3 Way handshake 방식이다.
4-Way handshake는 세션을 종료하기 위해 수행되는 절차
[STEP 1]
클라이언트가 연결을 종료하겠다는 FIN플래그를 전송한다. 이때 클라이언트는 FIN-WAIT 상태다.
[STEP 2]
서버는 플래그를 받고 확인메시지 ACK를 보내고 서버는 자신의 통신이 끝날때까지 기다리는데 이 상태가 CLOSE_WAIT상태다.
[STEP 3]
서버가 통신이 끝났으면 연결이 종료되었다고 클라이언트에게 FIN플래그를 전송한다. 이때 서버는 LAST-ACK 상태다.
[STEP 4]
클라이언트는 확인했다는 메시지를 보낸다.
클라이언트의 상태는 FIN-WAIT에서 TIME-WAIT로 변경된다.
그런데 만약 "Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황"이 발생한다면 어떻게 될까? Client에서 세션을 종료시킨 후 뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop되고 데이터는 유실될 것이다.이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 한다.
'개발 > 프론트엔드' 카테고리의 다른 글
[개발상식] 간단하지만 헷갈리는 개념들 (클래스, 객체, 인스턴스) (0) | 2022.10.27 |
---|---|
[네트워크] HTTP 0.9 vs HTTP 1.0 vs HTTP 1.1 vs HTTP 2.0 (0) | 2022.10.26 |
[Front-end] URL, URI 비교하여 알아보자 (0) | 2022.10.03 |
[Front-end] CSR / SSR (with Next.js) (0) | 2022.09.30 |
[Firebase] 파이어베이스 호스팅 (1) | 2022.01.27 |