[Lecture] Connection-oriented transport: TCP

TCP : Overview

• point-to-point 

one sender, one receiver

하나의 sender와 receiver(딱 한쌍)의 통신을 권장한다 (단일 소켓 통신 패턴)

엄격히 말하자면, process사이 소켓 한쌍 사이의 통신을 말한다

 

• reliable, in-order byte stream

no message boundaries

TCP는 스트림 지향 프로토콜로, TCP는 데이터를 메시지로 나누어 주지 않고, 연속된 스트림으로 전송한다. TCP는 데이터를 세그먼트로 나누어 전송하며, 수신측에서는 이 세그먼트를 재조립하여 완전한 데이터를 얻게 된다. 이 과정에서 데이터의 경계를 명확히 지정하지 않는다. 

 

유실되지 않고, 순서대로 간다

 

• pipelined

TCP congestion and flow control set window size

 

• send&receive buffers

send buffer의 존재 이유 : 패킷을 재전송하기 위함

• Send buffer는 데이터를 송신자 측에서 일시적으로 저장하는 공간이다.
• TCP는 데이터를 메시지 단위로 보내는 것이 아니라, 바이트 스트림 단위로 전송한다. Send buffer는 어플리케이션이 전송한 데이터를 임시로 저장하고, 이를 네트워크로 전송하기 위해 사용된다.
• 패킷이 손실되거나 재전송이 필요한 경우, send buffer에 있는 데이터를 이용하여 송신자가 필요한 패킷을 재전송할 수 있다.

receive buffer의 존재 이유 : out of order로 오는(순서가 뒤바뀐) 패킷들을 저장하기 위함

• Receive buffer는 수신자 측에서 도착한 데이터를 일시적으로 저장하는 공간이다.
• TCP는 데이터를 스트림으로 처리하며, 패킷이 네트워크를 통해 도착할 때마다 수신자는 해당 데이터를 receive buffer에 저장한다.
• 패킷이 순서대로 도착하지 않아도, receive buffer를 사용하여 데이터를 올바른 순서로 재조립할 수 있다. Out-of-order로 도착한 패킷들을 수신 버퍼에 저장하고, 정렬된 순서대로 어플리케이션에 전달된다.

 

하지만 사실, 웹브라우저와 서버 모두 receiver이자 sender이다

A process		B process
TCP sender buffer	=segment=>	TCP receiver buffer
TCP receiver buffer	<= segment =	TCP sender buffer

 

• full duplex data

위에서 말한것처럼 하나의 process는 receiver이자 sender이므로 데이터가 양방향으로 전달된다

bi-directional data flow in same connection : 동일한 연결에서 양방향 데이터 흐름

MSS : maximum segment size

 

• connection-oriented

handshaking(exchange of control masgs) init's sender, receiver state before data exchange

(다음주에 수업할 예정)

 

• flow controlled

sender will nowt overwhelm receiver

(다음주에 수업할 예정)

 

• congestion controlled

내부 네트워크가 받을 수 있도록 조정한다

(다음주에 수업할 예정)

 

TCP segment structure

 

src port, dest port : 16bit

seq number

ACK

Receive window : (상대방이 많이 보내는 것을 방지하기 위해) 빈공간의 크기를 report해준다 

 

 

 

 

 

 

 

 

 

Application 전송단위				message	[header/data]
Transport 전송단위			segment	header	data(message)
Network 전송단위		packet	header	data(segment)
Link 전송단위	FRAME	header	data(packet)

 

내부 data에 어떤 내용이 들어가 있는지 상관없다. 우린 header만 가지고 활동할 것이기 때문 ! 따라서 header에 집중해야한다

 

TCP seq# and ACKs

seq : byte stream number of first byte in segment's data

data의 first byte number의 정보를 알려준다

ACKs: seq# of next byte expected from other side; cumulative ACK

cumulative ACK이지만, ACK10은 9번까지 완벽하게 받았으니, 10번이 올 차례라는 뜻을 담고 있다 (Go-back-N과의 차이점)

 

!! 서로 하고 싶은 말만 한다 !!

C라는 char 하나를 보내려고 한다

1) Seq=42, ACK=79, data 'c'

window size에 따라 받은 data의 first byte번호가 42번이라는 뜻이다

78번까지 잘받았으니 79번을 넘겨주라고 요쳥하는 것이다

 

2) Seq=79, ACK=43, data 'c'

79번을 넘겨주라고 요청했기 때문에(79~)의 데이터를 넘겨준다. data의 first byte number가 79이므로 Seq에 79가 쓰인다

A로부터 42까지 잘 받았으니 43번을 넘겨주라고 요청하는 것이다

 

 

 

 

(지금은 사진에 화살표가 되어있기 때문에 어디서 어디로 보낸지 알 수 있는 것이다)

Q. 그럼 보내는 메세지가 B가 만든건지, A가 만든건지 어떻게 알 수 있을까? 

A. Header를 통해 확인한다 ( 대부분 통신 프로토콜은 메시지의 헤더 부분에 송신자와 수신자에 대한 정보를 포함한다 )

 

Q. 메세지가 쏟아져서 올텐데, 메세지에 대해서 하나씩 ACK답을 보내야할까?

A. 그래서 데이터가 들어오면 바로 즉석에서 ACK를 보내지 않고 약 500ms 이후에 보내라고 권고한다.

지연 ACK를 통해 데이터를 수신한 후에 일정 시간 동안 대기하다가 ACK를 보내면, 여러 개의 작은 패킷이 도착하는 경우에도 하나의 ACK로 응답할 수 있다. 이로써 패킷의 수를 줄이고 효율적인 통신이 가능하다.

 

Timeout (function of RTT)

TCP는 RTT보다 길면 timeout시킨다

* RTT : "Round Trip Time(라운드 트립 타임)"의 약어로, 네트워크에서 메시지가 송신자에서 수신자로 이동하고 다시 수신자에서 송신자로 돌아오는 데 걸리는 총 시간을 지칭한다.

 

A와 B사이 소켓통신에서 RTT가 고정되어있지 않다. 

ㄴ A와 B를 지나치는 경로가 다 틀리고, queueing delay(명절때 차막히는 현상과 유사)가 각기 다르기 때문에 RTT가 다르다. 아래 표를 보면 편차가 심하다는 것을 확인할 수 있다

그래서 보정한 RTT를 만들 것이다.

EstimatedRTT = (1-a)*EstimatedRTT(축적된 RTT값) + a*SampleRTT(측정한 값) // a = 0.125

ㄴ 이동편균으로, 최근에 나타난 RTT의 경향성을 통해 RTT를 추정한 것

 

실제로 우리가 사용하는 Timeout값은

TimeoutInterval = EstimatedRTT + 4*DevRTT(마진)

마진을 붙인값이다

 

TCP reliable data transfer

• TCP creates rdt service on top of IP's unreliable service
• Pipelined segments : 파이프라인 방식으로 세그먼트를 전송
• Cumulative acks : 누적확인 응답
• TCP uses single retransmission timer : 재전송을 위해 단일 타이머 사용
  • Go-back-N처럼 Timer를 하나 사용한다. Go-back-N은 문제가 생긴 패킷부터 뒤에 있는 것까지 다시 보낸다면, TCP는 문제가 있는 segment만 재전송한다
    • • Go-Back-N:
        • Go-Back-N은 주로 데이터 링크 계층에서 사용되는 프로토콜로, 데이터 링크 계층에서는 "프레임" 또는 "패킷"이라는 용어를 사용한다
      • TCP:
        • TCP는 전송 계층에서 동작하는 프로토콜이므로, 전송 계층에서는 "세그먼트"라는 용어를 사용한다
• Retransmissions are triggered by
  • timeout events
  • duplicate acks
• Initially consider simplified TCP sender:
  • ignore duplicate acks
  • ignore flow control, congestion control

 

TCP sender events

TCP : retransmission scenarios

 

Host A가 (92~99)segment를 보낸다

Host B의 ACK 100이 유실됐다

해당 segment가 timeout이 돼서 재전송한다

Host B입장에서 같은 segment가 두개가 들어왔기 때문에 drop한다

Host B가 ACK100을 보낸다

(수신자는 중복된 요청에 대해서도 이미 받은 세그먼트에 대한 중복 ACK를 보내게 된다)

 

 

 

 

 

 

 

 

ACK를 보내고 있는 중에 timeout이 발생했을 때

Seq=92, 8bytes data만 재전송한다

 

 

 

 

 

 

 

 

 

 

segment유실을 아는 경우 : timeout

ACK = 120이어도 sender를 다 버려준다

그래서 권고사항 : delayed ack

 

segment유실을 아는 경우1 : timeout

하지만 timeout은 너무 오래 걸린다

 

segment유실을 아는 경우2 : fast retransmit

세그먼트를 잘 받지 못했을때, 중복된 ack를 보내게된다

ACK9 ACK9 ACK9 ACK9 (3 step) 특정번호가 연속으로 홍수가 될 때

유실로 판단해도 문제가 없어 timer가 터지기 전에 미리 전송하는 것을 권고한다