Win32 소켓으로 작성된 간단한 특정 TCP 클라이언트 - 서버 사용. 요청 및 응답 블록 크기가 작습니다. TCP ping (패킷 도착 시간)으로 인해 발생할 수있는 성능 문제가 우려됩니다. 8 바이트의 500 패킷을 보내면 라우트에있는 서버의 대기 시간 때문에 4000 바이트의 패킷 1 개를 보내는 것보다 느립니다. send() 및 recv()의 크기가 패킷 크기에 영향을 미치지 않습니다. 이해할 수 있습니다. 어떤 식 으로든 프로세스?TCP 클라이언트 - 서버, ping 및 패킷 크기
Microsoft는 KB 문서에서 TCP/IP를 통해 작은 세그먼트를 보내는 성능을 조정하는 방법을 제공합니다. 당신의 필요에 미세 조정 TCP/IP에 대한 문서를 확인하십시오 http://support.microsoft.com/kb/214397
내가 TCP 핑 (패킷 도착 시간)에 의해 발생 가능한 성능 문제에 대한 걱정.
'TCP 핑'과 같은 것은 없으며 '패킷 도착 시간'과 관련이 없습니다.
8 개의 500 패킷을 보내는 것은 경로상의 서버에서 대기 시간 때문에 4000 바이트의 1 패킷을 보내는 것보다 느립니다.
아마도 그렇지 않습니다. 데이터가 Nagle 알고리즘에 의해 부분적으로 또는 완전히 병합 될 확률이 높습니다.
send() 및 recv()의 크기는 패킷 크기에 영향을주지 않습니다.
맞음, 위를 참조하십시오.
어떤 방식 으로든 프로세스를 제어 할 수 있습니까?
Nagle 알고리즘을 사용 중지 할 수 있지만 아직 수행하지 않은 케이스는 없습니다.
더 많은 제어를 원할 경우, 도랑 TCP –
찾고있는 제어 유형에 대해 자세히 설명해 줄 수 있습니까? –
신원 확인. CRC/MD5를 보내십시오 - 그것의 상태를 얻으십시오. 0.01 초에있는 100의 품목이고 가능한 바람직한 응답은 1 개의 요구를 보내고 그것을위한 응답을 기다리는 것이 가장 편리하다, 그러나 속도로 만족할 수 있지 않을 수 있었다. –
user3874158