TCP 3 Way-Handshake & 4 Way-Handshake

3 Way-Handshake

-TCP 연결지향적이며 오류제어, 흐름제어, 혼잡제어, 타이머재전송 등의 기능을 하며 연결지향이란말은 데이타를 전송하는 측과 데이타를 전송받는 측에서 전용의 데이타 전송 선로(Session)을 만든다는 의미이다. 데이타의 신뢰도가 중요하다고 판단될때 주로 사용된다.

-TCP는 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 three-way handshake를 사용한다.

연결 과정

SYN : Synchronize Sequence Number

ACK : Acknowledgement

 

3 way Handshake를 간단하게 설명해보자면

1. a->b 내말 들려?(SYN)

2. b->a 응 잘들려(ACK) 내말은 들려(SYN)?

3. a->b 응 잘들려(ACK)

 

[STEP 1]

 A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다. 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 된다.

 

[STEP 2] 

 이때 서버는 Listen 상태로 포트 서비스가 가능한 상태여야 한다. (Closed :닫힌상태) B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다. 이때 B서버는 SYN_RECEIVED 상태가 된다.

  

[STEP 3]

 A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다. 이때의 B서버 상태가 ESTABLISHED 이다.

 위와 같은 방식으로 통신하는것이 신뢰성 있는 연결을 맺어 준다는 TCP의 3 Way handshake 방식이다.

 

 

처음에 클라이언트에서 SYN 패킷을 보낼 때 Sequence Number에는 랜덤한 숫자가 담겨진다.

• Connection을 맺을 때, 사용하는 포트(port)는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용한다. 따라서 이전에 사용한 포트 번호를 재사용할 가능성이 있다.
• Sequence Number가 순차적인 숫자로 전송된다면 서버는 이전의 Connection으로부터 전송되는 패킷으로 인식할 수 있다. 따라서 이러한 문제를 해결하기 위해 난수로 초기 Sequence Number를 설정한다.

 

 위 방식을 통해 TCP는 연결지향적인 특성과 자체적으로 오류를 처리하며 순서가 뒤바뀐 패킷을 교정해주는 기능이 더불어 주로 데이터의 신뢰도가 중요하다고 판단되어질 때 쓰인다.

 신뢰도 확보가 중요하거나 용량이 큰 데이터를 전달해야 때, 실시간일 필요는 없을 때 활용 된다.

 

 하지만 데이터의 신뢰성 보다 전송 속도가 중요시되는 경우면 어떨까? 스트리밍 서비스 같은 경우 속도가 생명이다. 만약 계속해서 버퍼링이 걸린다면 사용자는 매우 불쾌할 것이다. 

 

 UDP 프로토콜은 위와 같은 과정이 없이 단순히 데이터만을 전송하므로 속도가 빠르다. 스트리밍  서비스 같은경우 약간의 화질이나 음질의 손상이 있다 해도 끊기지 않는 서비스가 중요하다. 그래서 UDP방식을 사용한다.

 

 

4Way-HandShake

-TCP/IP 프로토콜을 이용한 통신 과정에서는 위에서 언급했던 것처럼 3 way handshake 과정을 통해 연결을 설정하고

 4way handshake 과정을 통해 연결 설정을 해제한다.

[연결 과정]

1. 클라이언트는 서버에게 연결을 종료하겠다는 FIN 패킷을 보낸다.
2. 서버는 클라이언트의 요청(FIN)에 대한 응답으로 ACK 패킷을 보낸다.

​ 2-1) 처리해야 할 자신의 통신이 끝날 때까지 기다린다.

1. 처리해야 할 모든 통신을 끝마쳤다면 연결을 종료하겠다는 FIN 패킷을 보낸다.
2. 클라이언트는 FIN 패킷에 대한 확인 응답으로 ACK 패킷을 보낸다.
3. 클라이언트의 ACK 패킷을 받은 서버는 소켓 연결을 close 한다.
4. 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 것을 대비해 기다리는 과정을 거친다.(TIME_WAIT)

[에러 발생]

클라이언트에서 FIN 패킷 전송 후 ACK 패킷을 기다리는 FIN_WAIT1과 서버의 ACK 패킷을 받은 후 FIN 패킷을 기다리는 FIN_WAIT2 에러 발생으로 인해 Time out이 되면 스스로 연결을 종료한다.

 

그런데 만약 "Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황"이 발생할 수도 있다.

 

Client에서 세션을 종료시킨 후 뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop되고 데이터는 유실될 것입니다. 

이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 합니다.

 

또한 CLOSE_WAIT은 Application이 close()를 적절하게 처리하지 못하면 CLOSE_WAIT 상태로 계속 기다리게 되어 Socket Hang Up 에러가 발생할 수 있습니다.

 

 

 

참고

sleepyeyes.tistory.com/4

mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-22%ED%8E%B8-TCP-3-WayHandshake-4-WayHandshake

github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/3%20way%20handshake.md