TCP的相关性质

文章目录

  • 流量控制
  • 拥塞控制
    • 拥塞窗口
  • 延迟应答
  • 捎带应答
  • 面向字节流
  • 粘包问题
  • TCP的异常

流量控制

由于接收端处理数据的速度是有限的,如果发送端发的太快,那么接收端的缓冲区就可能会满。此时如果发送端还发数据,就会出现丢包现象,并且可能出现一系列连锁反应。

所以TCP支持根据接收端的处理能力去决定发送端的发送速度,这种机制就叫做流量控制

  1. 接收端会将自己的缓冲区大小,也就是报头中的窗口大小告知给发送端,发送端根据情况改变发送速度
  2. 窗口大小越大,说明网络的吞吐量就越高

拥塞控制

虽然TCP有滑动窗口这个机制可以高效可靠的发送大量数据,但是如果在刚开始的时候就发送了大量的数据就仍然可能出现问题

因此TCP在防止出现拥塞问题上加入了慢启动机制

顾名思义就是先发送少量的数据区探探路,摸清当前的网络拥堵情况,再决定应该按照多快的速度去传输数据

少量的丢包, TCP仅仅是触发超时重传; 大量的丢包, TCP就认为网络拥塞。

TCP通信开始后, 网络吞吐量会逐渐上升; 随着网络发生拥堵, 吞吐量会立刻下降.

所以拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案

拥塞窗口

此处就又引入一个概念—拥塞窗口

  1. 在通信开始前,拥塞窗口设为1
  2. 每收到一个ACK应答时,拥塞窗口加1
  3. 每次发送数据包时,都将拥塞窗口和报头中的窗口大小做比较,之后取较小的值作为实际发送的窗口大小

这样做就可以很符合慢启动机制,一开始的窗口大小就会呈指数型的增长,到后面就会慢下来呈线性增长,这种就相当于给了一个阈值,没超过这个值时就可以增长的快一点,一旦超过就慢下来

因此可以将这个阈值一开始启动时候就设为窗口大小的最大值,每次超过这个值那么TCP就会触发重发机制,这时候每一次触发重发都将这个阈值减少一半,同时拥塞窗口置为1

这样就可以很好的控制住拥塞

延迟应答

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小。因为可能会出现应答一发出就有数据被读取了,那缓冲区就又大一点了,但是应答没有能够及时知道

又因为窗口越大,网络吞吐量就越大,传输效率就越高。最终的目标是在保证网络不拥塞的情况下尽量提高传输效率。因此就可以引入延迟应答的机制。

另外还有利用到TCP的应答机制原理,只要将该序号的数据应答回去,那么就说明该序号前的所有数据都已经收到了。所以延迟的时间就可以取在超时重发的时间前。

捎带应答

在很多情况下,两端主机都是一发一收的模式在通信,也就是说客户端给服务端发送数据,服务端也会回一个数据给客户端。那这个时候搭配着延迟应答,服务端可以在这段时间内将之前处理完的数据。等到服务端发送应答了,一并这数据带走发送,这样就可以省下一步,这就是捎带应答

面向字节流

TCP是以字节流的方式去读写的。

在创建TCP的套接字时,操作系统内核会同时创建一个发送缓冲区和一个接收缓冲区

  1. 调用write时, 数据会先写入发送缓冲区中;
  2. 如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
  3. 如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
  4. 然后应用程序可以调用read从接收缓冲区拿数据;

另外TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工

由于缓冲区的存在,TCP的读和写就不需要一一匹配了,只需要读写到指定的字节数就可以

粘包问题

因为字节流的原因,就可能会出现读取一个数据没读完或者读多了读了别的数据

因此为了解决这种粘包问题可以采用几种方案

  1. 定长读写,指定字节数
  2. 利用分隔符分隔数据
  3. 约定报头的位置,在报头里加上有效载荷的字节数

TCP的异常

  1. 进程终止:进程终止会释放文件描述符,仍然可以发送FIN和正常关闭没有什么区别。
  2. 机器重启:和进程终止的情况相同。
  3. 机器掉电/网线断开:接收端认为连接还在,一旦接收端有写入操作,接收端发现连接已经不在了,就会进行reset(重置连接)。即使没有写入操作,TCP自己也内置了一个保活定时器,会定期询问对方是否还在,如果对方不在也会把连接释放

你可能感兴趣的:(网络,tcp/ip,网络)