[컴퓨터 네트워크] 22. Transport Layer (8) : TCP 연결 설정 (3-way handshake)

TCP connection management

TCP를 이용해서 데이터를 주고 받으려면, 그 전에 먼저 sender와 receiver 사이에 'handshake'가 필요하다.

연결 설정하는 것에 서로 동의하고, 어떤 seq 넘버를 시작점으로해서 데이터를 주고 받을 지 서로에게 알리는 과정을 거치는 것이다.

 

UDP는 이 과정이 필요없다. 내가 보내고 싶으면 상대방이 준비되어 있는지 확인하지 않고 그냥 보내면 된다.

하지만 TCP는 신뢰성을 보장해야 하기 때문에 연결을 설정하는 과정을 사전에 거쳐야 한다.

 

사전에 협의하는 내용은 구체적으로 아래와 같다.

 

1. 서로의 IP, port 번호, TCP 소켓 여부를 확인한다.

2. 데이터를 보낼 때 시작할 initial Seq Number (항상 0으로 시작하는게 아니라 임의로 지정할 수 있다.)

3. rcv buffer 크기

 

Handshake

2-way handshake

사람과 사람 사이에는 '우리 이야기합시다' - '좋아요' 와 같이 두 번의 대화로 연결을 설정할 수 있다.

이렇게 2번의 의사 전달로 연결을 설정하는 것을 2-way handshaking 이라고 한다.

 

 

이를 컴퓨터에 똑같이 적용하면 위 그림과 같다.

'나 너한테 연결하고 싶어' 라고 데이터를 보내는데 1번

'알겠어' 라고 데이터를 응답하는데 1번

총 2번의 데이터 전송을 거쳐서 연결을 설정하는 과정이다.

 

그런데 사람과 사람 사이에 대화할 때는 직접 만나서 이야기를 하니 괜찮은데, 컴퓨터와 컴퓨터 사이에 대화할 때는 중간에 데이터가 유실되거나, 전송이 늦어질 수 있기 때문에 이것만으로는 부족하다.

 

연결을 요청하는 데이터가 중간에 유실되거나 지연되면, sender 입장에서는 수신자의 상황을 모르니 의미없이 재전송을 계속할 수도 있고, 재전송을 하자마자 뒤늦게 응답이 오면 메세지의 순서가 뒤바뀌는 문제 등에 대처할 수 없다.

---

구체적인 예시를 보자.

 

위 그림은 이상적인 2-way handshake 방식으로 연결을 설정한 후 데이터를 주고받는 과정을 나타낸다.

연결 설정을 요청했고, 이에 대해 승인을 받아서 x+1 을 데이터로 보냈다.

리시버는 x+1을 받아서 ACK(x+1)을 돌려주고 연결이 정상적으로 종료되었다.

이 상황에서는 아무런 문제가 없다.

---

 

이번엔 다른 상황을 보자.

클라이언트가 연결 설정을 요청하고, 서버가 연결을 설정한 뒤, 승인 응답을 보냈다.

그런데 이 승인 응답이 늦게 오는 바람에, 클라이언트는 연결 설정 요청을 한번 더 보낸것이다.

 

클라이언트 입장에서는 다시 보내긴 했어도 연결 설정 요청을 보낸 뒤에 승인 응답을 받았기 때문에 연결을 설정할 것이고, 이 상태로 시간이 지나 연결이 종료되었다고 하자.

 

그런데 연결이 종료된 이후에 연결 설정을 요청하는 응답이 뒤늦게 서버에 도착했다고 해보자.

그러면 클라이언트는 자기는 연결을 잘 종료했다고 생각했는데, 서버는 뒤늦게 온 연결 설정 요청을 보고 연결을 설정한 뒤, 연결을 승인하는 응답을 보낸다.

 

클라이언트 입장에서는 연결 설정을 요청한 적도 없는데 갑자기 연결이 승인되었다고 하니 당황스러울 것이다.

그래서 이 연결 승인 메세지를 무시한다.

 

위와 같은 상황은 한쪽만 열린 half open connection 상황이므로 분명 문제가 있는 상황이다.

하지만 서버도 이 상황에서 내가 승인을 했는데 아무런 데이터를 안보내면 시간이 지나고 알아서 연결을 끊어버릴 수도 있으니 이것도 그럴수 있다고 하자.

---

 

 

하지만 위와 같은 상황에서는 문제가 생길 수 있다.

정상적으로 데이터를 잘 주고받고 있는 상황처럼 보이는데, 알고보니 최초에 연결을 설정할 때 연결 설정 요청을 재전송했었다고 해보자. 이 요청이 좀 돌아가는 라우터 경로를 탔든가해서 나중에 연결이 종료된 뒤에서야 서버에 도착했다고 하자.

 

그러면 서버는 연결을 다시 설정하고 연결을 승인하는 메세지를 보낸 뒤, 클라이언트가 보내는 메세지를 기다릴 것이다.

여기까지는 이전 예시와 똑같다.

 

 

그런데 하필 클라이언트가 데이터를 보낼 때, 한번에 도착을 안해서 재전송을 했고, 그 재전송한 데이터도 연결 설정이 종료된 이후에 서버에 도착했다고 해보자.

 

그러면 서버 입장에서는 이게 늦게 온 요청인지, 다시 들어온 요청인지를 모르니 연결을 설정하고, 그 이후에 온 데이터를 받아들이는 문제가 생긴다.

 

클라이언트 입장에서는 연결 요청을 보낸 적도, 데이터를 보낸 적도 없는데, 서버가 연결을 수락하고 데이터까지 수신해서 뭔가 내부적으로 처리를 해버리는 상황이 발생한다.

 

3-way handshake

이렇게 2-way 방식으로 연결 설정을 하게 되면, 서로의 상황을 알 수 없는 네트워크 환경에서는 문제가 생길 수 있기 때문에, TCP 연결 설정을 할 때는 3-way 방식으로 handshaking 한다.

이름 그대로, 3개의 메세지를 주고 받아서 연결을 설정한다는 뜻이다.

 

먼저 클라이언트와 서버 모두 소켓을 만들어두고, 상대방의 데이터 전송을 기다린다.

 

연결을 설정할 때는, 클라이언트가 initial seq num와 SYN (synchronize) 필드를 활성화한 세그먼트를 서버로 보낸다.

즉, 연결을 설정하고 싶다는 요청을 보내는 것이다.

이 과정을 거치면 Client State는 SYNSENT 상태로 천이된다.

 

서버도 자신이 사용할 init seq number 를 y로 설정한 뒤, 이 값과, SYN 에 대한 ACK를 설정하여 응답 세그먼트를 보낸다.

헤더에는 SYN 에 해당하는 S 플래그, ACK 에 해당하는 A 플래그가 활성화될 것이고, ACK number는 x+1 이 된다. (데이터가 실리지 않았지만 이때는 유일하게 byte가 아니라 세그먼트 자체에 번호를 부여한다고 보면 된다.)

서버도 S 플래그를 활성화하는 이유는 서버 입장에서도 나도 연결을 설정하겠다는 의사표시를 보내는 것이라고 보면 된다.

응답을 보낸 이후 Server 의 상태는 SYN RCVD 상태로 천이된다.

그리고 중요한 것은 2-way 때와 다르게 아직 서버는 establish 된 상태가 아니다.

 

이제 서버가 보낸 SYNACK 세그먼트를 클라이언트가 받으면 서버가 현재 응답을 받을 수 있는 상태라는 것을 알 수 있으므로 연결을 설정하여 ESTAB 상태로 천이한다.

또한 서버에게 너의 응답을 잘 받았다는 의미로 ACK (y+1)을 보내면서, 필요한 경우 자신이 보내고 싶은 데이터도 같이 담아 보낸다.

 

서버는 ACK를 보고 클라이언트가 자신이 보낸 요청(클라이언트 입장에서는 응답)을 잘 받았다는 것을 확인한 후에 ESTAB 상태로 천이한다.

---

 

이 방식을 사용하면 어떻게 2-way handshake의 문제를 해결할 수 있을까?

만약 클라이언트가 보낸 연결 설정 요청이 뒤늦게 도착했다면, 서버는 연결 설정을 하기 전에 SYNACK를 보낼 것이다.

만약 클라이언트가 자신은 요청을 보낸적이 없다고 판단한다면 SYNACK에 대해 '나는 요청을 보낸 적이 없으니 연결설정을 초기화하라' 는 의미로 RESET 플래그를 활성화시킨 세그먼트를 응답한다.

그러면 서버는 이를 보고 연결 설정을 하지 않고 다시 연결을 기다리는 상태로 돌아가게 된다.

---

TCP connection 종료

연결 설정을 종료하는 과정도 프로토콜에 의해 정의되어 있다.

(이때는 4-way handshake를 사용한다는 모양이다. 하지만 수업에서는 다루지 않아서 추후 정리하는 것으로 넘어간다.)

 

간략하게만 이야기하면,

연결을 종료하고 싶을 때 이상이 없는 정상적인 상황이라면 F 플래그를 활성화한 세그먼트를 보낸다. (클라이언트, 서버 둘 다 보낼 수 있다. 따라서 양쪽에서 동시에 보내는 경우도 가능하다. 이 경우도 처리하도록 프로토콜이 설계되어 있다.)