[ 네트워크 ] 13. Transport layer : TCP

 

TCP

: 안전하고 정확한 데이터 전송을 해주는 프로토콜이다.

 

 

📌 전반적인 기능

- Reliable하며, 순서가 맞춰진 상태로 정보를 받는다.

 

- Cumulative ACKs를 사용한다.

   ex) ACK(n) : 0번부터 n번까지는 다 받은 상태다. = 이제 (n+1)번째 받을 준비를 하겠다.

 

- Connetion Oriented 소통을 한다.

   ➡️ handshaking 을 통해서 Sender와 Receiver 상태를 설정한 뒤 통신한다.

 

- Connetion이 되었다면, 양방향 통신이 가능하다.

 

- Pipelining 기능이 있어서, Congestion + flow control 이 가능하다.

   ✚ flow control : Sender가 너무 과하게 메시지를 보내지 않는 것

 

 

📌 TCP segment 구조

(작은 네모 세로로 하나가 4bytes임 )

 

1. src / dest port #

: 어디로 와서 어디로 가는지 알려준다.

 

 

2. Seq #

: 하나의 파일은 여러 패킷으로 나누어져서 온다. 

만약 파일의 크기가 2000bits인데, 한 패킷에 담을 수 있는 데이터의 크기는 100bits이라고 해보자.

 

첫 패킷은 어디서 시작하는가? 1번 bits

두 번째 패킷은 어디에서 시작하는가?  101번 bits

➡️ seq #는 받은 패킷이 파일 안에서 시작하는 offset 을 나타낸다.

 

 

 

3) ACK #

: Sender : "너가 이걸 잘 돌려주면, 너가 #번까지 잘 보관하고 있다는 걸로 알고 다음 패킷도 줄게"

 Receiver : "#까지 잘 보관하고 있으니까, 그 다음 패킷을 줘 "

 

 

4) Header length w/ some flag

: 어디까지가 헤더고, 어디부터가 데이터인지 나타내준다

* 4bits 단위로 count

 ex) 20bits만 헤더임 or 28bits까지가 헤더임. = len 5 , len 8

      ➡️ 주로 options 가 헤더가 되냐 마냐에 따라서 나뉘는 것 같다.

 

Flag는 총 8개가 있다.

- 1,2번째 칸 ( C,E ) = Congestion Notification. 

- 4번째 칸  ( A ) = ACK

- 6,7,8 칸 = RST(리셋) , SYN(동기화), FIN(끝)   

 

3,5는 pass

 

4-1) receive window

: receiver 가 몇 바이트를 받는지 나타내준다.

➡️ Flow control 할 때, 이 곳의 정보를 참고하여 움직인다.

 

 

5) Checksum

: 받은 데이터에 error가 있는지 판단해준다.

 

 

---

 

 

 

- 초록색 : ACK를 받은 상태

- 노란색 : 보냈지만 ACK를 받지 못해서, 아직 send buffer에 남아있는 상황 ( 재전송해야 할 수도 있으니까 )

 

 

 

 

- Host A : offset 42에서 시작하는 거 보내는데,  79번째 위치로 받을 준비하고있다. 데이터는 C ( 1bit ) 

 

- Host B : offset 79로 준다. [ 42에서 1bit 넣어서 ] 43번 째 위치로 받을 준비하고있다.  데이터는 C (1bit) 

 

➡️ Receiver가 날리는 ACK # = Sender's Seq # + size of Data

 

---

Packet Timeout

 

 

Timeout 시간을

- Too Short ➡️ ACK 보내는 중에 Timeout 발생 ➡️ 불필요한 재전송

 

- Too Long ➡️ 패킷 Loss 발생 시에 대응하기 너무 느리다.

 

➡️ 결론  : RTT 시간보다는 길게

              > 문제점 : RTT시간은 항상 다른데??

 

 

 

 

 

기본적으로 걸리는 RTT보다는 시간을 조금 더 많이 준다.

이거도 넘으면 Timeout으로 치겠다.. 이런 거임

 

가장 최근에 나온 건 아래와 같다~

---

TCP 연결에서 Sender / Receiver  Diagram

 

그림 말고 글로 보자

 

어려운 내용은 없다 Pass

 

---

Receiver 

 

 

 

Case 1) Expected  Packet들이 순서대로 들어온 경우

➡️ 약간 기다렸다가 ACK 를 보낸다.

 이유 : Cumulative ACKs를 사용하기 때문에, 하나 받자마자 보내는 게 아니라

           가장 마지막으로 받은 놈만 ACK 보내면 여러 동작을 할 필요가 없기 때문이다.

 

⚫️ 정상적인 데이터 전송

 

 

Case 2) Expected  Packet이 순서에 맞게 들어왔고, 다른 Segment는 ACK 대기

➡️ 바로 ACK 전송

= 두 개가 한 번에 처리된다.

 

⚫️ 한 번에 여러 세그먼트 처리

 

Case 3) Expected 보다 더 높은 Packet이 들어왔다.

➡️ 중복된 ACK를 그냥 전송하되, 그 안에 어떤 Seq # 가 들어와야하는지 알려준다.

 

⚫️ 손실이나 순서 문제 발생된다.

 

 

Case 4) Expected 보다 더 높은 Packet이 들어와서, 그에 대한 GAP을 채워주는 Packetdㅣ 왔다.

➡️ 바로 ACK 전송, 필요한 Seq가 가야할 자리로 보낸다.

 

 

⚫️ 순서 안 맞는 문제 보정

 

---

 

Retransmission - scenarios

 

Receiver측에서 보내는  ACK가 보내지다가 Lost 되는 경우다.

= 

 

[ Event ] -  Receiver가 ACK 보내는 중에 Lost 된다면

[ Action ] - Sender에서 다시 보내준다.

 

 

 

Timeout이 너무 짧을 때

 

[ Event ] -  여러 개의 ACK 가 도착하기도 전에 Timeout이 발생했다.

[ Action ] - 1. 시간이 지나더라도 그 여러 개의 ACK를 받고 SendBase를 기록해둔다.

                    2. Sender가 여러 개 중에서 첫 번째 패킷을 보내준다. 

                    3. 이미 Receiver 쪽에서 받았음 + 어디까지 받았고 어디서부터 보내야하는지 SendBase에 있음

                    4. 패킷 하나만 ACK 받아도 그냥 SendBase가 가장 큰 값으로 뛰어 넘어간다.

 

 

 

📌 TCP fast retransmit

 

[ 조건 ]

똑같은 Data에 대해서 3개의 ACK가 더 온다면

 

= 계속 줬는데도 ACK가 같게 오면 잘못된거니까

[ ACTION ]

[ (unACK) && ( Smallest seq #) ] 인 패킷을 찾아 보낸다.

 

 

 

(출처)

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