延迟应答

一种提高传输效率的机制, 又是基于流量控制, 来引入的提高效率的机制

比如：原缓冲区

1kb 数据来到了我们缓冲区里

实际 TCP 的延时时间, 不一定非是用时间来衡量, 也可能是用传输轮次来衡量

不同的系统里面, 延时的方式可能是不一样的

捎带应答

捎带应答, 基于延时应答的基础上, 引入的.

网络通信中, 典型的通信模型, 是一发一收.

TCP 中, 只要把数据传过去, 对方收到之后, 就会立即由内核返回一个 ack 确认报文, 另外, 响应数据, 则是应用程序里负责传输.

由于这俩操作是不同的时机传输的, 因此不能把这两次传输合并起来, 但是上面有一个延时应答,

本来 ack 是立即就要返回的, 但是由于延时应答, ack 稍等一会返回

稍微一等, 正好, 业务上也要返回这个响应, 此时就可以把两个报文合二为一了.

在面向字节流中, 存在一个典型的问题, 叫做 “粘包问题”.

我们来看这样一个例子： TCP (或者其他面向字节流的传输方式), 都是有一个接收缓冲区

小Gujiu 的应用程序, 就需要从接收缓冲区中,读取收到的数据.

由于是面向字节流的, 无法确定, 从哪里到哪里, 是一个完成的应用层数据报.

就可能把 “不玩” 当做完整响应, 也可能把 “不玩还是” 当成完整响应.

# 注意 #

想要解决粘包问题, 就是要在应用层协议里进行区分. 只要定义应用层数据协议的时候, 明确包和包之间的 “边界”, 就可以了.

典型的办法, 有两种:

自定义应用层协议, 有几个典型的实现:

程序崩溃了(进程异常退出)

操作系统会回收进程的资源. 包括释放文件描述符表. 这样的释放操作, 就相当于调用了对应 socket.close

执行 close 就会触发 fin 报文, 进一步开始四次挥手 (这种情况和普通的四次挥手其实没啥区别)
正常关机 (通过开始菜单这种方式关闭主机)

关机的时候, 系统会先强制结束所有的用户进程. 和上述的程序崩溃类似.

系统内核, 会进行文件描述符的释放操作, 进一步进行四次挥手.
主机掉电 (断电关机)
- 掉电的是接收方, 发送方不知道. 继续发送数据, 此时发的数据没有 ack 了, 发送方触发超时重传.
  
  重传几次之后, 仍然无应答, 就会尝试重置连接, (复位报文段) , 也会失败, 只能放弃连接.
- 掉电的是发送方, 此时接收方就等着. 接收方等待一阵后, 就会发送一个 “心跳包”. 心跳包是周期性触发的. 只是一个简单的不携带任何数据的包,存在的意义就是确认一下对方是否存在.
  
  如果对方不返回心跳包, 说明心跳遗失, 此时也就会放弃连接了.
网线断开

情况通主机掉电, 只不过通信双方的主机都是好着的.

客户端和服务器各自按照上述 (主机掉电) 的两种情况分别进行.