TCP

TCP 개요

• 포인트 투 포인트 연결
  • 소켓과 소켓 사이의 연결을 보장합니다. 송신자와 수신자가 1:1로 연결되어 통신합니다.
• 신뢰성 있고, 순서대로 통신하며, 경계가 없음
  • TCP는 데이터의 신뢰성을 보장하며, 데이터가 전송된 순서대로 도착하도록 합니다. 또한, 메시지 경계를 구분하지 않기 때문에 스트림으로 데이터를 전송합니다.
• 슬라이딩 윈도우를 사용한 파이프라인 통신
  • TCP는 슬라이딩 윈도우 방식을 사용하여 데이터를 파이프라인으로 전송합니다. 한 번에 보내는 데이터의 양은 네트워크와 버퍼의 상태에 따라 달라집니다.
  • 예: 네트워크가 혼잡할 경우, 혼잡 제어를 통해 전송하는 데이터 양을 줄입니다. 플로우 제어와 혼잡 제어 메커니즘에 따라 데이터 전송량이 조절됩니다.
• 양방향 통신 및 MSS
  • TCP는 양방향 통신을 지원하며, 대량의 데이터를 전송할 때 사용됩니다. 최대 세그먼트 크기(MSS)에 따라 데이터를 적절한 크기로 분할하여 전송합니다.
• 3-way 핸드셰이크와 연결 지향성
  • TCP는 연결 지향 프로토콜로, 연결을 설정하기 위해 3-way 핸드셰이크 과정을 거칩니다. 연결을 종료할 때는 4-way 핸드셰이크를 사용합니다. 이 과정 때문에 UDP에 비해 오버헤드가 크며, 짧은 데이터를 전송할 때는 비효율적일 수 있습니다.
• 플로우 제어
  • TCP는 플로우 제어를 통해 송신자가 수신자의 버퍼를 초과하지 않도록 합니다. 이를 통해 수신자가 데이터를 효율적으로 처리할 수 있도록 합니다.

 

TCP 세그먼트 구조 

 

 

TCP 세그먼트 헤더 구조

• 헤더 크기: 20바이트
• 시퀀스 번호 (Sequence Number):
  • 세그먼트의 바이트 번호를 나타내며, 단위는 바이트입니다.
  • 전체 데이터 중 현재 전송 중인 데이터의 시작 바이트 번호입니다.
• ACK 번호 (Acknowledgment Number):
  • 수신자가 정상적으로 받은 데이터의 다음 바이트 번호를 나타냅니다.
  • 중복된 ACK가 발생할 수 있으며, 이는 GBN(Go-Back-N) 프로토콜과 유사합니다. 그러나 TCP는 순서가 맞지 않게 도착한 패킷도 일단 저장해 두고 나중에 순서를 맞춥니다.
  • ACK 번호가 항상 존재하지 않을 수 있습니다.
• A 비트: 이 비트를 통해 ACK가 오는지 확인할 수 있습니다.
• RSF (Reset, SYN, FIN):
  • Reset (RST): 연결을 강제로 종료할 때 사용합니다.
  • SYN: 연결 설정을 위한 시퀀스 번호를 동기화할 때 사용합니다. 3-way 핸드셰이크의 일부입니다.
  • FIN: 연결을 종료할 때 사용합니다. 4-way 핸드셰이크의 일부입니다.

1. 순서가 바뀐 패킷 처리:
   • TCP는 순서가 바뀐 패킷이 도착하면 이를 저장해둡니다.
   • 중간에 누락된 패킷이 있을 경우 누적 ACK(cumulative ACK)를 보냅니다. 누적 ACK는 현재까지 순서대로 수신된 마지막 바이트의 다음 바이트 번호를 나타냅니다.
   • 누적 ACK는 수신자가 모든 이전 바이트를 제대로 받았음을 나타냅니다.
2. 타임아웃 및 재전송:
   • 타임아웃이 발생하면 송신자는 누락된 패킷을 다시 전송합니다.
   • TCP는 단일 타이머를 유지합니다. 가장 오래된 확인되지 않은 패킷에 대해 타이머가 설정되고, 이 타이머가 만료되면 해당 패킷과 그 이후의 모든 패킷을 재전송합니다.
3. Selective Repeat (SR)와 TCP의 차이점:
   • SR (Selective Repeat): 여러 개의 타이머를 유지하여 각 패킷마다 개별적으로 타이머를 설정하고 재전송합니다. 이는 정확히 어떤 패킷이 누락되었는지 확인하고 그 패킷만 재전송합니다.
   • TCP: 단일 타이머를 사용합니다. 누적 ACK를 통해 수신자가 어디까지 데이터를 제대로 받았는지 알 수 있으며, 가장 오래된 패킷에 대해 타이머가 만료되면 해당 패킷과 그 이후의 패킷을 모두 재전송합니다. 이는 단일 타이머만 사용하기 때문에 SR보다 더 간단하지만, 더 많은 데이터를 재전송할 수 있습니다.
4. 장점 및 단점:
   • 장점:
     • 단일 타이머를 사용함으로써 구현이 간단하고 타이머 관리의 복잡성을 줄입니다.
     • 누적 ACK를 사용하여 수신자의 상태를 쉽게 추적할 수 있습니다.
   • 단점:
     • 특정 패킷이 누락되었을 때 그 이후의 모든 패킷을 다시 보내야 하므로, 불필요한 재전송이 발생할 수 있습니다.
5. 실제 데이터 전송 예시:
   • 송신자가 패킷 1, 2, 3을 보냈고, 수신자가 패킷 1과 3을 받았지만 2를 받지 못한 경우:
     • 수신자는 패킷 3을 저장하고, 누락된 패킷 2를 기다립니다.
     • 송신자는 패킷 2에 대한 타이머가 만료되면 패킷 2를 재전송합니다.
     • 수신자는 패킷 2를 받으면 패킷 2와 3을 순서대로 처리하고 누적 ACK를 송신자에게 보냅니다.

 

ack 79는 저기까지 잘 받았으니까, 79부터 보내줘! 하는 것임. ack이랑 같이 보내? 

RTT? timeout 시간? 

---

TCP round trip time, timeout

Q:how to set TCP timeout value?

longer than RTT but RTT varies 

too short:premature timeout, unnecessary retransmissions

too long:slow reaction to segment loss 

 

Q:how to estimate RTT? 

SampleRTT: measured time from segment transmission until ACK receipt 

ignore retransmissions

 

SampleRTT will vary, want estimated RTT “smoother" 

average several recentmeasurements, not just current SampleRTT 

 

EstimatedRTT = (1-a)*EstimatedRTT + a*SampleRTT

exponential weighted moving average

influence of past sample decreases exponentially fast

typical value: a =0.125

 

timeout interval:EstimatedRTT

plus “safety margin”

large variation in EstimatedRTT ->larger safety margin

estimate SampleRTT deviation from EstimatedRTT:

DevRTT = (1-b)*DevRTT +b*|SampleRTT-EstimatedRTT| (typically, b= 0.25)

---

TCP reliable data transfer

- TCP creates rdt service on top of IP’s unreliable service

 

• 파이프라인 방식으로 세그먼트를 전송하고, 누적 ACK를 사용합니다.
• 단일 재전송 타이머를 사용하며, 가장 오래된 확인되지 않은 세그먼트에 대해서만 타이머를 설정합니다.

 

IP 통신은 신뢰성 있는 서비스를 제공하지 않는다. TCP는 그러한 IP 위에서 동작기에 rdt를 만든다. 

rdt는 reliable data transfer의 약자이다. 이는 데이터의 신뢰성 있는 통신을 보장해준다. 

데이터의 문제가 있을 시에, 데이터를 다시 보내게 된다. 이를 retransmission이라고 한다. 

데이터를 보낸 후에 ack가 오지 않아 timeout이 발생하는 경우와 동일한(duplicated) ack가 오는 경우이다. 

timeout이 발생하면, 타이머를 다시 동작시키고, 다시 보낸다. 

 

데이터를 송수신할 때 바이트 단위로 나누어 보내게 된다. 이 때 필요한 것이 seq number이다. 

seq # 는 세그먼트의 첫번째 바이트 넘버이다. 가장 오래된 ack 되지 않은 세그먼트에 대해서 timer 가 동작한다. 

time 값은 상황에 따라 변한다. 

 

수신자 입장에서, ack을 보낼 때 중복된 ack이 아닌 다음 ack을 보냈다는 것은 그 앞의 데이터는 잘 받았다는 의미이다.

때문에 송신자 입자에서는 받은 ack까지 모두 정상적으로 보냈다고 처리된다. 때문에 ack 다음 데이터를 보내게 된다. 

또한 SR과 다르게 중간 중간 녹색이 없고, 일련의 데이터 뭉치가 한번에 녹색이 된다. 

=> 뒤에 먼저 온 애들이 있으면 똑같은 ack 이 생긴다.

그러면 앞에 ack이 손실 됐을 확률이 높아서, 동일한 ack을 3번 받으면 time-out 되지 않아도 다시 보낸다.

이를 fast retransmission이라 한다. 

 

TCP 송신자의 동작

1. 중복 ACK와 플로우/혼잡 제어는 무시합니다.
2. 애플리케이션 계층에서 데이터를 받으면:

• 시퀀스 번호(seq #)를 포함한 세그먼트를 생성합니다.
• 시퀀스 번호는 세그먼트의 첫 데이터 바이트 스트림 번호입니다.
• 타이머가 실행 중이지 않다면, 가장 오래된 확인되지 않은 세그먼트에 대해 타이머를 시작합니다. 타이머 값은 계속 변경될 수 있습니다.

   3. 타임아웃이 발생하면:

• 타임아웃을 유발한 세그먼트를 재전송합니다.
• 타이머를 재시작합니다.

요약하면, 이 간단화된 TCP 송신자는 애플리케이션 데이터를 세그먼트화하여 전송하고, 확인되지 않은 세그먼트에 대해 타이머를 관리하며, 타임아웃 시 해당 세그먼트를 재전송합니다.

 

 

이 이미지는 TCP(전송 제어 프로토콜)의 송신 측 동작을 나타내는 상태 전이도입니다. 중앙에 'wait for event'라는 대기 상태가 있고, 여기서 다음과 같은 이벤트들이 발생할 수 있습니다.

• 애플리케이션 계층에서 데이터를 받으면, 새로운 세그먼트를 생성하고 IP 계층에 전송("send")하며, 타이머를 시작합니다.
• 타이머 시간 초과(timeout)가 발생하면, 가장 작은 순서 번호를 가진 확인되지 않은 세그먼트를 재전송하고 타이머를 다시 시작합니다.
• ACK(확인 응답)를 받으면, ACK 필드 값 y와 SendBase를 비교합니다. y가 SendBase보다 크면 (ack가 커졌다면) SendBase를 y+1로 업데이트하고, 확인되지 않은 세그먼트가 있다면 타이머를 다시 시작하거나, 없다면 타이머를 중지합니다.

이 상태 전이도를 통해 TCP 송신 측에서 데이터 전송, 타임아웃 재전송, ACK 처리 등의 동작을 효율적으로 관리할 수 있습니다.

 

 

맨 앞의 노란색, 타이머를 잡고 있는 그 데이터에 대해서 retransfmit 한다. 

받는 쪽에서 window가 있어서, 순서가 바뀌어서 오면 저장해둔다. SR과 차이점은 ACK을 보낼 때 동일한 ACK을 보낸다. 

맨 앞에 애만 다시 보내라고 ack을 보낸다. 작은 뭉텅이가 생기면 그 뭉텅이 다음으로 다시 보내라고 요구한다. 

 

중간에 ack 이 소실되는 경우  + time out 시간이 너무 작은 경우, 120을 2번 보내는데 큰 문제는 없음.

 

 

정상적인 경우에는 ACK를 제대로 받으면서 다음 데이터를 계속 보내면 됩니다.

하지만 중간에 데이터를 못 받는 경우가 생기면 TCP 빠른 재전송(Fast Retransmit) 방식을 사용합니다.

• 타임아웃 기간이 상대적으로 길어 재전송이 지연될 수 있습니다.
• 중복 ACK를 통해 분실된 세그먼트를 감지합니다.
• 송신자가 여러 세그먼트를 연속해서 보내면, 하나라도 분실되면 많은 중복 ACK가 발생합니다.
• 송신자가 동일한 데이터에 대해 3개의 중복 ACK(Triple Duplicate ACK)를 받으면, 가장 작은 순서번호의 확인되지 않은 세그먼트를 재전송합니다.

따라서 TCP 빠른 재전송은 타임아웃 재전송보다 빠르게 분실 데이터를 재전송할 수 있습니다.

---

TCP flow control 

수신자 버퍼만 고려하면 됨. TCP 헤더에 받는 애의 원도우 크기가 있음. 

 

수신자가 송신자를 조절하는거임. 그래서 송신자가 overflow하지 않게 흐름을 제어하는 것이다. 

 

rwnd == free buffer space 

 

송신자는 free buffer space 만큼 윈도우 크기 조절해서 보낸다. ack을 안 받고 보낼 수 있는 사이즈가 rwnd이다. out of order로 와도 저장할 수 있다.

 

수신자 측면에서의 TCP 플로우 제어

• 수신자는 TCP 헤더의 rwnd(receive window) 필드 값을 통해 자신의 남은 버퍼 공간을 송신자에게 알려줍니다.
• 수신 버퍼 크기(RcvBuffer)는 일반적으로 소켓 옵션을 통해 설정할 수 있으며, 기본값은 보통 4096바이트입니다.
• 대부분의 OS에서 TCP 세그먼트 페이로드 크기는 RcvBuffer 크기에 자동으로 맞춰집니다.
• 송신자는 수신자의 rwnd 값을 초과하지 않도록 확인되지 않은("in-flight") 데이터의 양을 제한합니다.
• 이를 통해 수신 버퍼가 오버플로우되는 것을 방지합니다.

요약하면, 수신자가 버퍼 상황을 rwnd 필드로 알려주면 송신자는 이 값을 고려하여 데이터를 전송함으로써 수신측 버퍼 오버플로우를 방지하는 플로우 제어 메커니즘

---

Connection Management

데이터를 주고받기 전에 송신자와 수신자는 "핸드셰이크(handshake)" 과정을 거칩니다:

1. 연결 설정에 동의합니다 (상대방이 연결 설정에 동의했음을 알게 됩니다).
2. 연결 매개변수들에 대해 합의합니다.

이 과정이 끝나면 연결이 설정되고, 데이터를 주고받을 수 있게 됩니다.

제시된 이미지는 핸드셰이크가 완료된 후의 상태를 보여주고 있습니다.

노드(host)와 소켓(socket) 간의 연결이 이미 맺어진 상태입니다. 이제 이 연결을 통해 데이터 전송이 가능해집니다.

 

 

---

TCP 3-way handshake

서로 time-out을 고려해서 3 way를 한다. x+1로 잘 받았다고 알려줘 

이 그림은 TCP 3-way handshake 과정을 보여주고 있습니다. 클라이언트와 서버 간의 연결 설정 과정을 순서대로 설명하겠습니다.

1. 클라이언트는 임의의 초기 시퀀스 번호 X를 선택하고, SYN 비트를 1로 설정한 SYN 메시지를 서버에 보냅니다. (SYNSENT 상태)
2. 서버는 클라이언트의 SYN을 받고, 자신의 초기 시퀀스 번호 Y를 선택합니다. 그리고 SYN 비트와 ACK 비트를 1로 설정하고, ACK 번호는 x+1로 해서 SYNACK 메시지를 클라이언트에 보냅니다. (SYN RCVD 상태) 
3. 클라이언트는 서버의 SYNACK을 받고 서버가 살아있음을 확인합니다. 그리고 ACK 비트를 1로, ACK 번호를 Y+1로 설정한 ACK 메시지를 서버에 보내고 ESTAB(Established) 상태가 됩니다. 이 세그먼트에 데이터도 포함될 수 있습니다.
4. 서버는 클라이언트의 ACK를 받고 클라이언트가 살아있음을 확인하고 ESTAB 상태가 됩니다.

이렇게 3-way handshake를 통해 클라이언트와 서버가 서로를 인식하고 연결을 맺게 됩니다.

 

4 way handshaking 

 

• 클라이언트에서 close() 시스템 호출을 하면 FIN 세그먼트를 서버에 보내고, FIN_WAIT_1 상태가 됩니다. 이 상태에서는 더 이상 데이터를 보낼 수 없지만 받을 수는 있습니다.
• 서버는 FIN을 받고 CLOSE_WAIT 상태가 되며, 아직 데이터를 보낼 수 있습니다. 서버에서 close()를 호출하면 FIN 세그먼트를 클라이언트에 보냅니다.
• 클라이언트는 서버의 FIN을 받고 ACK를 보내고 FIN_WAIT_2 상태로 전환되어 서버의 응답을 기다립니다.
• 서버는 클라이언트의 ACK를 받고 LAST_ACK 상태가 되어 더 이상 데이터를 보낼 수 없게 됩니다.
• 클라이언트는 서버의 ACK를 받고 TIMED_WAIT 상태로 들어가 2*최대세그먼트수명 시간 동안 기다립니다. 이는 연결이 완전히 종료되기를 기다리는 것입니다.
• 시간이 지나면 클라이언트와 서버 모두 CLOSED 상태가 됩니다.

 

중요한 점은 클라이언트의 TIMED_WAIT 상태 때문에 그 소켓은 일정 시간 동안 사용할 수 없다는 것입니다.

이는 아직 네트워크 상에 남아 있을 수 있는 패킷 때문입니다. 내가 보낸 ACK 이 없어질 수 있다.