요약

  • RFC 3074는 클라이언트 식별자 또는 하드웨어 주소를 256개 버킷 중 하나로 매핑하여, 협력하는 DHCP 서버들이 요청마다 협상하는 대신 공유된 구성을 근거로 누가 응답할지 결정할 수 있게 했다.
  • 이 RFC는 별도로 배정된 서버의 장애나 주소 고갈, 클라이언트 시간 필드의 신뢰성 부족, 미할당 버킷, 변조된 배정 등을 미리 예상했다. 정확한 해시는 구성된 선택을 증명할 뿐, 실시간 준비 상태나 서비스 완료를 증명하지 않는다.

DHCP 클라이언트가 디스커버리 요청을 브로드캐스트하면 여러 서버가 이를 수신할 수 있다. 서버들이 모두 응답하여 클라이언트가 선택하게 할 수도 있는데, BOOTP 릴레이도 요청을 구성된 모든 목적지로 전달함으로써 같은 확산을 재현할 수 있다. 2001년 2월 B. Volz, S. Gonczi, T. Lemon, R. Stevens가 발표한 RFC 3074는 보다 조용한 방식을 제안했다. 협력하는 서버들은 초기 구성 이후에는 정보를 교환하지 않고도 동일한 서비스/서비스하지 않음 결정에 도달할 수 있었다.

이 결정은 서비스 트랜잭션 ID에서 시작한다. DHCP 클라이언트 식별자가 존재하면 서버는 반드시 이를 사용해야 한다. 그렇지 않으면hlen에서 길이를 가져와chaddr을 해시하되, 처음 16바이트를 넘지 않는다. 지정된 피어슨(Pearson) 함수는 0부터 255까지의 값 하나를 반환한다. 각 참여자는 해시 버킷 배정(Hash Bucket Assignment)을 보유하며, 서버의 경우 32옥텟 비트맵으로 표현된다. 비트가 설정되어 있으면 해당 서버는 트랜잭션 식별자가 대응하는 버킷에 속하는 요청을 서비스해야 한다.

이 설계는 가치 있는 종류의 합의를 만들어냈다. 동일한 입력, 규정된 믹싱 테이블, 일치하는 HBA 상태를 갖추면 두 구현체가 독립적으로 계산해도 같은 결과를 얻을 수 있다. 릴레이는 서버 ID/버킷 쌍을 사용해 전달 목적지를 선택할 수 있다. 지속적인 중재는 불필요하다. 공통 알고리즘은 기존 DHCP 클라이언트를 보존하면서 브로드캐스트 인구를 구성된 몫으로 바꾸었다.

그러나 그 결과는 배정이지 상태 점검이 아니었다. 피어슨 계산에는 선정된 프로세스가 실행 중인지, 네트워크 경로가 닿는지, 임대 데이터베이스가 파트너와 일치하는지, 주소 풀에 아직 적합한 오퍼가 남아 있는지를 조회하는 단계가 전혀 없다. 입력은 클라이언트 트랜잭션을 기술하고, HBA는 행정적 책임을 기술한다. 어느 쪽에도 실시간 용량 정보는 없다.

RFC 3074는 이 점을 운영적 언어로 명시한다. 응답해야 할 서버가 사용 불가능하거나 적합한 주소가 고갈된 경우를 구현체가 처리할 수 있도록 허용한다. 선택 사항인 지연 서비스(Delayed Service) 매개변수를 통해, 평소 해시에 의해 제외되는 서버가 클라이언트의 첫 시도 후 S초가 경과하면 응답할 수 있다. 이 대안은 산술을 무효화하지 않는다. 첫 배정에 기회를 줄 만큼 충분히 기다린 뒤에 서비스 정책을 바꾸는 것이다.

타이머조차 조건부 근거 위에 놓여 있다. 클라이언트가 0이 아닌 값을 제공하면 서버는secs필드를 사용해야 하지만, RFC는 일부 클라이언트가 이 필드를 올바르게 구현하지 않을 수 있다고 명시한다. 서버는 대신 자신이 거절한 첫 요청을 기억했다가, 동일한 트랜잭션 ID와 0인secs값으로 새 요청이 도착하면 경과 시간을 로컬에서 계산할 수 있다. 한 방법은 클라이언트가 보고한 기간을 신뢰하고, 다른 방법은 재시도를 결합해 기간을 추정한다. 두 방법 모두 시도의 시간을 측정하는 대체 수단이며, 배정된 서버가 침묵한 이유를 증명하는 영수증이 아니다.

지연 서비스가 구성되지 않으면 HBA는 엄격한 서비스/서비스하지 않음 정책을 산출한다. 할당되지 않은 버킷에 해당하는 일부 클라이언트 서비스 트랜잭션은 완전히 무시되며, RFC는 이것이 어떤 시나리오에서는 바람직할 수 있다고 말한다. 따라서 구성 범위는 별도의 점검 대상이 된다. 완벽한 구현체도 미할당 값을 완벽하게 계산하면서 설계상 응답자를 전혀 내지 않을 수 있다.

부하 비율에도 또 다른 한계가 있다. RFC 3074는 운영자가 다음에 어떤 클라이언트가 요청할지 예측할 수 없기 때문에 이 방법을 확률적이라고 부른다. 짧은 기간에는 한 서버가 처리하는 몫이 구성된 비율에서 벗어날 수 있고, 요청 수가 늘어나면 관측 분포가 그 할당에 수렴해야 한다. 해시는 현재 CPU, 큐 깊이, 가용 주소, 응답 시간을 반영하지 않는다. 식별자를 분배할 뿐이며, 통계적 균형은 트랜잭션 ID의 충분한 다양성에 의존한다.

따라서 구성은 실행 경로의 일부다. HBA는 파일, Windows NT 레지스트리, EEPROM 또는 합의된 알고리즘에서 올 수 있고 다른 프로토콜 안에 실려 전달될 수 있다. RFC 자체는 보안을 제공하지 않는다. HBA 데이터가 네트워크로 전송된다면 변조된 버킷이 일부 또는 전체 클라이언트에 대한 서비스 거부를 일으킬 수 있으므로 메시지를 보호해야 한다. 지도가 서로 다른 참여자들, 또는 공통 지도가 악의적으로 변경된 참여자들을 동일한 코드가 구원할 수는 없다.

DHCP 기반 문서들도 이 구분을 강화한다. RFC 2131은 클라이언트가 여러 응답을 견디도록 요구하고, DHCP를 로컬 행정 정책 아래에서 작동하는 메커니즘으로 다룬다. 서비스 트랜잭션은 DISCOVER에서 OFFER, REQUEST, ACK로 이어질 수 있으며, 그 후에도 클라이언트는 제공된 구성을 실제로 사용해야 한다. RFC 3074는 첫 질문—누가 응답할 수 있는가—을 최적화하면서 이후의 모든 사건을 해시 결과로 축소하지 않는다. RFC 1542 역시 릴레이 동작을 제공할 뿐, 특정 릴레이가 이 선택 방식을 올바르게 채택했다는 증거는 아니다.

RFC 7031의 이후 DHCPv6 페일오버 요구사항은 구성 합의를 반복적인 운영 문제로 명시하고, 부하 분산을 핵심 페일오버 프로토콜 밖에 둔다. 이 후속 문서를 RFC 3074 배포에 대한 보고처럼 소급해서 읽어서는 안 된다. 다만 이 문서는 범주의 차이를 보존한다는 점에서 유용하다. 들어오는 작업의 분배, 서비스 상태의 동기화, 장애의 생존은 서로 관련된 책임이지만 동일한 메커니즘은 아니다.

Running-Code Primacy는 이 영수증들을 올바른 순서로 결합하기 위한 이후의 렌즈를 제공한다. 그 연쇄는 다음과 같다: 의도된 STID를 추출하고, 규정된 버킷을 계산하고, HBA 커버리지를 확인하고, 배정된 서버를 식별하고, 도달 가능성을 관찰하고, 적합한 주소 용량을 검증하고, 지연 서비스 인수 여부를 평가하고, 오퍼와 클라이언트의 선택을 기록하고, ACK를 수신하고, 결과 네트워크 구성을 검증한다. Reality Layers는 결정론적 소유자의 상징적 확실성이 실행 연쇄가 완전하지 않은 상태에서도 운영적 확실성처럼 느껴지는 이유를 묻는다. 이 둘은 이후의 분석 도구이며, RFC 저자들과 IETF가 주장한 내용이 아니다.

RFC 3074의 성과는 실재했다. 협력 서버들 간의 협상을 줄이고, 적은 계산과 클라이언트 변경 없이 작업 분할을 재현 가능하게 만들었다. 그 절제 역시 중요했다. 이 문서는 배정된 서버가 반드시 살아 있거나 자원이 충분하다고 가장하지 않았고, 침묵에 대한 선택적 탈출로를 설계했다. 교훈은 해싱이 실패했다는 것이 아니다. 해시가 정확히 한 가지 질문에 답했다는 것이다.

버킷은 먼저 시도하도록 구성된 서버를 지명할 수 있다. 그러나 그 서버가 존재하는지, 유능한지, 정직한지, 동기화되어 있는지, 성공했는지는 보고하지 않는다. 운영자가 이 주장들을 별개의 영수증으로 다루면, 결정론적 조율은 결코 담지 않은 증거로 격상되지 않으면서도 유용하게 유지된다.

출처