컴퓨터 네트워크: 네트워크 계층 (2)

(1) 버전

IP 프로토콜 버전을 나타내는 4 자리 숫자입니다. 쌍방이 사용하는 IP 프로토콜 버전은 반드시 일치해야 한다. 현재 널리 사용되고 있는 IP 프로토콜의 버전 번호는 4 (즉, IPv4) 입니다. IPv6 (버전 6 IP 프로토콜) 을 사용하는 것도 있습니다.

(2) 제목 길이

4 자리 숫자, 표현할 수 있는 최대 10 진수 값은 15 입니다. 이 필드가 나타내는 숫자의 단위는 32 비트 (1 32 비트 문자 길이 4 바이트) 이므로 I 의 헤더 길이가 1 1 1 (10 진수/) 일 때 패킷의 헤더 길이가 4 바이트의 정수 배수가 아닌 경우 마지막 채우기 필드로 채워야 합니다. 따라서 데이터 부분은 항상 4 바이트의 정수 배로 시작되므로 IP 프로토콜을 구현할 때 더욱 편리합니다. 헤더 길이를 60 바이트로 제한하는 단점은 때로는 충분하지 않을 수 있다는 것입니다. 그러나 이렇게 하는 것은 사용자가 지출을 최소화하기를 바라는 것이다. 가장 일반적으로 사용되는 헤드 길이는 20 바이트입니다 (즉, 헤드 길이는 0 10 1). 이 경우 옵션이 사용되지 않습니다.

(3) 차별화 서비스

8 곳을 걸으면 더 좋은 서비스를 받을 수 있다. 이 필드는 이전 표준에서 서비스 유형이라고 하지만 사용된 적이 없습니다. 1998 ITF 필드 이름을 DS (difference service (DS)) 로 변경합니다. 이 필드는 구분 서비스를 사용하는 경우에만 유효합니다. 이 필드는 일반적으로 사용되지 않습니다.

(4) 전체 길이

총 길이는 헤더와 데이터의 합계의 길이 (바이트) 입니다. 총 길이 필드는 16 비트이므로 데이터그램의 최대 길이는 2 16- 1=65535 바이트입니다.

IP 계층 아래의 각 데이터 링크 계층에는 프레임 형식의 최대 데이터 필드 길이를 포함한 자체 프레임 형식이 있으며 이를 최대 전송 단위 (MTU) 라고 합니다. IP 데이터보가 링크 계층에서 프레임으로 캡슐화되는 경우 데이터그램의 총 길이 (즉, 헤더+데이터 부분) 는 아래 데이터 링크 계층의 MTU 값을 초과할 수 없습니다. 가능한 한 긴 데이터그램을 사용하면 전송 효율성이 향상되지만 이더넷이 널리 사용되기 때문에 실제로 사용되는 데이터그램 길이는 1500 바이트를 거의 초과하지 않습니다. IP 데이터그램의 전송 효율성을 낮추지 않기 위해 IP 에 대한 표준 파일은 모든 호스트와 라우터가 처리할 수 있는 IP 데이터그램 길이가 576 바이트 이상이어야 한다고 규정하고 있습니다. 이 값은 또한 최소 IP 데이터그램의 총 길이입니다. 데이터그램 길이가 네트워크에 허용된 최대 전송 단위인 MTU 를 초과하면 긴 데이터그램을 분할해야 네트워크를 통해 전송할 수 있습니다. 이 경우 데이터그램 헤더의 "총 길이" 필드는 조각 전 데이터그램 길이가 아니라 조각 이후 각 조각의 헤더 길이와 데이터 길이의 합계를 나타냅니다.

(5) 식별

16 을 차지하다. 소프트웨어는 메모리에 카운터를 유지 관리합니다. 데이터그램이 생성될 때마다 카운터는 1 을 증가시키고 이 값은 식별 필드에 할당됩니다. 그러나이 "ID" 는 일련 번호가 아닙니다. IP 는 연결되지 않은 서비스이므로 데이터그램을 순차적으로 수신하는 문제는 없습니다. 데이터그램이 네트워크의 MTU 를 초과하기 때문에 세그먼트화되어야 하는 경우 이 식별 필드의 값은 모든 데이터그램 세그먼트의 식별 필드에 복사됩니다. 식별 필드의 동일한 값을 사용하면 세그먼트 후의 각 데이터그램 세그먼트를 원본 데이터그램으로 올바르게 재구성할 수 있습니다.

(6) 깃발

세 개, 하지만 지금은 두 개만 의미가 있다.

플래그 필드의 가장 낮은 비트는 MF (더 많은 조각) 로 기록됩니다. MF= 1 데이터그램 뒤에 "조각화" 가 있음을 나타냅니다. MF=0 은 이것이 조시 데이터보의 마지막임을 의미합니다.

Flag 필드 중간에 있는 한 사람은 DF (조각하지 않음) 로 표시되어 "조각할 수 없음" 을 나타냅니다. DF=0 인 경우에만 세그먼트화가 허용됩니다.

(7) 용지 마이그레이션

13 을 차지하다. 분할 영역 오프셋은 긴 그룹을 분할한 후 원래 그룹에서 분할 영역의 상대적 위치를 나타냅니다. 즉, 사용자 데이터 필드의 시작점을 기준으로 슬라이스가 시작되는 위치는 어디입니까? 슬라이스 오프셋은 8 바이트 단위입니다. 즉, 각 슬라이스의 길이는 8 바이트 (64 비트) 의 정수 배수여야 합니다.

(8) 생존 시간

생존 시간 (TTL) 은 TTL (생존 시간 필드) 에서 일반적으로 사용되는 약어로, 네트워크에서 데이터보의 수명을 나타냅니다. 이 필드는 데이터그램의 출처에 의해 설정됩니다. 배달할 수 없는 데이터보가 인터넷을 돌지 않도록 하기 위한 것입니다 (예: 라우터 R 1 에서 R2, R3, R 1). 네트워크 자원을 헛되이 낭비합니다. 초기 설계에서는 초를 TTL 값의 단위로 사용합니다. 라우터를 통과할 때마다 데이터보가 라우터에 소비한 시간에서 TTL 을 빼야 한다. 데이터그램이 라우터에서 1 초보다 적은 시간을 소비한다면 TTL 값은 1 을 줄입니다. TTL 값이 0 으로 줄어들면 데이터그램이 삭제됩니다. 그러나 기술이 발전함에 따라 라우터가 데이터그램을 처리하는 데 필요한 시간이 짧아지고 있으며 일반적으로 1 초보다 훨씬 적습니다. 이후 TTL 필드의 기능이 "홉 수 제한" 으로 변경되었습니다 (이름은 변경되지 않음). 라우터는 데이터그램을 전달하기 전에 TTL 값에서 1 을 뺍니다. TTL 값이 0 으로 줄어들면 데이터그램은 폐기되고 전달되지 않습니다. 따라서 TTL 의 단위는 더 이상 초가 아니라 점프입니다. TTL 의 의미는 데이터 신문이 인터넷에서 통과할 수 있는 최대 라우터 수를 나타내는 것입니다. 분명히 데이터그램은 인터넷에서 최대 255 개의 라우터를 통과할 수 있다. TTL 의 초기 값이 1 으로 설정되어 있으면 이 데이터그램은 LAN 내에서만 전송할 수 있습니다. 데이터그램이 LAN 의 라우터로 전송되면 TTL 값이 전달되기 전에 0 으로 줄어들어 해당 라우터에 의해 폐기됩니다.

(IX) 합의

프로토콜 필드는 대상 호스트의 IP 계층에서 데이터 부분을 어느 처리 프로세스로 넘겨야 하는지 알 수 있도록 이 데이터그램이 전달하는 데이터에 사용되는 프로토콜을 나타냅니다.

프로세스는 대략 다음과 같습니다.

(1) 데이터그램 헤더에서 대상 호스트의 IP 주소 D 를 추출합니다. 대상 네트워크 주소는 N 입니다. .....

(2) N 이 이 라우터에 직접 연결된 네트워크 주소인 경우 데이터그램은 다른 라우터를 통해 대상 호스트에 직접 전달되지 않습니다 (대상 호스트 주소 D 를 특정 하드웨어 주소로 변환하고 데이터그램을 MAC 프레임으로 캡슐화한 다음 프레임 전송 포함). 그렇지 않으면 간접적으로 전달되어 실행됩니다 (3).

(3) 라우팅 테이블에 대상 주소가 D 인 특정 호스트 경로가 있는 경우 라우팅 테이블에 지정된 다음 홉 라우터로 데이터 그램을 전달합니다. 그렇지 않으면 (4) 를 실행합니다.

(4) 라우팅 테이블에 네트워크 N 에 대한 경로가 있는 경우 라우팅 테이블에 지정된 다음 홉 라우터로 데이터 그램을 전달합니다. 그렇지 않으면 실행 (5)

(5) 라우팅 테이블에 기본 경로가 있는 경우 라우팅 테이블에 표시된 기본 라우터로 데이터그램을 보냅니다. 그렇지 않으면 실행 (6) 합니다.

(6) 패키지 전달 오류를 보고합니다.

좀 더 자세한 전달 설명을 하기 전에 서브넷 마스크에 대해 알아보겠습니다.

이전 문장 에서는 보조 IP 주소, 즉 IP 주소가 네트워크 번호와 호스트 번호로 구성되어 있다고 설명했습니다.

보조 IP 주소에는 다음과 같은 단점이 있습니다.

첫째, IP 주소 공간의 사용률이 낮은 경우가 있습니다. 각 클래스 a 주소 네트워크는 654.38+백만 개 이상의 호스트에 연결할 수 있으며 클래스 b 주소 네트워크당 6 만 개 이상의 호스트에 연결할 수 있습니다. 그러나 일부 네트워크는 네트워크로 연결된 컴퓨터의 수에 제한이 있어 이렇게 큰 수치에 이르지 못한다. 예를 들어 10 BASE-T 이더넷은 최대 노드 수가 1024 에 불과하다고 규정합니다. 이런 이더넷이 클래스 B 주소를 사용하면 6 만여 개의 IP 주소가 낭비되고, 주소 공간 활용률이 2% 미만이며, 다른 단위의 호스트에서는 이러한 낭비된 주소를 사용할 수 없습니다. 일부 유닛은 클래스 B 주소 네트워크를 신청했지만 연결된 호스트 수가 많지 않지만 향후 가능한 개발을 고려하여 충분한 클래스 C 주소를 신청하고 싶지 않습니다. IP 주소 낭비로 인해 IP 주소 공간의 자원이 너무 일찍 소모될 수도 있습니다.

둘째, 각 물리적 네트워크에 네트워크 번호를 할당하면 라우팅 테이블이 너무 커서 네트워크 성능이 저하됩니다.

각 라우터는 라우팅 테이블에서 다른 네트워크에 도달하는 방법을 찾을 수 있어야 합니다. 따라서 인터넷에 네트워크가 많을수록 라우터 라우팅 테이블의 항목이 많아집니다. 이렇게 하면 각 물리적 네트워크에 네트워크 번호를 할당할 수 있는 충분한 IP 주소 리소스가 있어도 라우터의 라우팅 테이블 항목이 너무 많아질 수 있습니다. 이로 인해 라우터 비용이 증가할 뿐만 아니라 (더 많은 스토리지 공간 필요) 라우팅을 검색할 때 더 많은 시간이 소요됩니다. 동시에 라우터 간에 교환되는 라우팅 정보가 급격히 증가하여 라우터와 인터넷 전체의 성능이 저하됩니다.

셋째, 보조 IP 주소가 유연하지 않습니다.

응급 상황에서는 한 단위가 즉시 새 위치에서 새 네트워크를 열어야 하는 경우가 있습니다. 그러나 새로 추가된 네트워크는 새 IP 주소를 신청할 때까지 인터넷에 연결할 수 없습니다. 우리는 인터넷 규제 기관에서 새로운 네트워크 번호를 미리 신청하지 않고도 한 회사가 언제든지 자신의 네트워크를 유연하게 늘릴 수 있는 방법이 있기를 희망합니다. 원래의 2 차 IP 주소는 이것을 할 수 없다.

따라서 위의 문제를 해결하기 위해 1985 부터 IP 주소에 "서브넷 번호 필드" 를 추가하여 보조 IP 주소를 3 차 IP 주소로 만들면 이러한 문제를 잘 해결할 수 있으며 사용하기도 유연합니다. 이를 서브넷 또는 서브넷 주소 지정 또는 서브넷 라우팅이라고 합니다. 서브넷은 이미 인터넷의 공식 표준 프로토콜이 되었다.

서브넷의 기본 아이디어는 다음과 같습니다.

(1) 많은 물리적 네트워크를 보유한 조직은 물리적 네트워크를 여러 서브넷으로 나눌 수 있습니다. 서브넷을 나누는 것은 순전히 단위 내부 사무이다. 이 단원 외부의 네트워크는 이 네트워크가 몇 개의 서브넷으로 구성되어 있는지 알 수 없다. 왜냐하면 이 단원은 대외적으로 여전히 네트워크 형태로 나타나기 때문이다.

(2) 서브넷은 네트워크의 호스트 번호에서 일부 비트를 서브넷 번호 subnet-id 로 차용하는 방법으로, 물론 호스트 번호도 같은 자릿수를 줄입니다. 그래서 2 차 IP 주소는 회사 내부의 3 차 IP 주소 (네트워크 번호, 서브넷 번호, 호스트 번호) 가 되었습니다. 또한 다음 기호로 나타낼 수 있습니다.

IP 주소: = (,< 서브넷 번호 >,< 호스트 번호 >}

(3) 다른 네트워크에서 회사 호스트로 전송된 모든 IP 데이터그램은 여전히 IP 데이터그램의 목적 네트워크 번호를 기준으로 회사 네트워크에 연결된 라우터를 찾습니다. 하지만 이 라우터는 IP 데이터그램을 받은 후 대상 네트워크 번호와 서브넷 번호에 따라 대상 서브넷을 찾아 IP 데이터그램을 대상 호스트에 전달했다.

간단히 말해 원래 IP 주소의 총 길이는 그대로 유지되며 원래' 네트워크 번호+호스트 번호' 로 구성된 IP 주소는' 네트워크 번호+서브넷 번호+호스트 번호' 로 변경되었습니다. 다른 네트워크는 현재 네트워크의 호스트를 찾을 때 여전히 네트워크 번호를 사용하기 때문에 현재 네트워크의 서브넷은 외부 네트워크에서 볼 수 없습니다. 이 네트워크의 라우터가 IP 데이터를 수신하면 대상 네트워크 번호와 서브넷 번호를 기준으로 대상 서브넷을 찾아 IP 데이터그램을 대상 호스트로 보냅니다.

이제 남은 문제는 데이터그램 (목표 주소가145.133.10) 이 라우터 R 1 에 도착했다고 가정해 봅시다. 그럼 이 라우터는 어떻게 서브넷 145.3.3.0 으로 전달될까요?

IP 데이터보의 헤더에서 소스 호스트나 대상 호스트가 연결된 네트워크가 서브넷으로 나뉘어지는지 알 수 없습니다. 이는 32 비트 IP 주소 자체와 데이터그램의 헤더에는 서브넷 구분에 대한 정보가 포함되어 있지 않기 때문입니다. 따라서 서브넷 마스크를 사용하는 또 다른 방법을 찾아야 합니다.

서브넷 마스크는 간단히 호스트 번호를 제외한 모든 숫자를 0 에서 1 으로 설정하는 것입니다.

클래스 b 주소를 예로 들어 보겠습니다.

레벨 3 IP 주소의 네트워크 번호와 서브넷 번호를 연결하고 서브넷 마스크와 and 연산을 수행하여 서브넷의 네트워크 주소를 얻습니다.

인터넷 표준에 따르면 모든 네트워크는 서브넷 마스크를 사용해야 하며 라우터 라우팅 테이블에 서브넷 마스크 열이 있어야 합니다. 네트워크에 서브넷이 없는 경우 네트워크의 서브넷 마스크는 기본 서브넷 마스크를 사용합니다.

그렇다면 서브넷이 없는 상태에서 왜 서브넷 마스크를 사용해야 합니까?

이는 라우팅 테이블을 쉽게 찾을 수 있도록 하기 위한 것입니다.

기본 서브넷 마스크에서 1 의 위치는 IP 주소의 네트워크 번호 필드 net-id 와 정확히 일치합니다. 따라서 기본 서브넷 마스크와 서브넷이 아닌 IP 주소를 사용하여 비트별로 합칠 경우 해당 IP 주소의 네트워크 주소를 얻을 수 있어야 합니다. 이렇게 하면 주소의 범주를 확인하지 않고도 어떤 IP 주소인지 알 수 있다. 분명히,

서브넷 마스크는 네트워크 또는 서브넷의 중요한 속성입니다. RFC950 이 인터넷의 공식 표준이 되면 라우터는 이웃과 라우팅 정보를 교환할 때 네트워크 (또는 서브넷) 의 서브넷 마스크를 알려야 합니다. 라우터 라우팅 테이블의 각 항목에 대해 대상 네트워크 주소 외에 네트워크의 서브넷 마스크도 제공해야 합니다. 라우터가 두 서브넷에 연결되면 두 개의 네트워크 주소와 두 개의 서브넷 마스크가 있습니다.

클래스 B 주소를 예로 들어 몇 개의 서브넷을 나눌 수 있는지 설명합니다. 고정 길이 서브넷을 사용하면 모든 서브넷의 서브넷 마스크가 동일합니다.

표에 있는 서브넷 번호의 자릿수는 0, 1, 15, 16 이 없습니다. 의미가 없기 때문입니다. 인터넷 표준 프로토콜이 된 RFC950 문서에 따라 서브넷 번호는 모두 1 또는 모두 0 일 수는 없지만 CIDR 이 분류되지 않은 도메인 간 라우팅에 널리 사용됨에 따라 모든 1 및 모든 0 서브넷 번호를 사용할 수 있지만 라우터에서 사용하는 라우팅 소프트웨어가 이 새로운 사용에서는 숫자가 적은 서브넷 번호를 사용하면 서브넷당 연결할 수 있는 호스트 수가 더 많다는 것을 알 수 있습니다.

반면 더 많은 수의 서브넷 번호를 사용하면 서브넷 수는 늘어나지만 서브넷당 연결할 수 있는 호스트 수는 줄어듭니다. 따라서 네트워크의 특정 상황 (분할해야 할 서브넷 수, 서브넷당 최대 호스트 수) 에 따라 적절한 서브넷 마스크를 선택할 수 있습니다.

따라서 서브넷은 유연성을 증가시키지만 네트워크에 연결할 수 있는 총 호스트 수를 줄입니다.

서브넷을 나누는 경우 패킷 전달 알고리즘을 적절하게 변경해야 합니다.

서브넷을 사용한 후 라우팅 테이블에는 대상 네트워크 주소, 서브넷 마스크 및 다음 홉 주소의 세 가지 항목이 포함되어야 합니다.

그래서 이전 과정은 다음과 같이 변했습니다.

(1) 수신된 데이터그램 헤더에서 대상 IP 주소 D 를 추출합니다.

(2) 직접 배송인지 아닌지를 먼저 판단한다. 라우터가 직접 연결된 네트워크를 하나씩 확인합니다. 각 네트워크의 서브넷 마스크와 d to 및 비트 단위 검사 결과가 해당 네트워크 주소와 일치하는지 확인합니다. 일치하는 경우 패킷을 직접 전달 (물론 D 를 물리적 주소로 변환하고 데이터그램을 프레임으로 캡슐화하여 전송해야 함) 하고 전달 작업이 종료됩니다. 그렇지 않으면 간접적으로 전달되어 실행됩니다 (3).

(3) 라우팅 테이블에 대상 주소가 D 인 특정 호스트 경로가 있는 경우 라우팅 테이블에 지정된 다음 홉 라우터로 데이터 그램을 전달합니다. 그렇지 않으면 (4) 를 실행합니다.

(4) 라우팅 테이블의 각 행 (대상 네트워크 주소, 서브넷 마스크, 다음 홉 주소) 에 대해 서브넷 마스크와 그 안의 D 를 사용하여 AND 를 비트로 지정합니다. 그 결과 n .. n 이 회선의 대상 네트워크 주소와 일치하면 회선 지정 다음 홉 라우터로 데이터그램이 전송됩니다. 그렇지 않으면 실행 (5) 합니다.

5) 라우팅 테이블에 기본 경로가 있는 경우 라우팅 테이블에 표시된 기본 라우터로 데이터그램을 전달합니다. 그렇지 않으면 실행 (6)

(6) 패키지 전달 오류를 보고합니다.