TCP [출처] TCP|작성자 실짱

|

outing : 가는 길을 알려는 것.

forwarding : 경로가 정해져 있고 그길로 보내주는 것.(전화)

* 인터넷은 routing + forwarding


전화는 전송률이 일정하다..

인터넷은 전송률이 일정하지 않고 보장하지 못한다.

* 인터넷 라우터는 패킷 하나하나를 보았을때는 비효율적이지만 전체를 봤을때는 가격비에 효율적이다.


라우터는 자신이 처리할 수 있는 패킷량보다 더 많이 들어오면 버려버린다.


Congestion : 네트웍에 트래픽이 너무 혼잡한 상태..

= Gueueing error


-> Packet loss가 일어나는 경우

1. 라우터의 큐가 넘치는 경우.

2. Checksum 검사를 했을때 데이터 손실이 있다고 판단된 경우 -> Transmission error

3. TTL(time to live)값이 0이 되었을 때(ex, routing loop)

* 위 3가지 문제를 TCP가 해결한다.


TCP가 해야할일 Retransmission(재전송), Reordering(순서정렬), Flow Control(흐름제어)  => Reliable(신뢰성)


IP계층(Network)에서는 패킷이 사라졌는지 확인이 불가능..(IP는 패킷 전송에 최선은 다하지만 보장은 못한다.)

TCP헤더에 Sequence number을 붙여서 패킷이 손실이 되었는지 / 순서되로 받았는지 확인함.

+ Flow control을 함


UDP

TCP가 하는 재전송, 순서정렬, 흐름제어를 해주지 않는다.

- 영상이나 음성 전달시 약간의 Loss는 무시할 수 있다.

- 경로가 하나뿐인경우 패킷순서정렬이 필요없다(LAN)

- 하나의 패킷으로 전송되는 경우에 순서정렬이 필요없다.

TCP는 기본적으로 위에 3가지 기능을 기본적으로 지원하기 때문에 필요가 없다 생각하는 경우 이를 해제 할 수 없다.

그렇기 때문에 UDP를 사용한다.


패킷이 1,2,4,5 순서로 들어왔을때 3번이 손실되었을 확률과 후에 늦게 들어올 확률??

- 뒤에 3개의 패킷이 전송되도록 전송이 안되면 3번 패킷이 에러난걸로 판정하고 재전송 요청..


ACK : 패킷을 정상적으로 받았을 때

NACK : 패킷이 에러가 났을 때..


수신한 패킷마다 ACK를 보낸다면 전송속도가 떨어진다.

* RTT : 패킷을 보냈을때 수신자의 대답이 돌아올때까지 걸리는 총 시간.

* PPS : 초당 처리하는 패킷수.

패킷길이가 길어지면 딜레이가 발생.. -> 패킷을 채울때까지 기달려야 하니깐.

* 음성은 약 10ms단위로 해서 패킷을 만들어 전송한다.

* Window : Ack를 안받고도 한번에 보낼 수 있는 패킷 수 조절..

Flow control 은 네트워크의 상태에 따라 패킷을 많이 보낼지 적게 보낼지 결정..

* dupACK : 1,2까지 전달되고 4,5,6이 전달되면서 3이 손실되었을때 수신자는 3번을 재전송해달라고 요청하는 경우.

* Fast Retransmit


재전송하는 경우

1. Time out : 수신이 완료된 패킷이 적어서 dupAck 조건이 성립안하면...

2 dupAck가 3개이상 뜨는 경우


패킷을 전송할때 첨에는 1부터 시작하여 2제곱승으로 증가한다 (최대 증가값(ssthresh)는 64) : Slow Start

최대값까지 증가후는 1씩 증가하며, 수신측에서 NAck가 왔을때 1/2로 감소한뒤 1씩 증가..


TCP의 속도는 RTT에 반비례한다.

* RTT는 패킷을 전송하고 ACK가 돌아오는데까지 걸리는 시간.


Congestion이 발생했으면 네트워크 상태가 혼잡한 상태..

Congestion이 발생하면 자기 책임이라 생각하고 전송량을 1/2로 줄인다.

-> 따라서 데이터를 전송하는 모든 송신자가 전송량을 1/2로 줄이기 때문에 라우터는 처리할 양이 반으로 줄어들기 때문에 그 사이에

    Congestion 문제를 해결시도하며, 금방 풀 수 있다.


Slow Start parse : 1부터 시작하여 2의 제곱승으로 증가하는 방식

Congestion avoid phase : 전송을 하다가 전송에러 1/2로 감소된 후 다시 1씩 증가하는 방식


TCP의 flow control 방식을 한단어로 AIMD (Additive increase, Muliiplicative Decrease)

- Slow Start 비율이 작기 때문에 보통 AIMD라 부름..


비디오/오디오는 일정한 전송속도 보장이 있는 것이 좋다.

하지만 Tcp에서는 네트워크 상태에 따라서 흐름제어를 하기 때문에 비효율 -> 따라서 버퍼링을 함


TCP에서는 Packet loss가 일어나면 무조건 congestion으로 판단..

-> 그렇다면 패킷 로스가 일어나는 경우는 3가지 경우인데 이를 다 congestion으로 처리를 한다면 TCP의 오동작으로 볼 수 있다.

하지만 통계로 보았을 때 유선에서 실제 Congestion이 일어날 확률이 99%이고 나머지가 1%미만이기 때문에 ...

하지만 무선환경에서는 다르다..오동작률이 20%....


무선에서 패킷전송 속도는 √p 에 반비례한다. (p : average packet loss rate)

유선에 비하여 약 30%정도 떨어진다.

[출처] TCP|작성자 실짱



'Network > Netowrk_transport' 카테고리의 다른 글

QoS Protocol & Architectures 1  (0) 2009.01.18
IntServ DiffServ  (0) 2009.01.18
diffserv  (0) 2009.01.18
ACK  (0) 2009.01.18
critical unfairness characterized  (0) 2009.01.18
And