网络原理

介绍TCP/IP协议中每一层里面的核心内容~

传输层TCP协议

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

在这里插入图片描述
实际TCP的延时时间,不一定非是用时间来衡量,也可能是用传输轮次来衡量~
比如下图:
每收到两条数据,返回一次ack

在这里插入图片描述
是让窗口大点的一种方法~

基于延时应答的基础上,引入的

网络通信中,典型的通信模型,是一发一收

TCP中,只要把数据传过去,对方收到之后,就会立即由内核返回一个ACK确认报文
另外,响应数据(fin),则是应用程序里负责传输
ack返回的时机和fin(结束报文段)返回的时机是不同的,因此不能把这两次传输合并起来~
但是上面有个延时应答!

本来ACK是立即就要返回的,但是由于延时应答,稍等一会儿返回~
稍微等一等,正好业务上也要返回这个响应,此时就可以把两个报文合二为一了,可以提高效率~

这个合二为一的操作是内核处理的~ 应用程序是调用socket的write方法把数据交给内核,内核进行封装,进行发送~

但是这种情况是偶发的~
主要还是看应用程序什么时候返回响应! 如果应用程序返回的太晚,此时就无法合并~

在面向字节流中,存在一个典型的问题,叫做"粘包问题"

TCP(或者其他面向字节流的传输方式),都是有一个 接收缓冲区~

A的应用程序,就需要从接收缓冲区中,读取收到的数据~~
在这里插入图片描述

由于是面向字节流的,A是无法确定,从哪里到哪里,是一个完整的应用层数据报

A就可能把"吃"当作完整响应
也可能把"吃个"当成完整响应
…

粘包问题:
TCP自身对于应用层数据报是无法做区分的~
UDP面向数据报,是不存在这个问题的~
一个UDP数据报,就是对应一个应用层报文

🥩要想解决粘包问题,就要在应用层协议这里进行区分!
只要定义应用层数据协议的时候,明确包和包之间的"边界",就可以了!!

典型的办法,有两种:

通过分隔符 : 比如约定用 ; 作为包的结束标记
通过指定包的长度,比如在数据包开头位置声明长度~

连接异常了怎么办?

程序崩溃了
正常关机(通过开始菜单这种方式来关闭主机)
主机掉电
网线断开

程序崩溃
进程异常退出
操作系统会回收进程的资源,包括释放文件描述符表
这样的释放操作,就相当于调用了socket 的 close
执行close 就会触发 FIN 报文,进一步的开始四次挥手~~
这种情况和普通的四次挥手其实没啥区别~
正常关机(通过 开始菜单 这种方式来关闭主机)
关机的时候,系统会先强制结束所有的用户进程,和上次的那个进程崩溃类似
系统内核,会进行文件描述符的释放操作,进一步的进行四次挥手
主机掉电(台式机被拔电源了)
非常突然,猝不及防的~

掉电的是接收方,发送方不知道对面挂了,继续发数据,此时发的数据,没有ack了,发送方就触发超时重传,重传几次之后,仍然无应答,发送方就尝试重置连接(复位报文段),也会失败,最后只能放弃连接
掉电的是发送方,此时接收方就等着~
接收方也不是干等,等了一阵之后,就会发送一个💗"心跳包"
心跳包是周期性触发的,只是一个简单的不携带任何业务数据的包~
存在的意义就是确认一下对方是否还在!
如果对方不返回心跳包,说明心跳就遗失,对方挂了💫
此时也就会放弃连接了~