전송계층(2) _ TCP

 TCP 

point-to-point

한 쌍의 프로세스 간의 통신 권장한다 (소켓 한쌍끼리의 통신을 책임)

 

reliable, in-order byte

하나도 유실되지 않고 전송되면서, 순서를 보장한다

 

pipelined

한꺼번에 전송한다

 

sender & receiver buffers

두 버퍼를 동시에 가지고 있다

 

full duplex data

connection-oriented

 

flow controlled

receiver 버퍼가 받을 수 있는 만큼 전송한다

congestion controll

내부 네트워크가 받을 수 있는 만큼 전송한다

---

 각 계층 전송단위 

출처: https://github.com/kyum8562

Application Layer: Message

Transport Layer: Segment

Network Layer: Packet

Link Layer: Frame

---

 TCP segment 헤더 구조 

1️⃣ Port Number

• source 16bits, dest 16bits
• 포트 번호: 0 ~ 65536 (2^16)
• 한 컴퓨터에서 동시 동작할 수 있는 어플리케이션 갯수: Maximum 2^16

2️⃣ Seq Number

• 세그먼트 데이터의 첫 바이트의 byte stream number 의미
  • 총 100바이트의 데이터 전송 상황, 첫 번째 세그먼트 0~9번 바이트, 두 번째 세그먼트 → 10~29번 바이트 가정
    • 첫 번째 세그먼트의 seq# ⇒ 0
    • 두 번째 세그먼트의 seq# ⇒ 10

3️⃣ ACK Number

• TCP에서의 ACK Number는 다음 번에 받을 세그먼트의 seq Number
  • ACK 10 → 9번 세그먼트까지 잘 받았고 10번 세그먼트 줘~
  • GBN의 ACK는 Cumulative ACK! (10번까지 잘 받았어!)

4️⃣ Checksum

• 에러 확인용

5️⃣ Receive window

• 현재 receiver가 수신할 수 있는 바이트 수 (receiver 버퍼의 남은 공간)

---

 TCP의 seq. #'s 와 ACKs 

• 모든 클라이언트와 서버는 sender이자 receiver
• 메시지를 보낼 때마다 서로 seq 번호와 ACK 번호를 전송한다

⇒ TCP에서는 seq와 ack가 각각 Host에서 동시에 사용되고 통신이 수행된다

 

❓데이터를 받으면 바로 ack를 보낼지, 보낼 데이터가 있을 때까지 기다렸다가 seq와 ack를 보낼지?

- 항상 각자(HostA 와 HostB) 할 말(보낼 데이터) 있다

- tcp 권고

    - "데이터가 들어와서 바로 ack를 보내기보다는 기다렸다가 ack를 해"

    - 보낼 데이터가 생길 수 있음 → 더 효율적. 이득임

    - 실제 데이터가 세그먼트 하나만 오는게 아니라 파이프라인을 통해 쏟아져 들어옴.
     쏟아져오는 데이터를 하나하나 ack 해줘야하는건 부담이 클 수 있음.

     tcp는 cumulative ACK 이기 떄문에 잘 받고 있다가 마지막에 잘 받은 ack만 잘 보내면 됨

---

 Timeout (function of RTT) 

loss를 확실히 판단하면서, timeout value를 작게 잡기 위한 방법

• RTT만큼 설정? → 변수 존재
  • 전송 경로(router)가 다름
  • Queueing Delay

• Estimatied RTT
  • 측정한 RTT의 평균 값
  • Estimated RTT = (1-a) * Estimated RTT + (a * sample RTT)
  • ⚡ 실제 RTT에 비해 Estimated RTT는 매우 작음 → 타임아웃이 왕창 발생할 수 있음

⇒ 따라서 여유를 더 준다!

DevRTT = (1-B) * DevRTT + B * |SampleRTT - EstimatedRTT| (Typically, B = 0.25)

Timeout Interval = EstimatedRTT + (4 * DevRTT)

 

중요한 것은 타임아웃을 잡되 여유를 더해준다는 것이다

---

 TCP reliable data transfer 

TCP는

• RDT 서비스를 활용한다
• Pipelined segment를 이용한다
• Cumulative acks를 활용한다
• Single Timer를 이용한다
  • GBN의 timeout → windows size 안의 모든 data 요청
  • TCP는 해당 segment만 요청
• timeout이 발생하거나 duplicate acks가 발생할 때 재전송한다

---

 TCP _ retransmission scenarios 

 

 

ACK가 유실된 상황

• A의 seq# 는 92
  • 92번 ~ 99번 데이터 전송
• B는 92~99번 데이터 잘 받아서 올리고 ACK 100을 보냄
• 근데 ACK 100 유실
• A에서 92번 데이터 timeout 발생
• 재전송

 

 

 

 

 

 

 

 

 

 

 

 

---

 

ACK가 전송되는 중에 timeout이 발생

• A가 seq# 92와 seq# 100인 데이터 전송
• B는 둘 다 잘 받아서 위로 올리고 ACK 100과 ACK 120 보냄
• A에서 ACK 100이 도착하기 전에 timeout 발생
• seq# 92 데이터 재전송
• B는 120번 이후의 데이터를 기다렸으나 92~99번 데이터가 왔음
  • 버리고 다시 마지막으로 잘 받았던 ACK 120 다시 보냄

 

 

 

 

 

 

 

 

---

 

 

ACK가 유실되었지만
그 다음 ACK가 정상 도착한 상황

• A가 seq# 92와 seq# 100인 데이터 전송
• B는 둘 다 잘 받아서 위로 올리고 ACK 100과 ACK 120 보냄
• 이때 ACK 100은 유실되고 ACK 120은 도착
• A는 ACK 120번을 받아서 다 잘받았다고 판단하여 send 버퍼에서 119까지 데이터 버림

 

 

 

 

 

 

 

---

 Fast retransmit 

출처: https://github.com/oth54477

timeout 전 loss packet 판단

• Three Duplicated ACK
• 세 번 복제된 ACK가 발생할 경우 유실로 판단하고 빠르게 재전송
  • ACK 9 // ACK 10 // ACK 10 // ACK 10 // ACK 10
  • TCP는 데이터의 순서가 보장됨
  • 10번 패킷이 유실되면 그 다음 도착하는 11, 12, 13 …의 패킷은 모두 ACK 10으로 응답되고 잘 받은 11,12,13 은 버퍼에 저장해놓고 있다가 sender가 다시 seq10을 재전송해서 잘 받았을 때 저장해둔 패킷과 함께 application layer로 올려보낸다

• 꼭 필요한 기능은 아니나 효율성을 높이는 최적화 기법 중 하나