인접한 두 노드 사이의 링크에서 트래픽을 제어하는 ​​작업은 어디에서 수행됩니까?

인접한 두 노드 사이의 링크에 대한 트래픽을 제어하는 ​​작업은 "링크 계층"에서 완료됩니다. 데이터 링크 계층의 가장 기본적인 기능은 이 계층의 사용자에게 투명하고 안정적인 기본 데이터 전송 서비스를 제공하는 것입니다. 데이터 링크 경로 계층은 원래의 비트 스트림을 전송하는 물리 계층의 기능을 강화하여 물리 계층에서 제공하는 오류가 발생하기 쉬운 물리적 연결을 논리적으로 오류가 없는 데이터 링크로 변환하여 네트워크에 오류가 없는 회선으로 표시되도록 합니다. 층.

이 튜토리얼의 운영 환경: Windows 10 시스템, DELL G3 컴퓨터.

인접한 두 노드 사이의 링크에서 트래픽을 제어하는 ​​작업은 완료됩니다

링크 계층에서 수행됩니다

데이터 링크 계층의 가장 기본적인 기능은 이 사용자에게 투명하고 신뢰할 수 있는 데이터를 제공하는 것입니다. 레이어 데이터 전송 기본 서비스. 투명성은 이 계층에서 전송되는 데이터의 내용, 형식 및 인코딩에 제한이 없으며 정보 구조의 의미를 설명할 필요가 없다는 것을 의미합니다. 신뢰할 수 있는 전송은 정보 손실, 정보 간섭 및 문제에 대한 사용자의 걱정을 제거합니다. 잘못된 주문. 이러한 상황은 물리계층에서 발생할 수 있으며, 오류를 검출하고 정정하기 위해서는 데이터링크계층에서 오류정정코드를 사용해야 한다. 데이터 링크 계층은 물리 계층의 기능을 강화하여 원래의 비트 스트림을 전송합니다. 물리 계층에서 제공하는 오류 가능성이 있는 물리적 연결을 논리적으로 오류가 없는 데이터 링크로 변환하여 오류가 없는 회선처럼 보이게 합니다. 네트워크 계층에.

확장 지식: 흐름 제어

오류 제어는 데이터 링크 계층 기능의 일부이며 또 다른 중요한 부분은 흐름 제어입니다. 흐름 제어에는 수신자가 수신하기 전에 각 문자나 프레임을 받아들일 수 있는 충분한 버퍼 저장 공간을 갖도록 링크의 문자나 프레임의 전송 속도를 제어하는 ​​작업이 포함됩니다. 예를 들어, 문자 중심의 단말-컴퓨터 링크에서 원격 컴퓨터가 많은 단말을 서비스하는 경우 피크 시간대에 미리 정해진 속도로 모든 문자를 전송할 수 없기 때문에 일시적으로 과부하가 발생할 수 있습니다. 마찬가지로, 프레임 중심의 자동 재전송 요청 시스템에서도 승인해야 하는 프레임 수가 증가하면 버퍼 저장 용량을 초과하여 과부하가 발생할 수 있다.

XON / 및 제한 사항. 한편, 시스템은 지나치게 큰 버퍼 공간의 설정을 허용하지 않는 반면, 속도가 크게 일치하지 않고 대용량 파일이 전송되는 경우 여전히 버퍼 저장 공간이 부족합니다. XON/XOFF 체계는 보다 적극적이고 활동적인 흐름 제어 방법입니다. XON/XOFF 체계에서는 흐름 제어를 구현하기 위해 한 쌍의 제어 문자가 사용됩니다. XON은 ASCII 문자 집합에서 제어 문자 DC1을 사용하고 XOFF는 ASCII 문자 집합에서 제어 문자 DC3을 사용합니다. 통신 체인의 수신자가 과부하되면 송신자에게 XOFF 문자를 보낸 다음 수신자가 버퍼 메모리의 데이터를 처리하고 과부하가 복원된 후 송신자에게 XON 문자를 보냅니다. . , 데이터 전송을 재개하도록 발신자에게 알립니다. 데이터 전송 프로세스 중에 XOFF 및 XON 주기는 여러 번 반복될 수 있지만 사용자에게는 투명합니다. 많은 비동기 데이터 통신 소프트웨어 패키지는 XON/XOFF 프로토콜을 지원합니다. 이 체계는 컴퓨터가 문자를 프린터나 다른 터미널 장치로 보내는 데에도 사용될 수 있으며, 이 경우 프린터나 터미널 장치의 제어 구성 요소는 문자 흐름을 제어하는 ​​데 사용됩니다.

창 메커니즘

채널의 효과적인 활용도를 높이기 위해. 이전 섹션에서 언급했듯이 송신자는 확인 프레임이 반환될 때까지 기다리지 않고 여러 프레임을 지속적으로 전송합니다. 이 전송 프로세스는 연속 파이프라인과 같아서 파이프라이닝 기술이라고도 합니다. 승인되지 않은 여러 개의 접힌 프레임을 연속적으로 전송할 수 있으므로 다중 비트 이진수를 사용하여 프레임 번호를 구별할 수 있습니다. 전송되었지만 승인되지 않은 프레임은 오류가 발생하거나 손실될 수 있으며 재전송이 필요할 수 있으므로 이러한 프레임을 유지해야 합니다. 이를 위해서는 재전송이 필요할 수 있는 승인되지 않은 프레임을 보관하기 위해 발신자에게 큰 전송 버퍼가 있어야 합니다. 그러나 버퍼 용량은 항상 제한되어 있습니다. 수신자가 송신자의 전송 속도로 수신된 프레임을 처리할 수 없는 경우에도 여전히 버퍼 용량이 부족하여 일시적으로 과부하가 발생할 수 있습니다. 이를 위해 유휴 RQ 방식과 유사한 조정 조치가 도입될 수 있습니다. 본질은 특정 프레임을 수신하기 전에 보낸 사람이 보낼 수 있는 프레임 수를 제한하는 것입니다. 이는 보낸 사람이 예약된 프레임 수를 조정한 결과입니다. 재발급은 프레임 수를 확인함으로써 이루어집니다. 수신자가 수신된 프레임을 처리할 시간이 없으면 수신자는 확인 정보 전송을 중지합니다. 이때 보낸 사람의 재공개 제한에 도달하면 확인이 이루어질 때까지 새 프레임이 전송되지 않습니다. 정보가 다시 수신되었습니다. 이 솔루션을 구현하려면 승인되지 않은 프레임의 재전송에 승인되지 않은 프레임의 최대 수가 설정되어야 합니다. 이 제한을 링크의 전송 창이라고 합니다. 당연히, 윈도우가 1로 설정되면, 즉 송신자의 버퍼링 용량이 1프레임과 같게 되면 전송 제어 방식은 이때 유휴 RQ 방식으로 돌아가게 되므로 전송 효율이 매우 낮아진다. 수신자가 수신된 모든 프레임을 최대한 처리하거나 수용할 수 있도록 창 제한을 선택해야 합니다. 물론 선택할 때 최대 프레임 길이, 사용 가능한 버퍼 용량, 전송 비트율 등의 요소도 고려해야 합니다. 재발행은 보낸 사람이 전송했지만 아직 확인하지 않은 프레임에 해당하는 연속 시퀀스 번호 목록입니다. 이러한 프레임의 시퀀스 번호에는 전송 창의 한계인 최대값이 있습니다. 소위 전송 창은 전송되었지만 아직 전송자가 확인하지 않은 프레임 번호 대기열의 경계를 나타냅니다. 상한 및 하한은 각각 전송 창의 상한 및 하한 가장자리라고 하며 사이의 거리입니다. 위쪽 및 아래쪽 가장자리를 창 크기라고 합니다. 마찬가지로 수신기에도 수신이 허용되는 프레임의 시퀀스 번호를 나타내는 수신 창이 있습니다. 수신 창의 상한 및 하한도 시간에 따라 미끄러집니다.

발신자가 프레임을 보낼 때마다 승인할 프레임 수가 1씩 증가합니다. 마찬가지로 발신자가 확인 메시지를 받을 때마다 승인할 프레임 수가 1씩 감소합니다. 재전송 횟수 값, 즉 승인할 프레임 수가 전송 창과 동일하면 새 프레임 전송이 중지됩니다. 일반적으로 프레임 번호는 제한된 이진수만 취하고 일정 시간이 지나면 반복적으로 순환합니다. 프레임 번호에 3자리 이진수가 포함된 경우 프레임 번호는 0에서 7 사이를 순환합니다. 전송 과정이 진행될 때 창 위치가 계속 슬라이딩되므로 슬라이딩 윈도우(Sliding Window) 또는 간단히 슬라이딩 윈도우라고도 합니다.

슬라이딩 윈도우의 상태 변경 과정은 다음과 같이 설명할 수 있습니다. (송신 윈도우가 2이고 수신 윈도우가 1이라고 가정)

초기 상태에서는 보낸 사람이 프레임을 보내지 않으며 보내는 창의 앞 가장자리와 뒷 가장자리가 동일합니다. 수신 창 제한은 1이며, 이는 프레임 0을 수신할 수 있도록 허용합니다.

발신자가 0번 프레임을 보냈습니다. 이때 전송 포트가 열리고(즉, 앞쪽 가장자리가 1만큼 증가함) 창이 0번에 정렬되어 프레임이 전송되었음을 나타냅니다. 하지만 확인 반환 메시지가 아직 수신되지 않았습니다. 수신 창 상태는 이전과 동일하며 0 프레임의 수신이 허용됨을 나타냅니다.

발신자는 프레임 0의 확인 반환 정보를 받기 전에 프레임 1번을 계속해서 보냅니다. 송신 창의 상태는 변경되지 않습니다.

발신자는 프레임 0을 수신했으며 창이 한 칸 이동하여 프레임 1번을 수신할 준비가 되었음을 나타냅니다. 송신 창의 상태는 변경되지 않습니다.

발신자는 0번 프레임의 확인 반환 정보를 수신했으며, 송신 창의 후행 가장자리가 1씩 증가하여 다시 게시에서 0번 프레임이 삭제되고 수신 창의 상태가 변경되지 않음을 나타냅니다. .

발신자는 계속해서 2개의 프레임을 전송하고 전송 창의 앞쪽 가장자리가 1씩 증가합니다. 이는 프레임 2도 확인 보류 목록에 포함되어 있음을 나타냅니다. 수신

창의 상태는 변경되지 않습니다.

수신기가 1번 프레임을 수신했고, 수신 창이 한 칸 슬라이드되어 2번 프레임을 수신할 준비가 되었음을 나타냅니다. 송신 창의 상태는 변경되지 않습니다.

송신자가 수신자로부터 1번 프레임이 수신되었다는 확인 메시지를 받으면 전송 창의 후행 가장자리가 1씩 증가합니다. 이는 가장 먼저 수신되는 1번 프레임이 재공개에서 삭제됨을 나타냅니다. 수신 창 상태는 변경되지 않습니다. 일반적으로 특정 범위 내에 도착하는 모든 프레임은 순서가 맞지 않더라도 수신자가 수신해야 합니다. 이 범위를 수신 윈도우로 간주할 경우 수신 윈도우의 크기는 1보다 커야 하며, Go-back-N은 수신 윈도우가 1인 특별한 경우입니다. 선택적 재전송은 송신 창과 수신 창이 모두 1보다 크다는 점을 제외하면 슬라이딩 창 프로토콜로 간주될 수도 있습니다. 슬라이딩 윈도우의 관점에서 유휴 RQ, Go-back-N 및 선택적 재전송의 세 가지 프로토콜을 살펴보면 이들 간의 차이점은 해당 창의 크기에 있습니다.

Idle RQ: 송신 창 = 1, 수신 window = 1

Go-back-N: 보내기 창>1, 받기 창=1

재전송 선택: 보내기 창>1, 받기 창>1

프레임 시퀀스 번호가 3자리 이진 인코딩을 채택하는 경우 최대 시퀀스 번호는 SMAX=2^3-1=7입니다. 순서화된 수신 모드의 경우 송신 창의 최대 크기는 SMAX로 선택됩니다. 비펜스 수신 모드의 경우 송신 창의 최대 크기는 최대 시퀀스 번호 범위의 절반입니다. 타임아웃 제어를 관리하는 타이머는 시퀀스 번호 공간의 크기가 아닌 전송 버퍼의 수와 동일해야 합니다. 실제로 각 버퍼는 타이머에 대응해야 합니다. 타이머 시간이 초과되면 해당 버퍼의 내용이 재전송됩니다. 수신자가 설정해야 하는 버퍼 수는 시퀀스 번호 공간의 크기가 아니라 수신 창 크기와 동일해야 합니다.

관련 지식이 더 궁금하시다면 FAQ 칼럼을 방문해 주세요!

위 내용은 인접한 두 노드 사이의 링크에서 트래픽을 제어하는 ​​작업은 어디에서 수행됩니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!