[컴퓨터망] - TCP 네놈이 뭔데?

TCP는 이제 설명하기 너무 입 아픕니다.

그저 간단하게 설명하자면

데이터의 신뢰성 있는 연결이 가능한 프로토콜입니다.

 

TCP 프로토콜의 특징

1. point- to - point
   1. 하나의 sender는 하나의 receiver와 통신한다.
2. Reliable, in-order byte system
   1. 데이터는 순서대로 applicaton layer로 넘겨지고, 데이터를 byte단위로 처리하기에, message의 맥락을 신경 쓰지 않는다.
3. full duplex data
   1. 데이터 통신을 할 때 양방향으로 흐른다.
4. cumulative ACKs
   1. 데이터의 신뢰성과 정확성을 확보, 안정적인 데이터 전송을 지원
5. pipelining
   1. TCP congetsion, flow cotrol이 window size를 결정함.
6. connection-oriented
   1. 데이터 통신을 하기 전에 Handshaking 과정을 통해 sender와 receiver의 상태를 확인한다.
7. flow controlled
   1. sender는 receiver의 상태를 보면서 전송량을 조절한다.

---

TCP segment 구조

• Source Port(16)
  • 송신측의 포트번호
• Destination Port(16)
  • 수신 측의 포트 번호
• Sequence number(32)
  • 패킷은 여러 개의 서로 다른 경로를 거치면서 전달되기에, 패킷의 순서가 뒤 바뀔 수 있다.
  • 하지만 TCP는 신뢰성 있는 데이터 보장이기에, 수신 측에서 재 조립을 하는 과정이 필요하다.
  • 이때 Sequence number를 이용해서 조립한다.
• Acknowledgement number
  • 수신자가 예상하는 다음 시퀀스 넘버
• length
  • TCP 헤더 크기의 값.
• Flag
  • congestion notification
    • E(ECN) : 송신 측에서 네트워크 혼잡을 감지했을 때 혼잡상태를 알림.
      수신 측에서는 여기를 확인해서 트래픽을 조절함.
    • C(CWR) : 수신 측에서 ECN 필드를 확인하고, 혼잡 상태에 대한 대응,
      1이면 송신측에게 혼잡상태가 해소되었음을 의미.
  • connection management
    • S(SYN) : TCP 연결의 시작을 나타내는 플래그
    • F(FIN) : TCP 연결의 종료를 나타내는 플래그
    • R(RST) : TCP 연결을 강제로 초기화하고 리셋하는 플래그
      오류 발생시 연결을 강제로 끊을 때 사용
  • U(URG) : 긴급한 데이터가 포함된 세그먼트임을 알림, 1이면 URG 포인터 필드가 유효해짐.
  • P(PSH) : 데이터를 즉시 전송하도록 요청하는 플래그, 1이면 상대방에게 데이터를 전송하라는 의미.
  • A(ACK) : 성공적으로 받은 데이터를 확인하는 플래그, 1이면 수신 측이 잘 받았다는 의미.
• window size
  
  • 수신 윈도우의 크기, 이 필드를 확인해서 데이터의 전송양을 조절 -> 네트워크 혼잡 현상을 방지함.

• checksum
  • 헤더 및 데이터의 에러 확인을 위해 사용되는 필드값.
• Urgent pointer
  • 선택적 필드값.
  • URG 플래그가 설정된 경우, 마지막 긴급 데이터 바이트를 가리킨다.

---

TCP의 seq num과 ACK

위 그림을 통해서 ACK를 받으면 바로 다음 턴에 ACK에 해당하는 패킷을 보내줘야 한다.

ACK는 수신측에서 받길 고대하는 seq num이다. 

더 정확하게 말하면 seq num+ data의 크기가 될 것입니다.

---

 

TCP RTT, Timeout

RTT는 패킷을 전송하고 다시 응답을 받기까지 걸린 시간을 의미한다.

TCP는 RTT를 예상해야 합니다.

Timeout값을 적절하게 설정하는 것도 TCP에서 중요하다

• Timeout이 RTT보다 크다면 패킷이 loss는 경우 너무 늦게 반응하여 문제가 생길 수 있다.
• Timeout이 RTT보다 작다면  패킷이 유실되지 않았는데도, 너무 급하게 반응해서 재전송을 하는 문제가 생길 수 있다.

다음과 같은 이유지만 간략하게 소개하겠습니다.

• Congestion Control
• 타임아웃 관리
• 세그먼트 순서화
• 성능 최적화

즉 요약하면 RTT를 예상하는 것은 TCP의 성능을 최적화하기 때문에 꼭 필요합니다.

그럼 어떻게 예상하느냐?

RTT를 추정하기 위해서는 sample RTT를 활용해야 합니다.

 

Sample RTT

송신측에서 데이터를 보내고, 수신 측에서 ACK를 받아 다시 송신 측으로 돌아오는 시간을 측정하여 RTT 값을 추정.

여기서 재전송은 무시합니다.

 

EWMA(Exponential Weighted Moving Average)

기본적으로 a는 0.125로 설정합니다.

Sample RTT값을 신뢰할 수 있다면 a값을 증가시킵니다.

반대로 신뢰할 수 없다면 a 값을 감소시킵니다.

 

 

이렇게 구한 Estimated RTT를 바탕으로 Timeout의 적절한 구간을 정해야 한다.

하지만 바로 적용하는 것은 적절하지 않습니다.

이유는 너무 deep하기에, 우리는 바로 구한 추정치를 적용하지 않고, 추가적인 보정 기술을 적용해서 Timeout을 설정합니ㅏㄷ.

여기서 추가적인 보정 기술이 safety margin을 의미합니다.

DevRTT는 아래와 같이 구합니다.

---

TCP 재전송되는 상황

ACK가 유실된 상황 

• Timeout동안 송신 측은 ACK를 기다리다가 timeout이 발생하면 재전송한다.

ACK가 타임아웃보다 느린 상황

 

 

• 92번 패킷에 대해 ACK 응답이 돌아오기 전에 Timeout이 발생된 상황이다.
• 여기서 TCP ACK의 특징인 culmulative ACK를 볼 수 있다.
• 수신 측은 92번 패킷과 100번을 받았기에, 나는 120번 패킷부터 받으면 된다고 ACK 120을 보내준다.
• 그러면 송신 측은 아 수신 측에서 92번과 100번을 잘 받았으니 120번 패킷을 보내주면 되는 것이다.

cumulative ACK covers for earlier lost ACK

• 수신측에서 92번을 받았지만 92번에 대한 ACK가 유실된 상황이다.
• 여기서 만약 92번을 응답받지 못했다면 100번 패킷을 받더라도 ACK(100)을 보내야 하지만,
  92번 패킷을 받고, 100번 패킷도 무사히 받았기에, 수신 측에서는 ACK(120)을 보낸다.
• 따라서 송신 측은 아 100번 패킷까지 무사히 갔구나!라는 것을 알게 되고, 다음 패킷에 대한 전송을 준비한다.

---

TCP fast retransmit

TCP에서 패킷이 유실된 상황은 아래와 같다.

1. 중복된 ACK가 오는 상황
2. timeout이 발생한 경우

위 상황은 100번 패킷이 loss 되었고, Timeout 동안 기다리고, timeout 발생 시 다시 재전송한다.

하지만 패킷 loss인 상황을 알지만, timeout동안 기다리는 것은 어떻게 보면 비효율적일 수 도 있다.

그래서 그림을 보면 timeout까지 기다리지 않고, 중복된 ACK가 와서 패킷 loss를 추정하고 재전송하는 것을 볼 수 있다.

이러한 방식을 TCP fast restransmit라고 한다.

---

😀요약

• TCP는 데이터의 신뢰성을 보장하는 연결에서 사용하는 프로토콜이다.
• TCP 세그먼트의 구조는 UDP 세그먼트보다 복잡하다.
  • 연결지향성, 흐름제어, 혼잡제어, 신뢰성 같은 기능들 때문에 헤더가 복잡하다.
  • 반대로 UDP는 위의 기능들을 제공하지 않기에, 헤더가 간단하다
• TCP 통신에서, ACK는 다음턴에 받을 고대하는  seq num이다. 
• TCP에서 RTT를 예측해야 하는 이유는 다음과 같다.
  1. Timeout이 RTT보다 크다면 패킷 loss 하는 경우 너무 늦게 반응해서 문제가 생길 수 있다.
  2. Timeout이 RTT보다 작다면 패킷이 유실되지 않았는데도, 너무 급하게 반응해서 재전송하는 문제가 생긴다.
• TCP는 재전송을 의심해야 하는 상황이 2가지이다.
  • 패킷 loss, timeout
    • 재전송의 원칙은 timeout까지 기다렸다가 응답이 오지 않을 시 재전송을 하는 것이지만,
      중복된 ACK가 계속 온다면 재전송하는 fast retransmit 방법도 있다.