[ 네트워크 ] 14. Transport layer : TCP ( flow control / connection control management )

Flow control

Q : 만약 Application Layer가 받는 속도보다

      Network Layer가 보내는 속도가 더 빠르다면? 

 

이에 대해서 문제가 생기지 않도록

Packet Header에 주고받는 Bytes 수를 정해두었다.

 

이 덕분에 Receiver는 Sender에 대한 조정을 하여

Sender가 Receiver의 Buffer에 넘쳐 흐르도록 담지 않도록 ( 양 , 속도 측면으로) 조정한다.

 

 

➡️ 이를 위해 Receiver는 Buffer에 얼만큼의 공간이 남았는지 알려준다.

      ( TCP header에 rwnd(Receive WiNDow) 로 담는다. )

 

RcvBuffer = rwnd(여유 공간) +  Buffered data

 

 

 

---

Connection Management

: 데이터를 주고받기 전에는, Sender / Receiver가 Handshake 과정을 거쳐야한다.

ex) 당근마켓 거래로 비유하면, "혹시 당근...." "네..XX거래 ? "  느낌의 주고받는 내용이라고 생각하면 된다.

 

➡️ Connection 구축

➡️ Connection Param 교환 / ex) 시작 seq #

 

 

 

---

 

📌 2-way handshake

이게 항상 유효할까?

➡️ Delay가 항상 변칙적이다.

➡️ Loss 나면 다시 보내야한다.

➡️ 반대편이 어떤 상태인지 알 수 없다.

 

 

시나리오 1)

 

이런 상태면 괜찮다.

- 연결 신청을 주고받고 Req_conn + Acc_conn

- 정보도 정상적으로 주고 확인하고, DATA + ACK

 

 

하지만 이런 상황을 생각해보자. 

- Connection 연결을 신청하고, 그에 대한 ACK가 너무 늦게 날라갔을 때 = Timeout

- 그 사이에 연결이 종료되거나 새로운 정보가 전송된다면, Server에서는 이를 판단할 수 없다. 

   ➡️ 연결된 Client는 없는데, 정보가 들어온다?

 

 

 

만약 데이터를 받고 ACK 도 제대로 보내지 않았다면, 다시 보내야 할 것이다.

그럴 때 Sender가 다시 보낸다 해도, Receiver는 이미 있는 정보이기 때문에 

Duplicated Data가 들어오게 된다.

 

 

 

 

---

📌 3-way handshake

 

2way handshake 문제를 해결하고자 나온 방식이다.

주고 받는 정보에 State도 추가하는 것이다.

 

1. Sender가 Receiver에게 연결하자고 요청함 : Flag = SYN

2. Receiver가 요청에 대해 확인했다는 의미로 응답을 보냄 : Flag = SYN + ACK

3. Sender가 Receiver가 응답한 걸 확인함 : Flag : ACK

 

 

 

- Sender : 너가 보낸 79번까지 받았어 + 해당 파일에 있는 42번째 자리에서 C크기로 하나 줄게

- Receiver : 너가 보낸 43번까지 받았어( 42번째 + C크기=(1) ) + 79번째 자리에서 하나 더 추가된 거 보내줄게

 

- Sender : 너가 더 보냈던 80까지 받았어 , 43번에 있는 거 (있으면) 줄게..

 

 

---

- 연결을 종료할 때

📌 4-way handshake

- Client가 연결을 종료하려고 FIN bit를 보낸다.

- Server가 종료 요청을 받았다는 의미에서 ACK를 보낸다.

  ➡️ 하지만 Server가 보내야하는 data들이 조금은 남아있기에 기다린다.

 

 ... 다 보냄

 

- 이번에는 Server가 Receiver에게 너가 요청한 거 이제 이행하겠다는 느낌으로

   FIN bit 를 보낸다.

 

- Receiver가 알겠다고 ACK를 보낸다. 

 

 

[ 요약 ]

- Receiver 가 FIN 보내고 마지막에 ACK (1,4번째)

- Sender 가 ACK 보내고 ,할 거 한 뒤에 FIN   (2,3번째)

 

clnt : 끄자, 너가 꺼 
-> serv : 하던 거만 다 끝내고! 
-> clnt : (기다려줌) 
-> serv : 다 했음 끝내도 됨 
-> clnt : ㅇㅋ 너가 꺼봐 (기다림)

 

요런 느낌

 

 

이것도 설명할 줄 알아야 함

 

 

---

Congestion Control

 

 

Sender가 너무 과하게 많이 or 빨리 보내면

1) Long Delay가 발생하거나
2) Packet Loss가 발생한다. ( Time out / Dup retransmision 으로 감지 가능 )

Flow control같은 경우에는 Receiver가 얼만큼 달라고 말해서 간단했는데
이거는 상황에 따라 계속 변하니까 복잡하긴하다.

 

* Flow control = Sender Receiver 둘 사이의 Buffer 관련

* Congetion    = 해당 네트워크 전체에 대한 처리율(Router)과 관련

 

 

Scenario 1

 

- 무제한 Buffer( = loss X ) Router

- 재전송 없음

- 두 Hosts

 

Q1. 둘 다 반반씩 쓰면 어떻게 되는가?

: 라우터의 활용도가 높아질수록

  Delay가 늘어난다. 활용도가 최대라면 Delay도 최대

 

➡️ 무제한 Buffer는 상상에서만 가능한데, 그것도차 Delay가 많다면 ... ㅠ

 

---

Scenario 2

 

- 제한된 크기의 Router 하나 ( = Loss 발생 )

- 재전송도 해줘야 함

 

+ Application Layer에서는 보내는 것과 받는 것이 같다.

+ 하지만, Transport에서는 [ 원래 보내는 것 + 재전송 ] 까지 해야하므로 APP에서 주는 것보단 양이 많다.

 

📌 Idealization

: Perfect Knowledge

= Sender는 Loss가 나지 않도록, Buffer에 여유공간이 있을 때만 전송한다.

  (언제 여유있는지 알고 보낸다.)

왜냐면 항상 Buffer가 꽉 차있을 때 보내다가 loss가 났기 때문에

 

 

 

 

따라서, 실제로는 Loss가 나서 재전송해야하므로 처리율은 조금 떨어진다. 

 

근데 더 골때리는 건, 우린 Loss가 확인될 때만 재전송하는 게 아니다.

Timeout이 발생해도 재전송을 해야한다.

 

 

 

 

전송 중인데 Timeout으로 똑같은 게 들어가면

즉, Duplicated data가 처리율을 떨어뜨리기도 한다.

 

 

---

Scenario 3

 

- 여러 개의 Hosts

- 여러 Router 

- 제한된 크기의 Router 하나 ( = Loss 발생 )

 

위와 같은 그림으로 이해하면 된다.

 

Q1 .  App 층에서 보내는 양과 Network 층에서 보내는 양이 증가하면?

     > 라우터에 더 많은 양을 차지할 것이기 때문에,

        해당 라우터를 같이 쓰는 다른 Link가 보낼 수 있는 패킷의 양이 줄어든다. 

 

  ex) 빨간색에서 보내는 게 많으면, R2에서 파란색 선이 보낼 수 있는 게 줄어든다.

        거의 처리율이 0까지 간다고 보면 된다.

 

 

 

---

Congestion control Insight

 

 

---

Congestion Control 방법 (2가지)

: Congestion Control 을 위해서는 네트워크나 통신 상황을 알아야 한다.

 

1) End - End Congestion Control

 

1) Segment 보냄

2) ACK 제대로 옴

= 문제가 없다는 것

 

 

Loss 나 Delay가 발생하면 어디에 문제가 있다는 것이다.

+ Network 상황에 대해서는 정보가 따로 없다.

   그냥 ' 문제가 없다면 잘 돌아간다 ' 로 생각함

 

2) Network-assisted Congestion Control

라우터가 Host들에게 Feedback을 준다 ( ex. 지금 보내도 된다. 안 된다 )

 

근데 라우터는 라우팅을 해야하는데 이런 것까지 하기에는 좀 낭비가 있지 않나?

Overhead도 크다고 해서 주로 1번 방법으로 간다고 함

 

 

 

 

(출처)

한동대학교 고윤민교수님 - 컴퓨터 네트워크