요약

  • URG와 긴급 포인터는 두 번째 데이터 채널을 만들지 않으며, 긴급 정보는 TCP의 일반 시퀀스 공간에 그대로 머뭅니다.
  • RFC 793은 서로 충돌하는 두 개의 경계 규칙을 담고 있었습니다. RFC 1122가 “마지막 긴급 옥텟” 해석을 선택했고, 이후 RFC 6093이 널리 배포된 “긴급 데이터 다음 옥텟” 관행에 맞춰 표준을 정렬했습니다.
  • RFC 9293은 현재 규칙과 의무 구현 지원을 유지하지만, 우선순위 채널을 만들거나 새로운 애플리케이션 의존을 권장하지는 않습니다.

URG가 설정되면 16비트 긴급 포인터는 세그먼트 시퀀스 번호로부터의 양의 오프셋으로 해석됩니다. 따라서 그 포인터는 일반 데이터와 동일한 시퀀스 공간에 속합니다. 수신자는 표시된 지점이RCV.NXT보다 앞서 있는 동안 긴급 모드에 머물고, 수신 진행이 그 지점에 도달하면 정상 상태로 돌아갑니다. 바이트는 순서대로 유지됩니다. 소켓 API가 기본적으로 한 바이트를 “대역 외(out of band)”로 제시한다면, 그것은 API 관례를 노출하는 것이지 두 번째 전송 서비스가 아닙니다.

원래의 모순은 작지만 결과는 컸습니다. RFC 793의 헤더 설명은 포인터를 긴급 데이터 다음 옥텟에 두었지만, SEND 처리는SND.UP를SND.NXT-1로 설정하여 마지막 긴급 옥텟을 암시했습니다. RFC 1122는 마지막 옥텟 해석을 선택하고, 임의 길이의 긴급 시퀀스 지원과 비동기 애플리케이션 통지를 요구했습니다. 그러나 RFC 6093은 조사한 널리 배포된 구현들이 다음 옥텟 해석을 따랐다고 보고했습니다. 따라서 RFC 6093은 그 관행을 성문화하기 위해 RFC 793, RFC 1011, RFC 1122를 갱신했습니다. RFC 9293은 이를 현재의 MUST 요구사항으로 계승합니다.

수신자가 이미 긴급 모드에 있는 동안 긴급 포인터가 갱신되더라도 애플리케이션에 새 통지가 발생하지 않을 수 있습니다. 따라서 송신자의 긴급 호출과 수신자의 통지는 일대일 관계일 필요가 없습니다. RFC 6093은 URG를 지우고 포인터를 0으로 만드는 일부 중간 장비를 문서화했지만, 모든 장비가 그렇게 동작한다고 주장하지는 않았습니다. 이 자료들은 현재 사용 현황, 최신 운영체제 기본값 또는 공격 빈도를 확립하지 않습니다.

출처