CH3. Transport Layer(3)

5. Connection oriented transport : TCP

 - TCP

-> connection oriented : client와 server가 연결이 되기 위해서는 three handshaking 과정이 필요하다.

-> 1 대 1 통신법 : 각각의 IP addr과 port #를 통해 구분하고 통신한다.

-> 쌍방이 모두 송신과 수신을 할수있다.

-> reliable 하고 데이터들이 순서대로 들어오게 된다. (sliding window protocol을 사용한다. )
     :message boundary가 아닌 byte단위로 끊어서 보낸다. 예를 들어 good를 전송하게 되면 g,o,o,d를 따로따로 보내게 되는것

     : UDP의 경우 message oriented로 receiver측의 버퍼가 데이터 양보다 작을경우 받을수 있는 만큼만 받고 나머지는 버리게된다.

-> flow control과 congestion control이 존재한다.

 

 - TCP Header

-> Sequence number : 각각의 byte마다 sequence number가 존재하게 된다. 그렇기에 모든 seq #를 보내는것은 무리가 있다. 그래서 segment에서 가장 앞에 있는 byte의 seq# 를 설정하여 보내게 되는 것이다.

-> Acknowledgment number : 다음 자신이 받고자 하는 sequence number를 상대방에게 알려주는 것이다.

-> TCP의 경우 full duplex이므로 데이터를 보내기도 하고 받기도 하기 때문에 seq #과 ack #이 모두 필요하다.

-> 6 control flog bits (1일때)

• URG : Urgent poiter를 사용하겠다.
• ACK : Acknoledgement number가 사용가능 한것임을 의미
• PSH : receiver측에서 가능한 빨리 apllication layer로 보내야 함을 의미한다.
• RST : reset a erroneous connection
• SYN : 초기 connection을 위해서 sequence number를 동기화 하는 작업을 의미한다. (SYN=1&ACK=0 => connection request, SYN=1&ACK=1 => connection accepted)
• FIN : 더이상 보낼 데이터가 없으니 연결을 끊겠다는 의미이다.

 - RTT Estimation and Timeout

-> Time out 의 값은 RTT보다 길어야 한다.

• Time out 값이 너무 짧을 경우 불필요한 재전송이 생길수 밖에 없다.
• Time out 값이 너무 길 경우 segment loss에 대한 재전송의 반응이 느리다.
• 네트워크 성능을 계속적으로 판단해서 시간초과 간격을 조정하는 매우 동적인 알고리즘이 필요가 해진다.

 - TCP reliable data transfer

-> Based on Sliding window protocol

-> SR ARQ와 비슷한 형태를 지닌다.(Selective Retransmission ARQ)

-> Window size가 가변적이다. (flow control과 congestion control을 관리하기 위해서)

-> 헤더의 ACK field는 항상 다음 받고 싶은 데이터에 대한 seq#를 넣어보낸다.
-> 재전송의 경우 time out이나 동일한 ACK이 3번 연속으로 왔을때 보내지게 된다.(fast restransmission)

 

 - Fast Retransmit

-> 3번연속 동일 ACK를 받으면 time out이 발생하기전 재전송을 시행하는 것이다.

-> time out 시간이 너무 길게 되면 재전송을 위한 시간이 너무나도 오래 걸리기 때문에 이를 해결하기 위해 만들어짐

-> sender측은 동일한 ACK을 3번받게 되면 자신이 보낸 데이터가 loss 됐다고 가정을하게 된다.

Event at Receiver	TCP Receiver action
-> 자신이 예상한 순서대로 segment 들이 도착하게 되고, 모든 데이터들이 이미 ACK을 받을 경우	-> ACK을 딜레이 시키고 있다가(500ms) 다음 segment가 없을 경우 마지막에 받은 segment에 대해서만 ACK를 보내게 된다.
-> 자신이 예상한 순서대로 segment들이 도착을 하되, 다른 segemnt에 대해 ACK이 지연되어 있는 경우	-> 즉시 지연되고 있던 ACK을 보내게 된다.
-> 자신이 예상한 순서보다 더 높은 seq#을 가진 segment들이 도착하여 받은 데이터 순서에 gap이 발생한경우	-> 즉시 gap이 발생한 segment에 대한 seq#를 ACK을 중복으로 보낸다.
-> 도착한 segment가 gap을 다 채우게 될 경우	-> 즉시 가장 마지막에 있는 segment에 대한 ACK를 보낸다.

 - TCP Flow Control

-> sender가 receiver측의 버퍼를 초과하여 data를 보내는 것을 막기 위한 것이다.

-> window 를 동적으로 관리할수 있어야 한다.

-> Receiver측에서 자신의 사용 가능한 window size를 ACK segment에 실어 보내게 된다(TCP header의 window size 이용)      -> RcvWindow = Receiver의 전체 버퍼 - (LastByteRcvd - LastByteRead)가 된다.

-> 만약 RcvWindow = 0이된다면 sender 측은 데이터를 더이상 보낼수가 없게 된다. 이때 receiver 측에서 RcvWindow가 0보다 커지게 되는것을 알려 주지 않으면 계속해서 sender는 데이터를 보낼수가 없게 된다.

-> 이를 해결 하기 위해 Timer를 사용하게 된다.

 

 - TCP : Timers

-> Retransmission Timer

     : TCP sender는 하나의 retransmission timer를 각각의 연결에 대해 가지고 있다.

-> Persistent Timer

     : RcvWindow가 0 이 됐을때 발생할수 있는 deadlock 상태를 해결하기 위해 만들어 졌다.

     : sender 측에서 RcvWindow size가 0이 됐다고 할때 timer는 on이 된다,

     : timer가 다 돌게 되면 sender측은 probe segment(ACK 재전송을 요구하는 특별 segment)를 보내게 된다.

     : persistent timer의 초기값은 2*RTT이다.

     : probe segment에 대해서도 대답이 오지 않게 되면 sender는 timer의 값을 임계지점까지 계속 두배로 올리다가 임계지점에 도달하면 timer를 reset하게 된다.

-> Keep alive timer

     : 서버측에서 client가 살아 있는지를 확인하기 위해서 사용되어지는 timer

     : 대게 두시간을 timer의 기본값으로 설정을하고 그 시간동안 TCP connection 사이에서 segment송수신이 없을 경우 10개의 probe segment들을 보내게 된다. 이때 응답이 없다면 연결이 종료가 되게 되고, 응답이 있다면 timer는 다시 2시간으로 설정되게 된다.

-> 2MSL(Maximum Segment Lifetime)

     : TCP connection이 완전히 끊기게 하기 위해서 기다려 주는 timer라고 생각을 하면 될듯...??