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

Question

웹에는 왜 그럴 수 있는지 자세히 설명하는 많은 기사가 있습니다. ~ 아니다 ETag에 대해 Apache의 기본 inode-mtime-size 형식을 사용하려고 합니다.

그러나 처음에 Apache에 inode를 포함하게 된 동기가 무엇인지에 대해서는 아직 읽은 적이 없습니다.표면적으로는 동일한 리소스의 옥텟 대 ​​옥텟 팩시밀리를 구별할 수 있어야 하는 경우에만 유용해 보이지만 이는 확실히 ETag의 목적에 어긋납니다.

Apache 작성자는 인터넷 표준을 엉성하게 처리하는 것으로 알려져 있지 않으므로 뭔가 빠진 것 같습니다.누구든지 자세히 설명할 수 있나요?

편집하다: 저는 웹 서버를 관리하는 대신 웹 서버를 구현하고 있기 때문에 ServerFault.com이 아닌 여기에 질문합니다.이것이 나쁜 생각인 이유에 대해 자세히 알아보려면 다음을 참조하세요. 여기 또는 여기.이러한 모든 기사에서는 동일한 내용을 권장합니다.etag에서 inode를 제거하십시오.문제는 그들이 거기에 있으면 어떤 이점이 있습니까?

Answer 1

이는 일반적인 경우에 대해 잘못된 추측을 하거나 약간의 의심이 있을 때마다 기본적으로 성능보다 정확성을 선호함으로써 쉽게 할 수 있는 일처럼 보입니다.

어떻게 되었는지에 대한 이야기를 만들어 보겠습니다.

그들은 콘텐츠에 대한 해시/체크섬이 성능상의 이유로 나쁜 생각이라고 일찍 결정했습니다."파일이 얼마나 큰지 누가 알겠어요?우리는 그것들을 항상 다시 계산할 수는 없습니다..." 그래서 그들은 크기와 날짜를 결정합니다.

"하지만 잠깐만요." A라는 사람이 말합니다. "파일 크기 충돌이 발생하지 않는다는 보장은 없습니다.실제로 펌웨어 바이너리와 같이 파일 크기가 항상 동일한 경우가 있으며 여러 개가 동시에 개발 컴퓨터에서 업로드될 수 있으므로 서로 다른 콘텐츠를 구별하기에 충분하지 않습니다. "

사람 B:"흠, 좋은 지적이네.파일 내용과 본질적으로 연결된 것이 필요합니다.수정된 시간과 함께 같은 내용인지 확실히 알 수 있는 것."

사람 A:"아이노드는 어떻습니까?이제 파일 이름을 바꾸더라도(예를 들어 "권장"을 다른 파일로 변경할 수 있음) 기본 etag가 제대로 작동합니다!"

사람 B:"모르겠어요. inode가 좀 위험한 것 같아요."

사람 A:"그럼 뭐가 더 좋을까요?"

사람 B:"그래, 좋은 질문이야.구체적으로 무엇이 문제인지는 생각할 수 없고, 다만 그것에 대해 전반적으로 나쁜 느낌이 들 뿐인 것 같아요."

사람 A:"하지만 적어도 변경된 내용이 있으면 새 것을 다운로드할 수 있다는 보장은 있습니다.최악의 상황은 필요한 것보다 더 자주 다운로드한다는 것이며, 이에 대해 걱정할 필요가 없다는 것을 아는 사람은 누구나 이 기능을 끌 수 있다는 것입니다."

사람 B:"그래, 말이 되네.대부분의 경우에는 괜찮을 것이며 쉬운 대안보다 더 나은 것 같습니다."

부인 성명:나는 Apache 구현자가 무엇을 생각하고 있었는지에 대한 내부 지식이 없습니다.이것은 모두 손으로 추측하고 그럴듯한 이야기를 만들어 내려는 노력에 불과합니다.하지만 나는 확실히 이런 일이 자주 일어나는 것을 보아왔습니다.

당신이 생각하지 못한 것이 무엇인지 결코 알 수 없습니다(이 경우에는 동일한 파일을 제공하는 중복 로드 밸런싱 서버가 크기+시간 충돌을 걱정하는 것보다 더 일반적이었습니다).로드 밸런서는 Apache의 일부가 아니므로 이러한 감독을 더 쉽게 수행할 수 있습니다.

또한 여기서 실패 모드는 캐시를 완벽하게 효율적으로 사용하지 못했다는 것입니다(잘못된 데이터를 얻은 것은 아님). 이는 짜증나지만 틀림없이 더 좋습니다.이는 그들이 생각하더라도 로드 밸런서를 설정하는 데 관심이 있는 사람이 구성 세부 사항을 조정해도 괜찮을 것이라고 합리적으로 가정할 수 있음을 의미합니다.

추신:표준에 관한 것이 아닙니다.etag를 계산하는 방법을 지정하는 것은 없으며 내용이 변경되었는지 여부를 높은 확률로 알려주기에 충분해야 합니다.