做网站工作,网站添加手机站,网站风格定位怎么写,台州制作网站软件文章目录 TCP核心机制TCP核心机制九: 面向字节流TCP核心机制十: 异常处理 小小的补充(URG 和 PSH)~TCP小结TCP/UDP 对比用UDP实现可靠传输(经典面试题) 结尾 TCP核心机制
上一篇文章JavaEE: 深入探索TCP网络编程的奇妙世界(五)
书接上文~
TCP核心机制九: 面向字节流
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标准文档
本文到这里就结束啦~
