checksum
UDP는 데이터의 오류가 발생했는지 체크만 해준다.
(왜 체크만 해주냐? 확인해서 어플리케이션에서 알아서 하라고 이름부터 User Datagram 인 이유가 있다.)
checksum은 16비트로 구성되어있다.
방식은 DATA를 16비트로 쪼갠뒤 모든 16비트 값을 더한다.
캐리가 나온것은 맨뒤에 다시 더한후 1의 보수를 취한다.
이를 우리는 checksum이라 한다.
패킷이 오류가 없다고 수신자에서의 합은 FFFF가 될것이고 FFFF가 아니라면 오류가 발생한 것이다.
다만 특정한 경우 오류가 발생했음에도 checksum이 그대로인 경우가 있을수도 있다.
무조건 오류 검출이 아님TCP의 신뢰적인 데이터 전송
앞에 IP는 데이터의 신뢰도를 보장해주지 않았다.
하지만 TCP는 데이터의 신뢰도를 보장해 주어야한다.
어떻게 가능한 것일까???
이를 위해 우리는 문제상황을 추상화 시킨후
점진적으로 완전한 신뢰적인 데이터 전송 프로토콜에 도달하기위해 구체화 한다.rdt 1.0
if : sender와 receiver가 신뢰성 있는 연결을 통해 데이터를 전송한다고 가정할때
sender : 패킷을 만들어 보낸다. (다중화)
receiver : 패킷을 받으면 풀어서 전달한다. (역다중화)
단순히 위과정만 반복하면 된다.rdt 2.0
if : 비트 오류가 발생하는 상황이라면?
비트 오류를 검출하는 기능을 추가해야한다.
이를 위해 3가지 과정이 요구된다.
1. 오류 검출 (checksum 활용)
2. 수신자 피드백 (ACK/NAK로 구분 정상인지 아닌지 구분)
3. 재전송 (오류난 패킷 다시전송)
sender
1. 데이터 전송
2. 사용자 피드백을 기다림
3.1. NAK를 받으면 다시 패킷전송
3.2. ACK를 받으면 다시 대기상태
receiver
1. 패킷 도달시 오류있는지 확인
2.1. 오류가 있다면 NAK전송
2.2. 오류가 없다면 ACK전송 하고 data 전달rdt 2.1
if : 야 근데 ACK/NAK도 오류나면 어떡해?
해결방안은 간단하게 "그냥 다시보내면 안돼?" 이다.
이때 문제가 생기는 것은 난 정상적으로 받아서 ACK보냈는데 다시 같은 패킷이 온다면?
수신자는 난 정상적으로 받아서 다음 데이터 기다리는데 이전 데이터가 온다면
어떻게 처리해야하며 왜 이것이 온지 구분하기도 힘들다.
이것을 해결하기 위해 순서(sequence)를 둔다.
순서를 전부 다 쓰면 오버헤드가 너무 커지니 flag bit를 둬서 0과 1로 이전과 현재를 구분하게한다.
구분선기준 윗부분을 설명하자면
sender
1. 시작시 (순서,data,체크썸)을 전송한다.
2.1 만약 NAK가 오거나 받은 데이터 비트의 오류가 난다면 다시 보내고 기다린다.
2.2 모든게 정상이라면 넘어감
receiver
1. 0기다리다가 데이터가 들어오면 문제없고 시퀀스 맞으면 1대기로 넘어간다.
이때 ACK전송 및 체크썸 전달 후 1 시퀀스 대기로 이동
2.1. 1 시퀀스 받았는데 오류나면 NAK와 chksum보내고 (NAK가 오류났는지 다시확인하기 위해서)
기다린다.
2.2. 제대로 오긴했는데 이전 시퀀스(0)면 ACK 보내줌
-> 이전에 내가 보낸 ACK 문제생겨서 다시 온거니까 ㅇㅋ 해주고 버리면됌
이 과정을 반복한다.
밑과정도 동일rdt 2.2
>> 어차피 ACK 이전꺼오면 제대로 답변 못받은건데 걍 NAK없애고 통일하죠?
오..?
sender
- 어차피 비트손실 또는 이전 시퀀스 ACK가 온다면 다시 보내줌
receiver
- 문제가 생겼으면 이전 시퀀스 ACK 전송
- 또는 이전 패킷 보내주면 아 내가 보낸 이전 ACK 문제생겼구나? 하고 ACK 전송
이때 Sender는 S1 대기중이므로 ACK 다시받고 S2로 넘어갈거임
<요약>
sender가 이전 seq ACK받는건 무조건 내가 보낸거 오류니까 다시 보내줘라
receiver는 오류나면 이전 ACK 보내고
내가 보낸 ACK 문제생기면 이전 seq 패킷오니까 알아서 잘 버려라
다른부분은 rdt 2.1과 동일하다고 보면됌번외편 : checksum에도 오류가 나면 어쩔건데...?
패킷에 checksum을 보내고 이를 통해서 오류를 검출한다고 했는데
만약에 checksum또한 오류가 나면 어쩔건데...?
이럴경우에도 TCP가 신뢰도있는 데이터 전송을 한다고 말을 할수가 있는가
1. checksum만 오류가 난다면?
-> 어차피 합이 FFFF가 아니라 오류
2. checksum과 패킷 둘다 오류난다면?
-> FFFF나올 확률이 매우 낮음
3. 단 이를 뚫고 매우 가끔 데이터 손실이 났음에도 FFFF가 오기도함
https://networkengineering.stackexchange.com/questions/44807/can-the-checksum-bits-be-corrupted
참고rdt 3.0
if : 야 근데 패킷자체가 사라지면 어떡해???
>>> 특정시간이 지나도 안온다면 패킷 사라진거로 하죠?
>>> 그냥 느려서 늦게온것도??
>>> ㅇㅇ
sender
1. 대기하다가 실행시에 전송후 타이머 재기
2.1. ACK(1) 즉 NAK오면 무시(어차피 타이머 지나면 재전송이니)
2.2. 시간 지나면 재전송해주고 타이머 초기화
3. 제대로 답변오면 타이머 정지
위와 같은 4개의 케이스가 나올수 있다.
중요한건 (d) 처럼 타이머가 너무 짧으면 제대로 받았는데도 재전송하고
너무 길면 또 네트워크 지연이니 문제다.
학생