[11월07일]Chapter 3 - transport: TCP

TCP: Overview (RFCs: 793,1122,1323,2018,2581

• point-to-point : 하나의 sender와 하나의 receiver만 연결
• 신뢰할 수 있는 바이트 스팀
• pipelined : TCP 혼잡 및 흐름제어(flow control) -> bulk로 오기 때문
• full duplex data : 보내기 받기 동시에 가능, MSS - 최대 세그먼트 크기

• simplex : sender는 보내는 역할만 할 수 있고 receiver는 받는 역할만 할 수 있음
• half duplex : 보낼때는 보내기만 할 수 있고 받을때는 받기만 할 수 있음

• connection-oriented : 데이터를 교환하기 전에 sender와 receiver사이의 handshaking(제어 메시지 교환)이 있어야 함 
• flow controlled : sender가 보내는 양이 receiver가 받는 양보다 많아서 손실이 일어나서는 안됨

---

TCP segment structure

• source port# : 출발지 포트 번호 - 16bit
• dest port# : 목적지 포트 번호 - 16bit
• sequence number : 순서번호 필드 - 32bit
• acknowledgement number : 확인응답번호 필드 - 32bit -> 데이터 byte만큼 번호를 늘림
• head len : 헤더 길이 - 4bit
• not used : 사용하지 않음
• U/A/P/R/S/F : 플레그 필드 - 6bit
• receive window : flow control에 사용됨, 이는 수신자가 받아들이려는 바이트의 크기를 나타내는데 사용 - 16bit
• options : 선택적이고 가변적인 길이

---

TCP sequnce numbers, ACKs

• sequnce numbers : 세그먼트에 대한 순서번호는 세그먼트에 있는 첫 번째 바이트의 바이트-스트림 번호
• acknowledgements : 호스트 A가 자신의 세그먼트에 삽입하는 확인 응답 번호는 호스트 A가 호스트 B로부터 기대하는 다음 바이트의 순서번호
• ex) sender에서 패킷을 1000바이트 단위로 보낼 때 가장 첫 번째 바이트는 0으로 설정되어 있다면 처음 sequence number는 0이 되고 그 다음 패킷의 sequence number는 1000이 된다. -> receiver에서 패킷을 받았다면 receiver또한 응답 패킷을 보내게 되는데 이는 받은 패킷의 바로 다음 바이트의 번호를 ACK로 정하여 보낸다.(플레그 중 A를 설정)
• 여기서 이전 시간에 언급했던 데이터 딜레이 같은 것이 발생하여 패킷의 순서가 섞일 경우 두 가지 방법으로 해결 할 수 있다.

1. 순서가 안맞는 패킷이 들어왔을 시 버림 : 수신자 설계를 단순화 할 수 있음
2. 순서가 안맞는 패킷을 보유(buffer)하고 있다가 기다리던 순서의 패킷이 오면 함께 app으로 보냄 : 네트워크 밴드폭 관점에서 효율적이고 실제로도 취하는 방식

---

Telnet

 

• client와 server간의 데이터를 송수신 할 때 보낸 데이터를 다시 반송하여 보내주는 것
• TCP순서와 확인응답 번호를 설명하는데 편하기 때문
• seq = 42, ACK = 79, data = 'C'인 한 바이트의 패킷을 보내면 수신측에서는 ACK에 따른 seq번호인 79, 받은 seq번호의 다음 seq번호인 ACK = 43, 그리고 데이터를 반송하여 수신되고 처리되었음을 나타내주기 위해 data = 'C'
• 송신 측에서는 이 패킷을 받은 후 seq=43, ACK = 80을 보낸 후 대기 -> 보낼 데이터가 없어도 ACK는 보내고 대기해야 함

 

---

TCP round trip time, timeout

• roundtrip : receiver까지 갔다가 돌아오는 시간(RTT) -> 이 RTT는 timeout시간보다 느슨하게 설정하는 것이 좋음

• 너무 짧게 설정 : 쓸데없는 재전송이 자주 생김
• 너무 길게 설정 : segment loss에 대한 반응이 느림

• sample RTT : 패킷을 보내고 긍정 확인 응답을 받을 때 까지의 시간 -> 전송마다 달라질 수 있음

• EstimatedRTT(새로운 RTT) : 이전의 EstimatedRTT와 현재 RTT의 가중적인 평균으로 구할 수 있음
• α값은 0.125(1/8)정도가 권장하는 값이며 다른 값을 설정할 수도 있음

 

• α값이 커질수록 EstimatedRTT의 값은 급변
• RTT값을 적절하게 포함한 평균값을 사용하는 것이 중요(smooth)

• DevRTT : sampleRTT와 EsrimatedRTT값 차이의 EWMA

 

• SampleRTT가 EstimatedRTT로부터 얼마나 많이 벗어나는지에 대한 예측
• SampleRTT값이 어떠한 변화도 없다면 DevRTT는 작게 될 것이며, 그렇지 않다면 DevRTT는 클 것이다.
• β의 권장값 : 0.25

• 그렇다면 타임아웃 주기는 어떻게 설정하는가?

 

---

 

TCP의 신뢰적인 데이터 전달

• rdt(reliable data transfer sevice)제공
• 데이터 손상x, 손실이나 중복x, 순서유지 보장
• 데이터 전송 시 : seq#를 포함한 세그먼트 생성(패킷의 가장 첫 번째 바이트의 번호) -> 타이머 실행(이미 실행중이라면 x) -> 가장 오래 ACK를 받지 못한 세그먼트가 타이머(만료간격 : timeoutinterval)
• 시간초과 시 : 시간초과한 세그먼트를 재전송
• ACK된 만큼 window이동 -> timer를 윈도우 가장 앞에서 재실행
• TCP sender

• TCP: retransmission scenarios

 

• ACK가 손실난 경우 -> timeout이 발생한 후 재전송

• ACK에 딜레이가 발생하여 timeout이 발생 -> 재전송을 하지만 receiver에서는 이미 받은 패킷은 무시 후 가장 최근에 ACK응답을 재전송
• ACK또한 중복되면 무시

• 두 개의 세그먼트를 동시에 보냈는데 ACK 100번은 손실되고 ACK 120번만 수신된 경우 -> ACK 120번이 수신된것만 확인하면 이전의 세그먼트들은 모두 수신 완료된 것으로 판단

---

TCP ACK generation [RFC 1122, RFC 2581]

• 다음 세그먼트가 있을 경우 사실 ACK를 매번 보낼 필요가 없어짐
• ACK delay를 주어 일부러 느리게 줌
• 순서가 바뀐경우 ACK를 재전송하면 원래순서의 데이터를 받을 수 있음

이벤트	TCP수신자 동작
기다리는 순서번호를 가진 '순서가 맞는' 세그먼트의 도착, 기다리는 순서번호까지의 모든 데이터들은 이미 확인응답 됨	지연된 ACK. 또 다른 '순서가 맞는' 세그먼트의 도착을 위해 500msec까지 기다린다. 만약 다음 '순서에 맞는' 세그먼트가 이 기간에 도착하지 않으면, ACK를 보낸다.
기다리는 순서번호를 가진 '순서가 맞는' 세그먼트의 도착. ACK 전송을 기다리는 다른 하나의 '순서에 맞는' 세그먼트가 있음	즉시 2개의 '순서가 맞는' 세그먼트들을 ACK하기 위해, 하나의 누적된 ACK를 보낸다.
기다리는 것보다 높은 순서번호를 가진 '순서가 틀린' 세그먼트의 도착. 격차가 발견됨.	즉시 순서번호가 다음의 기다리는 바이트(즉, 격차의 최솟값)를 나타내는 중복 ACK를 보낸다.
수신 데이터에서 격차를 부분적으로 또는 모두 채우는 세그먼트의 도착	즉시, ACK를 보낸다. 단, 그 세그먼트가 격차의 최솟값에서 시작한다고 가정.

 

---

TCP fast retransmit

• 빠른 재전송 :아무것도 못 받는 경우 Timeout이 걸리는데 이때 재전송하는 것이 아니라 sender가 ACK를 3개 연속으로 받으면 재전송

 

---

TCP flow control(흐름제어)

• application이 데이터를 읽는 속도가 비교적 느리다면, 송신자가 점점 더 많은 데이터를 빠르게 전송함으로써 연결의 수신 버퍼에 아주 쉽게 오버플로우를 발생 시킴
• 이를 방지하기 위해서 application에게 흐름제어 서비스를 제공 - app으로의 전달과 app이 읽는 속도를일치시키는 서비스
• buffer가 존재하지만 결국 손실되는 경우가 생김

• receiver는 receiver-to-sender의 TCP헤더에 rwnd를 포함시켜 사용가능한 buffer를 알림(buffer중 일부만 rwnd로 사용)
• 데이터의 양을 수신자의 rwnd의 값으로 제한
• 수신 오버플로우가 발생하지 않도록 보장

---

Connection management

• 데이터를 송/수신하기 전에 receiver와 sender간의 handshake가 필요 -> 연결에 각자 동의
• 2-way handshake

• sender가 연결 요청 -> receiver가 응답 -> 데이터 전송 시작

• 2-way handshake failure scenarios

• 연결응답 전에 연결요청을 다시 시도 한 경우

• 연결응답 전에 재요청 후 연결되기 전에 데이터를 보낸경우

• 3 way-handshake

1. 클라이언트 측 TCP는 서버 TCP에게 특별한 TCP 세그먼트(SYN 플레그 비트를 포함)를 전송(SYN 세그먼트)
2. 연결 승인 세그먼트를 수신하고 클라이언트와 서버는 각자 데이터를 포함하는 세그먼트를 보낼 수 있음

• TCP 3-way handshake: FSM

• closing a connection : 클라이언트와 서버가 각각 연결을 닫음, FIN bit가 1인 세그먼트 전송

• Closed는 클라이언트, 서버 양쪽에서 모두 보내고 응답했을때 가능