精华内容
下载资源
问答
  • 写在面前大话与PLC通讯中,我们已经很粗浅提到了TCP,UDP ,ISO ON TCP等,今天我们详细来讲讲,即OUC通讯(开放式用户通信,与S7-300/400S5兼容通信相同),OUC通讯服务适用于S7 -1500 /300/400 PLC之间通信、S7...

    写在面前

    大话与PLC的通讯中,我们已经很粗浅的提到了TCP,UDP ,ISO ON TCP等,今天我们详细来讲讲,即OUC通讯(开放式用户通信,与S7-300/400的S5兼容通信相同),OUC通讯服务适用于S7 -1500 /300/400 PLC之间通信、S7 PLC与S5 PLC间的通信,以及PLC与PC或与第三方设备进行通信。

    OUC通信有下列通信连接:

    • ISO Transport——该通信连接支持第四层(ISO Transport)开放的数据通信,主要用于SIMATIC S7-1500/300/400与SIMATIC S5的工业以太网通信。S7 PLC间的通信也可以使用ISO通信方式。ISO通信使用MAC地址,不支持网络路由。一些新的通信处理器不再支持该通信服务,S7-1500系统中只有CP1543-1支持ISO通信方式。ISO通信方式基于面向消息的数据传输,发送的长度可以是动态的,但是接收区必须大于发送区。最大通信字节数64K。
    • ISO-on-TCP——由于ISO不支持以太网路由,因而西门子应用RFC1006将ISO映射到TCP协议上,实现网络路由,与ISO通信方式相同。西门子PLC间的通信建议使用ISO-on-TCP通信方式。最大通信字节数64K。
    • TCP/IP——该通信连接支持TCP/IP协议开放的数据通信。用于连接SIMATIC S7和PC以及非西门子设备。PC机可以通过VB、VC SOCKET控件直接读写PLC数据。TCP/IP采用面向数据流的数据传送,发送的长度最好是固定的。如果长度发生变化,在接收区需要判断数据流的开始和结束位置,比较繁琐,并且需要考虑到发送和接收的时序问题。所以,在西门子PLC间进行通信时,不建议采用TCP/IP通信方式。最大通信字节数64K。
    • UDP——该通信连接属于第四层协议,支持简单数据传输,数据无须确认,与TCP/IP通信相比,UDP没有连接。最大通信字节数1472。

    不同接口支持OUC通信连接的类型如下所示。

    S7-1500 系统以太网接口支持OUC通信连接的类型

    f3636d87197db1fdb202572b4fae5dd6.png

    如果对上述不是很懂的小伙伴不要着急,下一期我们会以S1500为例,以实例来讲解西门子的 OUC通信 ,之后会逐步讲到I智能设备I-Device, TIA Portal Openness等,

    此外,这是本系列的第六讲,也是第一次对通讯系列进行小结,对于网络知识和编程知识还没学好的小伙伴,可以仔细看看前面通信系列中其它几期(微信公众号:智能制造之家),先将对应的网络学习资料和编程资料下载学习了

    大话与PLC通讯的N种方式第一期-以西门子300为例

    大话与PLC通讯的N种方式第二期-S1200通讯案例说明

    MES与PLC握手的几种方式——大话与PLC通讯的N种方式第三期

    西门子S7-1200的Modbus RTU通讯-大话与PLC通讯的N种方式第四期

    大话PLC的N种通讯第五期-基于C#的TCP通讯与S7通讯

    今天就到这里啦~,如果各位看官喜欢的话,欢迎点击右下角的“在看”,或转发和收藏哦。(不要忘记文末彩蛋哦)

    • 对于文中所有使用的图片,资料,下载链接中所包含的软件,资料等,如有侵权,请告知删除,谢谢。

    往期推荐(往期推荐仅仅限于微信公众号:智能制造之家)

    玩Vmware虚拟机多年的工程师们,桥接模式、NAT、仅主机模式你们懂了吗?| 详解网络模式

    WinCC V7.5典型架构及选型指南

    Simcenter Amesim:安装与使用过程中的那些坑

    罗克韦尔AB全系列PLC产品介绍(附AB安全PLC资料下载)

    知识体系系列|给你最完善的Teamcenter知识体系

    西门子840DSL二次开发简介

    感兴趣的朋友可以关注微信公众号:智能制造之家,申请加入【智能制造之家】技术群,和志同道合的朋友们共同打卡学习!

    展开全文
  • 什么是握手信号多比特跨时钟域握手接口多比特跨时钟域握手设计方案一接口时序电路设计多比特跨时钟域握手设计方案二接口时序电路设计什么是握手信号握手指是两个设备之间通信种方式,用来通信信号就是握手...

    f4c05326975044f805da76e4d8f52b7b.png

    关于多比特跨时钟域设计,在前面的文章中我们已经总结了格雷码和异步FIFO。本篇文章我们来看一下握手控制,本文将从以下几点来总结:

    • 什么是握手信号
    • 多比特跨时钟域握手接口
    • 多比特跨时钟域握手设计方案一
      • 接口时序
      • 电路设计
    • 多比特跨时钟域握手设计方案二
      • 接口时序
      • 电路设计

    什么是握手信号

    握手指的是两个设备之间通信的一种方式,用来通信的信号就是握手信号。最简单的握手信号是 valid 和 ready,也可以叫 request 和 grant。假设设备1向设备2发送数据,设备1不知道设备2什么时候可以接收数据,设备2也不知道设备1什么时候会发送数据,那么它们之间如果用握手通信可能是这样的顺序:

    1. 设备1将 valid 信号置1,告诉设备2,数据准备就绪了,请查收
    2. 设备2此刻正处于忙碌状态无法接收数据,设备2将 ready 信号保持为0
    3. 设备2空闲了,将 ready 信号置1接收设备1的数据
    4. 设备1看到设备2的 ready 为1,它知道设备2已经接收好数据了,将 valid 置0同时撤销数据,准备下一次发送。

    可以看到因为有握手控制,可以确保数据的正确传输,不会丢失。跨时钟域的握手设计就是利用握手控制这种优势,从而避免因为跨时钟域引起的数据传输错误。

    多比特跨时钟域握手接口

    图1是多比特跨时钟域的接口设计。

    bb5aaada239b49a9bf474c1e1834ac13.png
    图1 - 多比特跨时钟域握手接口设计

    可以看到握手模块其实就是一个桥梁,用来连接 clock1 时钟域和 clock2 时钟域。接口上看它有:

    • 两组时钟复位信号输入,(clk1,rst1) 和 (clk2,rst2)
    • 两组握手信号,(valid1,ready1)和(valid2,ready2)
    • 两路数据信号,(data1输入)和(data2输出)

    多比特跨时钟域握手设计方案一

    方案一和本文在第一部分讲的设备1和设备2通信的顺序是一样的。

    接口时序

    c1ce29096e023a15d113726a10e1c973.png
    图2 - 跨时钟域握手方案一接口时序

    电路设计

    按照图2的接口时序,我们可以先描述一下握手模块的功能和步骤:

    1. (跨时钟域)同步 clock1 时钟域的 valid1 信号到 clock2 时钟域,称之为 valid1_2
    2. (clock2时钟域)利用同步后的 valid1_2 产生一个脉冲信号 pulse_1
    3. (clock2时钟域)当看到 pulse1 为高电平时需要采样数据 data1 到寄存器 data1_2,同时拉高 valid2 信号,然后将寄存器 data1_2 存放的数据输出到 data2
    4. (clock2时钟域)当看到 ready2 为高同时 valid2 也为高时,拉低 valid2,同时产生一个脉冲信号,称之为 pulse2
    5. (跨时钟域)将脉冲信号 pulse2 同步到 clock1时钟域,同步后的脉冲信号称之为 pulse2_1
    6. (clock1时钟域)将脉冲信号pulse2_1输出到 ready1

    描述完上述步骤之后,对应的电路/代码设计其实也一目了然了:

    步骤1. 两级寄存器同步器

    logic [1:0] valid1_2_ms_q;
    logic       valid1_2_q;
    always_ff @(posedge clk2 or posedge rst2)
      if (rst2) begin
        valid1_2_ms_q <= 2'b00;
        valid1_2_q    <= 1'b0;
      end else begin
        valid1_2_ms_q <= {valid1_2_ms_q[0], valid1};
        valid1_2_q    <= valid1_2_ms_q[1];
      end
    

    步骤2. 组合逻辑

    logic pulse_1;
    always_comb begin
      pulse1 = !valid1_2_q & valid1_2_ms_q[1]; 
    end
    

    步骤3和4. 数据数据寄存器data1_2,标志寄存器valid2 + 控制组合逻辑

    // 输出数据寄存器
    logic [N-1:0] data1_2_q;  // assume input data is N bits
    always_ff @(posedge clk2 or posedge rst2)
      if (rst1) begin
        data1_2_q <= '0;
      end else begin
        if (pulse_1) begin 
          data1_2  <= data1;
        end
      end
    assign data2  = data1_2_q;
    
    // 输出 valid 标记寄存器
    logic valid2_d, valid2_q;
    always_comb begin
      valid2_d = valid2_q;
      if (pulse_1) begin
        valid2_d = 1'b1;
      end else if (valid2_q & ready2) begin
        valid2_d = 1'b0;
      end
    end
    always_ff @(posedge clk2 or posedge rst2)
      if (rst1) begin
        valid2_q <= '0;
      end else begin
        valid2_q <= valid2_d;
      end
    assign valid2  = valid2_q;
    
    // 脉冲信号
    assign pulse2 = valid2 & ready2;
    

    值得注意的时,这里数据data1是在 clock1 时钟域,而寄存器data1_2是在 clock2 时钟域,为什么可以直接采样而不会有问题呢。从图2可以看到data1在valid1拉高之后是保持不变的,跨时钟域采样一个不变的数据是不会有问题的。

    步骤5. 单比特脉冲跨时钟域同步器。

    之前的文章 FPGA 设计之 跨时钟域(二) 已经介绍过单比特脉冲同步器的设计。

    步骤6. 连线

    assign ready1 = pulse2_1;
    

    多比特跨时钟域握手设计方案二

    接口时序

    如图3所示。你能看出与图2的区别吗?

    533ace31c499719a743c2f6ca54089c0.png
    图3 - 跨时钟域握手方案二接口时序

    区别主要是在valid1,在图1的时序图中valid1是一个电平信号,而这里valid1变成了脉冲信号。

    电路设计

    因为valid1变成了一个脉冲信号,我们就不能用简单的两级寄存器来同步了。而是需要用单比特脉冲同步器,同时看到valid1有效时要先将数据 data1 存储在clock1时钟域的寄存器中。其他的逻辑基本上和方案一是一样的。

    logic [N-1:0] data1_local_q;
    always_ff @(posedge clk1 or posedge rst1)
      if(rst1) begin
        data1_local_q <= '0;
      end else begin
        if(valid1) begin
          data1_local_q <= data1;
        end
      end
    

    总结

    在本篇文章中我们总结了多比特跨时钟域的握手原理和设计,包括两种不同方案的接口时序和电路设计。

    另外,文章我也会后续发布在微信公众号 FPGA开发之路,欢迎讨论交流。

    展开全文
  • 综述:http有八种请求方式,常用是get和post,其余六种是option,delete,put,head,trace,connect,后边这几种不怎么常用,完全可以由get和post间接实现 1. http 1.0  1.1 链接无法复用,即不支持持久链接:  ...

    综述:http有八种请求方式,常用的是get和post,其余六种是option,delete,put,head,trace,connect,后边这几种不怎么常用,完全可以由get和post间接实现

    1. http 1.0

      1.1 链接无法复用,即不支持持久链接:

              http 1.0 规定浏览器与服务器保持较短时间的链接,浏览器每次请求都和服务器经过三次握手和慢启动(基本思想是当TCP开始传输数据或发现数据丢失并开始重发时,首先慢慢的对网路实际容量进行试探,避免由于发送了过量的数据而导致阻塞)建立一个TCP链接,服务器完成请求处理后立即断开TCP链接,而且不跟踪每个浏览器的历史请求。

            注意:由于http 1.0每次建立TCP链接对性能的影响实在是太大,http1.1实现持久化链接之后,又反向移植到http 1.0上,只是默认是没有开启持久链接的,通过http的header部分的 Connection: KeepAlive 来启用)

    1.2 线头阻塞(Head of Line (HOL) Blocking)

                   请求队列的第一个请求因为服务器正忙(或请求格式问题等其他原因),导致后面的请求被阻塞。

    2. http 1.1

        2.1 支持持久链接(在request和response中的header中的connection是close或者Keep-Alive进行控制)

              一个TCP链接可以传送多个http请求和相应,减少了TCP建立链接和关闭链接的消耗。另外http1.1允许客户端不用等待上一次请求结果返回,就可以发出下一次请求,但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果,以保证客户端能      够区分出每次请求的响应内容。

    2.2 支持http管道

    不使用管道的http请求,在使用持久链接时,必须严格满足先进先出的队列顺序(FIFO),即发送请求,等待响应完成,再发送客户端队列中的下一个请求。管道可以让我们把 FIFO 队列从客户端(请求队列)迁移到服务器(响应队列),即客户端可以并行,服务端串行。客户端可以不用等待前一个请求返回,发送请求,但服务器端必须顺序的返回客户端的请求响应结果。

    缺点:

    a. 一个请求响应阻塞,就会阻塞后续所有请求

    b. 并行处理请求时,服务器必须缓冲管道中的响应,从而占用服务器资源,如果有个响应非常大,则很容易形成服务器的受攻击面;

    c. 响应失败可能终止 TCP 连接,从页强迫客户端重新发送对所有后续资源的请求,导致重复处理;

    d. 由于可能存在中间代理,因此检测管道兼容性,确保可靠性很重要;

    e. 如果中间代理不支持管道,那它可能会中断连接,也可能会把所有请求串联起来。

    2.3 使用多个TCP链接

    http1.1 在客户端排队所有请求,让后通过一个TCP持久链接,一个接一个的发送请求(如果有http管道还必须顺序等待服务端的顺序返回结果)。但实际中,浏览器的开发时不会这么笨,浏览器允许我们打开N个TCP链接(大多说浏览器是6个TCP链接,这个数字越大,客户端和服务器的资源占用越多,这个数据也只是感觉安全的数字而已)。

    带来的好处:

    1. 客户端可以并行发送最多 N个请求;

    2. 服务器可以并行处理最多 N个请求;

    3. 第一次往返可以发送的累计分组数量(TCP cwnd)增长为原来的 N 倍。

    代价:

    1.更多的套接字会占用客户端、服务器以及代理的资源,包括内存缓冲区和 CPU时钟周期;

    2.并行 TCP 流之间竞争共享的带宽;

    3.由于处理多个套接字,实现复杂性更高;

    4.即使并行 TCP 流,应用的并行能力也受限制。

    因此使用多个TCP链接只是权宜之计,后续的http 2.0支持多路复用,很好的解决了上述问题。

    2.4 http 1.1 增加了请求头和响应头来扩充功能

        举例:
             a. 支持Host请求:
             b. Connection: 请求头的值为Connection时,客户端通知服务器返回本次请求结果后保持连接;Connection请求头的值为close 时,客户端通知服务器返回本次请求结果后关闭连接
             c. 支持断点续传:
             d.身份认证:
             e.状态管理:
             f. 缓存处理:

    2.5 域名分区

    域名分区是思想是将原来集中到一个服务器上的资源分布到多个服务器上,这样就可以突破浏览器的链接限制(一般是6个),提高并行能力。

    代价:

    1. 每多一台主机都要多一次的 DNS 查询,每多一个套接字都会多消耗两端的一些资源;

    2.必须手工分离一台主机上的资源到多台;.

    实际实践中,效果并不是很明显,反而导致被滥用。

    2.6 http的header的优化

    目前所有的header请求都是以没有经过压缩的纯文本的形式发送(通常会有600`1000字节),而通常使用的http请求body却很少(10~200字节),和header相比,显得很少,特别是在使用了cookie之后,这样的矛盾就更加突出,因此要减少header的数据。

    2.7 减少连接次数

    即将需要多次才能获取的文件或资源组合并成一个,通过一次网络请求获取。这样减少了协议的开销,间接地将服务器端的管道思维移植到了客户端。缺点:增加复杂性,更缓存带来负担,页面的分步显示,改成一次显示,在网络慢的时候影响用户体验。

    2.8 嵌入小的文件

    即将资源嵌入文档(通过URI嵌入图片,音频或PDF),可以减少请求次数。嵌入资源作为页面的返回一部分一次返回,即如果在多个页面中都嵌入同样的资源,那么这个资源将会随着每个页面的加载而被加载,从而增大每个页面的总体大小,如果嵌入资源被更新,客户端只能重新获取有效的资源。

    实践:一般只考虑嵌入1~2KB一下的资源

    参照建议:

    1. 如果文件很小,而且只有个别页面使用,可以考虑嵌入;

    2.如果文件很小,但需要在多个页面中重用,应该考虑集中打包;

    3. 如果小文件经常需要更新,就不要嵌入了;

    4. 通过减少 HTTP cookie 的大小将协议开销最小化。

    3. http 2.0

    HTTP 2.0把解决性能问题的方案内置在了传输层,通过多路复用来减少延迟,通过压缩 HTTP首部降低开销,同时增加请求优先级和服务器端推送的功能。

      3.1 支持多路复用

             多路复用允许同时通过单一的 HTTP 2.0 连接发起多重的请求-响应消息,即所有HTTP 2.0 连接都是持久化的,而且客户端与服务器之间也只需要一个连接即可,所有数据流共用同一个连接 ,减少了因http链接多而引起的网络拥塞(在 HTTP1.1 协议中,同一时间,浏览器会针对同一域名下的请求有一定数量限制),解决了慢启动针对突发性和短时性的http链接低效的问题。

    3.2 将通信的基本单位缩小为帧

                 即应用层(HTTP)和传输层(TCP or UDP)之间增加一个二进制分帧层,因此在多向请求和响应时,客户端和服务器可以把HTTP消息分解为互不依赖的帧,然后乱序发送,最后再在另一端把它们重新组合起来,解决了http 1.*的对手阻塞问题。 

    3.3 首部压缩

                  http 2.0支持DEFLATE和HPACK 算法的压缩。

    3.4 服务端推送

              指客户端请求之前发送数据的机制,在 HTTP 2.0 中,服务器可以对客户端的一个请求发送多个响应。

    3.5 请求优先级

       HTTP 2.0 使用一个31比特的优先值,0表示最高优先级, 2(31)-1表示最低优先级,服务器端就可以根据优先级,控制资源分配,优先处理和返回最高优先级的请求帧给客户端。

    4.​​​​​八种http请求以及各自之间的异同

    • GET:向特定的资源发出请求。 

    • POST:向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。

    • OPTIONS:返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。 

    • HEAD:向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息。  

    • PUT:向指定资源位置上传其最新内容。 

    • DELETE:请求服务器删除Request-URI所标识的资源。 

    • TRACE:回显服务器收到的请求,主要用于测试或诊断。 

    • CONNECT:HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

       虽然HTTP的请求方式有8种,但是我们在实际应用中常用的也就是get和post,其他请求方式也都可以通过这两种方式间接的来实现。

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 在这种情况下,需要使用另一种方式来定位高延时点。 查找高延时点最有效方法之一是检查最初的握手信号以及跟随其后几个报文。例如,一个简单客户端与网络服务器连接,客户端尝试通过浏览器访问网络服务器...

    在某些情况下,丢包可能并不是造成延时的原因。你可能会发现尽管两台主机之间通讯速度很慢,但这种慢速并没有伴随着TCP重传或是重复ACK的征兆。在这种情况下,需要使用另一种方式来定位高延时点。

    查找高延时点最有效的方法之一是检查最初的握手信号以及跟随其后的几个报文。例如,一个简单的客户端与网络服务器的连接,客户端尝试通过浏览器访问网络服务器的站点。我们只关心这一通信序列的前六个报文,包括TCP握手过程,首次HTTP GET请求,对此GET请求的确认,以及从服务器发至客户端的第一个数据报文。

    更多信息

    正常通讯:

    在讨论高延时状况之前,找一个正常的通讯作为参照。在第二节已经介绍过TCP握手过程以及HTTP通讯,这里不再赘述。在下面这张图里,我们关心的部分只有Time列:

    这一通讯序列是非常快速的,整个过程耗时不到0.1秒。

    接下来几个抓包文件包含同样的traffic模式,但是在报文时序上有所不同。

    慢速通讯——线路延时:

    让我们看看下面这个报文。注意到所有报文都是相同的,除了报文2和5的时间延时较长:

    逐一分析这六个报文,立刻就会看到第一次延时。客户端(172.16.16.128)发送首次SYN报文以开始TCP握手,在服务器(74.125.95.104)返回SYN/ACK之前,有0.87秒的延时。这是线路延时的第一个信号,这是由客户端和服务器之间的设备引起的。

    我们判断这是线路延时的依据是所传送的报文类型特征。当服务器接收到一个SYN报文,只需花费很少的处理过程就可发送回复,因为这一工作负载并不包含任何传输层之上的处理。即使服务器工作负载非常繁重,它通常也会快速地以SYN/ACK来回复SYN报文。这就排除了服务器是高延时的潜在原因。

    客户端也被排除的原因在于,它除了接收SYN/ACK报文之外,没有进行任何处理。

    这一抓包的前两个报文帮我们排除了客户端和服务器,并指出了潜在原因。

    继续分析,我们发现结束三步握手信号的ACK报文快速出现,客户端发送的HTTP GET请求也是如此。产生这两个报文的所有处理在本地客户端接收到SYN/ACK之后进行,因此在客户端没有繁重的负载需要处理的情况下,这两个报文预计会很快传送。

    到了报文5,我们看到另一个延时高得离谱的报文。出现在最初的HTTP GET请求发送过后,从服务器返回的ACK报文花费了1.15秒才收到。接收到HTTP GET请求之后,服务器在开始发送数据之前首先发送了一个TCP ACK,同样只需占用服务器很少的处理。这是另一个线路延时的信号。

    不管何时你经历着线路延时,你几乎总是会看到:在最初的握手信号期间的SYN/ACK报文,以及整个通讯过程的ACK报文中,存在着高延时。即使这一信息并没有告诉你网络上延时的确切原因,至少让你明白客户端和服务器都不是延时点所在,因此延时发生在两者之间的设备。这时,你应当开始检查受影响主机之间的各种防火墙,路由器,以及代理,以定位罪魁祸首。

    慢速通讯——客户端延时:

    下一个延时场景的抓包如下图所示:

    这一抓包开始时很正常,TCP握手非常迅速,没有任何延时的迹象。正常状态持续至第四个报文:握手信号结束之后接收到一个HTTP GET请求。这个报文距离前一个接收到的报文有1.34秒的延时。

    要确认网络的延时点,需要检查第3和第4个报文之间发生了什么。报文3是客户端发送到服务器的TCP握手信号中的最后一个ACK,报文4是从客户端发送至服务器的GET请求。这两个报文的共同之处在于都是由客户端发送,并且独立于服务器。由于所有这些操作都集中在客户端上,GET请求应当在发送了ACK之后快速传送。

    不幸的是对于终端用户,从ACK到GET的传送并没有快速发生。GET报文的创建与传输取决于应用层的处理,这一过程中的延时意味着客户端无法及时的执行这一功能。这表示客户端最终为通讯中的高延时负责。

    慢速通讯——服务器延时:

    最后一个延时场景的抓包如下图所示:

    在这一抓包中,两个主机之间的TCP握手过程完成得干脆利落,因此开始时并无问题。接下来几个报文也很顺利,首个GET请求及回复ACK报文也在快速交付。直到最后一个报文,我们看到了高延时的信号。

    第六个报文是服务器响应客户端GET请求的第一个HTTP数据报文,但是在服务器发送GET请求的TCP ACK 0.98秒之后才到达。报文5和6的传送过程与我们在前一个场景所见ACK和GTE请求的传送类似。但是,在这一情况下,服务器是我们关注的焦点。

    报文5是服务器对从客户端接收GET请求的回应。只要该报文被发送,服务器就应当立即发送数据。这一读取,封装,传送的过程是由HTTP协议完成的,由于这是应用层协议,需要服务器参与处理过程。这一报文的延迟接收表明服务器无法在合理的时间内处理数据,最终指向服务器是延时点。

    延时定位思路:

    通过六个报文,我们能够定位服务器与客户端之间的网络高延时点。这些场景可能看起来有点复杂,但是下图能使你的定位延时过程变得简单快捷。这一原则几乎能应用于任何基于TCP的通讯。

    转载于:https://www.cnblogs.com/1x-zfd50/p/6971719.html

    展开全文
  • 2.13.2 接口数据一致性握手方式 29 2.14 调研后续工作落实阶段 30 2.14.1 如何写业务调研报告 30 2.14.2 业务调研报告完成后续工作 30 3. 如何写解决方案? 31 3.1 解决方案难写在哪里? 31 3.1.1 第一是没有体系 ...
  • 在某些情况下,丢包可能并不是造成延时原因。你可能会发现尽管两台主机之间通讯速度很慢,但这种慢速并没有伴随着TCP重传或是重复ACK征兆。...我们只关心这一通信序列个报文,包括TCP握手
  • 2.13.2 接口数据一致性握手方式 29 2.14 调研后续工作落实阶段 30 2.14.1 如何写业务调研报告 30 2.14.2 业务调研报告完成后续工作 30 3. 如何写解决方案? 31 3.1 解决方案难写在哪里? 31 3.1.1 第一是没有体系 ...
  • 在某些情况下,丢包可能并不是造成延时原因。你可能会发现尽管两台主机之间通讯速度很慢,但这种慢速并没有伴随着TCP重传或是重复ACK征兆。...我们只关心这一通信序列个报文,包括TCP握手过...
  • 一站式学习Wireshark():狙击网络高延时点 ...在这种情况下,需要使用另一种方式来定位高延时点。   查找高延时点最有效方法之一是检查最初的握手信号以及跟随其后几个报文。例如,...
  • python核心编程答案(第十章)

    千次阅读 2014-07-27 16:15:31
    ()网络提供的服务分两: 面向连接的服务和无连接的服务. 对于无连接的服务(邮寄), 发送信息的计算机把数据以一定的格式封装在帧中, 把目的地址... 这种连接是通过三次握手(three hand shaking)的方式建立起来的.
  • 进程通信,有几种方式?举例说说3.死锁条件和如何避免,说具体操作,银行家算法4.虚拟地址,逻辑地址,物理地址关系网络部分:1.http和https,SSL?加密解密?2.TCP为什么是三次握手?time_wait?3.交换机和路由器...
  • 写在前面:本篇介绍多路IO转接服务器实现种方式,select、poll、epoll,下面开始一一介绍,本篇文字叙述会比较少,代码量会大点。 Linux 网络编程 全解(一)--------网络基础协议 Linux 网络编程 全解(二...
  • 进程间共享信息种方式 IPC对象持续性 24进程间通信介绍(二) 死锁 信号量 PV原语 用PV原语解决司机与售票员问题 用PV原语解决民航售票问题 用PV原语解决汽车租赁问题 25System V消息队列(一) ...
  • Java 面试分享《一》

    2019-11-20 14:01:59
    Java 面试分享《一》一、map 集合按 value 排序二、类的实例化顺序三、描述一下类加载器四、动态代理的方式和优点五、通过反射创建类实例的三方式、JavaBean 的生命周期七、Spring 和 SpringBoot 的区别八、...
  • 进程间共享信息种方式 IPC对象持续性 24进程间通信介绍(二) 死锁 信号量 PV原语 用PV原语解决司机与售票员问题 用PV原语解决民航售票问题 用PV原语解决汽车租赁问题 25System V消息队列(一) 消息队列 IPC...
  • 进程间共享信息种方式 IPC对象持续性 24进程间通信介绍(二) 死锁 信号量 PV原语 用PV原语解决司机与售票员问题 用PV原语解决民航售票问题 用PV原语解决汽车租赁问题 25System V消息队列(一) ...
  • TCP协议3.1 TCP协议特点3.2 TCP报文段首部3.2.1 TCP的六个控制位3.3 TCP连接管理3.3.1 三次握手(建立连接)3.3.2 TCP四次挥手3.4 可靠传输3.4.1 序号3.4.2 确认3.4.3 重传3.5 TCP流量控制3.6 TCP拥塞控制3.6.1 ...
  • 4,request处理cookie种方式 五、自动化测试 1,自动化核心框架 2,自动化测试好处 3,自动化前提 4,自动化测试场景 5,元素定位8种方式 6,如果一个元素无法定位,一般会考虑哪些原因 7,driver.close...
  • LwIP经验分享

    2018-07-11 22:33:53
    LWIP使用经验一 LWIP内存管理数据包管理设置内存大小宏编译开关二 LWIP启动时序...LWIP常见问题网卡驱动程序内存泄露PC机无法与LWIP建立TCP连接 LWIP使用经验一 LWIP内存管理LWIP内存管理使用了2种方式:内存池...
  • 96.spring 支持几 bean 作用域? 97.spring 自动装配 bean 有哪些方式? 98.spring 事务实现方式有哪些? 99.说一下 spring 事务隔离? 100.说一下 spring mvc 运行流程? 101.spring mvc 有哪些组件? 102.@...
  • 44. 创建线程池有哪几种方式? 17 45. 线程池都有哪些状态? 18 46. 线程池中 submit()和 execute()方法有什么区别? 18 49. 什么是死锁? 19 50. 怎么防止死锁? 19 51. ThreadLocal 是什么?有哪些使用场景? 20 ...
  • linux网络编程

    2019-07-11 00:07:03
    getsockname、getpeername gethostname、gethostbyname、gethostbyaddr 11socket编程() TCP回射客户/服务器 TCP是个流协议 僵进程与SIGCHLD信号 12socket编程(七) TCP 11状态 连接建立三次握手、连接终止四...
  • 2.13.2 接口数据一致性握手方式 29 2.14 调研后续工作落实阶段 30 2.14.1 如何写业务调研报告 30 2.14.2 业务调研报告完成后续工作 30 3. 如何写解决方案? 31 3.1 解决方案难写在哪里? 31 3.1.1 第一是没有体系 ...

空空如也

空空如也

1 2
收藏数 34
精华内容 13
关键字:

六种握手的方式