JavaEE传送门

JavaEE

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

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

---

---

延迟应答

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

比如： 原缓冲区

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 协议可以胜任.

---

🌷(( ◞•̀д•́)◞⚔◟(•̀д•́◟ ))🌷

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

这里是Gujiu吖！！感谢你看到这里🌬 祝今天的你也 开心满怀，笑容常在。