전송계층(3) _ Flow Control, 3-way handshake, 4-way Handshake

 TCP Flow Control 

• sender측과 receiver측의 데이터 처리 속도 차이를 해결하기 위한 기법
• receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
• receiver가 sender에게 현재 자신의 버퍼 상태를 feedback한다
  • sender는 recevier 버퍼에 남은 공간 만큼만 데이터를 보낸다

---

 why flow control 

TCP receiver buffer

• TCP에서 flow control은 receiver 측 소켓에 존재하는 버퍼를 기준으로 삼음
• receiver 버퍼에 데이터가 쌓이면 application layer에서 데이터를 계속 가져감
• 그러나, application layer에서 가져가는 속도보다 버퍼에 데이터가 쌓이는 속도가 더 빠르면 데이터가 유실될 수 있으므로 속도를 조절해줘야하는 것

---

 how it works 

• receiver의 수용가능한 window size ⇒ receiver의 비어있는 버퍼의 크기
• recevie window 만큼 데이터를 보낸다
  • receive 버퍼에 비어있는 공간 10byte → sender는 10byte만큼 데이터를 보냄

 

❓ receiver의 버퍼가 꽉 찬다면?

receiver의 버퍼가 가득 차있으면 sender에게 보내지는 receiver window size는 0이 된다. sender는 데이터를 보내지 않고 대기하게 되는데, 그러면 receiver 버퍼에 공간이 생겼을 때 sender는 어떻게 이를 알 수 있을까?

 

이러한 상황에 대응하기 위해 TCP는 persist Timer 를 사용한다

TCP의 persist Timer는 sender가 receiver 버퍼에 빈 공간이 있는지 알아보려고 주기적으로 1byte 데이터(더미 데이터)를 담은 세그먼트를 전송하는 것이다.

 

이런 의미없는 세그먼트를 보내야 receiver가 ACK를 보내게 되고, sender가 그 ACK를 받아야 ACK 헤더에 있는 Receiver buffer size(receiver window)를 읽고 이걸 기준으로 다시 데이터를 전송할 수 있는 것이다!

---

 TCP Connection Management(연결 제어) 

TCP에서의 버퍼간 데이터 전달 구조. Send 버퍼의 시퀀스 번호가 상대 Recv 버퍼의 시퀀스 번호로 연결됨

 

• TCP에서 연결이 성립되기 전 먼저 셋팅되어야 할 것

1️⃣ sender와 receiver 각각의 send 버퍼, receive 버퍼

2️⃣ sender와 receiver가 주고 받을 packet의 seq#

 

→ 이 셋팅 과정을 TCP Connection Management 라고 함

 

 

TCP 통신 과정에서는 세그먼트의 순서가 중요하기 때문에 seq#가 필요하다.

TCP는 기본적으로 양방향 통신이다. A의 send 버퍼에서 데이터를 전송하면 B의 recv 버퍼가 데이터를 받는다.

따라서 A의 send 버퍼의 seq#는 B의 recv 버퍼의 seq#와 같다.

반대로 B의 send 버퍼에서 데이터를 전송하면 A의 recv버퍼가 받는다.

따라서 B의 send 버퍼의 seq#는 A의 recv 버퍼의 seq#와 같다.

A’ send buffer seq# === B’ recv buffer seq#

B’ send buffer seq# === A’ recv buffer seq#

---

 TCP 3-way handshake 

클라이언트와 서버 간의 연결을 위한 세 번의 악수!

1️⃣ SYN

• 클라이언트의 seq#를 서버에 알려줌
• header에 있는 SYN 필드에 1을 담아 보냄 (세그먼트의 헤더 SYN 비트가 1이되면 연결하겠다라는 뜻)
• SYN msg를 보내는 것 ⇒ TCP 커넥션 열기를 요청하는 것

2️⃣ SYN/ACK

• 잘 받았고 서버를 열겠다는 의미로 SYNACK를 보냄
  • 서버의 seq#를 서버에 알려줌
  • SYNACK의 SYN 필드 역시 1
  • 클라이언트의 seq# + 1을 ACK로 전달
• 이 과정에서 서버는 버퍼를 만듦

3️⃣ ACK

• SYNACK를 받은 클라이언트는 서버가 열렸음을 인지하고 이에 대한 응답으로 ACK를 보냄
• ACK 과정에서 SYN 필드는 0이며, 클라이언트는 서버에 실제 데이터를 담아 보낼 수 있음

❓ 굳이 ACK를 또 보내는 이유

❗클라이언트는 2번째 과정에서 메시지가 성공적으로 전달이 되었다는걸 알 수 있지만 서버는 자신이 보낸 메시지(SYNACK)가 클라이언트에게 정상적으로 전달이 되었는지 알 수 없다.

따라서 클라이언트가 ACK로 응답 메시지를 보냄으로써(3번째 과정) 서버 역시 자신의 메시지가 클라이언트에게 제대로 전송이 되고 있음을 알 수 있게 된다.

---

 Closing TCP Connection (4-way Handshake) 

 

1️⃣ FIN

: 클라이언트가 서버에게 FIN을 보내서 연결 종료 알림

 

2️⃣ ACK

: 서버는 클라이언트의 연결 중단 요청을 확인하고 ACK를 보냄 이때 서버는 FIN을 받자마자 종료되는 것이 아니라 보낼 데이터가 남아있으면 마저 다 보내고나서, 역할이 확실하게 끝난 후 종료

 

3️⃣ FIN

: 서버가 클라이언트에게 연결 중단을 알림

클라이언트가 FIN을 받으면 잠시 동안 timed wait 상태가 되어 연결 종료 통지를 받고도 잠시 기다리게 됨

 

4️⃣ ACK

: 클라이언트가 서버에게 연결 중단을 확인했다고 ACK를 보냄

서버가 ACK를 받고 나서 TCP 연결이 종료됨!

 

 

 

 

❓왜 timed wait 을 할까?

❗클라이언트는 바로 received buffer와 sender buffer에 대한 메모리를 해제하지 않고 timed wait이라는 마진 시간 개념을 두고 천천히 메모리를 해제한다.

왜냐하면 만약 클라이언트에서 보낸 ACK가 유실되면, 서버는 보낸 FIN에 대한 ACK를 받기 위해 다시 FIN을 보낼 수 있기 때문이다.

그러면 클라이언트는 ACK를 재전송하기 위해 여전히 메모리 정보들이 필요하다!

 

---

참고자료

https://ddongwon.tistory.com/85

TCP Flow Control

https://dev-nicitis.tistory.com/30

3-5. 전송(Transport) 계층: TCP 2

http://www.kocw.net/home/cview.do?cid=6166c077e545b736 

컴퓨터네트워크