답변:
무슨 일이 일어나고 있는지 이해하려면 DNS에 대해 약간 알아야합니다.
클라이언트가 지정된 호스트의 서비스에 연결하려고하면 로컬 DNS 인프라를 통해 호스트 이름을 조회하고 이에 대한 응답으로 IP 주소를받습니다. 그런 다음 해당 IP 주소에 연결하고 구현하도록 구축 된 프로 코톨이 지정한 방식으로 서비스를 요청합니다.
경우에 따라 해당 프로 코톨의 일부에 원래 조회 된 호스트 이름 의 두 번째 전송이 포함 되는데,이 경우 DNS 인프라가 아닌 서버로 전송됩니다. HTTP의 경우, 이는 RFC 2616 에서 HTTP / 1.1의 일부로 추가되었습니다 . HTTPS의 경우 RFC 4366 에서 SNI ( Server Name Indication) 로 구현되었습니다 . FTP의 경우 RFC 7151 에서 명령 에 의해 추가되었습니다 (그러나 나중에주의해야 할 사항 참조). 이러한 두 번째 전송이 발생하지 않으면 서버는 서버의 IP 주소를 얻기 위해 클라이언트가 로컬 DNS에 제공 한 호스트 이름을 알 수 없습니다.HOST
모든 경우에이 두 번째 전송을 수행하기 위해 프로토콜을 변경해야하므로 클라이언트와 서버 간 상호 작용을 호스트 이름으로 인식해야합니다. 프로토콜이 변경된 후 서버 코드를 업데이트하여 구현해야했습니다. 마지막으로 새로운 프로토콜을 서버와 통신하도록 클라이언트를 업데이트해야했습니다. 마지막 단계는 특히 느릴 수 있습니다. SNI의 경우 Windows XP의 Internet Explorer는이를 구현하지 않았기 때문에 여전히 많은 수의 IE-on-XP 사용자가있는 동안 프로토콜을 신뢰할 수 없었으며,이를 위해 충분히 10 년이 걸렸습니다. SNI를 안정적으로 배포 할 수있는 기능을 중단하거나 업그레이드하십시오.
비 호스트 이름 인식 프로토콜을 호스트 이름 인식으로 만드는 데 필요한 것입니다. 단순한 플래그 설정 또는 구성 변경 이 아닙니다 . 우리는 몇 가지 프로토콜 별 응답 특히 그 프로토콜에 대한 업무의 상태와 그 거래 가능한 완화 조치가 있습니다에 대한
SSH (그리고 또한 SFTP를) 및 위해
FTP (그 밖의 어떤 점 HOSTFTP에 대한 지원은 누덕 누덕 기운 현재 -지원 단계이므로 아직 신뢰할 수 없습니다.)
짧은 대답은 프로토콜이 현재 호스트 이름 인식을 구현하지 않고 클라이언트와 서버 모두에서 잘 지원한다면 잊어 버린다는 것입니다. 그것은 할 수있는 일이 아닙니다.
baz이 소유자와 단독 구현 자만 변경할 수있는 경우 호스트 이름을 인식 할 수있는 유일한 방법은 소유자에게 호소하는 것입니다. 그것은 흥미로운 SF 답변을하지 않으며, 더 이상 주제에 관한 것이 아닙니다. " 호스트 이름 인식 프로토콜을 어떻게 디자인합니까? "는 또 다른 질문이며, 관심이있는 질문은 아닙니다.