如何避免网站被耍流量,附近计算机培训班咨询,做网站需要多少兆空间,网站建设对数据库有何要求文章目录 基于UDP应用场景 TCP协议TCP 协议段格式确认应答机制16位窗口大小 下定义32位序号和32位确认序号 基于UDP应用场景
UDP#xff0c;tcp这样的协议根本不是直接谈UDP。tcp的应用场景#xff0c;一定是上层写了应用层协议#xff0c;所以才有UDP协议的应用场景。
比… 文章目录 基于UDP应用场景 TCP协议TCP 协议段格式确认应答机制16位窗口大小 下定义32位序号和32位确认序号 基于UDP应用场景
UDPtcp这样的协议根本不是直接谈UDP。tcp的应用场景一定是上层写了应用层协议所以才有UDP协议的应用场景。
比如http
TCP协议
传输层最重要的协议几乎没有之一 因为TCP基于通信时保证可靠性对于高效传输也有一定策略。 TCP协议是目前应用层协议使用时常见的协议。 比如网络版本计算器底层是TCP套接字。 http底层就是TCP协议用的也是TCP套接字。
TCP叫传输控制协议 为什么叫传输控制从何而来
TCP在OS内部存在自己的发送和接受缓冲区。 每建立一个链接的的时候此时OS内部就要为该链接创建发送缓冲区和接受缓冲区
应用层也要定义缓冲区来接受用户输入和输出结果给用户–用户级缓冲区
计算器为了能接受请求定义string in_buffer 通过read把数据读上来。
当上层调用write,read接口时本质不是把数据发送到网络中 那是什么呢 比如发送发送的数据拷贝到TCP的发送缓冲区应用层就认为数据已经交给了系统。 至于数据什么时候发送发 送多少出错了怎么办 完全由OSTCP协议自主决定
所以write,read,recv ,send与网络相关的发送接口本质不是发送函数而叫做拷贝函数
好像在哪里听过啊 以前讲文件的时候不就是这样吗 往文件里写也用的wirte接口所以当时说C语言提供缓冲区也是用户级缓冲区我们把数据写到文件里写到OS内部要通过fd写入的每个文件都有自己的文件缓冲区,所以应用层读写文件时把数据写到文件里本质就是把数据拷贝到内核的文件缓冲区里至于数据什么时候刷刷多少整个刷新细节你不用关心是由OS和磁盘交互的今天看来磁盘和网络有区别吗 把磁盘设备换成网卡不就完成数据发送IO吗冯诺依曼体系结构里文件是IO往网络里写本质不就是在硬件层面上把内存里的数据写到网卡上也是IO大家在理念上是一致的更何况Linux一切接文件。
从今天开始对于网络的理解就可以这么认为了 我的应用层只负责对收上来的数据进行协议处理把报文和报文分开诸如反序列化变成结构化数据根据协议对数据做处理把数据写好的响应发给TCP缓冲区应用层的工作就完了至于数据什么时候发由TCP决定。
通信双方都支持TCP协议所以CS的地位是对等的。所以一方学懂了另一方一样。
应用层把数据本质拷贝到发送缓冲区。 至于数据怎么发其实把传输层发送缓冲区 的数据导到对方的接受缓冲区里本质也是拷贝 只不过这个拷贝工作需要通过网络而已通过网络可能会出错所以需要很多策略。
接收方通过read调用时会阻塞由于接受缓冲区没有数据有数据则资源就绪了。
后面网络和文件揉在一起说说 解释为什么UDP或Tcp 只有同样一个FD既可以读也可以写因为一个fd配套两个缓冲区所以可以即读又写了。-- 全双工
这就是TCP缓冲区的理解。
TCP下层还有协议我们把数据交给下层并不是直接发送给对方。
1。传输层的接受缓冲其实就是内存空间 2。OS为了管理对应的内存其实是把整个内存想成一个个4KB空间所以OS有这么多内存块OS怎么知道哪些已经被占用了那些没有那些被锁定了那些过期了 OS就要对内存块管理。 为了管理内存所以每个内存块都要有strcut page这样的结构
所以接受发送缓冲区无非就是多个内存块即strcut page构成的。
OS中用数组把100多万个page管理起来对内存管理转为对数组的增删查改。
打开一个网络相当于得到一个文件描述符底层一定有Strcut file对象Strcut file对象以前指向磁盘今天网络Strcut file对象指向网络设备每个Strcut file后面跟上两个缓冲区由多个4kb构成的此时上层不变下层直接切换成网络这样的效果。
为什么突然扯到这里呢? 问题 所以为什么叫传输能理解控制协议能理解 控制是什么意思 应用层把数据经过write拷贝到发送缓冲区里至于发送缓冲区里的数据什么时候发发多少本质就是在控制如何发送的问题。 这些工作由TCP协议自主决定所以把他叫做传输控制协议。
为什么提供发送缓冲区呢 当前对端来不及接受了发送端怎么知道呢用户一直把数据往缓冲区写因为有缓冲区的存在即便来不及接受了但对于应用层来讲可能并不影响应用层继续向OS拷贝数据拷贝多了发送缓冲快满了OS就让对方接受缓冲区快点拿数据了。
TCP是具有接受发送缓冲区进行全双工通信的进行数据发送控制的一种协议。
TCP 协议段格式
应用层 请求和响应 传输层 数据段 网络层 数据报 链路层 数据帧
问题 1、报头和有效载荷如何分离如何交付给上层
TCP协议基本结构分三部分 TCP报头前20字节就是TCP标准报头 TCP支持对应的选项–我们忽略但存在 第三部分TCP协议的有效载荷
如何交付给上层 前两个字段端口交付给上层目标进程 对TCP报文向上交付给进程 一行是4字节0-31 标准报头一共五行所以标准报头是4x520字节
报头和有效载荷如何分离?
当读取TCP数据时在缓冲区里把前20字节拿出来报头信息全拿到了标准报头全拿到了他也是约定长度。 TCP报文里有一个字段4位首部长度 凡是报文里介绍首部长度他就真的是。 表示报头总长度你不是说了标准报头是20字节吗因为还包含了选项选项也可以不带。 4位首部长度 【00001111】【0-15】 全写成1表示数字也就是15怎么可能是20 呢 是不是有问题呢 不是因为4位首部长度计算的时候有基本的大小单位4字节 则表示长度范围【060字节】 所以选项最多是40字节。
如果不带选项则四位首部长度设为X x * 4 20 x 5 0101
4位首部长度准确的把报头从整个报文里去掉
报头和有效载荷如何分离我们怎么做呢 实际上先读取前20字节固定长度之后根据4位首部长度计算出实际总大小再减去20剩下的就是选项的大小没有的就不读了剩下的就是数据 所以如何分离 固定长度前20字节 自描述字段
你收到一个数据能不能按照指定字节数对数据做截取呢 你直接把数据收上来截取前20字节整个报文也是结构体地址强转成结构体指针直接从里面提取4位首部长度这个4位长度描述是自身的报头大小所以他叫自描述字段。我们网络版本计算也带有有效载荷长度也叫做自描述字段 固定长度自描述 的方式 能把标准报头和选项全部读上去因为标准报头就是20字节剩下的就是数据所以能作分离。
1、报头和有效载荷如何分离如何交付给上层 搞定
整个报文也是结构体他所谓的封装是把报头结构体变量形成的对象内容拷贝到数据前面。 能封装也能拆开
下一个问题 16位窗口大小
左边客户端有应用层和传输层/TCP TCP有自己的接受缓冲区和发送缓冲区。 对于服务端也是这个结构 此时应用层构建Http请求 把数据通过write结构写到发送缓冲区里传输层要发送这个数据给对方此时要给发送的数据添加TCP报头 没来得及发送的就放到发送缓冲区里可能有多个Http请求
封装报头经过底层交到对方的接受缓冲区里时对方收到这个报文要进行报头有效载荷分离套接字创建出来都要有自己的接收缓冲区至此去掉报头的Http有效载荷请求放到接受缓冲区中。
问题 你心里要特别清楚客户端和服务器基于tcp协议进行通信时互发消息的时候发送的可是完整的tcp报文哦即一定携带完整的tcp报头 不管课件如何简写双方通信时发数据发确认当你看到数据时可不仅仅是数据他一定要涵盖tcp报头数据响应同理
看起来是发synack,本质上是把报头特定的属性字段设置了归根结底所有请求和响应都要基于tcp报头为载体 发起Http请求时一定要想到请求包含报头一大堆东西的。 tcp一样报头必须完整
换句话说C给S发消息时基于套接字上层来看都是通过fd来读写的。 所以你打开多个套接字建立多个连接每个连接都要有一对收发缓冲区
双方通信时发送的报文携带完整报头
tcp协议要保证可靠性 不可靠的表现呢 数据传输出现重复乱序丢包 发送的过程本质是把数据拷贝给对方对方接受缓冲区是固定大小的所以他的剩余空间就少了如果应用层就不想读此时发送方应用层给对方一直发消息客户端和服务器双方进行通信时客户端不清楚服务器接受能力的所以客户端一直给服务器发消息时服务器来不及接受最终可能导致服务器接受缓冲区被写满客户端又不知道就继续发最后导致接受缓冲区没空间导致数据丢包。 所以CS通信时服务器接受能力很少的时候我们要让客户端发慢点或者干脆不发了 由发送方向服务端发消息通过控制发送数据的速度让对方来得及接受从而规避大面积丢包的情况我们称为流量控制。
tcp注定要解决这个问题 tcp可靠性里有一种叫做丢包重传 如果报文丢失了发送发可以对服务器补发的。 如果对方来不及接受了出现大面积丢包tcp害不害怕丢包不害怕他有重传啊。 可以吗这样可以。
但有更好的方案啊。 虽然你有重传但是这样不合理报文经过千里迢迢到了对端我没有明显错误却要把我丢弃掉所以他不合理。 我们不能让他启用重传策略浪费曾经的发送效率必定不高
既然来不及接受那就要发送慢一点
tcp保证可靠性凭什么说他保证可靠性 最基本的一个特点确认应答(最重要的机制
比如我们两个相隔千里老师说的话同学听到没听懂没老师不知道所以老师经常说听懂没听懂扣1要求你给我响应的过程就叫做确认应答。
所以暂时认为客户端给服务器发送任何消息的时候服务器都要对收到的消息进行响应
那你能保证你扣的6老师一定能看到吗
确认应答机制
CS双方地位对等
如果C给S发消息即便服务器没有任何话说但服务器至少要对消息进行一次确认应答。 服务器想给客户端发消息客户端OS也要立即给服务器确认应答。
这样就能保证对于C来讲客户端刚刚发的消息服务器收到了。 基于确认应答保证了客户端到服务器方向的可靠性 同理服务器给客户端发消息客户端做应答保证服务器到客户端方向数据的可靠性
重谈通信过程
客户端向发送消息交给服务器服务器收到了这个消息TCP协议要立即给对方应答 问题 无论发送消息确认应答最后都是tcp报文无论发的是什么消息什么应答一定携带完整的tcp报文或者是报头 发送方 发送的量非常大也很快 导致对方来不及接受所以需要流量控制无非就是让客户端发送数据慢一点要发慢一点依据是什么慢多少啊 靠谁来决定呢 由对方接受缓冲区当中剩余空间的大小决定
对于发送方来讲发送速度由对方的接受缓冲区中剩余空间的大小决定
剩多少空间让我知道了我就可以根据你剩余空间最多发送把你缓冲区打满的数据发满了我就不发了。
关键在于客户端是给你发送数据客户端怎么知道你服务器端剩余空间的大小呢
我们tcp基于确认应答机制的你发了一个报文我要给你响应别忘了请求和响应都要是完整的报文所以发一个消息对方会给我响应的我收到响应才发 第二个目前认为。 收响应的时候我就收到来自服务器给客户端发来的响应响应中16位窗口大小填充就是我服务端接受缓冲区剩余空间大小。 得知对方接受能力是多少客户端就知道应该最多发多少数据了。 这就叫16位窗口大小。
16位窗口大小填的应该是谁的接受缓冲区剩余空间大小呢 客户端给服务器发要进行流量控制服务器有没有可能给客户端发消息呢 tcp是全双工的。 所以从客户端到服务器端要进行流量控制那么从服务器到客户端发送要不要也进行流量控制呢 要 所以双方互发消息互相确认应答双方会出现很多tcp报头往来双方根据报头里16位窗口大小互相得知对方的接受缓冲区剩余空间大小双方就可以进行互相流量控制。
16位窗口大小 下定义
我要填充的报头一定是我要给对方发的。 所以16位窗口填写的是自己的接受缓冲区中剩余空间的大小
这么多报头传输效率会不会很低 后面有滑动窗口
应用层比如Http有主从关系你是客户端你只能向服务器发起请求 tcp双方地位对等即你能向我发送报文我给你确认应答左侧右侧都要互相有流量控制。
32位序号和32位确认序号
tcp说自己有确认应答机制我们该如何理解确认应答呢 为什么确认应答是保证可靠性最重要的一个核心点呢
思考一个问题 这个世界存不存在100%可靠的网络协议
例子我跟你不是面对面相隔100米 我给你发了个消息我们去吃饭吧 你回了个好的这样能保证我给你的消息你是收到了的但是你怎么知道刚刚说的好的被我收到了呢
那我要保证你刚刚给我发来的好的消息我也想让你知道我已经收到了怎么办呢我再给你回收到了你的好的了 可是当我给对方发了收到了你的好的了确实能保证上一次的好的消息被我收到了可是最新的消息怎么保证对方也收到了呢那对方再给你个应答吧 最新的消息怎么保证对方一定收到了呢 1。站在我个人角度只要我收到应答我就能保证我最近一次发送的消息对方收到了。 同理对对方也一样
2。没有应答的数据我们无法保证可靠性所以最新的一条消息不管是我给对方说还是对方给我说永远存在最新的一条消息是没有应答的所以在人类世界里几乎无法保证发出的消息时100%可靠的 所以世界上不存在100%可靠的协议的
虽然整体不存在但是局部上呢
我刚给你发的消息我给你应答对你来讲你并不确定这个应答我是否收到对我来讲我只要收到对应的应答我能保证从左向右方向上数据的可靠性。 对右边来讲右边给左边发的消息只要右边也收到应答他无法保证 最新的消息被自己收到但只要右边收到了应答就能保证从右向左的可靠性 虽然最新的一条消息没有应答无法保证最新的一条消息可靠但是局部上最新消息之前的消息我们其实是可以保证双方在两个方向上的可靠性。
这样说有点抽象直接说tcp真实的方案
左C右S tcp最基本最原始的通信过程 所以刚刚场景中除了最新的消息上面之前每一个报文的都有应答 所以之前的消息能保证各个方向上的可靠性 正常情况不会存在这样的场景的 我给你发个消息你给我应答了收到了站在我的角度呢我就不再给你发消息了。 我们没必要对应答再作应答实际上是鸡生蛋蛋生鸡的问题无穷尽了。
CS通信最终要的是保证两个方向上的可靠性 所以C给S发一条消息tcp数据 S要合适的时候对消息进行应答因为是客户端给服务器发消息我要保证消息被对方收到了我是主动的对方被动我只要保证我发的消息被对方收到了这不就达到了宏观层面上我们两个通信的目的吗。 所以我给对方发消息对方只要给我应答我收到应答时能保证我发的消息被对方收到了这就叫保证客户端到服务器方向上的可靠性。 我们不需要再对应答再给S进行响应。 如果服务器要给客户端发消息tcp数据本质也是完整的tcp报文。 服务器是主动的一方他要给客户端发消息本质的目的就是想确认把这个数据发送给C包括C给我做应答你也是告诉对方你刚给我发的消息我已经收到了。 所以C也给S发了个应答 虽然C不能确定应答有没有被S收到暂时我们不管但假设S收到了应答服务器立马就意识到我刚刚发的消息对方也收到了所以只要收到应答我们从右向左的可靠性也能保证。 所以要发送的一个数据对应配套的收到应答就能保证两个朝向上的可靠性。
所以第一阶段总结论
