初始TCP协议

Posted 2020-12-28 tangkaishou

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了初始TCP协议相关的知识，希望对你有一定的参考价值。

技术分享图片

初始TCP协议

TCP通过序列号与确认应答提高可靠性

消息应答：在TCP中，当发送端的数据到达接收主机时，接收端主机会返回一个已收到消息的通知，这个消息叫做确认应答（ACK）

通信过程

技术分享图片

TCP通过肯定的确认应答（ACK）实现可靠的数据传输。当发送端将数据发送之后会等待对端的确认应答。如果有确认应答，说明数据已经成功到达对端。

如果没有收到确认应答，发送端就会认为数据已经丢失，并进行重发。

未收到确认应答有三种情况：

1.数据未发送成功

2.数据发送成功，只是确认应答的包丢失啦

3.数据发送成功，确认应答没有在特定的时间间隔内收到确认应答

由于确认应答延迟到达，在源主机重发数据以后才到达的情况，导致源主机按照重发机制给目标主机反复发相同的数据。所以就得引出一种机制，能够识别是否已经接收数据，又能够判断是否需要接收。所以引出 序列号。

序列号可以解决确认应答处理，重发控制以及重复控制等功能

确认应答中携带序列号，告诉源主机，下一次应该从哪里发送

技术分享图片

重发超时如何确定

重发超时是指在重发数据之前，等待确认应答到来的那个特定时间间隔。

那么它是如何确定的呢？

由于重发超时受数据报途径的网络环境的不同而有所变化，TCP要求不论处在何种网络环境下都要提供高性能通信，而且无论网络拥堵情况发送何种变化，都必须保持这一特性。所以，它在每次发包时都会计算往返时间及其偏差。

重发超时 > 往返时间+偏差 (稍大一点)

如果数据重发之后还是收不到确认应答，则进行再次发送。此时，确认应答的时间将会以2倍、4倍的指数函数延长。不过当反复重发多次之后，就会强制关闭连接，并且通知应用通信异常强行终止。

连接管理

TCP是面向连接的通信传输，所以通信之前要先做好通信两端之间的准备工作。

TCP三次握手四次挥手

技术分享图片

请详细介绍一下TCP协议建立连接和终止连接的过程？

建立一个TCP连接时，会发生下述情形：
1、服务器端必须做好准备接受外来的连接。这通常通过 socket(), bind(), listen() 三个函数来完成的。我们称之为被动打开(passive open).

2、客户端通过调用connect发起主动打开(active open)。这导致客户端TCP发送SYN同步分节。它告诉服务器客户端在(待建立的)连接中发送的数据的初始化序列号。通用SYN分节不携带数据，
3、服务器必须确认(ACK) 客户端的SYN，同时自己也得发送一个SYN分节，它含有服务器将在统一连接中发送的数据的初始化序号。服务器在单个分节中发送SYN和对客户端SYN的ACK确认。
4、客户端必须确认服务器的SYN。

TCP连接的终止：
1、某个应用程序首先调用close，主动关闭(active close) 该端的TCP于是发送一个FIN分节，表示数据发送完毕。
2、接收到这个FIN的对端执行被动关闭(passive close)。这个FIN是TCP确认。它的接收也作为一个文件结束符(end of file) 传递给接收端的应用程序(放在排队等候应用进程接收的任何其他数据之后)，因为FIN的接收意味着接收端应用程序在相应连接上再无额外数据可以接收。
3、一段时间以后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。
4、接收这个最终FINd额原发送端TCP(即执行主动关闭的一端)确认这个FIN

三次握手建立连接时，发送方再次发送确认的必要性？

主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多资源就这样白白浪费了。

　四次挥手释放连接时，等待2MSL的意义？

第一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

TCP以段为单位发送数据

在建立TCP连接的同时，也可以确定发送数据包的单位，我们也可以称其为“最大消息长度”（MSS：Maximum Segment Size）,最理想的情况是，最大消息长度正好是IP中不会被分片处理的最大数据长度

TCP传送大量数据时，是以MSS的大小将数据进行分割发送。进行重发时，也是以MSS为单位

MSS的确定过程

MSS是在三次握手的时候，在两端主机之间计算得出的，一般是 MTU = IP首部（20字节）+TCP首部（20字节）+MSS

MTU 是数据链路层的最大传输单元

技术分享图片

利用窗口控制提高速度

TCP以1个段为单位，每发一个段进行一次确认应答的处理，这样的传输方式有一个缺点：包的往返时间越长通信性能越低

引入窗口，确认应答不再是以每一个分段，而是以更大的单位进行确认时，转发时间将会被大幅度缩短。也就是说发送端主机，在发送一个段以后不必要一直等待确认应答，而是继续发送。

技术分享图片

窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。发送端主机在等到确认应答返回之前，必须在缓冲区中保留这部分数据。

滑动窗口控制：收到确认应答的情况下，将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。

技术分享图片

窗口控制与重发控制

数据已经到达对端，没有收到确认应答的数据都会被重发，这是没有使用窗口控制的时候发生的

使用窗口控制，某些确认应答即便丢失也无需重发，可以通过下一个确认应答进行确认

技术分享图片

高速重发控制：当某一报文段丢失后，发送端会一直收到序号为xxx的确认应答，当连续3次收到同一个确认应答，就会将其所对应的数据进行重发

技术分享图片

流控制（流量控制）

TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量，这就是所谓的流控制。

它的具体操作是，接收端主机向发送端主机通知主机可以接收数据的大小，而是发送端会发送不超过这个限度的数据，该大小限度就被称作 窗口大小。

所以窗口大小的值就是由接收端主机决定的。

TCP首部中，专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端，这个字段值越大，说明网络的吞吐量越高。

不过，接收端的这个缓冲区一旦面临数据溢出时，窗口大小的值也会随之被设置为一个更小的值通知给发送端，从而控制数据发送量。也就是说，发送端主机会根据接收端主机的指示，对发送数据的量进行控制。这也就形成了一个完整的TCP流控制。

技术分享图片

当接收端收到从3001号开始的数据段后其缓冲区即满，不得不暂时停止接收数据。之后，在收到发送窗口更新通知后通信才得以继续进行。如果这个窗口的更新通知在传送途中丢失，可能会导致无法继续通信。为避免此类问题发生，发送端主机会时不时的发送一个叫做窗口探测的数据段，此数据段仅含有一个字节以获取最新的窗口大小信息。

拥塞控制

在网络出现拥堵时，如果突然发送一个较大量的数据，极有可能会导致整个网络的瘫痪。

TCP为了防止该问题的出现，在通信一开始时就会通过一个叫做慢启动的算法得出的数值，对发送数据量进行控制。

技术分享图片

首先，为了在发送端调节所要发送数据的量，定义了一个叫做“拥塞窗口”的概念，于是在慢启动的时候，将这个拥塞窗口的大小设置为1个数据段（1MSS）发送数据，之后每收到一个确认应答，拥塞窗口的值就加1MSS。在发送数据包时，将拥塞窗口的大小与接收端主机通知的窗口大小作比较，然后按照他们当中较小那个值，发送比它还要小的数据量。

如果重发采用超时机制，那么拥塞窗口的初始值可以设置为1MSS 以后再进行慢启动修正。有了上述这些机制，就可以有效地减少通信开始时连续发包导致的网络拥堵，还可以避免网络拥塞情况发生。

不过，随着包的往返，拥塞窗口也会以2、4倍指数函数的增长，拥堵状况激增甚至导致网络拥塞的发生，为了防止这些，引入了慢启动阀值的概念。只要拥塞窗口的值超出这个阀值，在每收到一次确认应答时，只允许一下面这种比例放大拥塞窗口：

技术分享图片