[Network]3-Way Handshake

클라이언트와 서버가 TCP소켓으로 연결할때 서로의 연결상태를 3단계로 확인하는 것이 3-Way Handshake다. 이를 이해하려면 먼저 TCP소켓의 특징에 대하여 알아야할 필요가 있다. TCP는 연결 지향 소켓으로 클라이언트와 서버가 연결되었는지 확인하는 과정이 존재한다. 그 확인하는 과정중에 하나의 방법이 3-Way Handshake이다.

이를 수행하는 정확한 목적을 무엇이냐고 묻는다면, 클라이언트에서 서버로 통신할 수 있는 경로를 생성하고 검사하는 작업이라고 할 수 있다. 처음에 클라이언트는 서버의 IP주소를 가지고 서버에 접근한다. 그 IP에 도달하기 위한 다양한 경로 중 가장 적절한 경로(라우터의 역할)를 거쳐서 도달하게 된다. TCP는 이런 경로가 생성되고 나면 그 경로를 통해 클라이언트, 서버의 송수신이 잘 되는지 검사를 하게 된다. 이 검사를 하는 과정이 3-Way Handshake의 목적이라고 할 수 있다.

* 소켓(Socket)이란 서로 떨어져있는 두 컴퓨터를 소프트웨서 상으로 연결해 주기위한 프로그램이다. 이 소켓이 어떤 통신을 하느냐에 따라서 소켓의 종류가 다양하게 존재하고, 그 종류중의 하나가 TCP소켓이다. 이 소켓은 연결지향적 소켓으로 통신시 연결이 되었는지 확인하는 절차가 존재한다.

1. 클라이언트에서 서버에게 먼저 연결을 요청한다.

클라이언트 : 서버야 나 연결해도 되니?

2. 그럼 서버는 연결이 가능하다면 연결 가능하다는 대답과 함께 서버에서 클라이언트로 연결이 가능한지 요청한다.

서버 : 응 클라이언트야 연결해도 돼! 나도 연결해도 되니?

3. 그럼 클라이언트는 연결이 가능하다면 연결이 가능하다는 대답을 전송한다.

클라이언트 : 응 서버야 연결해도 돼!

위의 세번의 연결요청을 통하여 연결이 되었는지 확인한다. 위 연결을 수행하기 위해서 주고받는 메시지를 패킷이라고 하는데 아래에서 자세히 알아보자.

패킷(Packet)

간단하게 말하면 패킷은 데이터의 한 단위라고 할 수 있다. 네트워크 상에서 컴퓨터와 컴퓨터 사이에서 서로 주고받기에 용이하도록 데이터를 형식화한 블록이다. 보내고자하는 데이터가 크다면 일정한 조각으로 나누어서 전송하는데 이것이 패킷 단위로 이루어진다.

따라서 조각난 데이터들을 보내고 다시 받을때 재조합의 필요성이 있다. 그래서 패킷에는 고유 번호가 존재하여 이를 구분하여 재조합한다. 이는 엄청난 장점을 가지는데 만약에 하나의 커다란 파일을 연속적으로 보낸다면 중간에 네트워크가 끊어져버린다면 그 데이터는 손실된 데이터가 되어버린다. 하지만 이렇게 패킷단위로 나누어서 전송한다면 전송 오류가 난 패킷부터 다시 재전송할 수 있는 강점이 있다.

패킷 = 헤더 + 페이로드 + 트레일러

위와 같은 형식으로 패킷이 구성된다.

1. 헤더 : 패킷의 정보. 즉, 고유 번호 및 도착 주소와 같은 제어정보가 들어가게 된다.

2. 페이로드 : 실제 데이터가 적재된다.

3. 트레일러 : 오류 정보가 들어가게 된다. 없는 패킷도 존재한다.

메시지 교환 방식

전반적인 구성과 패킷을 정리해 보았다. 그렇다면 저 위의 세 단계를어떤 형식으로 패킷을 주고 받는지 알아볼 필요가 있다. 주고 받는 패킷의 형태는 크게 두가지로 나눌 수 있다.

SYN(Synchronize) 연결을 요청하는 패킷

ACK(Acknowledge) 요청에 응답하는 패킷

위의 패킷은 데이터가 없이 헤더만 존재하는 패킷이다. 단지 확인을 위한 최소한의 크기의 패킷이라는 것이다.

1. 클라이언트가 서버에게 SYN 패킷를 보낸다. (SYN 1000)

2. 그럼 서버에서 받았을 경우 클라이언트로 부터 받은 패킷에 1을 더한 수를 ACK 패킷으로 보낸다. (ACK 1001) 그리고 서버도 클라이언트에게 SYN 패킷을 보낸다. (SYN 2000) 즉 요청에 응답하는 패킷과 연결을 요청하는 패킷을 함께 보낸다.

3. 클라이언트가 정상적으로 서버의 SYN 패킷을 받았다면 그 패킷에 1을 더한 수를 서버에게 ACK 패킷으로 보낸다. (ACK 2001)

위 세 단계의 과정이 완료되었다면, 연결이 완료되었다고 할 수 있다. 각 컴퓨터의 안정적 연결이 확정된 상태를 ESTABLISHED 상태라고 한다. 이 상태에서 서버와 클라이언트는 비로소 데이터를 주고받을 수 있게 된다.

타임아웃(Timeout)

클라이언트가 어떤 서버에 접속할 때 하루종일 응답을 기다릴 수는 없는 노릇이다. 네트워크는 언제 끊어질지 모르는 연결이다. 따라서 연결 요청시 타임아웃(Timeout) 시간을 두어서 연결 요청을 하고나서 일정시간동안 응답이 없다면 이 네트워크는 연결되지 않는 것으로 처리하는 것이다. 타임아웃값은 정확히 말하면 SYN 패킷을 보내고 ACK 패킷을 받기까지의 한계 시간을 뜻한다.

이 타임아웃 값의 크기는 네트워크의 성능에 큰 영향을 미친다. 이 시간이 너무 짧으면 느린 네트워크에서 정상적으로 서버에서 클라이언트가 응답했음에도 불구하고 다시 보내라는 재전송 요청을 하게된다. 이렇게 되면 같은 패킷을 의미없이 두번 보내게 되어 패킷의 혼란이 오고 대기시간도 증가하게 된다. 또 너무 길면 실제로 연결이 끊어졌을때의 대기시간이 길어져 전체적인 연결과 해제에 시간을 많이 쓰게 된다. 그래서 이 값은 정적인 값으로 설정하는 것이 아니라 동적으로 유연하게 하는 것이 바람직하다.

확인 절차보다 속도를 중시하는 경우

어떤 서비스의 경우에는 빠른 전송속도가 생명인 것들이 있다. 예를들어 게임, 동영상 스트리밍 서비스와 같은 경우는 빠르게 데이터를 전송하고 받아야 유저들의 원성을 피할 수 있을 것이다. 이럴때는 이러한 확인절차마저 큰 시간낭비로 느껴질 수 있다.

그래서 이러한 확인 절차를 배제하고 오로지 전송만 하는 소켓도 있는데 이것이 UDP소켓이다. 따라서 데이터의 손실을 어느정도 허용하면서 속도를 중시한다면 UDP소켓을 사용하는 것이 바람직하다. 반대로 데이터의 손실을 절대로 허용하지 않겠다면, TCP소켓을 사용하는 것이 더 좋다.

2-Way Handshake도 가능하지 않을까?

간단하게 보면 클라이언트가 서버에게 확인 패킷을 보내고 서버가 클라이언트에게 확인 패킷을 보내는 방식으로 두번의 과정으로 연결확인 되는 것이 아니냐는 반문이 나올 수 있다. 하지만 우리는 TCP의 기본이 양방향 네트워크 통신이라는 점을 다시 생각해볼 필요가 있다.

1. 먼저 클라이언트가 서버에게 SYN 패킷을 보낸다. (SYN 1000)

2. 서버가 클라이언트에게 ACK 패킷을 보낸다. (ACK 1001)

이렇게 두번의 전송으로 연결이 완료된 것 같지만, 이 과정은 단지 클라이언트 입장에서 서버에게 패킷을 보내고 받을 수 있다는 확인밖에 할 수 없다. 서버 입장에서는 클라이언트에게 패킷을 전송한 것이 잘 도착했는지 알 수 없다. 아까 말했듯이 TCP는 양방향 송수신 프로토콜이기 때문에 서버도 클라이언트에게 데이터를 전송하고 받을 수 있어야한다. 따라서 서버도 클라이언트에게 SYN을 보내고 ACK를 받음으로써 완벽한 연결의 확인을 하는 과정이 있어야한다는 것이다.

처음에 어떤 연결을 서버와 클라이언트가 시행하게 되면 양쪽 다 서로의 존재를 모르고 시작한다. 그래서 2-Way Handshake로는 단지 단방향의 연결만 입증할 수 있다는 것이다. 그래서 반드시 3-Way Handshake가 필요한 것이다.

4-Way Handshake는 무엇일까?

3-Way Handshake를 검색하다보면 동시에 4-Way Handshake라는 말이 꼬리표처럼 따라다닌다. 그래서 4-Way Handshake도 무엇인지 의문이 생겨 찾아 보았다.

FIN(Finish) 연결해제 요청 패킷

3-Way Handshake가 연결을 확정하는 작업이라면, 4-Way Handshake는 연결을 안정적으로 끊어버리는 작업이다. 처음에 클라이언트나 서버중 한 쪽에서 연결을 종료하는 FIN 패킷을 보내는 과정이 추가로 존재한다. 이 과정은 연결의 해제를 요청하는 역할을 하여 이 패킷을 받은 순간부터 연결해제를 하는 과정을 시작하게 된다. 이 과정은 3-Way Handshake와 동일한 과정이다.

3-Way Handshake의 결과물이 서버와 클라이언트의 ESTABLISHED상태라면, 4-Way Handshake의 결과는 CLOSED상태이다. 결국 처음에 어떤 컴퓨터인지는 모르겠지만(주로 클라이언트), 그 컴퓨터에서 연결 해제 요청을하고 연결과정과 동일하게 해제 과정도 서로가 충분히 확인을 하고 해제를 한다는 것이다.

이 과정은 정말 쓸데없다고 생각할 수 있지만 굉장히 중요하다. '그냥 끊으면 땡 아니야?'라고 생각할 수 있지만, 서버의 자원도 물리적인 한계가 존재하기 때문에 어떤 확정된 연결 해제가 존재하면 이 연결은 다른 클라이언트에게 제공될 수 있게 된다. 만약 이런 과정이 없다면 서버에서는 '연결이 되어있는데 요청이 없는 상태'로 오해할 소지가 있다. 결국 의미없는 연결을 계속적으로 신경써줘야 되는 상황이 생기고, 자원의 낭비가 발생하는 것이다.

따라서 여러 클라이언트에게 서비스를 제공하야하는 서버의 입장에서는 연결 해제를 확정하는 과정은 자원 관리를 위해 정말 중요하다고 할 수 있다.

참고

http://asfirstalways.tistory.com/356

http://www.inetdaemon.com/tutorials/internet/tcp/3-way_handshake.shtml

https://networkengineering.stackexchange.com/questions/24068/why-do-we-need-a-3-way-handshake-why-not-just-2-way