Z모뎀
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
Z모뎀은 YMODEM을 개선한 파일 전송 프로토콜이다. 성능 향상을 위해 슬라이딩 윈도우 방식을 도입하여 ACK 대기 시간을 줄였으며, 전송 재개 기능을 통해 파일 전송 실패 시 중단된 지점부터 다시 시작할 수 있도록 했다. 또한, 송신 측 자동 시작 기능과 확장된 32비트 CRC, 제어 문자 인용 기능을 제공한다. Z모뎀은 4GB 미만의 파일 전송에 적합하며, 터미널 이스케이프 문자 인코딩에 문제가 있을 수 있다. ZMODEM의 변형으로 ZedZap, LeechZmodem 등이 있으며, Chuck Forsberg의 Omen Technology, Inc.에서 개발한 구현이 널리 사용되었다.
더 읽어볼만한 페이지
- 파일 전송 프로토콜 - UUCP
UUCP는 유닉스 시스템 간 파일 복사, 원격 명령 실행, 이메일 및 유즈넷 뉴스 전송을 위한 프로토콜 및 프로그램 모음으로, 초기 인터넷 확장에 중요한 역할을 했으나 TCP/IP 기반 서비스 보편화로 사용이 감소했다. - 파일 전송 프로토콜 - TFTP
TFTP는 UDP 기반의 단순화된 파일 전송 프로토콜로, 구현이 간단하여 메모리가 제한적인 환경에서 라우터 부팅, 펌웨어 업데이트, 네트워크 부팅 등에 활용되며 보안 취약점 보완을 위한 고려 사항이 존재한다. - PC통신 - 전화 접속
전화 접속은 공중 교환 전화망을 통해 모뎀과 전화선으로 인터넷에 연결하는 방식으로, 1980년대부터 사용되었으나 광대역 인터넷의 등장으로 2000년대 이후 사용이 줄어 현재는 제한적으로 사용되며 사라지는 추세이다. - PC통신 - 전자우편
전자우편은 컴퓨터 네트워크를 이용하여 편지와 메시지를 주고받는 시스템으로, 시분할 메인프레임 통신에서 시작하여 @ 기호 주소 체계 도입 후 아파넷을 통해 대중화되었으며, 다양한 형식의 파일 첨부와 스팸 등의 문제에도 불구하고 널리 사용되는 통신 수단이다. - 통신공학 - 무선 통신
무선 통신은 전선 없이 전자기파 등을 이용하여 정보를 전달하는 방식으로, 마르코니의 무선 전신 실험 성공 이후 다양한 형태로 발전해왔으며, 현대 사회에서 필수적인 기술로 자리 잡았다. - 통신공학 - FM 방송
FM 방송은 주파수 변조 방식을 사용하여 음질이 좋고 잡음에 강하며 스테레오 방송과 부가 서비스를 제공하는 라디오 방송 기술이다.
| Z모뎀 | |
|---|---|
| 일반 정보 | |
| 개발자 | 척 포스버그 |
| 개발 날짜 | 1986년 |
| 기반 프로토콜 | YMODEM |
| 용도 | 파일 전송 프로토콜 |
| 하드웨어 | 모뎀 |
2. 특징
ZMODEM은 이전 프로토콜에 비해 다음과 같은 주요 특징을 갖는다.
- 성능 향상: 슬라이딩 윈도우 방식을 채택하여 네트워크 지연 시간으로 인한 성능 저하를 최소화하고, 스트리밍 전송 방식을 사용하여 데이터를 지속적으로 전송한다.
- 전송 재개: 파일 내 실제 위치를 나타내는 32비트 숫자를 사용하여 전송 실패 지점부터 전송을 재개할 수 있다.
- 자동 시작: 송신 측에서 전송을 시작하여 관리를 단순화한다.
- 확장된 32비트 CRC: 32비트 CRC를 사용하여 데이터 무결성을 보장하고 오류 검출 능력을 향상시켰다.
- 제어 문자 인용: 전송되는 데이터에 포함된 제어 문자를 특별하게 처리하여 통신 프로토콜에 영향을 미치지 않도록 한다.
2. 1. 성능 향상
ZMODEM은 슬라이딩 윈도우 방식을 채택하여 네트워크 지연 시간으로 인한 성능 저하를 최소화한다. 이는 ACK를 기다리지 않고 여러 패킷을 연속적으로 전송하는 방식이며, 전화 회선과 같이 지연 시간이 있는 환경에서 효율성을 높인다. 또한 스트리밍 전송 방식을 사용하여, 오류가 발생하지 않는 한 데이터를 지속적으로 전송한다. 이러한 방식을 통해 ZMODEM은 이전 프로토콜보다 훨씬 향상된 성능을 제공하며, 특히 오류 수정 기능이 내장된 링크에서 자주 사용되었다.2. 1. 1. 슬라이딩 윈도우
슬라이딩 윈도우는 송신 측에서 ACK (수신 확인)를 기다리지 않고 여러 패킷을 연속적으로 전송하는 방식이다. 전화 회선에는 지연 시간이 존재하므로, 이 ACK 대기 시간은 처리량 저하로 이어진다. 하지만 슬라이딩 윈도우에서는 ACK를 기다리지 않고 다음 패킷을 보내며, NAK (오류)를 보낼 때만 해당 패킷을 재전송한다.이 방식은 네트워크 지연이 있는 환경에서도 높은 전송 효율을 유지한다. 슬라이딩 윈도우는 TCP에서도 사용되는 기술이다.
2. 2. 전송 재개
ZMODEM은 패킷 번호를 파일 내 실제 위치를 나타내는 32비트 숫자로 대체했다. 이를 통해 파일 길이에 관계없이 전송 실패 지점으로 되돌리는 메시지를 보낼 수 있었다. 이와 동일한 기능은 전송이 실패하거나 의도적으로 중단된 경우에도 다시 시작하는 데 사용되었다. 이 경우, 수신자는 이전에 얼마나 많은 데이터가 수신되었는지 확인한 다음 해당 위치와 함께 메시지를 보내고, 자동으로 송신자가 해당 지점부터 전송을 시작하도록 한다.2. 3. 자동 시작
자동 시작은 전송 측에서 전송을 시작할 수 있도록 하여 관리를 단순화한다. 이전에는 파일을 받기 위해서, 사용자가 먼저 발신자에게 파일을 요청하여 "대기" 상태로 만든 다음, 로컬 프로그램으로 돌아가서 전송을 시작하는 명령을 호출해야 했다. 자동 전송을 사용하면 파일을 요청하기만 하면 발신자가 사용자의 프로그램에서 전송을 자동으로 시작한다.2. 4. 확장된 32비트 CRC
YMODEM에 비해 개선된 점 중 하나는 확장된 32비트 CRC를 사용한다는 것이다. 이는 데이터의 무결성을 더욱 강력하게 보장하며, XMODEM의 1바이트 체크섬에 비해 오류 검출 능력이 향상되었다.2. 5. 제어 문자 인용
YMODEM에 비해 개선된 점 중 하나는 제어 문자 인용이다. 이는 전송되는 데이터에 포함된 제어 문자를 특별하게 처리(인용)하여, 제어 문자가 통신 프로토콜에 영향을 미치지 않도록 하는 기능이다.3. 개선 사항 (영어 원문 참조)
ZMODEM은 수신 측의 확인(ACK) 없이 지속적으로 데이터를 전송하는 스트리밍 방식을 사용하여 효율성을 높였다. 이전 프로토콜들은 데이터를 패킷 단위로 나누어 전송하고 각 패킷마다 ACK를 기다려야 했기 때문에, 회선 지연 시간으로 인해 채널 효율이 떨어지는 문제가 있었다. 특히 모뎀 속도가 빨라질수록 이러한 문제는 더욱 심각해졌다.
이러한 문제를 해결하기 위해 슬라이딩 윈도우 방식이 도입되었고, ZMODEM은 더 나아가 ACK를 사용하지 않고 오류 발생 시에만 NAK (Negative Acknowledgement)를 전송하는 방식을 채택했다. ZMODEM은 X.25와 같이 오류 수정 기능이 내장된 링크에서 자주 사용되었기 때문에, 수신자는 발신자에게 다시 보내는 메시지를 최소화할 수 있었다. 결과적으로 ZMODEM은 전체 파일을 연속적인 스트림으로 전송하는 "스트리밍 프로토콜"로 불리며, 이전 프로토콜들보다 훨씬 향상된 성능을 제공했고, YMODEM-g와 같은 특수 프로토콜까지 대체했다.
3. 1. 스트리밍
ZMODEM은 수신 측의 ACK 없이 지속적으로 데이터를 전송하는 스트리밍 방식Streaming영어을 사용한다. 일반적인 파일 전송 프로토콜은 파일을 패킷 단위로 분할하여 전송하고, 수신 측은 각 패킷에 대해 확인(ACK) 메시지를 보낸다. 그러나 전화 회선에는 지연 시간이 존재하여 ACK를 기다리는 동안 채널 효율이 떨어진다.XMODEM은 128바이트 페이로드에 3바이트 헤더와 1바이트 체크섬을 사용하여 패킷당 총 132바이트를 사용했다. 300 bit/s 모뎀 시대에는 하나의 패킷을 보내는 데 약 4초가 걸렸고, 일반적인 지연 시간은 1/10초 정도였으므로 성능 오버헤드는 크지 않았다. 그러나 모뎀 속도가 빨라짐에 따라, 예를 들어 2400 bit/s에서는 패킷 전송에 약 0.55초가 걸려 사용 가능한 대역폭의 약 1/5가 ACK를 기다리는 데 낭비되었다. 9600 bit/s에서는 패킷 전송 시간이 0.13초로 단축되어 대역폭의 약 1/2이 낭비되었다.
이러한 문제를 해결하기 위해 슬라이딩 윈도우 방식이 도입되었다. 이 방식은 발신자가 ACK를 기다리지 않고 여러 패킷을 계속 전송하여 지연 시간을 줄이는 방식이다.
ZMODEM은 더 나아가 ACK를 아예 사용하지 않고, 오류가 발생했을 때만 NAK를 전송하는 방식을 채택했다. ZMODEM은 X.25와 같이 내장된 오류 수정 기능이 있는 링크에서 자주 사용되었기 때문에 수신자는 발신자에게 단일 메시지를 다시 보내지 않는 경우가 많았다. 결과적으로 시스템은 전체 파일을 지속적인 스트림으로 전송했으며, ZMODEM은 자체를 "스트리밍 프로토콜"이라고 지칭했다. 이는 이전의 일반적인 프로토콜보다 훨씬 향상된 성능을 제공했으며, YMODEM-g와 같은 특수 프로토콜까지 대체했다.
4. 변형 (Variations)
ZedZap은 고속 모뎀에서 더 나은 성능을 위해 8KB 블록을 사용하는 ZMODEM의 변형이었다. LeechZmodem은 BBS 다운로드 할당량을 속이는 악의적인 ZMODEM 변형이었다. 32KB 및 64KB 블록 길이를 가진 ZMODEM의 하위 호환 확장 기능은 ISDN 또는 TCP/IP 네트워크와 같은 고속 무오류 연결에서 성능을 향상시키기 위해 2002년과 2007년에 ADONTEC에서 만들었다.
Synchronet 개발자들은 zmtx/zmrx 패키지를 기반으로 하는 SEXYZ라는 최신 X/Y/ZMODEM 구현을 만들었는데, 이는 Windows 및 유닉스 변종에서 네이티브로 실행되며, 긴 파일 이름을 지원하고 더 빠르고 신뢰할 수 있는 데이터 전송을 지원한다. SEXYZ의 ZMODEM 구현은 SyncTERM 프로젝트에도 통합되었다. Synchronet, SEXYZ 및 SyncTERM은 모두 오픈 소스, 크로스 플랫폼, BBS 중심 프로젝트이다.
Forsberg 자신은 ZMODEM-90에 여러 개선 사항을 수집했다. 첫 번째는 MobyTurbo로, 제어 인용을 제거하여 성능을 약 15% 더 향상시켰다. 제어 문자를 "먹는" 네트워크에서도 ZMODEM-90은 모든 가능한 문자가 아닌 네트워크가 실제로 먹는 문자만 인용하도록 조정할 수 있다. 유사한 개선 사항을 통해 ZMODEM-90은 7비트 네트워크에서 작동할 수 있지만, 이전 프로토콜(케르미트 제외)은 어느 정도 8비트를 요구했다. 마지막으로 ZMODEM-90에는 압축되지 않은 파일의 성능을 더욱 향상시키기 위한 기본 런 길이 인코딩 압축 시스템이 포함되어 있다.
5. 한계
ZMODEM은 몇 가지 기술적 한계를 가지고 있다. ZMODEM 패킷 중 일부는 전송된 파일 내의 바이트 오프셋을 32비트 부호 없는 정수로 포함하는데, 이 때문에 4GB 미만의 파일만 안정적으로 전송할 수 있다. 또한, (l)rzsz 참조 구현은 텔넷이나 SSH와 같은 클라이언트 측 "터미널 이스케이프" 문자로 사용되는 비제어 문자를 인코딩할 수 없다.
5. 1. 4GB 파일 크기 제한
ZMODEM 패킷 중 일부(예: ZACK, ZRPOS)는 전송된 파일 내의 바이트 오프셋을 32비트 부호 없는 정수로 포함한다. 이러한 설계로 인해 ZMODEM은 4GB 미만의 파일만 안정적으로 전송할 수 있다.5. 2. 터미널 이스케이프 문자 인코딩 문제
(l)rzsz 참조 구현은 텔넷 및 SSH와 같은 클라이언트 측 "터미널 이스케이프" 문자로 자주 사용되는 임의의 비제어 문자(예: '~')를 인코딩할 수 없다. 사용자는 이러한 종류의 링크를 통해 안정적인 전송을 수행하려면 터미널 이스케이프 기능을 비활성화해야 한다. 예를 들어 SSH에서는 `-e none` 옵션을 사용하여 이를 수행할 수 있다.
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com