2의 파워가 아닌 버퍼 사이즈로 socket.recv를 호출하는 실제 영향은 무엇입니까?

2의 파워가 아닌 버퍼 사이즈로 socket.recv를 호출하는 실제 영향은 무엇입니까?

python을 socket.recv과 같은 .

socket.recv(bufsize[, flags])

socket.recv용 python 문서에는 다음과 같이 모호하게 명시되어 있습니다.

참고: 하드웨어 및 네트워크 현실과 가장 잘 일치하려면 버퍼 크기 값이 2의 비교적 작은 거듭제곱(예: 4096)이어야 합니다.

질문:"하드웨어 및 네트워크 현실과 가장 잘 부합한다"는 것은 무엇을 의미합니까?버퍼 크기를 2중 전력이 아닌 상태로 설정할 경우의 실제 영향은 무엇입니까?

저는 이 판독값을 2의 거듭제곱으로 만들기 위한 다른 권장사항들을 많이 봤습니다.배열 길이를 2의 거듭제곱(길이에 대한 비트 시프트/마스킹 작업, 최적 FFT 배열 크기 등)으로 설정하는 것이 유용한 경우가 많지만 이는 응용 프로그램에 따라 다릅니다.나는 단지 그것에 대한 일반적인 이유를 이해하지 못할 뿐입니다.socket.recv. python 설명서의 구체적인 권장 사항의 요점은 확실히 아닙니다.또한 기본 python 코드에서 python-specific 권장 사항으로 만들 수 있는 power-of-two 최적화가 없습니다.

예를 들면...수신 패킷 길이를 정확히 알 수 있는 프로토콜이 있는 경우 처리 중인 패킷에 필요한 내용을 "최대한"만 읽는 것이 좋습니다. 그렇지 않으면 다음 패킷을 먹을 수 있으므로 짜증이 날 수 있습니다.현재 처리 중인 패킷이 42바이트만 보류되어 있다면 버퍼 사이즈를 42로 설정할 것입니다.

제가 무엇을 빠뜨리고 있나요?임의의 버퍼/배열 크기를 선택해야 할 경우 보통(항상?) 길이를 2의 거듭제곱으로 만듭니다.이것은 오랜 세월에 걸쳐 발전된 습관일 뿐입니다.파이썬 문서도 그저 습관의 희생자일 뿐입니까?

이것은 python만의 것은 아니지만, 나는 python 문서를 특별히 참조하고 있기 때문에, 나는 그것을 그렇게 태그할 것입니다.

---

업데이트: 방금 시스템의 커널 레벨에서 버퍼 크기를 확인했습니다(또는 최소한 확인했다고 생각합니다).했다cat /proc/sys/net/core/rmem_default124928 .2의 힘이 아닙니다.rmem_max 역시 힘이 아닙니다. 131071고,히 다.

이 문제를 좀 더 조사해 보면 아직 두 가지 권장 사항의 효과를 볼 수 없습니다.나는 그것을 가짜 추천이라고 부를 준비가 되어있습니다.

저도 추가했습니다.tcp그리고.C관련성도 있기 때문에 태그를 지정합니다.

저는 '2의 힘' 조언이 편집상의 오류에 근거한 것이기 때문에 요구 사항으로 받아들여져서는 안 된다고 확신합니다.

Python 문제 #756104에 대한 응답으로 Python 2.5 설명서(그리고 Python 2.4.3 문서로 다시 보고됨)에 해당 조언이 추가되었습니다.기자는 불합리하게 큰 버퍼 크기를 사용하고 있었습니다.socket.recv()했습니다 업데이트를

'2의 힘'이라는 개념을 도입한 것은 팀 피터스였습니다.

역사상 이렇게 큰 값을 recv()에 전달하려고 시도한 사람은 당신밖에 없을 것으로 예상합니다. 작동했다고 해도 1.9에 대한 버퍼 공간을 할당하려고 할 때 메모리가 거의 부족할 것입니다.GB.소켓은 낮은 수준의 설비이며, (하드웨어 및 네트워크 현실과 가장 잘 일치하는) 2의 비교적 작은 전력을 통과시키는 것이 일반적입니다.

(대담한 강조 나의 것).저는 팀과 함께 일을 해보았는데, 그는 네트워크 프로그래밍과 하드웨어에 대한 경험이 풍부하기 때문에, 일반적으로 말해서 저는 그런 말을 할 때 그의 말을 믿었습니다.그는 특히 윈도우 95 스택을 '좋아한다'며 스트레스를 받아 실패하는 능력 때문에 탄광의 카나리아라고 불렀습니다.하지만 2의 거듭제곱을 사용해야 하는 것이 아니라 일반적인 것이라고 말합니다.

문서 업데이트로 이어진 것은 이 문구 때문이었습니다.

이는 설명서 버그이므로 사용자에게 "경고"해야 합니다.

이것은 나를 한번 사로잡았는데, 두 명의 다른 사람이 #python에 이것에 대해 물었으니, 아마도 우리는 다음과 같은 것을 recv() 문서에 넣어야 할 것입니다.

"""
및
은 2,은 2다의 .
예를 들어 4096입니다.
"""

문구가 맞다면 버그만 저에게 맡겨주시면 제가 처리하겠습니다.

여기서 '2의 힘' 주장에 이의를 제기한 사람은 아무도 없었지만, 편집자는 몇 개의 답변 공간에 있어야 하는 것이 일반적입니다.

저에게 문서 업데이트를 제안하는 사람들은 2의 거듭제곱이 아니라 작은 버퍼를 사용하도록 하는 것에 더 관심이 있었습니다.그렇다고 좋은 조언이 되는 것은 아닙니다. 커널과 상호 작용하는 하위 수준의 버퍼는 커널 데이터 구조와 정렬되어 혜택을 받습니다.

하지만 2의 거듭제곱을 가진 버퍼가 더 중요한 난해한 스택이 있을 수도 있지만, 팀 피터스가 그런 철벽 같은 용어로 캐스팅되는 것이 일반적인 경험이 될 수 있을지는 의문입니다.버퍼 크기를 달리하는 것이 특정 사용 사례에 더 적합하다면 무시하기만 하면 됩니다.

다음과 관련하여: "수신 패킷 길이를 정확히 알 수 있는 프로토콜이 있다면 처리 중인 패킷에 필요한 것을 "최대한"만 읽는 것이 좋습니다. 그렇지 않으면 다음 패킷을 먹을 수 있으므로 짜증이 날 수 있습니다."

이는 애플리케이션 개발자에게는 바람직하지만, 기본 네트워크 스택에는 비효율적일 수 있습니다.첫째, 추가 네트워크 I/O에 사용할 수 있는 소켓 버퍼 공간을 묶습니다.둘째, 각 recv()는 시스템 호출/커널 공간으로 이동하는 것을 의미하며 전환 시 성능 저하가 발생합니다.항상 가능한 한 많은 데이터를 커널 공간에서 벗어나 시스템 호출 횟수가 적은 사용자 공간으로 가져와 메시지 구문 분석을 수행하는 것이 좋습니다.이렇게 하면 응용 프로그램 코드와 메시지 처리가 더욱 복잡해지지만 아마도 가장 효율적일 것입니다.

즉, 오늘날의 프로세서 속도와 사용 가능한 메모리 양을 고려할 때 대부분의 애플리케이션에서는 이 문제가 문제가 되지 않을 수 있지만, 이는 과거 "옛날"의 네트워크 애플리케이션에서는 일반적으로 권장하는 사항이었습니다.

사용자 공간 애플리케이션의 2가지 추천의 힘에 대해서는 잘 모르겠습니다.정렬 및 페이지 크기 문제 등으로 인해 드라이버에 대한 이러한 유형의 요구 사항을 본 적이 있지만 커널 버퍼에서 사용자 버퍼로 데이터를 복사하는 데 도움이 되지 않는 한 사용자 공간에서 어떤 효과가 있는지는 명확하지 않습니다.더 많은 OS 개발 지식을 가진 사람이 코멘트를 할 수도 있습니다.

언급URL : https://stackoverflow.com/questions/6363523/what-is-the-actual-impact-of-calling-socket-recv-with-a-bufsize-that-is-not-a-po