내 TCP/IP 스트림 소켓 서비스의 클라이언트가 데이터를 버퍼로 이동하는 것보다 빠르게 서비스에 데이터를 전송할 수있는 시나리오를 고려해야합니다 (응용 프로그램 버퍼에 대해 자연스럽게 말하고 있습니다). recv 및 작업 그것으로. 그래서 기본적으로 그러한 시나리오에서는 어떤 일이 발생합니까? 분명히, 사용자 응용 프로그램 인 내 서비스 아래의 일종의 서비스는 들어오는 스트림을 받아야하고 'recv'를 발행 할 때까지 어딘가에 저장해야합니다. 맞습니까? 가장 확실하게 운영 체제. 나는 낡은 질문을 다시하고 싶지 않지만,이 뚜렷하게 명백한 것에 대한 답을 찾을 수없는 것 같습니까?``recv`를 충분히 빠르게 호출하지 못하면 어떻게 될까요?
TCP는 flow control을 제공합니다. TCP 스택 (송신 측 및 수신 측 모두)은 사용자를 위해 일부 데이터를 버퍼링 할 수 있으며 이는 일반적으로 OS 커널에서 수행됩니다.
수신자 버퍼가 가득 차면 보낸 사람은 그 사실을 알게되고 더 많은 데이터 전송을 중단하여 결국 공간이 다시 사용할 수있을 때까지 송신 응용 프로그램을 차단합니다 (그렇지 않으면 더 많은 데이터를 보낼 수 없음).
간단히 설명하면, 전송 된 모든 TCP 패킷 (세그먼트)에는 버퍼링 할 수있는 데이터 크기 (창 크기)가 포함됩니다. 즉, 상대방은 항상 버퍼가 가득 차서 수신자가 버려도 데이터를 얼마나 멀리 보낼 수 있는지 알 수 있습니다. 창 크기가 0이되면 버퍼가 꽉 차고 더 이상 데이터가 전송되지 않습니다 (차단하는 경우 발신자가 차단 될 경우 send() 호출이 차단됨), TCP 창이 여전히 0인지 여부를 확인하기위한 Theres 절차로 전송이 재개 될 수 있습니다 다시 데이터가 소비되었을 때.
은 제로 창은 보낸 사람에게 알려집니다 좀 더 자세한 사항은 here
데이터 버퍼 (들어오는 데이터의 버퍼 포함)를 유지하는 네트워크 드라이버 스택입니다. 버퍼가 가득 차면 그 결과로 발생하는 TCP 패킷이 삭제되고 클라이언트가 데이터를 보내려고 시도합니다. 이 here 및 here에 대한 자세한 내용이 있습니다.
번호가 그리고 송신자는 전송을 중지합니다. 궁극적으로 보낸 사람의 소켓 전송 버퍼가 가득 차고 응용 프로그램이 비 차단 모드에 있지 않으면 차단됩니다.이 경우 EAGAIN 또는 EWOULDBLOCK이됩니다. TCP 패킷은 보낸 사람이 TCP를 올바르게 구현하지 않고 크기가 0 인 창으로 보내는 경우에만 삭제됩니다. – EJP
@EJP 귀하의 의견은 부분적으로 만 정확합니다. IP 레벨에서 패킷 *은 버려집니다. TCP 패킷에 대한 내 답장이 잘못되었습니다. (오타가있는 것 같군요.) 그래도 클라이언트는 여전히 (귀하의 의견이있는 경우에도) 차단되어 있습니다. –
질문은 TCP에 관한 것입니다. TCP 세그먼트는 IP 패킷으로 구성됩니다. IP 레벨에서 패킷은 둘러싸는 세그먼트가 보내진 경우에만 버려지고, 창이 허용되면 보내지며 창은 허용되지 않으므로 보내지 않아야합니다. – EJP
아닙니다. 모든 TCP * 확인 응답에는 현재 창 크기가 포함됩니다. 이 시점에서 위키피디아가 잘못되었습니다. 올바른 참조는 Wikipedia가 아니라 RFC 793입니다. – EJP