企业网站建设板块,友情链接检索数据分析,关于网站建设的广告语,上海闵行网文章目录 OSI七层物理模型UDP 报头TCP 报头TCP 的特性1.确认应答2.超时重传3.连接管理 (**重点重点重点#xff01;#xff01;#xff01;**)TCP三次握手断开连接 - 四次挥手4.滑动窗口(效率保证)介绍一下TCP的滑动窗口机制#xff1f; 5.流量控制6.拥塞控制7.延时应答(提… 文章目录 OSI七层物理模型UDP 报头TCP 报头TCP 的特性1.确认应答2.超时重传3.连接管理 (**重点重点重点**)TCP三次握手断开连接 - 四次挥手4.滑动窗口(效率保证)介绍一下TCP的滑动窗口机制 5.流量控制6.拥塞控制7.延时应答(提高效率)8.捎带应答(提高效率)9.面向字节流如何处理TCP里面的粘包问题呢 10.TCP中的异常情况机器突然断电了TCP连接会怎么样 TCP中的心跳包机制基于UDP协议实现可靠传输场景适用于TCP场景适用于UDPTCP 和UDP的区别 OSI七层物理模型 物理层
最主要的功能传输比特流。利用传输介质为数据链路层提供物理连接实现比特流的传输。让上一层的数据链路层传送数据是尽可能屏蔽掉传输介质和物理设备的差异。
数据链路层
在物理层提供的比特流的基础上通过差错控制、流量控制等方法将物理层的比特流封装成数据帧传送到上一层。同样将这一层的数据帧插装成比特流转发到物理层。
网络层
数据链路层的数据在这一层转化成数据包通过路径选择、ip寻址基于IP地址进行路由转发将信息从一个设备传送到另一个网络设备。
传输层
提供可靠的端到端的差错控制与流量控制保证报文的正确传输。
会话层
建立和管理应用程序之间的通信可以检查两个app之间的对话是否可以对接
表示层
数据格式化、加密解密。
应用层
直接向用户提供网络服务完成用户在网络上的各种操作。
实际上OSI模型只是一个概念并没有落地在后期的实际组件网络中是以TCP/IP五层模型来实现的
应用层
复测应用程序之间的沟通。如简单电子邮件传输(SMTP) 、文件传输协议(FTP)、网络远程访问协议(Telnet)
传输层
负责两台主机间的数据传输。如TCP、UDP协议能够保证数据可靠的从源主机发送到目的主机
网络层
负责IP寻址和路由选择。 在IP协议中通过IP地址来表示标识一台主机并通过路由表的方式规划两台主机之间的数据传输线路路由。
数据链路层
负责设备之间数据帧的传送和识别。实现数据帧与比特流的转换
物理层
负责物理介质的传输设备传输比特流。
UDP 报头 UDP 报头一共8个字节4个字段
(1) 源端口号2个字节16位
(2) 目的端口号 2个字节16位
(3) UDP数据报长度2个字节16位
能表示0-65535 的数据单位是字节所以UDP数据报最大长度是 64KB,如果报文长度大于64KB,可能丢失数据。
(4) 校验和
传输的都是比特流0、1,可能受到干扰发生比特翻转数据发生错误。校验和来校验数据。
几种校验和的算法
CRC 循环冗余校验
简单介绍一下
发送数据之前按照字节取出数据再进行累加得到一个CRC校验和发送的时候发送数据包CRC校验和接收方拿到数据后根据数据在计算一遍CRC校验和如果和收到的CRC一致说明数据大概率没有问题。
md5
也是一种算法本质上是一个非对称的哈希算法
特性
1.定长无论输入的字符串是多长得到的md5值都是固定长度
2.分散只要输入的字符串哪怕只变化了一点点得到的md5 值都会变化巨大
3.不可逆给定原串很容易得到md5值但是给定md5 值理论上无法恢复成原串的。
TCP 报头 (1) 源端口号 2个字节 16位
(2) 目的端口号 2个字节 16位
(3) 序号和确认序号 都是32位4个字节
他俩的作用是保证应答机制的可靠性就是发送方连续发送了几个数据接收方也回了多个应答报文能用序号和确认序号给应答报文和发送的数据对应上。
(4) 4位首部长度 它能够表示0-15 ,但是呢头部长度远远大于15个字节所以它的单位是4个字节首部长度是15就意味着头部长度是 60个字节首部长度最大是60个字节
首部长度划分了 header 和 payload 的分界线
(5)保留6位
现在还没啥用以后可能有用就先留着。
(6)
TCP 的特性
1.确认应答
发送方发送数据给接收方了接收方立刻回应一个应答报文。这个是TCP 保证可靠性的核心
如果A连续发了两条信息B也要回两条信息怎么保证应答和发送是对应的呢 2.超时重传
什么时候重传
1.A发送给B数据因为网络堵塞数据丢了,A一直没有收到B的应答不知道是否发送成功给B.
2.A给B发送数据B接收到了B给A发送应答报文这个应答报文丢了所以A就也不知道到底发送成功了没有。
所以这种情况怎么解决?
等待一段时间后重发一次还没有收到应答再次重发每重发一次等待的时间越长(让重发的频率降低)累积到一定的重发次数还是失败的话网络异常连接关闭。
3.连接管理 (重点重点重点) 有两台主机想要建立连接 A发送了一个SYN1的报文给B,尝试建立连接。
B收到请求后立刻发送一个ACK1的报文确认应答同时第一时间发送一个SYN为1的报文也尝试与A建立连接。因为都是第一时间发送这个报文为了减小开销就合成一步发送SYN 、ACK都为1 的报文给A
A收到B的应答ACK和SYN后立刻返回一个ACK1 的报文确认应答。
至此两台主机的TCP就连接完成。
TCP三次握手
同上
TCP三次握手的目的是什么
1.投石问路。通过三次握手的过程来确认发送方与接收方的发送能力以及接受能力都是正常的。
2.协商参数。通过三次握手让发送方和接收方在正式连接之前先通通气选择一些传输中合适的参数比如TCP传输数据的序号从几开始。
为什么TCP是三次握手能不能是两次握手能不能是四次握手
为啥是三次握手,说明
TCP建立连接之前发送方和接收方不知道对方的接收发送能力也不知道自己的发送接收能力。
A要知道自己收发正常也要知道B收发正常。
B要知道自己收发正常也要知道B收发正常。 结合图片进行分析
第一次握手A尝试与B建立连接
B知道了 A的发送正常B的接收正常
第二次握手B确认引发、尝试与连接
A知道了 B的发送能力、接收能力A的发送能力、接收能力都正常A对于双方的情况都知道了但是B他不知道B自身的发送能力是否正常
第三次握手A发送确认应答报文
这个时候B就知道了B的发送正常A的接收也正常。
同时A、B双方都知根知底了都知道对方和自身接收发送能力是否正常了所以完成连接。
两次握手行不行
你就和面试官说一下前两次握手的细节过程给他走一遍看看发送方到底知道了啥接收方到底知道了啥只有发送和接收方都啥都知道才能建立可靠的连接。
不行此时只有发送方对自己和对方的收发能力都知道了但是接收方信息不全不知道对方的接收和自己的发送是否正常所以如果两次握手建立连接那么这个连接就会有问题。
四次握手行不行
理论上是可以的就是把第二次握手发送的那个syn1 ack1 的报文拆成两次发但是没必要反而会增大开销如果把这个一个报文分成两次发那么就要在经历层层封装报头解析报文等等等操作开销很大所以因为第一次握手直接同时触发了确认应答和同步报文合成一个报文减小开销提高效率理所应当。
断开连接 - 四次挥手
这个过程一定要记住客户端与服务器端的各个状态 第一次挥手
客户端----服务器端
客户端想要尝试断开连接发送了一个FIN1 的报文此时客户端进入fin-wait1 状态 fin_wait 1 这个状态是等待自己的fin报文是否发送成功等待接收回应 第二次挥手
服务器端收到客户端的请求断开连接的请求确认应答回复一个ACK报文
服务器端进入close_wait 状态等待执行 自身断开连接的请求 close_wait状态 服务器收到FIN之后进入到的状态等待用户代码执行 close关闭连接操作因为要等待关闭所以 叫 close _ wait (服务器端请求断开是用户控制的比如网络编程中我们在socekt.close()之前 执行thread.sleep那么服务器就得等待时间到了才能执行发送fin报文)
此时客户端接收到了ack进入到了fin_wait2 状态 fin_wait2 状态是等待接收服务器端的fin报文 第三次挥手
服务器可以执行 断开连接的操作给客户端发送一个fin报文此时进入到last_ack 状态等待客户端回应ack last_ack 服务器端在发送完fin之后等待客户端回应一个ack的状态 第四次挥手
客户端接收到了服务器端发送到fin报文确认应答回应一个ack报文
客户端在回复的同时立刻进入到time_waiting 状态这个状态是为了处理最后一个ack丢失。
随后如果最后ack正常发到如果客户端没有接收到服务器重传的fin那么此时销毁连接tcp连接关闭。
time _wait 状态(重点)
这个状态就是为了处理最后一个ack丢包就是如果A收到fin并回复一个ack就直接销毁连接了而不是进入time _wait状态那么可能是因为丢包最后B 没接收到ack就销毁了最后一个ack就没接收到。因为连接销毁也没办法重传ack了。
所以进入到time_wait 状态等待一段时间如果一定时间内客户端没有收到服务器重传的fin发过去才会真正的销毁连接。
time_wait 会等待多长时间
2MSLMSL是报文最大生存时间
1MSL是主机A和主机B之间的一次最大通信时间就是发送方发送数据给接收方接收方处理后又会给对方相应一来一回需要等待2倍的时间。
2MSL是从客户端收到服务器的fin发送ack开始计时的如果在time-wait 时间内客户端的ack没有传输到服务器那么服务器就会重传的fin报文客户端重新发送ack。
tcp挥手的过程什么时候会丢包
1.第一个fin丢了A收不到ack就会重传fin
2.第一个ack丢了A收不到ack就会重传fin
3.第二个fin丢了B收不到ack,就会重传fin
4.第二个ack丢了B收不到ack就会重传fin
为什么发送ack 和 fin 的报文不能合并发送呢
对于服务器来说ack和fin的触发时机是不一样的
1.服务器收到客户端的fin就会立刻出发ack这是内核完成的
2.服务器发送fin报文是用户代码控制的用户的代码出现了socket.close才会触发
四次挥手一定是四次吗能不能是三次
有可能是三次虽然ack和fin是不同时机触发的但是在延时应答和捎带应答的情况下是有可能合并在一起的。
四次挥手一定会执行吗
也不一定四次挥手是一个TCP正常断开的流程但是又的时候TCP连接会异常断开(网线直接拔了)
4.滑动窗口(效率保证)
TCP不仅要考虑可靠性还要尽可能的提高效率问题。
介绍一下TCP的滑动窗口机制
就是说因为TCP有一个确认应答的特性对于每个发送的数据段收到之后都会回复一个ack报文应答但是这有一个缺点性能较差。 一发一收的方式处理数据效率很低。
所以TCP是一次发一波数据一次接收多个ack提高效率。 这里的提高效率可以用一个例子来理解
一发一收
我去小吃街去买饭我想买香肠、包子、饺子一发一收就是我去包子摊给老板说买包子等他做好了我再去香肠摊给老板说卖香肠等他做好了再去饺子摊等他做好了就买完了。最后我们所需的时间就是所有小吃摊做饭的时间
多发多收
我去小吃街去买饭我想买香肠、包子、饺子我先去包子摊说我要买包子说完直接去饺子摊给老板说买饺子说完立刻去香肠摊给老板说要香肠同时等他们做完最后我们所需要等待的时间是做饭最长的那个摊的时间
滑动窗口就是多发多收的机制但是限制了发送数据的大小
而什么是滑动窗口滑动窗口是一次发送数据的最大值比如说窗口大小4000一次只能发送11000,10012000,20013000,30014000,这是数据发送的范围然后接收到1001200130014001 的ack说明已经全部发送成功了。
在滑动窗口的机制下如果发生了丢包怎么重传呢
1.丢的是ack。
如果丢的是ack那么无所谓我们通过序号和确认序号来对应每条请求和确认应答的确认序号的作用就是说明前面的数据都接收到了如果后面数据的ack都接收到了那么前面数据的ack接不接收都无所谓了。
2.丢的是发送的数据
如果丢的是发送的数据的话发了110001001200020013000这几个数据11000丢失的话虽然后面的数据服务器接收到了但是服务器这边一直没有1001的数据那么接收端会一直索要确认序号是1001的报文,提醒发送端重发发送端接收到3次后就会重新发送这块数据1~1000
5.流量控制
流量控制是对滑动窗口的一种补充~
窗口大小是决定了传输的效率窗口越大效率越高但是不可靠了窗口越小效率降低但是可靠。
所以通过流量控制来保证效率和可靠性的均衡。
滑动窗口的值能不能无限大
如果无限大的话就很不好控制我们应答机制就是一个请求一个回应如果一次全部发送完就是不等ack就一顿发就完全没有可靠性而言了我们是靠ack来保证可靠性的。
|
怎么控制流量 滑动窗口的大小就是 接收方缓冲区大小的字节数 发送数据与接收数据很像生产者消费者模型阻塞队列就相当于这个接收方的缓冲空间。如果一下子发送数据的速度太快了同时窗口很大但是接收方读取数据的速度很慢那么接收方一下子就处理不了了。
所以发送方每过一段时间发一个窗口探测包问一问接收方缓冲剩余空间还有多少空间发送一个数据包询问tcp首部窗口大小再回一个确认报文ack得知还有多少空间。然后再根据剩余空间的大小决定发送数据的速度以及多少。
如果窗口大小为0停止发送数据等到滑动窗口有空间了再次传输其中怎么得知是否有空间就是通过窗口探测包来确定的。 TCP首部窗口大小字段最多是64KB那么传输更大的数据发现效率太慢怎么办? TCP首部滑动窗口只有16位表示0-65525,单位是字节所以最多表示滑动窗口的大小是64kb但是真实要传输的数据确实很大的64kb的滑动窗口确实太小了所以在tcp首部选项字段中有一个窗口扩大因子M,实际的窗口大小是 16位窗口大小左移M位
6.拥塞控制
站在另一个角度来控制滑动窗口的大小的方式
先用木桶原理来说明就是在传输数据的时候发送方和接收方要经过很多网络路由设备如果只根据接收方的接受能力比如接收方处理数据很快那么发送方就发的快这样是很不合理的尽管接收方处理的很快但是只要中间过程有一个设备处理的很慢那么整体就很慢。
所以用拥塞控制的方式来解决这种问题
拥塞控制确认滑动窗口的大小
为了不发生上面的情况发送方先放松一个比较小的窗口来传输数据看看是否丢包。
如果不丢包说明网络通畅那么就逐渐加大发送速率
如果丢包说明网路堵塞那么就立即降低发送速率。
经过多次实验能够得到一个具体的合理的能够传输数据的一个窗口大小。
最终的窗口大小是(流量控制得到的窗口大小)与 (拥塞控制得到的窗口大小) 两者之间的最小值
拥塞控制计算窗口大小的方式(重要重要重要)
我认为可以先举例子。
你和对象刚开始认识的时候很有新鲜感所以感情上升的很快(指数级上升)随着时间的推移感情上升的就比较平稳了当发生了矛盾感情直接调入低谷。 和好之后感情又从低谷上升也很快(但是没有第一次快)然后上升到程度又开始平稳又遇到矛盾重复此过程。
拥塞控制计算滑动窗口的大小的大概流程就是这么个过程
具体我们来说一下在tcp中计算拥塞控制的滑动窗口怎么计算。 慢启动
窗口大小从1开始二倍增长
拥塞避免
达到一定的阈值ssthresh此时每次窗口大小cnwd1
网络超时
如果这个窗口的数据发送过去造成了网络超时此时窗口大小cnwd从1开始慢启动此时阈值为之前网络超时cnwd/2然后达到阈值拥塞避免逐渐1.
得到失序报文段
就是虽然没有造成网络超时但是我们接收方得到的数据不是完整的数据报丢失了或者发生错误了所以此时的窗口大小也是不可取的。发送方接收到三个重复确认后进行快恢复。窗口大小又从当前窗口的一半重新开始拥塞避免逐渐1.
以后每次都是这样的过程把这个具体的窗口大小给更加精细化到最后算出一个大小来。
7.延时应答(提高效率)
之前我们通过流量控制、拥塞控制得到了一个具体的窗口大小
但是如果接收到数据立刻返回ack的话那么此时返回的窗口可能较小。
假如接收缓冲区为1M一次收到500k的数据如果立刻应答返回的窗口就是500k但是实际上接收端处理数据很快如果在等一小会窗口里的数据就全部处理完了所以我们可以在保证网络不阻塞数据不丢失的前提下延时发送ack此时返回的窗口大小就更大那么数据吞吐量就越大效率就越高。
8.捎带应答(提高效率)
在延时应答的基础上有了捎带应答提高效率
啥叫捎带应答
咱通俗的说就是因为延时应答导致原本发送两个报文但是因为延时让这两个报文在同一时刻发送那么就可以捎带应答合成一个报文发送提高效率 原本内核态的ack因为延时应答导致和用户态的响应报文一块发送合成一个报文返回给客户端这就叫做捎带应答。
通过这种方式很多发送都能合二为一。 四次挥手也能变成三次
9.面向字节流
TCp数据包是面向字节流的所以接收方拿到数据后放到缓冲区缓冲区全是字节
应用程序从缓冲区读取数据的时候就不知道从哪到哪是一个完整的数据包了。此时应用程序只能看到一个一个的字节然后就整混了.
这就是粘包问题
如何处理TCP里面的粘包问题呢 通过设计一个合理的应用层协议解决
1.给应用层数据设置结束符、分隔符 每个数据都加上一个分号然后应用层读取的时候如果读到分号就知道前面的数据是一个完整的报文
2.给应用层设定一个长度 给应用层数据中加上一个读取的长度这个长度int占4个字节
接收方先读前4个字节就知道一个完整数据报的内容到哪里了然后把之后的内容读去这个长度
然后再读4个字节就知道这个数据包的长度然后读取这个数据报…
10.TCP中的异常情况
进程终止
进程终止后会释放PCB也会释放对应的文件描述符此时也会触发TCP四次挥手进程终止相当于socekt.close()
机器重启
机器重启也是先杀进程就是TCP会先四次挥手只不过可能还没挥完电脑就关闭了
机器断电/网线断开
机器突然断电了TCP连接会怎么样
突发情况机器来不及任何操作
要分成两种情况
1.断电的是接收方
发送方还是正常运行正常发送数据只不过一直收不到ack那么此时超时重传重传几次后还没反应就会重置连接将复位报文段RST1 发送给接收端要是还没反应就把连接销毁了。
2.断电的是发送方
发送方断电了接收方还正常运行发送方发送不了数据了接收方不知道发送方是挂了还是暂时没发数据。所以接收方采用心跳包机制每过一段时间发送一个PING包如果对方回复一个PONG包说明还有连接 如果PING包发过去没反应重试几次还没反应认为发送方挂了。
TCP中的心跳包机制
把场景引导TCP发生异常的情况
发送方突然挂了来不及四次挥手。
然后。。。。
基于UDP协议实现可靠传输
说一下tcp的各个特点就ok了
1.实现确认应答tcp在内核完成ack我们可以在应用层发送一个ack应答数据包
2.实现序号与确认序号确认序号保证之前的数据都收到了
3.实现超时重传超过一定时间就重新发送每次等待的时间更差高一点降低重传的次数
4.实现连接管理实现三次握手、四次挥手的过程
5.实现滑动窗口一次实现多发多收的效果提高效率。
6.实现流量控制/拥塞控制
流量控制是通过每次返回带有缓冲区的剩余空间大小的数据包给发送方然后发送方决定滑动窗口的大小
拥塞控制是发送方先发送一个滑动窗口很小的一个报探探路看网路是否拥塞经过多次实验得到一个窗口大小。
7.实现延时应答、捎带应答、心跳包机制
场景适用于TCP场景适用于UDP
1.需要可靠性首选TCP
2.发送的单个数据报较长(超过64kb),首选tcp
3.需要效率首选udp. 因为tcp为了所谓的可靠性牺牲了很多效率尽管使用了滑动窗口、拥塞控制、捎带应答等提高效率的手段但是还是没udp快
需要效率的场景机房内部的主机间通信
(1)网络环境简单带宽充裕丢包可能性不大
(2)机房内部的通信往往数据量更大更需要速度需要效率
4.如果需要广播(一份数据同时发给多个主机)优先考虑udp
tcp只能在应用层程序通过多个连接通过轮询的方式给每个主机返送数据(伪广播)
TCP 和UDP的区别
1.tcp是可靠的用确认应答超时重传等来保证可靠性udp是不可靠的
2.tcp有连接udp无连接
3.tcp面向字节流udp面向数据报
4.tcp全双的可靠信道udp是不可靠信道
5.udp首部只有8个字节udp数据包长度只有64kb。tcp首部最小长度是20个字节可能还有选项4n个字节。tcp的有一个首部字段4位首部长度最大表示15单位是4个字节如果头部最大长度就是60个字节
