TCP #1 - 신뢰성

Transmission Control Protocol

특징

- 연결형 (Connection-Oriented) : IP 계층 위 가상의 회선, 호스트 간 데이터 송수신

- 신뢰성 (Reliability) : 확인을 통한 신뢰성 있는 통신 서비스

- 흐름 제어 : 상대방이 처리할 수 있는 범위 내 데이터를 보내야 함 (수신쪽에서 ACK에 큐 상태를 줘야 함)

- 혼잡 제어 : 네트워크 혼잡 현상을 방지, 제어

- 스트림 통신

 

스트림 배달 서비스

- 바이트 스트림 형태로 데이터 송수신

- 두개의 프로세스가 가상의 채널로 연결

- 송신 프로세스 : 바이트 스트림 생성(쓰기)

- 수신 프로세스 : 바이트 스트림 소비(읽기)

 

송신 버퍼와 수신버퍼

버퍼에 보낼 바이트를 쌓아서 보냄

수신자 버퍼에 자리가 있으면 보내고, 없으면 천천히 보냄 -> 플로우 컨트롤

 

일련의 바이트를 세그먼트라는 패킷으로 그룹화해서 IP 계층에 전달

 

전이중 통신

- 동시에 양방향 전송 및 데이터에 대한 확인 응답 보내기 가능 (piggy backing, 데이터랑 아크를 동시에 보내기 가능)

다중화 / 역다중화 : 송신측은 다중화, 수신측은 역다중화

연결형 서비스

신뢰성 서비스

 

특징

- 번호화 시스템

- 흐름 제어

- 오류 제어

- 혼잡 제어

---

신뢰성 있는 데이터 전송

 

밑 계층에서 완벽하게 하면 UDP 써도 문제 없는데, best effort라 그렇지 않음

rdt_send() : 보내는 쪽이 확실히 보내는 경우

udt_send() : 중간에 손실이 있을 수 있는 경우

rdt_rcv() : 받는 쪽이 확실히 받는 경우

deliver_data() : 문제가 없으면 올려줌

 

문제가 있는 경우

- bit 왜곡.. 체크섬으로 확인 -> NAK 전송

- 패킷 손실

 

FSM(Finish State Machine)

 

rdt 1.0

하위 네트워크 계층이 신뢰성이 있다

-> 콜을 계속 기다리면서 데이터가 들어오면(이벤트) 보내주기만 하면 된다

 

rdt 2.0

근데 그렇지 않다. 체크섬에 오류가 있으면, 아크나 나크를 기다려야 함

센더는 이벤트를 기다리다가, 이벤트 발생해서 데이터를 전송하고 나면 아크나 나크를 기다려야 함

나크가 왔으면 재전송하고 다시 대기해야 함

 

rdt 3.0

아크 / 나크에 에러가 오는 경우

뭐가 됐든 재전송을 해야 하는데 두번 받으면 중복 문제가 발생

-> 패킷에 순차 번호 (Sequence Number) 부여

그리고 타이머까지 사용

타임아웃이 되면 순차 번호를 사용해서 재전송

 

에러 문제 해결책 정리

- 체크섬 : 데이터의 왜곡 점검 -> 아크, 나크 전송

- 타이머 / 시퀀스 넘버 -> 패킷 손실 문제 해결

** 아크가 늦게 오거나 실제로 손실이 됐는지는 송신자는 모르니 타이머 필요, 다시 보내는 게 뭔지 알아야 하니 시퀀스 넘버

 

패킷 재전송을 위한 방법

- 스탑 앤 웨이트 -> 비효율

- 파이프라이닝 메소드 : Go-Back-N (오류 이후 전부), Selective Repeat (오류 패킷만 재전송)

 

Stop-and-Wait

데이터 전송 시간 : L/R

실제로 보내는 untilization : L/R / (RTT + L/R)

심하게 비효율 -> 파이프라이닝, 계속해서 흘려보냄

-> N * L/R / (RTT + L/R)

 

* 윈도우 N

한번에 처리하는 사이즈, 송신자와 수신자가 다를 수 있음

처리율에 영향을 미침

 

Go-Back-N

하나의 타이머로 체크

누적 확인, 문제가 없는 가장 최신 아크만 보내줌

1번까지 정상적으로 오고 3번이 오면 3번 아크가 아니라 1번 아크를 전송, 그동안 오는 건 다 무시

타임아웃 발생 -> 2번부터 다시 보낼 것

...인데, 사실 TCP는 3개 이상 똑같은 아크가 오면 그냥 다시 보냄. 효율의 문제

 

Selective Repeat

개별 타이머로 체크

안 온 패킷의 타임아웃 발생 -> 그거만 다시 보내기

중간에 안 온 애 이후로는 버퍼(큐)에 모아놨다가 리시버 측에서 순서 조정해서 올림

 

* 윈도우 사이즈는 시퀀스 넘버의 1/2이하가 좋음

예를 들어 시퀀스 넘버가 0, 1, 2, 3, 윈도우 사이즈가 3일 때

패킷 0, 1, 2가 전부 도착은 했는데 아크가 날아감

송신자는 다시 보낼 거고 수신자는 정상적으로 받았다고 생각 중

근데 송신자가 0번을 다시 보내면 수신자는 다른 0번 패킷이라 착각할 것

* 그냥 순환적으로 시퀀스 넘버를 매기지 않으면 된다