inode를 ETag에 넣는 (Apache) 목적은 무엇입니까?

Question

웹에 많은 기사가 있습니다. 이 아닐 수도 있습니다.은 Apache의 기본 inode-mtime-size 형식을 ETags에 사용하려고합니다.

하지만 처음에는 아파치 용 아이 노드가 포함되도록 동기를 부여한 내용을 아직 읽지 않았습니다. 그것의면에서 보면, 동일한 자원의 옥텟 - 옥텟 팩시밀리를 구별 할 수 있어야만 유용하게 보이지만, 이것은 ETags의 목적과는 분명히 반대입니다.

Apache의 저자는 인터넷 표준을 잘못 처리 한 것으로 알려지지 않았기 때문에 뭔가 빠뜨린 것 같습니다. 누구든지 정교 할 수 있습니까?

EDIT : 저는 ServerFault.com이 아닌 Web Server를 구현하기 때문에 여기에서 묻습니다. 왜 나쁜 생각인지 자세히 알아 보려면 다음을 참조하십시오. here 또는 here입니다. 그러한 모든 기사는 같은 것을 권장합니다 : 당신의 etags에서 inode를 제거하십시오. 문제는 거기에있는 사람들에게 어떤 이점이 있습니까?

Answer 1

보통의 경우에 대한 잘못된 추측이나 의심의 갈증이있을 때마다 기본적으로 성능에 비해 정확성을 선호하는 것으로 쉽게 할 수있는 것처럼 보입니다.

하는 날이 갈 수있는 방법에 대해 이야기를 구성 할 수 있도록 허용 :

그들은 내용에 대한 해시/체크섬이 성능상의 이유로 나쁜 생각이다 초기에 결정한다. "파일 크기가 얼마나 큰지 누가 알겠습니까? 우리는 항상 그 파일을 다시 계산할 수 없습니다 ..."그래서 크기와 날짜를 결정하면 꽤 가까워집니다.

"기다려라."사람 A는 "파일 크기가 충돌하지 않는다는 보장은 없지만 사실 파일 크기가 항상 동일 할 때 펌웨어 바이너리와 같은 경우가 있습니다. 가능한 여러 가지가 dev 컴퓨터에서 동시에 업로드되기 때문에 서로 다른 내용을 구별하기에 충분하지 않습니다. "

사람 B : "음, 좋은 지적입니다. 파일의 내용과 본질적으로 관련이있는 것이 필요합니다. 수정 된 시간과 함께 내용이 동일한 지 여부를 확실히 알 수 있습니다."

Person A : "아이 노드는 어떨까요? 파일의 이름을 바꾸더라도 (예를 들어"권장 "을 다른 파일로 변경 한 경우라도) 기본 etag가 정상적으로 작동합니다!"

사람 B : "나는 몰라요, inode는 약간 위험한 것 같습니다."

사람 A : "음, 뭐가 더 좋을까요?"

사람 B : "예, 좋은 질문입니다. 구체적으로 잘못되었다고 생각할 수 없다고 생각합니다. 나는 그것에 대해 전반적으로 나쁜 감정을 갖고 있습니다."

사람 A : "적어도 변경된 경우 새 것을 다운로드 할 것이라는 보장이 있습니다. 가장 자주 발생하는 현상은 필요한 것보다 자주 다운로드되며 걱정할 필요가없는 사람은 누구나 그냥 꺼 버릴 수있어. "

사람 B : "예, 그럴 수 있습니다. 대부분의 경우 괜찮을 것이고, 쉬운 대안보다 더 좋을 것 같습니다."

면책 조항 : Apache 구현자가 무엇을 생각하고 있었는지에 대한 내부 지식이 없습니다. 이것은 모두 손으로 물결 치는 추측이며 그럴듯한 이야기를 구성하려고합니다.그러나 나는 이런 종류의 일이 종종 충분히 자주 일어나는 것을 보았습니다.

당신이 생각하지 못했던 것이 무엇인지 전혀 알지 못합니다 (이 경우, 동일한 파일을 처리하는 중복로드 균형 서버가 크기 + 시간 충돌에 대해 걱정할 필요가없는 것보다 일반적 임). 로드 밸런서는 아파치의 일부가 아니기 때문에 이러한 감시를보다 쉽게 ​​할 수 있습니다.

또한 여기서 실패 모드는 캐시를 완벽하게 효율적으로 사용하지 않았다는 것입니다 (잘못된 데이터가 아님). 이는로드 밸런서를 설정하는 데 충분한 관심을 가진 사람이 구성 세부 정보를 조정해도 괜찮을 것이라고 생각할 수 있다고 생각합니다.

추 신 : 그것은 표준에 관한 것이 아닙니다. etag를 계산하는 방법을 지정하지 않습니다. 내용이 변경되었는지 여부를 높은 확률로 판단 할 수 있어야합니다.