JavaEE: 深入探索TCP网络编程的奇妙世界(六)

文章目录


TCP核心机制

上一篇文章JavaEE: 深入探索TCP网络编程的奇妙世界(五)

书接上文~

TCP核心机制九: 面向字节流

TCP是面向字节流的,这就意味着,读写100个字节的数据有以下方式:

  1. 可以一次读写一个字节,分100次.
  2. 一次读写10个字节,分10次.
  3. 一次读写50个字节,分2次.
  4. 一次读写100个字节,一次搞定.
  5. ...

通过面向字节流的方式传输数据,都是会涉及到"粘包问题",粘的是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核心机制十: 异常处理

  1. 进程崩溃

    Java中的体现,就是抛出异常,但是没人catch,最终异常到了JVM这里,JVM进程就会直接嘎了.

    看起来是崩溃,挺严重,实际上操作系统会进行善后,当进程崩溃的时候,进程中的PCB就要被回收.

    PCB中的文件描述符表里对应的所有文件,也会被系统自动关闭.

    其中针对socket文件,也就会触发正常的关闭流程(TCP四次挥手).

  2. 主机关机

    正常流程点击关机按钮,此时操作系统就会先干掉所有的进程.干的过程中,同样就会触发四次挥手.分以下两种情况:

    • 四次挥手非常快,四次挥手已经完成了,关机动作才真正完成.
    • 四次挥手没来得及挥完,关机就完成了.
  3. 主机掉电(拔电源)

    • 接收方掉电

      此时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标准文档

本文到这里就结束啦~

相关推荐
WTT001113 分钟前
2024楚慧杯WP
大数据·运维·网络·安全·web安全·ctf
杨德杰1 小时前
QT网络(一):主机信息查询
网络·qt
007php0071 小时前
Go语言zero项目部署后启动失败问题分析与解决
java·服务器·网络·python·golang·php·ai编程
yang_shengy1 小时前
【JavaEE】网络(6)
服务器·网络·http·https
zquwei2 小时前
SpringCloudGateway+Nacos注册与转发Netty+WebSocket
java·网络·分布式·后端·websocket·网络协议·spring
Aimin20223 小时前
路由器做WPAD、VPN、透明代理中之间一个
网络
火烧屁屁啦3 小时前
【JavaEE进阶】初始Spring Web MVC
java·spring·java-ee
群联云防护小杜3 小时前
如何给负载均衡平台做好安全防御
运维·服务器·网络·网络协议·安全·负载均衡
爱码小白3 小时前
网络编程(王铭东老师)笔记
服务器·网络·笔记
蜜獾云4 小时前
linux firewalld 命令详解
linux·运维·服务器·网络·windows·网络安全·firewalld