3.5 connection-oriented transport : TCP

<TCP>

- point-to-point : 하나의 sender -> 하나의 receiver

- reliable, in-order byte stream : 순서에 맞춰 전송

- TCP congestion, flow control이 window size 결정

- bi-directional data flow : 양방향 통신

- handshaking : data exchange하기 전 

-flow controlled

 

 

 

 

 

 

<TCP segment structure>

- segment : transport layer에서 전송되는 단위

- sequence number : 전송되는 data 몇 byte째 인지

- acknowledgement number : 몇 번째 byte를 받아야 하는지

- checksum : flag

 

 

* 순서대로 들어오지 않는 segment를 어떻게 처리할까?

1. Go-Back-N처럼 나중에 다 재전송(비효율적)

2. 재전송 받으면 receiver에서 segment가지고 있다가 순서대로 조립해서 application layer에 올리는 방법

 

 

 

[TCP RTT(round trip time)]

timeout시간을 얼마로 설정해야할까? -> RTT sampling해서

-> 너무 짧으면 불필요한 재전송 많아지고 너무 길면 segment loss에 대해 늦은 대응

- EstimatedRTT + safety margin(조금 더 여유시간)으로 timeout interval 결정

 

 

 

 

 

 

 

 

<reliable data transfer>

- pipelined segments : 연속적으로 계속 보냄

- cumlative ACKS

 

* retransmission하는 경우

- timeout 됐을 때

- ACK이 여러 개 도착했을 때

duplicate ACKS, flow control, congestion control은 여기서 무시하기로 한다

 

 

[sender]

- sequence number를 포함한 segment를 만든다

- sequence number는 첫 번째 data byte

- timeout이 되면 segment 재전송하고 timer 재시작

- ACK 받지 못한 segment일 때, 해당 segment update하고 timer 시작

 

 

 

[TCP ACK generation]

 

(receiver event -> TCP receiver action)

 

out-of-order segment가 들어와서 gap이 생김 -> duplicate ACK을 보냄

 

 

 

 

[TCP fast retransmit]

: receiver가 똑같은 ACK 계속 보내면 timeout이 나지 않아도 retransmission

 

 

 

 

 

 

 

<flow control>

: receiver가 sender를 control하는 효과

- free buffer space를 같이 전송해서 얼마나 남았는 지 알려줌

 

 

 

 

 

 

 

 

<connection management>

: data를 exchanging하기 전에, sender와 receiver handshaking

 

[2-way handshaking]

- message loss 발생했을 때 제대로 전송된 것인지 알 수 없다

 

 

 

[3-way handshaking]

 

[closing connection]