TCP Delay confirmation

Introduction

TCP Delay confirmationIs implemented by some technologies, Strive to improveNetwork PerformanceTransmission ControlProtocol.Essentially, severalResponseMay be combined to form a response to reduce protocol overhead.However, in some cases, this technology can reduce applicationProgramPerformance.

Methods and advantages

Description in RFC 1122The host may delay sending ACK responses to 500 ms.In addition, an ACK response is sent when a full TCP packet segment is received.

Delayed ack can give the application the opportunity to send updates togetherTCP Receiving Window, Ack and instant response of applications.For example, some protocols,Remote LoginBy combining ACK, TCP Window update, and application response into a packet segment, the latency ack can reduce the server's response data by three times.

Problem

When some applications interact with the configuration, the latency ack introduces additional wait time may cause further delay.

IfNagleAlgorithmIt is used by the sender, and the data will be queued until an ACK is received.If the sender does not send enough data to fillMaximum Segment Size(For example, if it executes two small writes with one blocking read), then the sender's application will pause until the ACK delay times out.

For example, consider a situation where Bob sends data to Carol, BobIn the socket layer, the valid data to be sent is not a complete packet. AccordingNagle algorithm, which is not sent until an ACK is received to confirm that the data has been sent.At the same time, Carol's Application Layer does not send a response until it gets all the data.If Carol uses delayed ACK, the socket layer will not send an ACK until the last timeout occurs.

This negative effect may occur if the application transmits data in a small block and expects Regular Response confirmation.To prevent this delay, the application layer needs to continuously send data without waiting for confirmation.In addition, the sending application may disable the Nagle algorithm.