标签：tcp连接   发包   高性能   soc   分享   位置   解决   ssi   资源   

初始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倍指数函数的增长，拥堵状况激增甚至导致网络拥塞的发生，为了防止这些，引入了慢启动阀值的概念。只要拥塞窗口的值超出这个阀值，在每收到一次确认应答时，只允许一下面这种比例放大拥塞窗口：

拥塞窗口越大，确认应答的数目也会增加。不过随着每收到一个确认应答，其涨幅也会逐渐减少，甚至小过比一个数据段还要小的字节数。因此，拥塞窗口的大小会呈直线上升的趋势。

TCP的通信开始时，并没有设置相应的慢启动阀值，而是在超时重发时，才会设置为当时拥塞窗口一半的大小。

由重复确认应答而触发的高速重发与超时重发机制的处理多少有些不同。因为前者要求至少3次的确认应答数据段到达对方主机后才会触发，相比后者网络的拥堵要轻一些。

而由重复确认应答进行高速重复机制，慢启动阀值的大小被设置为当时窗口大小的一半。然后将窗口的大小设置为该慢启动阀值+3个数据段的大小。

当TCP通信开始以后，网络吞吐量会逐渐上升，但是随着网络拥堵的发生吞吐量也会极速下降。于是会再次进入吞吐量慢慢上升的过程。因此所谓TCP的吞吐量的特点就好像是在逐步占领网络带宽的感觉

提高网络利用率的规范

Nagle算法

也是TCP粘包的根源

如果不满足这两个条件，那么数据暂时等待一段时间再发送。

1.已发送的数据都已经收到确认应答时

2.可以发送最大段长度（MSS）的数据时

延迟确认应答

没有必要收到数据就进行确认应答

延迟一段时间的机制：

1.在没有收到2*最大段长度的数据为止不做确认应答（根据操作系统的不同，有时也有不论数据大小，只要收到两个包就即刻返回确认应答的情况）

2.其他情况下，最大延迟0.5秒发送确认应答（很多操作系统设置为0.2秒左右）

 捎带应答

TCP的确认应答和回执数据可以通过一个包发送。这种方式叫做捎带应答。

比如，进行http通信 客户端发送请求，服务端返回响应数据

初始TCP协议

标签：tcp连接   发包   高性能   soc   分享   位置   解决   ssi   资源   

原文地址：https://www.cnblogs.com/tangkaishou/p/9429527.html