JavaEE

网络原理——No.2 传输层_TCP的连接管理

网络原理——No.3 传输层_TCP的滑动窗口, 流量控制与拥塞控制

目录

• 延迟应答
• 捎带应答
• 面向字节流
• • 粘包问题
• TCP 中的异常处理(连接异常)
• TCP 和 UDP 的应用场景

延迟应答

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

比如： 原缓冲区

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

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

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

捎带应答

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

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

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

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

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

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

面向字节流

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

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

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

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

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

# 注意 #

• TCP 自身对于应用层数据报是无法做区分的.
• UDP 面向数据报, 是不存在这个问题的. 一个 UDP 数据报, 就是对应一个应用层报文.

粘包问题

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

典型的办法, 有两种:

1. 通过分隔符, 比如约定 ; 作为包的结束标记.
2. 通过包的长度, 比如在数据包的开头位置声明长度.

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

1. xml; 分隔符就相当于 结束标签
2. json; 分隔符就相当于 }
3. protobuffer; 里面通过声明长度的方式来确定边界的.
4. http; 分隔符和长度两个都会用到.

TCP 中的异常处理(连接异常)

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

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

   执行 close 就会触发 fin 报文, 进一步开始四次挥手 (这种情况和普通的四次挥手其实没啥区别)

2. 正常关机 (通过 开始菜单 这种方式关闭主机)

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

   系统内核, 会进行文件描述符的释放操作, 进一步进行四次挥手.

3. 主机掉电 (断电关机)

   • 掉电的是接收方, 发送方不知道. 继续发送数据, 此时发的数据没有 ack 了, 发送方触发超时重传.

     重传几次之后, 仍然无应答, 就会尝试重置连接, (复位报文段) , 也会失败, 只能放弃连接.

   • 掉电的是发送方, 此时接收方就等着. 接收方等待一阵后, 就会发送一个 “心跳包”. 心跳包是周期性触发的. 只是一个简单的不携带任何数据的包,存在的意义就是确认一下对方是否存在.

     如果对方不返回心跳包, 说明心跳遗失, 此时也就会放弃连接了.

4. 网线断开

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

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

TCP 和 UDP 的应用场景

TCP 有可靠性需求的场景, 用到 TCP 非常广泛.

UDP 对于可靠性要求不高, 同时对于传输效率要求很高的情况.

比如： 机房内部的内网传输

• 机房内布带宽比较充裕, 网络结构更简单, 不容易丢包.
• 机房内布往往数据之间, 要传输的数据量是很大的, 传输效率要求比较高.

小知识:

传输层也不是只有这两个协议, 还有其他协议.

像 LOL, DOTA , 吃鸡 ,CSGO. 对于实时性要求非常高的游戏, 一般既需要保证可靠性, 有需要保证效率, TCP 和 UDP 都难以胜任, KCP 协议可以胜任.

以上就是今天要讲的内容了，希望对大家有所帮助，如果有问题欢迎评论指出，会积极改正！！