JAVAEE网络原理1(TCP)

TCP/IP协议栈
应用层: 数据怎么使用

传输层:只考虑起点和终点

网络层:任意两个节点的传输,规划路径

数据链路层:负责相邻节点的传输

物理层:信息公路,即电缆,光纤等.

应用层:

应用层为什么要自定义协议?
不同的业务有着不同的需求,没有一个通用的协议满足所有的业务需求.
怎么进行自定义协议?
1一结合需求 分析两者(服务器,客户端)要传输什么信息
例如: 外卖
1查看外卖列表
2你当前的位置
3你的历史点餐

二明确传递的信息以什么样的格式组织
约定的协议内容(传递的信息):和业务相关性比较大.
约定的协议格式(传递的协议格式):和业务的相关性不大.

因此,针对这个协议格式,有一些大佬发明的,被广泛使用的协议格式.
例如:
XML:标签化的数据组织方式.使用标签来表示键值对以及树形结构.
例如:

请求
陕西值

json:xml(2010以前比较流行)但后来被认为太啰嗦了
出自于js语言
例如:
请求:
{
userId:1234
position:“xxxx.xxxx.xxxx”,

}

响应:
{
shops[
{
name:凉皮,
description:描述信息
position:“xxxx,xxxx,xxxxx”
}

{
name:面馆,
description:描述信息
position:“xxxx,xxxx,xxxxx”
}

]
}

json逐渐就取代了XML

protobuffer:把数据通过二进制进行压缩发送

应用层广泛使用的协议:HTTP协议

传输层:

传输层由系统内核设计,但是程序员写代码调用socketAPI,它就是属于传输层的.
端口号: 区分一个主机的应用程序
端口号是2个字节,16个bit位来表示的…取值范围是:0-65535.
0-1023: 称为"知名端口号",已经分配给了一些端口.,不建议使用.

UDP:
无连接 不可靠 面向数据报 全双工

UDP图片

因为报文长度2个字节 就是64KB,如果超过了,就要进行手动分包多发送几次或者换协议(比如TCP).
校验和:网络传输是光电信号可能受到外界信号的干扰,数据失真,
针对数据内容进行一系列的运算得出结果,如果数据一样,接收方按照同样的方法重新计算一边校验和.,如果内容相同,校验和就是相同的.
知名的校验和:CRC(简单粗暴,但是有偶数对个数据可能数据变了,校验和没变),MD5(冲突概率小,不可逆,定长) SHA1(类似MD5)

TCP
有连接 可靠传输 面向字节流 全双工

在这里插入图片描述
------------------------ 上面即是一个TCP报头

TCP报文=TCP首部+TCP载荷
TCP报头长度可变,
选项: (可选的,)对TCP报文的一些属性进行解释.
选项之前固定20个字节.
首部长度-20就是选项的长度
首部长度是4个比特位 表示 0-15
首部长度的单位是4字节.
如果首部长度是4,TCP报头是20字节(相当于没有选项)
如果首部长度是15,TCP报头是60字节(选项相当于40字节)
保留位: 现在这些单词不用,以后可能要用,所以不能用这些变量
为什么要有保留位: 可扩展性

TCP重要工作机制
1 可靠传输
TCP可靠传输是通过确认应答来保证的.
发送方发一条,回应方回答一条.
bug:网络后发先至的顺序是客观存在的,所以需要方法规避这种错乱
解决方案就是给传输数据进行编号
任何一条数据(包括应答报文)都是由序号的.
确认序号(ACK=1)则只有应答报文有/
TCP的序号是依次累加的,这个累加的过程对于后一个数据来说,第一个数据就是上一个数据的最后一个字节的下一个序号 .
案例:
在这里插入图片描述
TCP可靠传输,是通过确认确认应答机制保证的,
通过应答报文.让发送方清楚的知道传输是否成功.
进一步引入序号和确认序号,对数据进行区分,

二超时重传
发送成功先不提,如果丢包了呢?包括发的包丢了,返回的包(ack)丢了,统一认为是丢包了.所以tcp要挣扎一下.

发送方发送数据之后,等待ack,超过时间阈值没有等到ack,就要重新传输.
超时重传有可能重传N次, N并不是一个很大的数字.

在这里插入图片描述
:重传重复数据怎么处理?
TCP存在一个接收缓冲区,每个TCP的socket对象都有.
B接受到A的数据,然后放入socket对应的接收缓冲区中,这个接收缓冲区可以根据序号来判断是否重复,如果重复则进行丢弃.(接收缓冲区根据序号排序,相同则丢弃)
.

TCP的可靠传输是通过确认应答+超时重传来保证的.
确认应答是传输顺利的情况,
超时重传是传输失败的情况.两者相互配合保证传输的可靠性.
因为 TCP是有连接的, 所以TCP需要建立和断开连接,建立连接的过程就是三次握手

连接管理
TCP建立连接和断开连接的过程:
三次握手: 通信双方互相记录彼此的信息(类似打电话)
例如:

在这里插入图片描述
在这里插入图片描述
SYN(synchronize同步):同步报文段
SYN+ACK:同步报文段+确认报文段
ACK:确认报文段
SYN,ACK是由内核控制的

三次握手的意义:
1通信双方建立对对方的认同
2验证通信双方各自的收发能力
3在握手的过程中,双方协商一些重要的参数

四次挥手:
断开连接的过程
在这里插入图片描述
FIN是由应用程序控制的,调用socket的close方法
ACK是由操作系统控制的,收到FIN之后,立即返回
ACK比等FIN发送完之后才能发送,收到FIN后 ,可能还有数据没发送完成,要等待数据发送完后才能发送ACK,之后另一方才能发送断开连接(FIN)请求.
TIME_WAIT的意义:通常用于描述TCP连接的关闭过程中的状态。当TCP连接的一方发送FIN(关闭连接请求)时,接收方会返回ACK(确认关闭请求),然后等待一段时间(通常为2倍的MSL,即Maximum Segment Lifetime),以确保对方收到了ACK,然后才会进入CLOSED状态。这段等待时间就是TIME_WAIT状态。
在这里插入图片描述
TIME_WAIT状态的主要作用是确保对方收到了ACK,以及在这段时间内不再接收到旧的重复包。

滑动窗口
可靠性和传输效率是矛盾的,
因此要在可靠性的基础上尽可能的止损
在这里插入图片描述
滑动窗口的本质是批量发送一组数据,用一份时间等待一组ACK
把不需要等待,就能直接发送数据的量,称为窗口大小.
上面的窗口大小就是4000
到一个ack,就继续往下发送下一条数据.这就使等待的ack始终都是4条
在这里插入图片描述
丢包处理:
ack丢了: 不需要做任何事在这里插入图片描述
因为关键在于序号,表示序号之前的数据都到达了.

数据丢了:主机B返回的ack都是上一个ack,所以重现传输上一个数据
在这里插入图片描述
由于1001的数据丢了,接下来2001-3000的数据到达之后,返回的ack仍然是1001,这是在索要1001的数据

流量控制
窗口越大,传输效率越高 ,但窗口也不能无限大.
流量控制就是根据接收方的处理能力协调发送方的发送速率

如何衡量接收方的处理能力?
看接收方的接收缓冲区的剩余大小
a给b发一个数据,b先计算自己的接收缓冲区剩余的大小再通过ack报文发送给a.a就根据这个值来决定接下来发送的速率是多大.
在这里插入图片描述

窗口大小是根据接收方的处理能力一直在动态控制的,(流量控制)和拥塞控制共同决定的

在这里插入图片描述

拥塞控制
传输过程中中间节点的处理能力.

在这里插入图片描述
传输过程中按照指数级增长一旦丢包就把值缩到很小(重复指数增长和阈值增长),
拥塞窗口不是固定数值,而是动态变化.

流量控制和拥塞控制共同决定了发送方的实际窗口大小.(谁小听谁的)

延时应答
收到数据后,等待一段时间后返回ack
等待的这段时间接收方可以处理一波数据,那接收缓冲区就更大了
在这里插入图片描述

捎带应答
在延时应答的基础上,引入的.
在这里插入图片描述
在延时应答下:
在这里插入图片描述

由于上面的延时应答,就导致b发送业务数据的同时捎带上ack一起发送给a

面向字节流:
引入了一个粘包问题
接收缓冲区是把多个数据放到了一起,怎么确认一次读几个字节?

解决方案:约定好应用层协议,明确应用层数据报之间的边界
使用分隔符或者约定长度.

异常情况
传输过程中出现了不可抗力
1进程崩溃了
2主机关机了
相当与socket.close();
3主机掉电了
4网线断开了
接收方突然断开:发完数据等待ack,等不到就超时重传 ,之后尝试重置TCP连接,失败之后放弃连接.
发送方突然断开:接收方不知道发送方情况,所以接收方要周期性给发送方发送一个数据(心跳包),确认对方是否正常工作.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值