JavaEE: 深入探索TCP网络编程的奇妙世界(六)
文章目录
- TCP核心机制
- TCP核心机制九: 面向字节流
- TCP核心机制十: 异常处理
- 小小的补充(URG 和 PSH)~
- TCP小结
- TCP/UDP 对比
- 用UDP实现可靠传输(经典面试题)
- 结尾
TCP核心机制
上一篇文章JavaEE: 深入探索TCP网络编程的奇妙世界(五)
书接上文~
TCP核心机制九: 面向字节流
TCP是面向字节流的,这就意味着,读写100个字节的数据有以下方式:
- 可以一次读写一个字节,分100次.
- 一次读写10个字节,分10次.
- 一次读写50个字节,分2次.
- 一次读写100个字节,一次搞定.
- …
通过面向字节流的方式传输数据,都是会涉及到"粘包问题",粘的是TCP携带的载荷(应用层数据包).
应用程序需要读取接收缓冲区中的数据.
由于TCP是面向字节流的,此处的操作,咋读都可以.
可以读出一个a,aa,bb,b,c,cc
也可以读aaab,bb,c,cc
还可以读aa,ab,bbc,cc
…
存在很多种读法,但是实际上,aaa,bbb,ccc这才是正确的读法,aaa,bbb,ccc才是完整的"应用层数据包".
乱读一通肯定是不太合适的.
为了解决以上问题,我们需要明确"包之间的边界".
有以下两种方案:
-
方案一: 指定分隔符
适合于文本类的数据.
之前我们写TCP echo server的时候,当时我们的做法是,约定请求响应,都以\n结尾.
发送请求响应的时候,专门使用println进行写数据.
读取请求响应的时候,专门使用scanner.next按照\n进行解析~指定分隔符时必须要确认,数据内容的正文中,不能包含指定的分隔符.
如果传输的数据是纯文本数据的话,此时使用 \n 或者 ; 可能都不合适,但是可以使用ascii中靠前的"控制字符".
找几个没用的来当控制字符~
-
方案二: 指定数据的长度.
比如,约定在每个应用层数据包,开头的2/4个字节,表示数据包的长度.
如果是传输二进制数据,这个方案就很有用了.
看到这里,思考一下,对于UDP协议来说,是否也存在"粘包问题"呢?
- 对于UDP,如果还没有上层交付数据,UDP的报文长度仍然在.同时UDP是一个一个的把数据交付给应用层.因此有很明确的数据边界.
- 站在应用层的角度.使用UDP的时候,要么收到完整的UDP报文,要么不收.不会出现"半个"的情况~
TCP核心机制十: 异常处理
-
进程崩溃
Java中的体现,就是抛出异常,但是没人catch,最终异常到了JVM这里,JVM进程就会直接嘎了.
看起来是崩溃,挺严重,实际上操作系统会进行善后,当进程崩溃的时候,进程中的PCB就要被回收.
PCB中的文件描述符表里对应的所有文件,也会被系统自动关闭.
其中针对socket文件,也就会触发正常的关闭流程(TCP四次挥手). -
主机关机
正常流程点击关机按钮,此时操作系统就会先干掉所有的进程.干的过程中,同样就会触发四次挥手.分以下两种情况:
- 四次挥手非常快,四次挥手已经完成了,关机动作才真正完成.
- 四次挥手没来得及挥完,关机就完成了.
-
主机掉电(拔电源)
-
接收方掉电
此时A给B发送的数据,不会再有ACK了~A触发超时重传,重传的数据,当然还是没有响应.反复多次之后,A尝试重置连接(rst),重置操作也没有ack,A就会单方面释放连接(A把保存的B的信息删除掉)
-
-
发送方掉电
A发着发着,没声了.
从B的视角来看,不知道A是嘎了,还是A只是稍微缓缓,晚点再发.此时B就会给A发送一个数据包(不携带业务数据,为了触发ACK),问问A你咋了.
如果发了探测报文之后,A返回了ACK,说明A只是先歇一会,没噶~
但是如果发了探测报文,A没有ACK.
甚至说,连续多个探测报文,A都没有ACK.
此时就可以视为A嘎了.这样的探测报文,是周期性的,同时这个报文是用来探测对方的"生死"的,也就把这样的报文称为"心跳包".
计算机中,有很多地方都使用了心跳包的思想.
TCP内置了心跳包,由于TCP内置的心跳包周期比较长,秒级-分钟级.
应用程序这一层通常也会自行实现一些心跳包,达到更快速的"保活机制". -
网线断开
和主机掉电是一样的~
小小的补充(URG 和 PSH)~
剩下了一点东西还没写，补充一下~
-
URG是和紧急指针配合使用的.
URG为1时,紧急指针能够生效,紧急指针里保存的是一个偏移量.
TCP正常情况来说,都是按照顺序来传输数据的.
而紧急指针,就是让后面的数据插队,根据紧急指针的偏移量,把指定位置的数据,优先发送出去.这是特殊场景的特殊方案,不是一个通用的方案,日常开发中很少能够直接涉及到~
-
PSH 催促标志位,带有这个标志位的数据,就相当于提醒接收方,要尽快的来处理这个数据(也是特殊场景的特殊方案)
TCP小结
为啥TCP这么复杂?
因为要保证可靠性,同时又要尽可能的提高性能.
可靠性:
- 校验和
- 序列号(按照序号到达)
- 确认应答
- 超时重传
- 连接管理
- 流量控制
- 拥塞控制
提高性能:
- 滑动窗口
- 快速重传
- 延时应答
- 捎带应答
TCP/UDP 对比
我们说了TCP是可靠连接,那么是不是TCP一定就是优于UDP呢?
答: TCP和UDP之间的优点和缺点,不能简单,绝对的进行比较.
- TCP用于可靠传输情况,应用于文件传输,重要状态更新等场景.
- UDP用于对高速传输和实时性要求较高的通信领域.例如,早期的QQ,视频传输等.另外UDP可以用于广播.
TCP/UDP 什么时机用,具体怎么用,还是需要根据具体的需求场景来去判定.
用UDP实现可靠传输(经典面试题)
可以参考TCP的可靠性机制,在应用层实现类似的逻辑.
例如:
- 引入序列号,保证数据顺序.
- 引入确认应答,确保对端收到了数据.
- 引入超时重传,如果隔一段时间没有应答,就重发数据.
- …
结尾
需要注意的是,文章里总共只写到了10个机制.
但是这不代表TCP一共只有十个机制!!
TCP更多机制的详情,请参考: rfc标准文档
本文到这里就结束啦~
