◇ 전송 계층 검토
기본적으로 TCP와 UDP가 있습니다. 재사용수업 오류 검사공급
◇ 안정적인 데이터 전송 원칙
하위 링크는 실제로 신뢰할 수 없습니다.
애플리케이션. 계층에 안정적인 통신을 제공한다는 환상을 제공할 뿐입니다.
신뢰할 수 없는 두 가지 1) 메시지 오류 2) 메시지 누락 << 두 가지만 하면 됩니다.
>> TCP는 위의 두 가지 신뢰할 수 없는 사항을 어떻게 처리해야 합니까? ?
>> 간단한 신뢰할 수 있는 데이터 전송 프로토콜을 고려하여 알아봅시다.
◇ 간단한 RDT 프로토콜
: 한 번에 한 팩 보낸다고 가정해 봅시다(하나를 보내고, 확인하고, 하나를 보내고, 확인)
FSM(Finite State Machine) 사용하기 >> 교수님이 나중에 검토해보라고 하셔서
그래요 https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=taehun3718&logNo=140162190370
인용하다.
-RDT1.0
: 하위 채널은 완전히 신뢰할 수 있습니다.
>> RDT와 아무 관련이 없습니다!
송신자는 패킷을 생성하고 전송하기만 하면 되고 수신자는 패킷을 수신하고 압축을 풀기만 하면 됩니다.
-RDT2.0
: 하위 채널 패킷 오류때에만
>> 원격 테스트
하나) 오류 감지 : 검사 숫자 추가
2) 피드백 : 승인(ACK) 또는 부정 승인(NAK) 전송
삼) 재전송 : 재전송
>> ACK나 NAK가 틀렸다면?
만약에. ACK 오류가 있는 경우 보낸 사람은 중복 패킷을 보냅니다(잘못된 패킷을 보낸 것을 알면!).
수신자의 입장에서는 이것이 새로운 패킷인지 중복 패킷인지 구별할 수 없다.
>> 발신자 순서#페이스트 솔루션
ACK/NAK가 왜곡되면 발신자는 무조건 재전송
수신자가 중복 항목을 버립니다.
-RDT2.1
: 제목에서 순서# 소개하다. > 헤더 필드 크기를 최소화해야 함 > seq # 필드 크기도 최소화해야 함
> 하나씩 보내는 데이터 패킷의 경우 0과 1 두 개면 충분(이전 데이터 패킷과 구분만 하면 되므로)
-RDT2.2
: NAK 제거 확인만마지막으로 받은 ACK 대신 시퀀스 추가#
– RDT3.0(정지 및 대기 동작)
: 부채널의 패킷 오류는 제외 손실도 나타났다
수표 손실 시간제 노동자필요
보낸 사람은 “적당히” 기다려야 합니다.
(타이머가 짧고 복구가 빠르면 대신 중복 패킷이 생기지만(단, seq#은 정상적으로 동작할 수 있으므로) 네트워크 오버헤드가 크다.
타이머가 길수록 복구 속도는 느려지지만 네트워크 오버헤드는 줄어듭니다.)
만약에. 너무 이른 시간 초과가 발생하면 복제가 계속 발생합니다.
중복 패킷은 수신기에서 삭제되므로 중복 패킷이 나타나지 않고 정상적으로 작동합니다.
◇ 편곡
– 신뢰할 수 없는 네트워크에서 패킷 오류 및 손실 발생
– 패킷 오류에는 오류 감지, 피드백, 재전송 및 시퀀스 번호 메커니즘이 필요합니다.
– 패킷 손실에는 시간 초과 메커니즘이 필요합니다.
>>TCP에는 위의 모든 메커니즘이 있습니다(헤더 필드에 구현됨!).
>>는 실제로 작동하는 파이프라인 프로토콜입니다. >> 다음에 배울 것 같습니까?