目录
UDP
UDP是不具有可靠性的数据报协议。细微的处理它会交给上层的应用去完成。在UDP的情况下，虽然可以确保发送信息的大小，却不能保证消息一定会到达。因此，应用有时候会根据自己的需求进行重发处理。UDP 的快速传输速度和无连接的特性使其最适用于实时通信场景，如在线游戏和视频流等。
UDP协议格式
- 源端口号(Source Por):字段长16位。该字段是可选项，有时可能不会设置源端口号。没有源端口号的时候该字段的值设置为0。可用于不需要返回的通信中。
- 目标端口号(Destination Por):表示接收端端口，字段长度16位。
- 长度(Length):该字段保存了UDP首部的长度跟数据的长度之和。单位为字节(8位字节)。
- 校验和(Checksum):校验和是为了提供可称的UDP首部和数据而设计。在计算校验和时，附加在UDP伪首部与UDP数据报之前。通过在最后一位增加一个“0”将全长增加16倍。此时将UDP首部的校验和字段设置为“0”。然后以16比特为单位进行1的补码”和，并将所得到的1的补码和写人校验和字段。接收主机在收到UDP数据报以后，从IP首部获知IP地址信息构造UDP伪首部，再进行校验和计算。校验和字段的值是校验和字段以外剩下部分的1的补码和。因此，包括校验和字段在内的所有数据之和结果为“16 位全部为1”时，才会被认为所收到的数据是正确的。另外，UDP中也有可能不用校验和。此时，校验和字段中填人0。这种情况下，由于不进行校验和计算，协议处理的开销"就会降低，从而可以提高数据转发的速度。
UDP传输的过程类似于寄信. 无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接; 不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息; 面向数据报: 不能够灵活的控制读写数据的次数和数量; 面向数据报应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并; 用UDP传输100个字节的数据: 如果发送端调用一次sendto发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节。
UDP没有真正意义上的发送缓冲区。调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作; UDP具有接收缓冲区.。但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃。UDP是全双工的通信。
TCP
TCP是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管道中的水流。当应用程序采用TCP发送信息时，虽然可以保证发送的顺序，但还是犹如没有任何间隔的数据流发送给接收端。TCP为提供可靠性传输，实行“顺序控制”或“重发控制”机制。此外还具备“流控制（流量控制）”、“拥塞控制”、提高网络利用率等众多功能。
TCP协议格式
TCP中没有表示包长度和数据长度的字段。可由IP层获知TCP的包长由TCP的包长可知数据的长度。
源端口号
表示发送端端口号，字段长16位。
目标端口号
表示接收端端口号，字段长度16位。
序列号
字段长32位。序列号(有时也叫序号)是指发送数据的位置。每发送一次数据，就累加-次该数据字节数的大小。序列号不会从0或1开始，而是在建立连接时由计算机生成的随机数作为其初始值，通过SYN包传给接收端主机。然后再将每转发过去的字节数累加到初始值上表示数据的位置。此外，在建立连接和断开连接时发送的SYN包和FIN包虽然并不携带数据，但是也会作为一个字节增加对应的序列号。
确认应答号
确认应答号字段长度32位。是指下一次应该收到的数据的序列号。实际上，它是指已收到确认应答号前一位 为止的数据。发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。
数据偏移
该字段表示TCP所传输的数据部分应该从TCP包的哪个位开始计算，当然也可以把它看作TCP首部的长度。该字段长4位，单位为4字节(即32位)。不包括选项字段的话，TCP的首部为20字节长，因此数据偏移字段可以设置为5。反之，如果该字段的值为5，那说明从TCP包的最一开始到20字节为止都是TCP首部，余下的部分为TCP数据。
保留
该字段主要是为了以后扩展时使用，其长度为4位。一般设置为0，但即使收到的包在该字段不为0，此包也不会被丢弃。
控制位
字段长为6位，每一位从左至右分别为 URG、ACK、 PSH、RST、SYN、 FIN。这些控制标志也叫做控制位。当它们对应位上的值为1时，具体含义如下：
- URG：该位为1时，表示包中有需要紧急处用的数据。对干需要紧急处用的数据，会在后面的紧急指针中再进行解释。
- ACK：该位为时，确认应答的字段变为有效。TCP规完除了最初建立连接时的SYN包之外该位必须设置为1。
- PSH ：该位为1时，表示需要将受到的数据立刻传给上层应用协议。PSH为0时，则不需要立即传而足先进行缓存。
- RST：该位为1时表示TCP连接中出现异常必须强制断开连接。例如，一个没有被使用的端口即使发来连接请求，也无法进行通信。此时就可以返回一个RST设置为1的包。此外，程序宕掉或切断电源等原因导致主机重启的情况下，由于所有的连接信息将全部被初始化，所以原有的TCP通信也将不能继续进行。这种情况下，如果通信对方发送一个设置为1的RST包，就会使通信强制断开连接。
- SYN ：用于建立连接。SYN为1表示希望建立连接，并在其序列号的字段进行序列号初始值的设定。
- FIN ：该位为1时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双方的主机之间就可以相互交换FIN位置为1的TCP段。每个主机又对对方的FIN包进行确认应答以后就可以断开连接。不过，主机收到FIN设置为1的TCP段以后不必马上回复一个FIN包， 而是可以等到缓冲区中的所有数据都因已成功发送而被自动删除之后再发。
窗口大小
该字段长为16位。用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小(8 位字节)。TCP不允许发送超过此处所示大小的数据。不过，如果窗口为0，则表示可以发送窗口探测，以了解最新的窗口大小。但这个数据必须是1个字节。
校验和
TCP的校验和与UDP相似。区别在于TCP的校验和无法关闭。
TCP和UDP一样在计算校验和的时候使用TCP伪首部。为了让其全长为16位的整数倍，需要在数据部分的最后填充0。首先将TCP校验和字段设置为0。然后以16位为单位进行1的补码和计算，再将它们总和的1的补码和放入校验和字段。接收端在收到TCP数据段以后，从IP首部获取IP地址信息构造TCP伪首部，再进行校验和计算。由于校验和字段里保存着除本字段以外其他部分的和的补码值，因此如果计算校验和字段在内的所有数据的16位和以后，得出的结果是“16位全部为1说明所收到的数据是正确的。
紧急指针
该字段长为16位。只有在URG控制位为1时有效。该字段的数值表示本报文段中紧急数据的指针。正确来讲，从数据部分的首位到紧急指针所指示的位置为止为紧急数据。因此也可以说紧急指针指出了紧急数据的末尾在报文段中的位置。如何处理紧急数据属于应用的问题。一般在暂时中断通信，或中断通信的情况下使用。例如在Web浏览器中点击停止按钮，或者使用TELNET输人Ctrl + C时都会有URG为1的包。此外，紧急指针也用作表示数据流分段的标志。
选项
选项字段用于提高TCP的传输性能。因为根据数据偏移( 首部长度)进行控制，所以其长度最大为40字节。另外，选项字段尽量调整其为32位的整数倍。
通过序列号与确认应答提高可靠性
通过使用序列号和确认机制，TCP 可以保证传输的数据包的正确性和可靠性。
在TCP中，当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK )。
通常，两个人对话时，在谈话的停顿处可以点头或询问以确认谈话内容。如果对方迟迟没有任何反馈，说话的一方还可以再重复一遍以保证对方确实听到。因此，对方是否理解了此次对话内容，对方是否完全听到了对话的内容，都要靠对方的反应来判断。网络中的“ 确认应答”就是类似这样的-一个概念。当对方听懂对话内容时会说:“嗯”， 这就相当于返回了一个确认应答(ACK)。而当对方没有理解对话内容或没有听清时会问一句“咦?”这好比一个否定确认应答（NACK）。
TCP通过肯定的确认应答(ACK) 实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。反之，则数据丢失的可能性很大。
在一定时间内没有等到确认应答，发送端就可以认为数据已经丢失，并进行重发。由此，即使产生了丢包，仍然能够保证数据能够到达对端，实现可靠传输。
未收到确认应答并不意味着数据一定丢失。也有可能是数据对方已经收到，只是返回的确认应答在途中丢失。这种情况也会导致发送端因没有收到确认应答，而认为数据没有到达目的地，从而进行重新发送。
此外，也有可能因为一些其他原因导致确认应答延迟到达，在源主机重发数据以后才到达的情况也履见不鲜。此时，源发送主机只要按照机制重发数据即可。但是对于目标主机来说，这简直是一种“灾难"。它会反复收到相同的数据。而为了对上层应用提供可靠的传输，必须得放弃重复的数据包。为此，就必须引入一种机制，它能够识别是否已经接收数据，又能够判断是否能够接收。
上述这些确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现。序列号是按顺序给发送数据的每一个字节(8 位字节)都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据的长度，将自己下一步应该接收的序号作为确认应答返送回去。就这样，通过序列号和确认应答号，TCP可以实现可靠传输。
序列号的初始值并非为0。而是建立连接后由随机数生成。而后面的计算则是对每一字节加1。
为什么TCP是三次握手
三次握手是 TCP 协议中用于建立连接的一个过程，其主要目的是保证通信的可靠性和安全性，防止网络不稳定和数据包丢失等情况。
具体来讲，三次握手的过程如下：
客户端向服务器发送 SYN 报文（SYN=1），表示希望建立连接并告诉服务器，自己的初始序列号是 x。
服务器收到客户端的 SYN 报文后，确认收到，返回 ACK 报文（ACK=1），同时也发送 SYN 报文（SYN=1），告诉客户端，希望建立连接，自己的初始序列号是 y。
客户端收到服务器的 SYN 报文后，也发送 ACK 报文（ACK=1），告诉服务器，收到了服务器的 SYN 报文，也同意建立连接。
这个过程之所以需要三次握手，是为了保证客户端和服务器的状态一致和正确。第一次握手后，服务器在等待第二次握手的同时，如果有第一个 SYN 报文迷路了或者延迟到达的情况时，服务器会认为有新的连接请求，但客户端不一定发起了连接，因此，服务器需要等待第二次握手的确认，确认客户端确实要建立连接。第二次握手仍然需要客户端回复确认 ACK，以完成确切建立连接，防止异常重启等情况。
因此，三次握手是一种可靠且安全的通信协议，可以有效地防止不必要的数据传输和误判，从而保证数据传输的安全和正确性。
为什么是四次挥手
四次挥手是 TCP 协议中用于释放连接的一个过程，其主要目的是确保通信双方都能正常释放连接，防止数据的重复或者漏传等问题。
具体来说，四次挥手的过程如下：
客户端发送 FIN 报文（FIN=1），请求半关闭连接，不再发送数据，但是仍然可以接受服务器发送的数据。
服务器收到 FIN 报文后，发送 ACK 报文（ACK=1）作为确认，并进入 CLOSE_WAIT 状态，等待最后的数据传输完毕。
服务器关闭传输，发送 FIN 报文（FIN=1），请求与客户端关闭连接。
客户端收到 FIN 报文后，同样发送 ACK 报文（ACK=1）作为确认，进入 TIME_WAIT 状态，等待 2MSL（Maximum Segment Lifetime，最长生存时间）即两倍报文最大生命周期时间后过期，期间如果收到重传的 FIN 报文则重复步骤 4，直至时间过期后关闭连接。
其实，四次挥手之所以需要四次，是因为连接的两端都需要进行确认操作，防止双方之间尚有未处理的数据。具体来说，客户端发送 FIN 报文后，服务器在等待数据传输完毕后再发送 FIN 报文，此时客户端也需要确认，才能够安全地关闭连接。
因此，四次挥手是一个保证通信的可靠性和完整性的过程，只有客户端和服务器都完成了这四个步骤，才能完全关闭连接，防止数据的遗漏或者误传。
TIME_WAIT（时间等待）状态是 TCP 协议中一种特定的状态，用于保证通信双方都能够正常地关闭连接并释放资源。在四次挥手过程中，客户端和服务器双方都需要进入 TIME_WAIT 状态一段时间，以完成最后的确认操作。
具体来讲，客户端在发送最后的 ACK 报文（即第四次挥手中的 ACK 报文）之后，进入 TIME_WAIT 状态。在这个状态中，客户端不再发送任何报文，但是仍然可以接受来自服务器发送的包，等待一个经过时间之后再进入 CLOSED 状态。具体的时间通常为 2MSL（Maximum Segment Lifetime，最长生存时间）即两倍报文最大生命周期时间。
这个状态的作用是什么？TIME_WAIT 状态可以保证 ACK 报文可以被服务器正确处理，并且可以防止类似的报文段因为网络延迟或者重传而重复发送已经关闭的 TCP 连接。如果另一个客户端尝试使用已经被关闭的连接的端口号，如果这个端口在 TIME_WAIT 状态，那么新的 SYN 报文将会得到一个 RST 报文来响应请求，这就避免了已经关闭连接的端口后续收到无用的请求报文。
总之，TIME_WAIT 状态的作用是保证连接的正确关闭，并在一定时间内防止因为网络延迟或者重传等问题出现连接未关闭的情况，保证 TCP 协议的稳定性和可靠性，并且避免端口重复使用。
CLOSE_WAIT（关闭等待）状态是 TCP 协议中的一种状态，表示连接被动关闭，即客户端发送了 FIN 报文，请求关闭连接，服务器收到 FIN 报文，即将关闭连接。此时服务器需要检查是否有所有数据均传输完毕，如果数据还没有传输完毕，则服务器会向客户端发送 ACK 报文，等待数据传输完毕后再发送 FIN 报文来关闭连接。在这个过程中，服务器就处于 CLOSE_WAIT 状态，等待最后的数据传输完毕。
CLOSE_WAIT 状态的持续时间通常较短，取决于数据传输的速度和量。在大多数情况下，数据通常很快传输完毕，服务器就会发送最后的 FIN 报文进行关闭。如果数据传输较慢或者数据量特别大，CLOSE_WAIT 状态可能会持续更长的时间。
在 CLOSE_WAIT 状态中，服务器不再接收来自客户端的数据，但仍然可以发送向客户端的数据，以确保所有数据都被传输和处理完毕，避免数据的遗漏和不完整。
总之，CLOSE_WAIT 状态提示服务器已经收到了来自客户端的 FIN 报文，等待最后的数据传输完成后再释放连接，确保连接的安全关闭。
超时重传机制
重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍未收到确认应答，发送端将进行数据重发。
那么这个重发超时的具体时间长度又是如何确定的呢?
最理想的是，找到一个最小时间，它能保证“ 确认应答一定能在这个时间内返回”。然而这个时间长短随着数据包途径的网络环境的不同而有所变化。例如在高速的LAN中时间相对较短，而在长距离的通信当中应该比LAN要长一些。即使是在同一个网络中，根据不同时段的网络拥堵程度时间的长短也会发生变化。TCP要求不论处在何种网络环境下都要提供高性能通信，并且无论网络拥堵情况发生何种变化，都必须保持这一特性。为此，它在每次发包时都会计算往返时间"及其偏差”。将这个往返时间和偏差相加，重发超时的时间就是比这个总和要稍大一点的值。
重发超时的计算既要考虑往返时间又要考虑偏差是有其原因。根据网络环境的不同往返时间可能会产生大幅度的摇摆，之所以发生这种情况是因为数据包的分段是经过不同线路到达的。TCP/IP的目的是即使在这种环境下也要进行控制，尽量不要浪费网络流量。
在BSD的Unix以及Windows系统中，超时都已0.5秒为单位进行控制，因此，重发超时都是0.5秒的整数倍。不过，由于最初的数据包还不知道往返时间，所以其重发超时一般设置为6秒左右。数据被重发之后若还是收不到确认应客，则进行再次发送。此时，等待确认应答的时间将会以2倍、4倍的指数函数延长。此外，数据也不会被无限、反复地重发。达到一定重发次数之后，如果仍没有任何确认应答返回，就会判断为网络或对端主机发生了异常，强制关闭连接。并且通知应用通信异常强行终止。
流控制
TCP 可以根据接收端的处理能力进行流控制，防止对方的数据包过多，导致接收端无法处理。
发送端根据自己的实际情况发送数据。但是，接收端可能收到的是一个毫无关系的数据包又可能会在处理其他问题上花费一些时间。 因此在为这个数据包做其他处理时会耗费一些时间， 甚至在高负荷的情况下无法接收任何数据。如此一来，如果接收端将本应该接收的数据丢弃的话，就又会触发重发机制，从而导致网络流量的无端浪费。
为了防止这种现象的发生，TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流控制。它的具体操作是，接收端主机向发送端主机通知自己可以接收数据的大小，于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。窗口大小的值就是由接收端主机决定的。TCP首部中，专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放人这个字段中通知给发送端。这个字段的值越大，说明网络的吞吐量越高。
不过，接收端的这个缓冲区旦面临数据溢出时，窗口大小的值也会随之被设置为一个更小的值通知给发送端，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制。这也就形成了一个完整的TCP流控制(流量控制)。
下图为根据窗口大小控制流量过程的示例。
当接收端收到从3001号开始的数据段后其缓冲区即满，不得不暂时停止接收数据。之后，在收到发送窗口更新通知后通信才得以继续进行。如果这个窗口的更新通知在传送途中丢失，可能会导致无法继续通信。为避免此类问题的发生，发送端主机会时不时的发送一个叫做窗口探测的数据段，此数据段仅含一个字节以获取最新的窗口大小信息。
利用窗口控制提高速度
TCP以一个段为单位，每发一个段进行一次确认应答的处理，这样的传输方式有一个缺点，那就是，包的往返时间越长通信性能就越低。
为解决这个问题，TCP引入了窗口这个概念。 即使在往返时间较长的情况下，它也能控制网络性能的下降。如下图所示，确认应答不再是以每个分段，而是以更大的单位进行确认时，转发时间将会被大幅度的缩短。也就是说，发送端主机，在发送了一个段以后不必要一直等待确认应答，而是继续发送。
窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。窗口大小为4个段。这个机制实现了使用大量的缓冲区（缓冲区在此处表示临时保存收发数据的场所。通常是在计算机内存中开辟的一部分空间。），通过对多个段同时进行确认应答的功能。如下图，发送数据中高亮圈起的部分正是前面所提到的窗口。在这个窗口内的数据即便没有收到确认应答也可以被发送出去。不过，在整个窗口的确认应答没有到达之前，如果其中部分数据出现丢包，那么发送端仍然要负责重传。为此，发送端主机得设置缓存保留这些待被重传的数据，直到收到它们的确认应答。
在滑动窗口以外的部分包括尚未发送的数据以及已经确认对端已收到的数据。当数据发出后若如期收到确认应答就可以不用再进行重发，此时数据就可以从缓存区清除。
收到确认应答的情况下，将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也被称为滑动窗口控制。
滑动窗口的本质是指针或者下标，滑动窗口的大小可以为0。
窗口控制与重发控制
超时重传以及滑动窗口协议的机制，以及根据网络拥塞情况自动调整传输速度的拥塞控制算法和其他机制来保证通信的稳定性，提高传输的效率和准确性。
在使用窗口控制中，如果出现段丢失该怎么办?
首先，我们先考虑确认应答未能返回的情况。在这种情况下，数据已经到达对端，是不需要再进行重发的。然而，在没有使用窗口控制的时候，没有收到确认应答的数据都会被重发。而使用了窗口控制，就如图所示，某些确认应答即便丢失也无需重发。
其次，我们需要考虑某个报文段丢失的情况。接受主机如果收到一个自己应该接收的序号以外的数据时，会针对当前为止收到数据返回确认应答。
如图下所示。当某一报文段丢失后，发送端会一直收到序号为1001的确认应答，这个确认应答好像在提醒发送端“我想接收的是从1001开始的数据”因此，在窗口比较大，又出现报文段丢失的情况下，同一个序号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答，就会将其所对应的数据进行重发。这种机制比之前提到的超时管理更加高效，因此也被称作高速重发控制。
拥塞控制
TCP 可以根据网络拥塞程度自动调整传输的速率，保证网络的稳定性和可靠性。
有了TCP的窗口控制，收发主机之间即使不再以一个数据段为单位发送确认应答，也能够连续发送大量数据包。然而，如果在通信刚开始时就发送大量数据，也可能会引发其他问题。
一般来说，计算机网络都处在一个共享的环境。因此也有可能会因为其他主机之间的通信使得网络拥堵。在网络出现拥堵时，如果突然发送一个较大量的数据，极有可能会导致整个网络的瘫痪。
TCP为了防止该问题的出现，在通信一开始时就会通过一个叫做慢启动的算法得出的数值，对发送数据量进行控制。
首先，为了在发送端调节所要发送数据的量，定义了一个叫做“拥塞窗口”的概念。于是在慢启动的时候，将这个拥塞窗口的大小设置为1个数据段(1MSS)发送数据，之后每收到一次确认应答( ACK)，拥塞窗口的值就加1。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小做比较，然后按照它们当中较小那个值，发送比其还要小的数据量。
如果重发采用超时机制，那么拥塞窗口的初始值可以设置为1以后再进行慢启动修正。有了上述这些机制，就可以有效地减少通信开始时连续发包导致的网络拥堵，还可以避免网络拥塞情况的发生。不过，随着包的每次往返，拥塞窗口也会以1、2、4等指数函数的增长，拥堵状况激增甚至导致网络拥塞的发生。为了防止这些，引人了慢启动阀值的概念。只要拥塞窗口的值超出这个阀值，在每收到一次确认应答时，只允许以下面这种比例放大拥塞窗口:
( 1个数据段的字节数 / 拥塞窗口(字节) ) x1个数据段字节数
拥塞窗口越大，确认应容的数目也会增加。不过随着每收到一个确认应答，其涨幅也会逐渐减少、甚至小过比一个数据段还要小的字节数。因此，拥塞窗口的大小会呈直线上升的趋势。
TCP的通信开始时，并没有设置相应的慢启动阀值。而是在超时重发时，才会设置为当时拥塞窗口一半的大小。由重复确认应答而触发的高速重发与超时重发机制的处理多少有些不同。因为前者要求至少3次的确认应答数据段到达对方主机后才会触发，相比后者网络的拥堵要轻一些。而由重复确认应答进行高速重发控制时，慢启动阀值的大小被设置为当时窗口大小的一半。然后将窗口的大小设置为该慢启动阀值+3个数据段的大小。有了这样一种控制，TCP的拥塞窗口如上图所示发生变化。由于窗口的大小会直接影响数据被转发时的吞吐量，所以一般情况下，窗口越大，越会形成高吞吐量的通信。当TCP通信开始以后，网络吞吐量会逐渐上升，但是随着网络拥堵的发生在吐量也会急速下降。于是会再次进入吞吐量慢慢上升的过程。因此所谓TCP的吞吐量的特点就好像是在逐步占领网络带宽的感觉。
Nagle算法
TCP中为T提高网络的利用事，经常使用个叫做Nagle的算法。该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送的一种处理机制。 具体来说，就是仅在下列任意种条件下才能发送数据。如果两个条件都不满足， 那么暂时等待一段时间以后再进行数据发送。
- 已发送的数据都已经收到确认应答时
- 可以发送最大段长度的数据时
根据这个算法虽然网络利用率可以提高，但是可能会发生某种程度的延迟。为此，在窗口系统以及机械控制等领域中使用TCP时，往往会关闭对该算法的启用。
延迟确认应答
接收数据的主机如果每次都立刻回复确认应答的话，可能会返回一个较小的窗口。那是因为刚接收完数据，缓冲区已满。当某个接收端收到这个小窗口的通知以后，会以它为上限发送数据，为此，引入了一个方法 ，那就是收到数据后并不立即返回确认应答， 而是延迟一段时间的机制。
- 在没有收到2x最大段长度的数据为止不做确认应答(根据操作系统的不同有时也有不论数据大小，只要收到两个包就即刻返回确认应答情况。)
- 其他情况下，最大延迟0.5秒发送确认应答 (很多操作系统设置为0.2秒左右)
如果延迟多于0.5秒可能会导致发送端重发数据。这个时间越小、CPU的负荷会越高，性能也下降。反之，这个时间越长，越有可能触发发送主机的重发处理，而窗口为只有1个数据段的时候，性能也会下降。
事实上，大可不必为每一个数据段都进行一次确认应答。 TCP采用滑动窗口的控制机制。因此通常确认应客少一些也无妨。 TCP文件传输中，绝大多数是每两个数据段返回一次确认应答。
捎带应答
根据应用层协议，发送出去的消息到达对端，对端进行处理以后，会返间一个回执。例如，电子邮件协议的SMTP或POP、 文件传输协议FIP中的连接控制部分等。这些应用协议使用同一个连接进行数据的交互。即使是都的WWW的HTTP协议，从1.1版本以后也是如此。再例如远程登录中针对输入的字符进行回送校验也是对发送消息的一种回执。（回送校验是指在远程登录中，从键仓中输入的字符到达服务器以后再返回来显示给客户端的意思。）
在农村人们到集市上卖猪时，顺便在猪背拖上几篮子菜一起带去集市的场景。其实就是顺带、捎带的意思。
在此类通信当中，TCP的确认应答和回执数据可以通过一个包发送。 这种方式叫做捎带应答 。通过这种机制，可以使收发的数据量减少。另外，接收数据以后如果立刻返回确认应答，就无法实现捎带应答。而是将所接收的数据传给应用处理生成返回数据以后进再进行发送请求为止，必须一直等待确认应答的发送。也就是说，如果没有启用延迟确认应答就无法实现捎带应答。延迟确认应答是能够提高网络利用率从而降低计算机处理负荷的一种较优的处理机制。
在互联网应用中，TCP 协议具有重要作用，通过保证传输的稳定性、完整性和可靠性，在数据传输过程中充当了重要的传输保障。了解 TCP 协议的基本特点和实现过程，对于提高计算机网络技术的应用水平有重要的意义。当然，TCP 协议还有一些缺点，如对网络带宽和负载的限制和对应用层协议的影响等，可以在实际应用中进行优化和改进，以更好地满足用户需求。
TCP 缓冲区是发送端和接收端的数据交换区域，是一种存储空间，用于暂时存放数据包。在传输的过程中，TCP 缓冲区会动态地分配和管理内存资源，以应对不同的数据传输负载和网络拥塞程度。
在发送端，TCP 缓冲区主要用于存放待发送的数据包和发送控制信息，如序列号、确认号、窗口大小等。发送端将数据放入缓冲区中，然后根据网络拥塞情况，将数据包发送到接收端。如果接收端无法接收数据包，发送端会根据对方的窗口大小进行自动缓存以保证流量控制和数据的稳定传输。
在接收端，TCP 缓冲区用于存储已接收但未处理的数据包，如待接收数据包和确认信息等。接收端会将数据包放入缓冲区中，解析数据包，并根据数据包的确认号等信息进行确认和处理。如果某个数据包未到达或被错误或重复发送，接收端的缓冲区会对数据进行去重、重组和排序等操作，保证数据的正确和连续性，然后发送 ACK 给发送端，表示数据包已被接收，同时释放缓冲区空间，以便接收更多的数据包。
需要注意的是，在实际使用中，通过调整缓存区大小能够影响TCP的性能。如果缓冲区过大，虽然能够支持更多数据传输，但可能会造成网络拥塞和延迟；如果缓冲区过小，则可能丢失数据包或者降低数据传输的效率。因此，需要根据具体的网络环境和应用需求来调整合适的缓存区大小。
TCP 与UDP区分
可能有人会认为，鉴于TCP是可靠的传输协议，那么它一定优于UDP。其实不然。TCP与UDP的优缺点无法简单地、绝对地去做比较。
TCP用于在传输层有必要实现可靠传输的情况。由于它是面向有连接并具备顺序控制、重发控制等机制的，所以它可以为应用提供可靠传输。
而在一方面，UDP主要用于那些对高速传输和实时性有较高要求的通信或广播通信。我们举个通过IP电话进行通话的例子。 如果使用TCP，数据在传送途中如果丢失会被重发，但这样无法流畅地传输通话人的声音，会导致无法进行正常交流。而采用UDP,它不会进行重发处理。从而也就不会有声音大幅度延迟到达的问题。即使有部分数据丢失，也只是会影响某一一小部分的通话。此外，在多播与广播通信中也使用UDP而不是TCP。RIP 、DHCP 等基于广播的协议也要依赖于UDP。
因此，TCP和UDP应该根据应用的目的按需使用。