建设银行佛山分行网站小规模企业所得税税率

当前位置： 首页 > news >正文

建设银行佛山分行网站,小规模企业所得税税率,网站框架怎么做,90设计网官网首页TCP 协议特性总结 TCP协议特点TCP协议段格式TCP原理确认应答#xff08;安全机制#xff09;超时重传#xff08;安全机制#xff09;连接管理#xff08;安全机制#xff09;(面试高频题)三次握手四次挥手 滑动窗口#xff08;效率机制#xff09;流量控制#xff08… TCP 协议特性总结 TCP协议特点TCP协议段格式TCP原理确认应答安全机制超时重传安全机制连接管理安全机制(面试高频题)三次握手四次挥手 滑动窗口效率机制流量控制安全机制拥塞控制安全机制 TCP协议特点 TCP协议具有 有连接可靠传输面向字节流全双工的特点 TCP协议段格式 TCP报文TCP报头首部TCP载荷 源/目的端口号表示数据是从哪个进程来到哪个进程去32位序号/32位确认号针对多组数据进行详细区分4位首部长度描述TCP报头具体的长度TCP报头长度可变UDP报头长度不可变固定8个字节 注意4位首部长度的单位不是字节而是4字节所以TCP报头最大长度是15 * 4 60字节 6位保留为了以后的扩展考虑 对于网络协议来说扩展升级是一件成本极高的事情后续TCP引入一些新功能的时候就可以使用这些保留位字段 6位标志位 URG紧急指针是否有效ACK确认号是否有效PSH提示接收端应用程序立刻从TCP缓 冲区把数据读走RST对方要求重新建立连接我们把携带RST标识的称为复位报文段SYN请求建立连接我们把携带SYN标识的称为同步报文段FIN通知对方本端要关闭了我们称携带FIN标识的为结束报文段 16位窗口大小16位检验和与UDP检验和作用相同都是验证数据传输是否正确但是不能保证数据安全性16位紧急指针标识哪部分数据是紧急数据选项选项之前的部分是固定长度20字节公式 选项长度首部长度-20字节 如果首部长度值是5表示整个TCP报头长度是20字节5x4字节相当于没有选项 如果首部长度值是15表示整个TCP报头长度是60字节15x4字节选项相当于是40字节 TCP原理 确认应答安全机制 示例图: A给B发了个消息B收到后就会返回一个应答报文ACK,此时A收到应答之后就知道刚才发的数据已经顺利被B接收。 考虑更复杂的情况 示例图: 由于网络上可能存在“后发先至”收到消息的顺序是可能存在变数的变成了“去吃饭不不好”“去学习不好”这就跟原义不符。 为了解决上述后发先至问题给传输的数据和应答报文都进行编号。 示例图: 这样就可以通过序号来区分当前应答报文是针对那个数据进行的 判断一条报文是否是应答报文取决于其报头中ACK标志位,如果ACK这个标志位为1则是应答报文为0则不是。 实际上由于TCP是面向字节流的TCP的序号也是按照字节来编号的 TCP的字节的序号是依次累加的每个TCP数据报报头填写的序号只需要写TCP数据的头一个字节的序号即可。 TCP知道了头一个字节的序号再根据TCP报文长度就很容易知道每个字节的序号。 确认序号的取值是收到的数据的最后一个字节的序号1 例如确认序号为1001 表示的含义 1.1001的数据都已经确认收到了。 2.A接下来应该从1001这个序号开始继续发送B向A索要1001的数据 小结TCP可靠传输能力最主要就是通过确认应答机制来保证通过应答报文ACK,就可以让发送方清楚的知道传输是否成功进一步的引入了序号和确认序号针对多组数据进行详细的区分 超时重传安全机制 上述讨论确认应答的时候只是讨论了顺利传输的情况并未讨论传输出现问题的情况例如丢包 以下是丢包的两种情况 第一种情况数据丢失 主机A发送数据给B之后可能因为网络拥堵等原因数据无法到达主机B如果主机A在一个特定时间间隔内没有收到B发来的确认应答就会进行重发 第二种情况ACK丢失 第二种情况重传数据可能会导致主机B收到很多重复数据。TCP就要对其进行去重以及重新排列。 TCP存在一个“接收缓冲区”这样的存储空间接收方操作系统内核里的一段内存每个TCP的socket对象都有一个接收缓冲区。 主机B收到主机A的数据其实是B的网卡读到数据并将这个数据放到B的对应socket的接收缓冲区中后续应用程序使用getInputStream,进一步使用read从接收缓冲区中读取数据。 TCP使用这个接收缓冲区根据数据的序列号识别是否有数据重复如果重复将后来的数据舍去并对收到的数据进行重新排序。 小结由于去重和重新排序机制都依赖于TCP报头的序号的存在发送方只要发现ACK没有按时到达就会重传数据即使重复了顺序乱了接收方都能很好地处理。 TCP的可靠传输就是通过确认应答超时重传来进行体现的。 其中确认应答描述的是传输顺利的情况 超时重传描述的是传输出现问题的情况。 连接管理安全机制(面试高频题) 在正常情况下TCP要经过三次握手建立连接四次挥手断开连接 三次握手 建立连接阶段的几种状态 1.LISTEN 监听对方建立连接请求表示服务器已经准备就绪随时可以有客户端来建立连接相当于手机开机信号良好随时可以接听他人的电话。 2.SYN_SEND属于请求连接此时发送的报文段不能携带数据。 3.SYN_RECEIVE接收到对方的连接建立请求。 4.ESTABLISHED 连接建立完成接下来可以进行正常通信相当于拨打电话对方接通。当客户端在此状态下发送的ACK报文段可以携带数据 所谓的三次握手本质上是“四次”交互。 通信双方各自要向对方发起一个“建立连接”的请求同时再各自向对方回应一个ack。中间两次交互是可以合并成一次交互的因此就构成了“三次握手”。 问题一为什么要将中间两次交互合并 答案和封装分用相关封装分用两次比封装分用一次成本更高。 问题二如果是两次握手能否建立连接的过程 答案不可以。 第一次握手客户端发送网络包服务端收到。 服务端可知客户端的发送能力,服务端的接收能力正常。 第二次握手服务端发送网络包客户端收到。 客户端可知客户端的发送能力,接收能力正常。服务端的发送能力接受能力正常。但是此时服务端并不知道自己的发送能力是否正常。 第三次握手客户端再次发送网络包服务端收到。 服务端可知客户端发送能力,接受能力正常。服务端的发送能力,接受能力正常。 因此需要三次握手才能确认双方的接收与发送能力是否正常 三次握手的意义 1.让通信双方各自建立对对方的“认同” 2.验证通信双方各自的发送能力和接收能力是否正常 3.在握手的过程中双方需要协商一些重要的参数来完成数据的同步。 建立连接阶段 四次挥手 四次挥手和三次握手非常类似都是通信双方各自向对方发起一个断开连接的请求在各自给对方一个回应。 建立连接阶段的几种状态 1.FIN_WAIT_1:客户端主动调用close时向服务器发送结束报文段(FIN)同时进入FIN_WAIT_1 2.CLOSE_WAIT:出现在被动发起断开连接的一方 当客户端主动关闭连接调用close服务器会收到结束报文段(FIN)服务器返回确认报文段(ACK)并进入CLOSE_WAIT 3. FIN_WAIT_2:客户端收到服务器对结束报文段的确认(ACK)则进入FIN_WAIT_2 开始等待服务器的结束报文段(FIN) 4. LAST_ACK:进入CLOSE_WAIT后说明服务器准备关闭连接需要处理完之前的数据当服务器真正调用close关闭连接时会向客户端发送FIN此时服务器进入LAST_ACK状态等待最后一个ACK到来这个ACK是客户端确认收到了FIN 5.TIME_WAIT:出现在主动发起断开连接的一方 假设是客户端主动断开连接当客户端进入TIME_WAIT状态的时候相当于四次挥手已经挥完了客户端收到服务器发来的结束报文段(FIN)进入TIME_WAIT并发出LAST_ACK 【TIME_WAIT - CLOSED】客户端要等待一个2MSL报文最大生存时间的时间才会进入CLOSED状态。 6.服务器收到了对FIN的ACK彻底关闭连接,进入CLOSED状态 TIME_WAIT的意义四次挥手与三次握手一样也会出现丢包的情况当服务器未收到最后一个ACK,就会进行重传操作因此使用TIME_WAIT状态保留一定时间是为了处理最后一个ACK丢包的情况能够在收到服务器重传的FIN之后,客户端能够针对这个重传的FIN进行ACK响应。 问题一为什么三次握手的中间两次j交互能够合并而四次挥手不能合并 答案 三次握手这三次交互过程是纯内核中完成的服务器的系统内核收到SYN之后就会立即发送ACK,也会立即发送SYN,同一时机所以能够合并。四次挥手中FIN的发起不是由内核控制的而是由应用程序调用socket的close方法或者进程退出才会触发FIN,ACK则是由内核控制当接收到发送方发来的FIN之后就会立即返回ACK,这两者之间通常情况下会有个时间差因此无法合并。 问题二想一想为什么是TIME_WAIT的时间是2MSL MSL是TCP报文的最大生存时间因此TIME_WAIT持续存在2MSL的话 就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失否则服务器立刻重启可能会收到来自上一个进程的迟到的数据但是这种数据很可能错误的 同时也是在理论上保证最后一个报文可靠到达假设最后一个ACK丢失那么服务器会再重发一个FIN。这时虽然客户端的进程不在了但是TCP连接还在仍然可以重发LAST_ACK 问题三服务器上出现大量的 CLOSE_WAIT 状态是什么原因 答案服务器没有正确的关闭 socket导致四次挥手没有正确完成。这是一个 BUG。只需要加上对应的 close 即可解决问题 滑动窗口效率机制 上述讨论的确认应答策略对每一个发送的数据段都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做使得性能较差。 此时就要引用滑动窗口机制来提高性能。 具体操作批量发送批量等待使用一份等待时间来等待一组数据的多个ACK本质上就是降低确认应答等待ack消耗的时间。
窗口大小:无需等待确认应答而可以继续发送数据的最大值,上图窗口大小就是4000 发送前四个段的时候不需要等待任何ACK直接发送收到第一个ACK后滑动窗口向后移动继续发送第五个段的数据依次类推 下面是针对丢包的两种情况进行的讨论 情况一数据包已经抵达ACK丢了。 这种情况下部分ACK丢了并不要紧因为可以通过后续的ACK进行确认 情况二数据包就直接丢了。 当某一段报文段丢失之后发送端会一直收到1001这样的ACK,是在提示发送端1001-2000的数据并没有接收到应将对应的数据1001-2000重新发送。这个时候接收端收到了 1001 之后再次返回的ACK就是7001了因为2001 - 7000接收端其实之前就已经收到了被放到接收缓冲区中。 上述机制也被称为“快速重传机制”。 流量控制安全机制 流量控制是一种干预发送窗口大小的机制 问题一为什么要控制窗口大小 窗口太大会消耗大量的系统资源.窗口太大完全不等待ack,就无法保证可靠性.要考虑接收方的处理能力 问题二TCP协议段格式中16位窗口大小是否意味着窗口大小最大是64kb呢 答案不是TCP通过在选项部分引入窗口扩展因子M使得实际窗口大小是 窗口字段的值左移 M 。 流量控制的工作就是根据接收方的处理能力通过查看接收方接受缓冲区的剩余大小来协调发送方的发送速率 发送端给接收端发送数据接收端查看自身接收缓冲区剩余大小并将这个值通过ACK报文返回给发送端发送端会根据这个数字来确认下一轮发送的窗口大小。 当窗口大小为0时发送方就要暂停发送暂停发送的等待过程中会给接收端定期发送窗口探测报文,这个报文不携带具体的业务数据只是为了触发ack查询窗口大小。 注意窗口大小是“发送方”的概念是通过接收方的ack报头里的窗口大小字段来告诉给发送方的。 拥塞控制安全机制 流量控制考虑的是接收方的处理能力接下来讲述的拥塞控制则是考虑传输过程中中间节点的处理能力二者共同决定发送方的窗口大小二者较小值 拥塞控制本质上就是通过实验的方式来逐渐找到一个合适的窗口大小。 0轮时窗口大小是1单位已非常慢的速度发送数据如果传输顺利就使窗口大小扩大一倍。初始阶段由于初始窗口比较小每一轮不丢包就会使窗口大小扩大一倍指数增长。当增长速率达到阈值后此时指数增长就转化为线性增长前提是不丢包的情况。当传输过程中一旦出现丢包说明此时发送的速率已经接近网络的极限这时就把窗口大小一下缩成很小的值重复上述指数增长和线性增长的过程 拥塞窗口不是固定数值而是一直动态变化的。 TCP是个非常复杂的协议不仅仅只有上述提到的特性如果想了解更多TCP特性可以去翻阅RFC标准文档。