目录

一、TCP特性

二、报文格式

 TCP十大核心特性 

1. 确认应答

2. 超时重传

3. 连接管理(三次握手,四次挥手)

三次握手

四次挥手

4. 滑动窗口

情况一:接收方的ACK丢失

情况二:发送方的数据包丢失

5. 流量控制

6. 拥塞控制

7. 延迟应答

8. 捎带应答

9. 字节流粘包问题

 10. TCP的异常处理

面试题:如何使用UDP来实现可靠传输?

一、TCP特性

1.有连接

2.可靠传输

3.面向字节流

4.全双工

二、报文格式

这是各大教科书上的

 这个和UDP一样,是为了排版方便,容易给我们造成误解,其实真正的结构是这样的

 TCP十大核心特性 

1. 确认应答

发送方在发送一条数据给接收方之后,接收方会立刻返回一个ACK作为回应,表示自己收到该条数据

这就是确认应答,能够保证传输的数据一定能发送给对方

2. 超时重传

如果发送方没有接收到回来的ACK相应,等待一段时间后,发送方默认该数据已经丢失,会重新发送该条数据给对方,如果依然没有接收到ACK回应,那么会再次发送 ,但是每次发送的时间间隔会越变越长 , 这就是超时重传

3. 连接管理(三次握手,四次挥手)

三次握手

1. 发送方给接收方发送一条信息(发送SYN);
2. 接收方接受到信息后,发送两个消息,一个是确认应答(ACK),另一个是回复消息(SYN)
3. 对于接收方发回来的ACK和SYN应答,发送方再次回复一个ACK确认应答

四次挥手

1.  发送方发送FIN,请求和接收方断开连接
2. 接收方回应ACK收到断开请求
3. 接收方向发起方也发送FIN,请求断开连接
4. ACK回应,接收方断开连接请求

4. 滑动窗口

滑动窗口的出现时为了提高TCP传输效率的,我们没有引入滑动窗口之前,TCP的大量时间都浪费在了等待ack上面,这时候我们便想到了一个办法  一次传输多个数据,

 而为了保证接受方能够承担同时处理的最大数据,保证接受方不崩溃,我们限制了发送方的最大发送 

也就是说,滑动窗口能够保证,接收方最大同时处理数据的上限,和发送方最大能发送数据的上限

如果在这种批量传输的情况下,出现数据丢失怎么办?

情况一:接收方的ACK丢失

这里可以看到,我们的ACK即使丢了,也无妨,下一条ACK只要能到达,ACK就不需要重新传送,因为发送5001的意思是前5000个数据全部收到了

  情况二:发送方的数据包丢失

这里可以看到,即使是数据包丢失了也无所谓,主机2会持续的返回1001,这样主机1就会重新发送一次1001 ,  所以滑动窗口,是很好的一种提高TCP传输速率的方法

5. 流量控制

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。
因此TCP支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做流量控制

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段，通过ACK端通知发送端；
• 窗口大小字段越大，说明网络的吞吐量越高；
• 接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值通知给发送端；
• 发送端接受到这个窗口之后，就会减慢自己的发送速度；
• 如果接收端缓冲区满了，就会将窗口置为0；这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端

6. 拥塞控制

 简单来说,就是速度如果达到了传输的上限,那么就会立刻反弹回一个较低的值,然后继续增长速率

如此反复,直到稳定在了一个比较合理的数值范围内,这就是拥塞控制

最开始我们的速率增长是指数级别的增长,比如  2的一次方 -> 2的二次方 -> 2的三次方....

然后到了一个比较高的值之后,为了防止下一个次方直接超出接受范围很多

所以从那个值之后,我们采用线性增长,而不是指数增长了

7. 延迟应答

接收方接受数据之后,不会立刻相应给发送方,而是等待一段时间,等接收方接收到多组数据后再返回

8. 捎带应答

 如果在很短的时间内,接收方收到很多信息,并且都需要返回,那么多条返回消息,就可以合并为一条消息返回

9. 字节流粘包问题

当TCP发送多条数据,数据都存储再缓冲区中,由于我们的数据是字节流的,所以我们的数据很有可能会粘到一起,无法区分出哪些是一条数据

粘包问题处理方法:

1.通过分隔符:比如指定一个分隔符作为包的结束标记,这样每一个包就区分开来了

2.通过指定报的长度:比如再报文开头位置声明长度,这样读数据的时候,只读取指定长度的数据,就不会发生粘包问题了

10. TCP的异常处理

情况一:程序突然崩溃
操作系统会自动回收程序遗留/占用的资源,类似于close操作,然后发生四次挥手

情况二:程序正常退出
同情况一,回收资源+四次挥手

情况三:没法发送和接收数据(电脑坏了,网络断了)
接收方无法接受
接收方无法接受数据,也就是无法回应ACK相应给发送方,当发送方多次发送数据也没有ACK回应之后,就默认接收方不行了,然后停止发送数据

发送方无法发送
在接收方和发送方里面存在一个"心跳包",双方会周期性发送一个小数据,判断对方是否存活,如果检测到发送方没有心跳回应,那么就默认发送方没了,接收方也就停止接收数据.

注意:在接收方电脑坏了的情况下也能用心跳包判断,但是ACK更加直接

面试题:如何使用UDP来实现可靠传输?

其实是考察TCP,我们只需要基于UDP在应用层,实现确认应答,超时重传,引入序列号等待操作就可以了