TCP 3-way handshake 란?

Udemy에서 강의를 듣던 중 알게 된 개념이다. Hacking for Beginners 라는 이름의 강의에서 IP, TCP, HTTP 등 프로토콜에 대해 설명하면서 언급하였는데 평소에 들어보았던 개념이기도 해서 따로 정리해 본다.

1) TCP 3-Way Handshake

Handshake는 '악수'라는 뜻을 가지고 있다. 이는 즉 우리가 다른 사람과 악수를 할 때 나와 상대방이 만나서, 악수를 요청하고, 상대방이 악수를 받듯이 3개의 과정(Way)을 거쳐 연결을 성립한다는 것을 짐작할 수 있게 해 준다. 그렇다면 그 과정은 무엇일까? 그전에 TCP에 대해서 간략하게 알아보자.

전송 제어 프로토콜인 TCP는 인터넷 프로토콜, IP의 상위 버전이라 할 수 있다. 이는 기존의 IP가 비신뢰성, 즉 보낸 정보가 제대로 갔는지 확인하지 않고 커넥션리스, 즉 지속적인 연결을 요구하지 않기 때문에 패킷이 정확하게 전송되거나 중복되어 전송하지 않는지 확인할 방법이 없는 것에 비해서 Handshake를 통해 송신자와 수신자 간의 연결을 성립함으로써 패킷을 순서대로, 에러 없이 전송할 수 있도록 해준다.

TCP의 가장 큰 특징은 언급한 것처럼 연결을 '성립'시키면서 패킷 전송 시 패킷의 무결성과 전송 순서를 보장할 수 있다는 것이 있다. 물론 이를 위해서 추가적인 데이터가 필요하게 되는데 이는 TCP 패킷이 구조를 참고하면 알 수 있을 것이다.

이와 대립하는 프로토콜로 사용자 데이터그램 프로토콜, UDP가 있는데 이는 순서대로, 온전하게 전달되었는지를 확인하지 않는 대신 속도가 빠르고 오버헤드가 적다는 특징이 있다. 당연히 신뢰성이 낮고 패킷 전송의 무결성을 보장하지 못하므로 대개 오류의 검사, 수정이 필요 없는 응용프로그램(게임, 비디오 스트리밍 등)에서 사용된다.

출처

이를 실생활에 비유하는 예로 다음과 같은 예시를 들 수 있다.
UDP) 초인종을 누르고 현관문 앞에 택배를 던져두고 가는 택배기사
TCP) 초인종을 누르고 주인이 나올 때 까지 기다렸다가 확인하고 물건을 건네주는 택배기사

2) Handshake란 무엇일까?

Handshake, Handshaking, 핸드쉐이크, 핸드쉐이킹 등 여러 가지 단어로 불리지만 공통적으로 나타내는 바는 동일하다. 통신이 시작되기 전에 두 지점이 확립된 연결을 가지도록 설정하는 것이다. 그렇다면 이것이 어떻게 TCP에 적용될 수 있을까? 우선 TCP 헤더를 살펴보자.

출처

위와 같이 TCP 헤더는 송신측(source)과 수신 측(destination)의 포트, sequence number(순서 번호) 등 여러 가지를 나타내는 비트들로 이루어져 있는데 여기서 우리가 살펴볼 것은 URG, ACK, PSH, RST, SYN, FIN 이 6가지의 제어 플래그다.(각 필드에 대한 설명은 이곳을 참고)

이 제어 플래그들은 두 호스트 사이의 연결 상태나 추가적인 정보를 제공하기에 이들을 이용해 성립된 연결이 어떻게 처리되고 있는지 파악하고 문제를 해결할 수 있다. 각 플래그가 무엇을 의미하는지는 다음과 같다.(출처)(출처)

• SYN: synchronize. TCP 연결을 시작하며 회선을 개설하는 용도. 연결을 요청하고 허락할 때 세워진다. 즉 3-Way Handshake를 시작하는 플래그며 두 호스트의 첫 번째 비트에만 세워진다.

• ACK: acknowledgement, 확인. Acknowledgement number 값이 설정되어 유효하다는 것을 의미한다. 쉽게 말해서 전송을 제대로 받았다는 증거가 된다. SYN 플래그를 받으면 이 플래그를 보내며 이후 모든 세그먼트에는 항상 이 플래그가 세워져 있다. 값은 Sequence number에 1을 더한 값이 된다.

• URG: urgent, 긴급. 이 플래그가 세워지면 수신자에게 다른 패킷보다 해당 패킷을 먼저 처리하도록 요청한다.

• PSH: push. 받은 패킷을 버퍼링하지 않고 즉시 처리하도록 요청한다. 예를 들어 패킷을 상위 계층 응용프로그램에 빠르게 전달하도록 하며 URG와 비슷하다고 볼 수 있다.

• RST: reset, 강제 연결 초기화. 연결이 확립(ESTABLISHED)된 회선에 강제로 리셋을 요청한다.

• FIN: finish. 연결을 해제하며 회선을 종료한다. 송신측에서 데이터 송신을 마친다. 이 플래그가 세워진 세그먼트를 받아 ACK 플래그를 세워 응답하면 연결이 종료된다.

이런 제어 플래그를 세운 세그먼트를 전송하여 Handshake, 연결을 확립함으로써 이를 제어하고 데이터를 관리할 수 있다.
Handshake에 쓰이는 플래그는 SYN, ACK 이며 절차는 다음과 같다.

1. 송신 측이 수신 측에게 SYN 플래그가 세워진 TCP 패킷 전송(SYN=1, ACK=0)

2. 수신 측이 이를 받아 송신 측에게 SYN-ACK 플래그가 세워진 TCP 패킷 전송(SYN=1, ACK=1)

3. 송신 측은 다시 수신 측에게 ACK 플래그가 세워진 TCP 패킷 전송(ACK=1)

이를 위해 Udemy 강의에서는 구글의 로고 이미지에 대한 요청의 패킷 통신을 pcap파일로 올려두었는데 그를 살펴보면 아래와 같다.

첫 번째로 10.10.192.92(HackersAcademy) 에서 94.201.252.25(Google)로 TCP 패킷을 전송하였다. 이 때 Info를 살펴보면 SYN 플래그가 세워진 것을 알 수 있으며 이는 3-Way Handshake의 시작이 된다.

두 번째로 Source와 Destination이 반대로 되어 Google에서 HackersAcademy로 SYN, ACK 플래그가 세워진 패킷이 전송되었다. 이는 즉 HackersAcademy에서 보낸 SYN 플래그와 동일하게 구글에서도 SYN 플래그를 보내고 거기에 추가적으로 Google이 응답, 확인하였다는 ACK 플래그를 전송한 것이다.

세 번째로 HackersAcademy에서도 Google에게 SYN-ACK 플래그가 세워진 세그먼트를 잘 받았다는 ACK 플래그를 전송하여 3-Way Handshake를 완성, 연결을 확립하였다.

그 뒤로는 HackersAcademy에서 HTTP의 GET 요청을 통하여 Google의 로고 이미지를 요청하였고 이를 확인했다는 구글의 ACK 플래그와 HTTP 패킷이 HackersAcademy로 전송되었고 마찬가지로 HackersAcademy도 Google에 다시 ACK 플래그를 보내면서 안정적인 통신을 진행한 것을 볼 수 있었다.

제타위키에서는 이를 다음과 같이 표현했다.

단계	경로	내용
1	A → B	내 말 들리니? (SYN)
2	B → A	응. 너도 내 말 들리니? (ACK + SYN)
3	A → B	응. (ACK)

이때 2단계 까지만 진행된 경우, 즉 A는 B가 보낸 수신 확인은 받았지만 B에게 수신 확인을 보내지 않은 상태를 TCP half open 이라 부르며 해커스쿨에 이를 이용한 스텔스 스캐너를 만드는 것에 대한 문서가 있다.

아무튼 이런 방식을 통해서 이루어지는 것이 TCP 3-Way Handshake 이며 이를 통해 송신측과 수신측이 무결성이 보증된 패킷 통신을 진행할 수 있게 되는 것이다. 그렇다면 연결을 종료할 땐 어떻게 될까? 그때도 역시 Handshake를 이용하는데 이때는 4-Way Handshake를 수행하게 된다. 이는 다음에 알아보도록 한다.