1.确认应答机制

由于发送信息的距离可能较远,可能出现后发的信息先到的情况,怎么办?

TCP将每个字节的数据都进行了编号,即为序列号

如何分辨一个数据包是普通数据还是应答数据呢

2.超时重传

由于丢包是一个随机的事件,因此在上述tcp传输的过程中,丢包就存在两种情况

但是在发送方的角度,无法区分这两种情况

无论出现哪种情况,发送方都会进行"重新传输"

所以udp一般延迟比较低

如果a给b发了消息,而b回复的数据丢了,那a就会超时重传一条一样的数据过去

3.连接管理机制

3.1 建立连接,TCP三次握手

TCP在建立连接的过程中,需要通信双方一共"打三次招呼",才能发完成连接建立的

ack和syn同时为一,此时就是三次握手了

3.2 连接断开,四次挥手

建立连接一般是客户端主动发起

断开连接,客户端和服务器都可以主动发起

和三次握手不同,此处的四次握手,不一定能把中间的两次交互合并

不能的原因:ack和第二个fin的触发时机是不同的

ack是内核响应,b收到fin,就会立即返回ack

第二个fin是应用程序的代码触发,b这边调用了close方法才会触发fin

可以的原因:

3.3 问题

3.3.1 怎么判断报文是不是同步报文段?

3.3.2 三次握手要解决什么问题? (核心作用)

这种设定,是避免前朝的剑斩本朝的官

3.3.3 两次,三次握手是否可行?

两次不行,四次可以,但没必要,两个数据合并成一个数据更高效\

4.滑动窗口机制

4.1丢包如何重传

这种情况不用任何重传,因为有确认序号机制

TCP前提是可靠性,在可靠性的前提上,再提高传输效率

5.流量控制

站在接收方的角度,反向制约发送方的传输速率

6.拥塞控制

6.1过程

在指数增长的过程中,如果达到阈值,就从指数增长,变成线性增长

线性增长也是增长,如果传输速率越来越快增长到一定程度,网络上就可能会出现丢包了(网络堵塞)

一旦触发丢包,就把窗口大小缩小,重新进行前面的慢开始 - 指数增长 - 线性增长

并且会根据当前丢包的窗口大小,重新指定线性增长阈值(为了避免指数增长一下就达到丢包阈值)

这是经典版本的拥塞控制,后面tcp又进行了改进

最终时机发送的窗口大小,是取流量控制和拥塞控制中窗口的较小值

7.延时应答

8.捎带应答

在延时应答的基础上,进一步提高效率

9.面向字节流

相比之下,UDP这样的面向数据报的通信方式就没有这样的问题

如何解决粘包问题?

前面写的回显服务器,就是这样的方式

10.异常情况处理

10.1 进程崩溃

10.2 主机关机(正常流程)

10.3 主机掉电

10.4 网线断开

11.TCP的心跳机制