2.1 소개
그림 1-4에서 볼 수 있듯이 TCP/IP 프로토콜 제품군에서 링크 계층에는 세 가지 주요 목적이 있습니다:
(1) IP 모듈에 대한 IP 데이터그램 보내기 및 받기
(2) ARP에 대한 ARP 요청 보내기 및 받기 모듈 ARP 응답
(3) RARP 요청을 보내고 RARP에 대한 RARP 응답을 받습니다.
TCP/IP는 이더넷, 토큰 링, FDDI(Fiber Distributed Data Interface) 및 RS-232 직렬 회선과 같이 네트워크에서 사용되는 하드웨어에 따라 다양한 링크 계층 프로토콜을 지원합니다.
이 장에서는 이더넷 링크 계층 프로토콜, 두 개의 직렬 인터페이스 링크 계층 프로토콜(SLIP 및 PPP), 대부분의 구현에 포함된 루프백 드라이버에 대해 자세히 설명합니다. 이더넷과 SLIP은 이 책의 대부분의 예에서 사용되는 링크 계층입니다. 이 책의 후반부에서 여러 번 접하게 될 개념인 MTU(최대 전송 단위)에 대한 소개가 제공됩니다. 또한 직렬 회선에 대한 MTU를 선택하는 방법에 대해서도 논의했습니다.
2.2 이더넷 및 IEEE 802 캡슐화
이더넷이라는 용어는 일반적으로 Digital Equipment Corp., Intel Corp. 및 Xerox가 1982년에 공동으로 발표한 표준을 의미합니다. 오늘날 TCP/IP에서 사용되는 주요 LAN 기술입니다. CSMA/CD라는 미디어 액세스 방식을 사용합니다. 이는 Carrier Sense, Multiple Access with CollisionDetection을 의미합니다. 속도는 10Mb/s이고 주소는 48비트입니다.
몇 년 후, IEEE(전기전자공학회) 802 위원회는 전체 CSMA/CD 네트워크용 802.3, 토큰 버스 네트워크용 802.4, 토큰 링 네트워크용 802.5와 함께 약간 다른 표준 세트를 발표했습니다. 이 세 가지의 공통적인 특징은 802 네트워크에 공통적으로 적용되는 LLC(Logical Link Control)인 802.2 표준에 의해 정의됩니다. 불행하게도 802.2와 802.3은 이더넷과 다른 프레임 형식을 정의합니다. 문서 [Stallings 1987]는 모든 IEEE 802 표준에 대한 자세한 소개를 제공합니다.
TCP/IP 세계에서 이더넷에 대한 IP 데이터그램 캡슐화는 RFC 894 [Hornig 1984]에 정의되어 있으며, IEEE 802 네트워크에 대한 IP 데이터그램 캡슐화는 RFC 1042 [Postel and Reynolds 1988]에 정의되어 있습니다. 호스트 요구 사항 RFC에서는 모든 인터넷 호스트가 10Mb/s 이더넷 케이블에 연결되어야 합니다.
1. RFC 894(이더넷) 캡슐화 형식을 사용하여 패킷을 보내고 받을 수 있어야 합니다.
2. RFC 894와 혼합된 RFC 1042(IEEE 802) 캡슐화 형식으로 패킷을 수신할 수 있어야 합니다.
3. RFC 1042 형식으로 캡슐화된 패킷을 보내는 것이 가능할 수도 있습니다.
호스트가 두 가지 유형의 패킷 데이터를 동시에 보낼 수 있는 경우 전송된 패킷은 구성 가능해야 하며 기본적으로 RFC 894 패킷이어야 합니다.
가장 일반적으로 사용되는 캡슐화 형식은 RFC 894에 정의된 형식입니다. 그림 2-1은 두 가지 다른 형태의 패키징 형식을 보여줍니다. 다이어그램의 각 상자 아래에 있는 숫자는 길이(바이트)입니다. 두 프레임 형식 모두 48비트(6바이트) 대상 및 소스 주소를 사용합니다(802.3에서는 16비트 주소 사용을 허용하지만 일반적으로 48비트 주소 사용). 이것이 이 책에서 하드웨어 주소라고 부르는 것입니다. ARP 및 RARP 프로토콜(4장 및 5장)은 32비트 IP 주소를 48비트 하드웨어 주소에 매핑합니다.
다음 2바이트는 두 프레임 형식 모두에서 다릅니다. 802 표준에서 정의한 프레임 형식에서 길이 필드는 후속 데이터의 바이트 길이를 참조하지만 CRC 검사 코드는 포함하지 않습니다. 이더넷 유형 필드는 후속 데이터 유형을 정의합니다. 802 표준에서 정의한 프레임 형식에서 유형 필드는 후속 SNAP(Sub-network Access Protocol)의 헤더에 의해 제공됩니다. 다행스럽게도 802에서 정의한 유효한 길이 값 중 이더넷의 유효한 유형 값과 동일하지 않으므로 두 프레임 형식을 구별할 수 있습니다.
이더넷 프레임 형식에서는 유형 필드 뒤에 데이터가 오고, 802 프레임 형식에서는 802.2LLC의 3바이트와 802.2SNAP의 5바이트가 옵니다. DSAP(Destination Service Access Point)와 SSAP(Source Service Access Point)의 값은 모두 0xaa로 설정되어 있습니다. Ct rl 필드의 값은 3으로 설정됩니다. 조직 코드의 후속 3바이트는 모두 0으로 설정됩니다. 다음 2바이트 유형 필드는 이더넷 프레임 형식과 동일합니다(다른 유형 필드 값은 RFC 1340 [Reynolds and Postel 1992] 참조).
CRC 필드는 프레임 내의 후속 바이트 오류에 대한 순환 중복 코드 검사(체크섬)에 사용됩니다(FCS 또는 프레임 검사 시퀀스라고도 함). 802.3 표준에 의해 정의된 프레임과 이더넷 프레임에는 최소 길이 요구 사항이 있습니다. 802.3에서는 데이터 부분이 최소 38바이트 이상이어야 한다고 규정하고 있으며, 이더넷의 경우 최소 46바이트가 필요합니다. 이를 위해서는 부족한 공간에 패드 바이트를 삽입해야 합니다. 이 최소 길이는 회선에서 패킷 관찰을 시작할 때 발생합니다.
이 책에서는 이더넷 캡슐화 형식이 가장 일반적인 캡슐화 형식이기 때문에 필요한 경우 이를 제공할 것입니다.
2.3 테일 포장
RFC 893 [Leffler and Karels 1984]에서는 트레일러 캡슐화라고 하는 이더넷의 또 다른 캡슐화 형식을 설명합니다. 이는 DEC VA X 시스템에서 실행될 때 초기 BSD 시스템에서 사용된 실험적인 형식으로, IP 데이터그램의 필드 순서를 조정하여 성능을 향상시켰습니다. 이더넷 데이터 프레임에서 첫 번째 부분은 가변 길이 필드(IP 헤더 및 TCP 헤더)입니다. 데이터가 커널에 복사될 때 데이터 프레임의 데이터 부분이 하드웨어 페이지에 매핑되어 메모리 간 복사본을 저장할 수 있도록 끝(CRC 앞)으로 이동합니다. TCP 데이터그램의 길이는 512바이트의 정수배이며 커널의 페이지 테이블에서 처리할 수 있습니다. 두 호스트는 ARP 확장 프로토콜을 협상하고 사용하여 데이터 프레임의 끝 부분을 캡슐화합니다. 이러한 데이터 프레임은 서로 다른 이더넷 프레임 유형 값을 정의해야 합니다.
이제 꼬리 캡슐화는 눈살을 찌푸리므로 이에 대한 예를 제시하지 않겠습니다. 관심 있는 독자는 RFC 893과 [Leffler et al. 1989]의 섹션 11.8을 참조하세요.
2.4 SLIP: 직렬 회선 IP
SLIP의 정식 명칭은 Serial Line IP입니다. 이는 직렬 회선을 통한 IP 데이터그램 캡슐화의 간단한 형태이며 RFC 1055 [Romkey 1988]에 자세히 설명되어 있습니다. SLIP은 가정에 있는 거의 모든 컴퓨터가 인터넷에 접속해야 하는 RS-232 직렬 포트와 고속 모뎀에 적용됩니다. 다음 규칙은 SLIP 프로토콜에 의해 정의된 프레임 형식을 설명합니다.
1. IP 데이터그램은 END(0xc0)라는 특수 문자로 끝납니다. 동시에, 데이터그램 도착 전의 회선 잡음이 데이터그램의 내용으로 간주되는 것을 방지하기 위해 대부분의 구현에서는 데이터그램 시작 부분에 END 문자도 전달합니다(회선 잡음이 있는 경우 END 문자는 오류 메시지를 종료합니다.이렇게 하면 현재 메시지는 올바르게 전송되지만 이전 오류 메시지가 상위 계층으로 전달된 후에는 그 내용이 의미가 없어 폐기됩니다.
2. IP 메시지의 문자가 END이면 이를 대체하기 위해 2바이트 0xdb 및 0xdc를 연속적으로 전송해야 합니다. 특수문자 0xdb는 SLIP의 ESC 문자라고 부르지만, 그 값은 ASCII 코드의 ESC 문자(0x1b)와 다릅니다.
3. IP 메시지의 문자가 SLIP의 ESC 문자인 경우 이를 대체하기 위해 2바이트 0xdb 및 0xdd를 연속적으로 전송해야 합니다. 그림 2-2의 예는 END 문자와 ESC 문자를 포함하는 IP 패킷입니다. 이 예에서 직렬 회선을 통해 전송된 총 바이트 수는 원래 IP 메시지 길이에 4바이트를 더한 값입니다.
SLIP은 간단한 프레임 캡슐화 방법이며 언급할 만한 몇 가지 단점이 있습니다.
1. 각 끝은 상대방의 IP 주소를 알아야 합니다. 이 끝의 IP 주소를 상대방에게 알릴 방법은 없습니다.
2. 데이터 프레임에는 유형 필드가 없습니다(이더넷의 유형 필드와 유사). SLIP에 직렬 회선을 사용하는 경우 동시에 다른 프로토콜을 사용할 수 없습니다.
3.SLIP은 데이터 프레임에 체크섬을 추가하지 않습니다(이더넷의 CRC 필드와 유사). SLIP으로 전송된 메시지가 회선 잡음의 영향을 받아 오류가 발생하면 상위 계층 프로토콜을 통해서만 이를 발견할 수 있습니다(또 다른 방법은 새로운 모뎀이 오류 메시지를 감지하고 수정할 수 있는 방법입니다). 이런 방식으로 상위 계층 프로토콜이 어떤 형태의 CRC를 제공하는 것이 중요합니다. 3장과 17장에서는 IP 헤더와 TCP 헤더 및 해당 데이터에 항상 체크섬이 있음을 살펴보겠습니다. 11장에서는 UDP 헤더와 해당 데이터의 체크섬이 선택 사항임을 알 수 있습니다. 이러한 단점에도 불구하고 SLIP은 여전히 널리 사용되는 프로토콜입니다.
SLIP的历史要追溯到1984年，Rick Adams第一次在4.2BSD系统中实现。
尽管它本身的描述是一种非标准的协议，但是随着调制解调器的速率和可靠性的提高，SLIP越来越流行。
现在，它的许多产品可以公开获得，而且很多厂家都支持这种协议。
2.5 압축된 SLIP
직렬 회선의 속도는 일반적으로 낮고(19200b/s 이하) 통신이 대화형인 경우가 많기 때문에(예: Telnet 및 Rlogin, 둘 다 TCP를 사용) SLIP 회선에는 작은 TCP 패킷이 많이 있습니다. . 1바이트의 데이터를 전송하기 위해서는 20바이트의 IP 헤더와 20바이트의 TCP 헤더가 필요하여 총 40바이트가 넘는다. (19.2절에서는 Rlogin 세션 중 간단한 명령을 입력할 때 이 작은 바이트에 대해 설명한다. 메시지 전송 세부 사항)
이러한 성능 결함을 인식하여 CSLIP(압축 SLIP)이라는 새로운 프로토콜이 제안되었으며 이는 RFC 1144 [Jacobson 1990a]에 자세히 설명되어 있습니다. CSLIP은 일반적으로 위의 40바이트를 3 또는 5바이트로 압축할 수 있습니다. 각 연결 헤더의 특정 필드는 일반적으로 변경되지 않는다는 점을 알고 CSLIP의 각 끝에서 최대 16개의 TCP 연결을 유지할 수 있습니다. 변경된 필드의 경우 대부분은 작은 수치 합계 변경에 불과했습니다. 이러한 압축된 헤더는 대화형 응답 시간을 크게 단축합니다.
现在大多数的SLIP产品都支持CSLIP。作者所在的子网（参见封面内页）中有两条SLIP链路，它们均是CSLIP链路。
2.6 PPP: 지점간 프로토콜
지점 간 프로토콜인 PPP는 SLIP 프로토콜의 모든 결함을 수정합니다. PPP는 다음 세 부분으로 구성됩니다.
1. 직렬 링크에서 IP 데이터그램을 캡슐화하는 방법. PPP는 8비트 데이터를 사용하고 패리티가 없는 비동기 모드(예: 대부분의 컴퓨터에 있는 유비쿼터스 직렬 인터페이스)와 비트 지향 동기 링크를 모두 지원합니다.
2. 데이터 링크의 링크 제어 프로토콜(LCP: 링크 제어 프로토콜)을 설정, 구성 및 테스트합니다. 이를 통해 통신 당사자는 다양한 옵션을 식별하기 위해 협상할 수 있습니다.
3. 다양한 네트워크 계층 프로토콜을 위한 네트워크 제어 프로토콜(NCP: Network Control Protocol) 시스템. 현재 RFC에 의해 정의된 네트워크 계층에는 IP, OSI 네트워크 계층, DECnet 및 AppleTalk가 포함됩니다. 예를 들어, IP NCP를 사용하면 CSLIP(약어 NCP를 TCP 앞에 사용할 수도 있음)와 유사하게 메시지 헤더를 압축할지 여부에 대해 양 당사자가 동의할 수 있습니다.
RFC 1548 [Simpson 1993]은 메시지 캡슐화 방법과 링크 제어 프로토콜을 설명합니다. RFC 1332 [McGregor 1992]는 IP에 대한 네트워크 제어 프로토콜을 설명합니다. PPP 데이터 프레임의 형식은 ISO HDLC(고급 데이터 링크 제어) 표준과 매우 유사합니다. 그림 2-3은 PPP 데이터 프레임의 형식이다.
각 프레임은 플래그 문자 0x7e로 시작하고 끝납니다. 그 뒤에는 항상 0xff 값을 갖는 주소 바이트가 오고 그 다음에는 0x03 값을 갖는 제어 바이트가 옵니다.
다음은 이더넷의 유형 필드 기능과 유사한 프로토콜 필드입니다. 값이 0x0021이면 정보 필드가 IP 데이터그램임을 나타내고, 값이 0xc021이면 정보 필드가 링크 제어 데이터임을 나타내고, 값이 0x8021이면 정보 필드가 네트워크 제어 데이터임을 나타냅니다. . CRC 필드(또는 FCS, Frame Check Sequence)는 데이터 프레임의 오류를 감지하는 데 사용되는 순환 중복 검사 코드입니다. 플래그 문자의 값이 0x7e이므로 PPP는 이 문자가 정보 필드에 나타날 때 이스케이프해야 합니다. 동기식 링크에서 이 프로세스는 비트 스터핑(Bit Stuffing)이라는 하드웨어 기술을 통해 수행됩니다[Tanenbaum 1989]. 비동기 링크에서는 특수 문자 0x7d가 이스케이프 문자로 사용됩니다. PPP 데이터 프레임에 나타날 때 다음 문자의 6번째 비트는 보수를 받아야 합니다.구체적인 구현 프로세스는 다음과 같습니다: 1. 문자 0x7e가 발견되면
두 문자 0x7d 및 0x5e를 연속적으로 전송해야 합니다. 플래그 문자의 이스케이프를 달성합니다.
2. 이스케이프 문자 0x7d를 만나면 이스케이프 문자의 이스케이프를 실현하려면 0x7d와 0x5d라는 두 문자를 연속적으로 전송해야 합니다.
3. 기본적으로 문자 값이 0x20보다 작은 경우(예: ASCII 제어 문자) 일반적으로 이스케이프됩니다. 예를 들어 0x01이라는 문자를 만나면 0x7d와 0x21이라는 두 개의 문자를 연속적으로 전송해야 한다. (이때 6번째 비트는 보수를 취하면 1이 되고 앞의 두 경우에는 0으로 변경된다.) .
그 이유는 두 호스트의 직렬 인터페이스 드라이버나 모뎀에 해당 문자가 나타나는 것을 방지하기 위한 것입니다. 때로는 이러한 제어 문자를 특별한 의미가 있는 것으로 해석하기 때문입니다. 또 다른 가능성은 링크 제어 프로토콜을 사용하여 32자 내의 특정 값을 이스케이프해야 하는지 여부를 지정하는 것입니다. 기본적으로 32자 모두 이스케이프됩니다.
SLIP과 마찬가지로 PPP는 저속 직렬 링크에서 자주 사용되므로 프레임당 바이트 수를 줄이면 애플리케이션 상호 작용 지연을 줄일 수 있습니다. 링크 제어 프로토콜을 사용하면 대부분의 제품에서 식별자와 주소 필드를 생략하고 프로토콜 필드를 2바이트에서 1바이트로 줄일 수 있습니다. PPP 프레임 형식을 이전 SLIP 프레임 형식(그림 2-2)과 비교하면 PPP는 3바이트만 추가한다는 것을 알 수 있습니다. 1바이트는 프로토콜 필드용으로 예약되어 있고 나머지 2바이트는 CRC 필드 사용용으로 예약되어 있습니다. . 또한 IP 네트워크 제어 프로토콜을 사용하면 대부분의 제품에서 Van Jacobson 메시지 헤더 압축 방법(CSLIP 압축에 해당)을 사용하여 IP 및 TCP 헤더 길이를 줄일 수 있습니다.
일반적으로 PPP는 SLIP에 비해 다음과 같은 장점이 있습니다:
(1) PPP는 IP 프로토콜뿐만 아니라 단일 직렬 회선에서 여러 프로토콜 실행을 지원합니다. (
2) 각 프레임에는 순환 중복 검사가 있습니다.
(3)) 통신 당사자는 동적으로 협상할 수 있습니다. IP 주소(IP 네트워크 제어 프로토콜 사용),
(4) CSLIP와 유사하게 TCP 및 IP 메시지 헤더가 압축됩니다.
(5) 링크 제어 프로토콜은 여러 데이터 링크 옵션을 압축할 수 있습니다. 설정을 합니다.
이러한 장점을 위해 지불된 대가는 각 프레임 헤더의 추가 3바이트, 링크가 설정될 때 전송될 여러 협상 데이터 프레임 및 더 복잡한 구현입니다.
尽管PPP比SLIP有更多的优点，但是现在的SLIP用户仍然比PPP用户多。随着产品越来越多，产家也开始逐渐支持PPP，因此最终PPP应该取代SLIP。
2.7 루프백 인터페이스
대부분의 제품은 동일한 호스트에서 실행되는 클라이언트와 서버 프로그램이 TCP/IP를 통해 통신할 수 있도록 루프백 인터페이스를 지원합니다. 클래스 A 네트워크 번호 127은 루프백 인터페이스용으로 예약되어 있습니다. 관례적으로 대부분의 시스템은 이 인터페이스에 IP 주소 127.0.0.1을 할당하고 이름을 localhost로 지정합니다. 루프백 인터페이스로 향하는 IP 데이터그램은 어떤 네트워크에도 나타날 수 없습니다.
전송 계층이 대상 주소가 루프백 주소임을 감지하면 전송 계층 중 일부와 모든 네트워크 계층 논리 작업을 생략할 수 있어야 한다고 상상합니다. 그러나 대부분의 제품은 여전히 전송 계층과 네트워크 계층의 모든 프로세스를 완료하고 네트워크 계층을 떠날 때 IP 데이터그램을 자신에게 반환합니다. 그림 2-4는 루프백 인터페이스에서 IP 데이터그램을 처리하는 간단한 프로세스입니다.
그림에서 지적해야 할 핵심 사항은 다음과 같습니다.
1. 루프백 주소(보통 127.0.0.1)로 전달되는 모든 데이터는 IP로 입력됩니다.
2. 브로드캐스트 주소나 멀티캐스트 주소로 전송된 데이터그램의 복사본은 루프백 인터페이스로 전송된 다음 이더넷으로 전송됩니다. 이는 브로드캐스트 전달과 멀티캐스트 전달의 정의(12장)에 호스트 자체가 포함되기 때문입니다.
3. 호스트의 IP 주소로 전송된 모든 데이터는 루프백 인터페이스로 전송됩니다.
루프백 데이터를 처리하기 위해 전송 계층과 IP 계층 방식을 사용하는 것은 비효율적으로 보일 수 있지만, 루프백 인터페이스를 네트워크 계층 아래의 또 다른 링크 계층으로 간주할 수 있으므로 설계가 단순화됩니다. 네트워크 계층은 루프백 인터페이스가 이를 IP 입력 대기열로 반환한다는 점을 제외하면 다른 링크 계층과 마찬가지로 루프백 인터페이스에 데이터그램을 전달합니다.
그림 2-4에서 또 다른 암시적인 의미는 호스트 자신의 IP 주소로 전송된 IP 데이터그램이 일반적으로 해당 네트워크에 나타나지 않는다는 것입니다. 예를 들어, 이더넷 네트워크에서는 일반적으로 패킷이 전송되거나 다시 읽혀지지 않습니다. 일부 BSD 이더넷 장치 드라이버의 설명은 많은 이더넷 인터페이스 카드가 자신이 보낸 데이터를 다시 읽을 수 없음을 나타냅니다. 호스트는 자신에게 전송된 IP 데이터그램을 처리해야 하므로 그림 2-4에 표시된 프로세스가 가장 간단한 접근 방식입니다.
4.4BSD系统定义了变量useloopback，并初始化为1。
但是，如果这个变量置为0，以太网驱动程序就会把本地分组送到网络，而不是送到环回接口上。
它也许不能工作，这取决于所使用的以太网接口卡和设备驱动程序。
2.8 최대 전송 단위 MTU
그림 2-1에서 볼 수 있듯이 이더넷과 802.3 모두 데이터 프레임 길이에 제한이 있으며 최대값은 각각 1500바이트와 1492바이트입니다. 이러한 링크 계층의 특성을 MTU(Maximum Transmission Unit)라고 합니다. 대부분의 다양한 유형의 네트워크에는 상한이 있습니다.
IP 계층에 전송할 데이터그램이 있고 데이터 길이가 링크 계층의 MTU보다 길면 IP 계층에서는 조각화를 수행하고 데이터그램을 여러 조각으로 나누어 각 조각이 MTU보다 작아지도록 해야 합니다. MTU. 섹션 11.5에서 IP 단편화 프로세스에 대해 논의할 것입니다.
그림 2-5에는 RFC 1191[Mogul and Deering 1990]에서 가져온 몇 가지 일반적인 MTU 값이 나열되어 있습니다. SLIP 및 PPP와 같은 지점 간 링크 계층의 MTU는 네트워크 미디어의 물리적 특성을 나타내지 않습니다. 오히려 이는 대화형 사용을 위해 충분히 빠른 응답 시간을 제공하도록 설계된 논리적 한계입니다. 섹션 2.10에서는 이 한도가 어떻게 계산되는지 살펴보겠습니다.
섹션 3.9에서는 netstat 명령을 사용하여 네트워크 인터페이스의 MTU를 인쇄합니다.
2.9 경로 MTU
동일한 네트워크에 있는 두 호스트가 서로 통신할 때 해당 네트워크의 MTU는 매우 중요합니다. 그러나 두 호스트 간의 통신이 여러 네트워크를 통과하는 경우 각 네트워크의 링크 계층은 서로 다른 MTU를 가질 수 있습니다. 중요한 것은 두 호스트가 위치한 네트워크의 MTU 값이 아니라 두 통신 호스트 간 경로의 최소 MTU입니다. 이를 경로 MTU라고 합니다.
두 호스트 사이의 경로 MTU는 반드시 일정할 필요는 없습니다. 그때 선택한 경로에 따라 다릅니다. 라우팅이 반드시 대칭일 필요는 없습니다(A에서 B로의 경로는 B에서 A로의 경로와 다를 수 있음). 따라서 경로 MTU가 양방향에서 반드시 일관되지는 않습니다.
RFC 1191 [Mogul and Deering 1990]에는 경로 MTU 발견 메커니즘, 즉 언제든지 경로 MTU를 결정하는 방법이 설명되어 있습니다. ICMP와 IP 단편화 방식을 소개한 후 어떻게 동작하는지 살펴보겠습니다. 섹션 11.6에서는 이 방법을 사용하여 ICMP 도달 불가능 오류가 발견되는 것을 볼 수 있습니다. 섹션 11.7에서는 Traceroute 프로그램도 이 방법을 사용하여 대상 노드에 대한 경로 MTU를 결정하는 것을 볼 수 있습니다. 11.8절과 24.2절에서는 제품이 경로 MTU 검색 방법을 지원할 경우 UDP와 TCP가 어떻게 작동하는지 소개합니다.
2.10 직렬 회선 처리량 계산
회선 속도가 9600b/s이고 바이트에 8비트, 시작 비트 및 정지 비트가 포함된 경우 회선 속도는 960B/s(바이트/초)입니다. 이 속도로 1024바이트 패킷을 전송하는 데는 1066ms가 걸립니다. SLIP 링크를 사용하여 대화형 응용 프로그램을 실행하고 FTP와 같은 다른 응용 프로그램도 실행하여 1024바이트의 데이터를 보내거나 받는 경우 일반적으로 대화형 응용 프로그램이 1024바이트를 보내거나 받을 수 있을 때까지 절반 시간(533ms)을 기다려야 합니다. 데이터 패킷 데이터가 전송됩니다.
다른 "청크" 패킷 데이터가 전송되기 전에 대화형 패킷 데이터가 전송될 수 있다고 가정합니다. 대부분의 SLIP 구현은 이러한 유형의 서비스 대기열 방법을 제공하여 더 큰 데이터 청크 앞에 대화형 데이터를 배치합니다. 대화형 통신에는 일반적으로 Telnet, Rlogin 및 FTP의 제어 부분(데이터가 아닌 사용자 명령)이 포함됩니다.
这种服务排队方法是不完善的。它不能影响已经进入下游（如串行驱动程序）队列的非交互数据。
同时，新型的调制解调器具有很大的缓冲区，因此非交互数据可能已经进入该缓冲区了。
대화형 애플리케이션의 경우 533ms를 기다리는 것은 허용되지 않습니다. 사람에 대한 관련 연구에 따르면 100~200ms를 초과하는 대화형 응답 시간은 나쁜 것으로 간주됩니다[Jacobson 1990a]. 대화형 메시지를 보낸 후 응답 정보(보통 에코 문자가 나타남)를 수신할 때까지의 왕복 시간입니다.
SLIP의 MTU를 256으로 줄이면 링크가 프레임을 전송하는 데 최대 266ms가 걸리고 그 중 절반은 133ms(일반적인 대기 시간)입니다. 이렇게 하면 더 나아지지만 여전히 완벽하지는 않습니다. 우리가 이를 선택한 이유(64 또는 128과 비교)는 대량의 데이터가 좋은 회선 활용도(예: 대용량 파일 전송)를 제공하기 때문입니다. CSLIP 메시지 헤더가 5바이트이고 전체 데이터 프레임 길이가 261바이트라고 가정하면, 256바이트의 데이터로 인해 라인 활용률이 98.1%, 프레임 헤더가 1.9%를 차지하는데 이 활용률은 매우 좋다. 의. MTU가 256 미만으로 낮아지면 대량의 데이터를 전송하는 데 필요한 최대 처리량이 줄어듭니다.
그림 2-5에 나열된 MTU 값 중 지점 간 링크의 MTU는 296바이트입니다. 데이터가 256바이트이고 TCP 및 IP 헤더가 40바이트를 차지한다고 가정합니다. MTU는 링크 계층에 대한 IP 쿼리의 결과이므로 이 값에는 일반적인 TCP 및 IP 헤더가 포함되어야 합니다. 이를 통해 IP를 조각화하는 방법에 대한 결정이 내려지게 됩니다. IP는 CSLIP의 압축에 대해 아무것도 모릅니다.
평균 대기 시간 계산(가장 큰 데이터 프레임을 전송하는 데 필요한 시간의 절반)은 대화형 통신과 대용량 데이터 전송의 두 가지 경우의 SLIP 링크(또는 PPP 링크)에만 적용됩니다. 대화형 통신만 있는 경우 회선 속도가 9600b/s이면 어떤 방향으로든 1바이트 데이터의 왕복(5바이트 압축 프레임 헤더 가정)에 약 12.5ms가 걸립니다. 앞서 언급한 100~200ms에 비하면 훨씬 작은 수치입니다. 프레임 헤더가 40바이트에서 5바이트로 압축되므로 1바이트 데이터의 왕복 시간이 85ms에서 12.5ms로 단축됩니다.
불행하게도 최신 오류 수정 및 압축 모뎀을 사용하면 이러한 계산이 더 어렵습니다. 이러한 모뎀이 사용하는 압축 방법은 회선에 전송되는 바이트 수를 크게 줄이지만 오류 수정 메커니즘은 전송 시간을 늘립니다. 그러나 이러한 계산은 건전한 의사 결정을 위한 출발점입니다. 이후 장에서는 이러한 직렬 회선 처리량 계산을 사용하여 데이터가 직렬 회선을 통해 이동하는 데 걸리는 시간을 확인합니다.
2.11 요약
이 장에서는 인터넷 프로토콜 제품군의 가장 낮은 수준 프로토콜인 링크 계층 프로토콜에 대해 설명합니다. 이더넷과 IEEE802.2/802.3의 캡슐화 형식, SLIP과 PPP의 캡슐화 형식을 비교했습니다. SLIP과 PPP는 저속 링크에서 자주 사용되기 때문에 둘 다 자주 변경되지 않는 공통 필드를 압축하는 방법을 제공합니다. 이로 인해 대화형 성능이 향상됩니다.
대부분의 구현은 루프백 인터페이스를 제공합니다. 이 인터페이스는 특수 루프백 주소(보통 127.0.0.1)를 통해 액세스할 수 있습니다. 또한 호스트가 소유한 IP 주소로 IP 데이터그램을 전송하여 수행할 수도 있습니다. 루프백 데이터가 상위 계층 프로토콜 스택으로 반환되면 전송 계층과 IP 계층에 의해 완전히 처리됩니다. 지금까지 많은 링크가 갖고 있는 중요한 특징인 MTU에 대해 설명했는데, 이와 관련된 개념이 경로 MTU이다. SLIP 및 CSLIP 링크의 전송 지연은 일반적인 직렬 회선 MTU를 기반으로 계산되었습니다.
이 장의 내용은 오늘날 TCP/IP에서 사용되는 일반적인 데이터 링크 기술 중 일부만을 다루고 있습니다. TCP/IP가 성공한 이유 중 하나는 거의 모든 데이터 링크 기술에서 실행될 수 있다는 것입니다.