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

文章目录

• TCP核心机制
• • [TCP核心机制九: 面向字节流](#TCP核心机制九: 面向字节流)
  • [TCP核心机制十: 异常处理](#TCP核心机制十: 异常处理)
• [小小的补充(URG 和 PSH)~](#小小的补充(URG 和 PSH)~)
• TCP小结
• • [TCP/UDP 对比](#TCP/UDP 对比)
  • • 用UDP实现可靠传输(经典面试题)
• 结尾

---

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

本文到这里就结束啦~