jjzjj

Wireshark-Lab5:TCP

MINGgoS 2023-10-11 原文

更好的阅读体验

Lab5:TCP

在本实验中,我们将详细研究著名的 TCP 协议的行为。 我们将通过从您的电脑向远程服务器传输一份 150KB 的文件(一份 Lewis Carrol 的“爱丽丝梦游仙境”文本),并分析 TCP 传输内容的发送和接收过程来实现。 我们将研究 TCP 对序列和确认号的使用,以提供可靠的数据传输;我们将看到 TCP 的拥塞控制算法 – 慢启动和拥塞避免 – 在过程中,我们将看看 TCP 的接收器发送流量控制的机制。 我们还将简要地观察 TCP 连线的设置,我们还会研究计算机和服务器之间 TCP 连线的性能(吞吐量和往返时间)。

在开始本实验之前,您应该先查看课本中的第 3.5 和 3.7 节。

1. Capturing a bulk TCP transfer from your computer to a remote server (捕获从计算机到远程服务器的批量 TCP 传输)

在开始我们对 TCP 的探索之前,我们需要使用 Wireshark 来获取文件从计算机到远程服务器的 TCP 传输的数据包内容。您可以通过访问一个网页,在网页上输入您计算机上⬀储的文件名称(包含 Alice in Wonderland 的 ASCII 文本),然后使用HTTP POST 方法将文件传输到 Web 服务器(见文中第 2.2.3 节)。我们使用POST 方法而不是 GET 方法,因为我们希望将大量数据从您的计算机传输到另一台计算机。当然,我们将在此期间运行 Wireshark 以获取从您的计算机发送和接收的 TCP 区段的内容。

执行以下步骤:

  • 启动 Web 浏览器。 在 http://gaia.cs.umass.edu/wireshark-labs/alice.txt 查看Alice in Wonderland 的 ASCII 档案文件。 将此文件⬀储在计算机上的某个位置。

  • 接下来去 http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html.

  • 你将会看到如下图的网页

  • 使用此表单中的“Browse…”按钮在计算机上输入包含 Alice in Wonderland 的文件名(完整路径名)(或手动执行)。这个时候请不要按下“Upload alice.txt file”按钮。

  • 启动 Wireshark 并开始数据包捕获 (Capture-> Start),然后在 Wireshark 数据包捕获选项视窗上按 OK (我们不需要在此处选择任何选项)(详细操作因Wireshark 版本略有不同)。

  • 返回浏览器,按“Upload alice.txt file”按钮将文件上传到 gaia.cs.umass.edu服务器。文件上传后,浏览器窗口中会显示一条简短的祝贺消息。

  • 停止 Wireshark 数据包捕获。 您的 Wireshark 视窗内容应该类似于下面显示的内容。

  • 如果您无法在实际的网路上运行 Wireshark,则可以下载在作者的计算机上执行上述步骤时捕获的数据包跟踪文件。当您探索下面的问题时,即使您已经捕获了自己的传输内容并使用它来回答下面的问题,您也可能会发现这份下载的跟踪包很有参考价值。

2. A first look at the captured trace (跟蹤包的初步觀察)

在详细分析 TCP 连接的行为之前,让我们先概观看一下跟踪包的内容。

  • 首先,在 Wireshark 视窗顶部的显示的过滤器指定窗口中输入“tcp”(小写,无引号,并且不要忘记在输入后按 enter 键!),过滤 Wireshark 视窗中显示的数据包。

您应该看到的是计算机和 gaia.cs.umass.edu 之间的一系列 TCP 和 HTTP 讯息。您应该看到包含 SYN 讯息的初始三次握手。您应该看到 HTTP POST 讯息。根据您使用的 Wireshark 的版本,您可能会看到从您的计算机向 gaia.cs.umass.edu 发送一系列“HTTP Continuation”讯息。 回想一下我们在早期的 HTTP Wireshark 实验室中的讨论,这不是 HTTP Continuation 消息 – 这是 Wireshark 指示有多个 TCP 区段用于承载单个 HTTP 讯息的方式。在 Wireshark 的最新版本中,您将在 Wireshark显示的 Info 列中看到“[重新组装的 PDU 的 TCP 段]”,以指示此 TCP 区段包含属于上层协议讯息的数据(在我们的示例中为,HTTP)。您还应该看到从gaia.cs.umass.edu 返回到您的计算机的 TCP ACK 区段。

利用下载的 http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip 档案,打开其中的 Wireshark 捕获的数据包文件 tcp-ethereal-trace-1 来回答以下问题(即下载跟踪包并打开 Wireshark 中的跟踪包;见附注 2)。在回答问题时,您应该提交用于回答问题的跟踪内的数据包的列印输出。 加上适当的注释以解释您的答案。 要印出数据包,请使用文件 - >列印,选择仅选定数据包,选择数据包摘要行,然后选择回答问题所需的最小数据包详细信息量。

  1. 将文件传输到 gaia.cs.umass.edu 的客户端计算机(源)使用的 IP 地址和TCP 端口号是什么? 要回答这个问题,最简单的方法是使用“所选数据包标头的详细信息”视窗,选择 HTTP 讯息并探索用于携带此 HTTP 讯息的TCP 数据包的详细信息(如果你不确定是哪一个 Wireshark 视窗。请参阅“Getting Started with Wireshark”实验中的图 2 )
    • 分析作者提供的抓包结果
    • 作者 IP:192.168.1.102,TCP 发送端口 1161
  2. gaia.cs.umass.edu 的 IP 地址是什么? 在哪个端口号上发送和接收此连接的TCP 区段?
    • 接收 IP:128.119.245.12,TCP 接受端口 80

如果您能够连网并使用 Wireshark 创建自己的跟踪包,请回答以下问题:

  1. 客户端计算机(源)将文件传输到 gaia.cs.umass.edu 所使用的 IP 地址和TCP 端口号是多少?

由于本实验是关于 TCP 而不是 HTTP,让我们更改 Wireshark 的“捕获数据包列表”视窗,以便显示有关包含 HTTP 讯息的 TCP 区段的信息,而不是 HTTP 讯息。 要让 Wireshark 执行此操作,请选择 Analyze-> Enabled Protocols。 然后取消勾选 HTTP 框,并选择确定。 您现在应该看到一个 Wireshark 窗口,如下所示:

这就是我们正在寻找的 – 在您的计算机和 gaia.cs.umass.edu 之间发送的一系列 TCP区段。我们将使用您捕获的数据包跟踪(和/或 http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip 中的数据包跟踪 tcp-ethereal-trace-1:请参阅前面的脚注 )

在本实验的其余部分研究 TCP 行为。

3. TCP Basics (TCP 基础)

回答下列关于 TCP 区段的问题:

  1. 用于在客户端计算机和 gaia.cs.umass.edu 之间启动 TCP 连接的 TCP SYN 区段的序列号是什么? 将区段标识为 SYN 区段的区段有什么功能?

    • SYN相对序列号为 0, 绝对序列号为 232129012
    • 根据三次握手,客户端应该发送 SYN 请求请求建立连接,我找到发送的第一个请求并且发现客户端(我的电脑)将 SYN 标志标 0 用来请求建立连接。 S e q u e n c e   n u m b e r = 232129012 Sequence \ number =232129012 Sequence number=232129012 这是个随机值,这一步也是三次握手的第一步
  2. gaia.cs.umass.edu 发送给客户端计算机以回复 SYN 的 SYNACK 区段的序列号是多少? SYNACK 区段中的 Acknowledgment 栏位的值是多少?Gaia.cs.umass.edu 是如何确定此 Acknowledgment 的数值的? 在将区段标识为 SYNACK 区段的区段在连线中有什么功能?

    • SYN 为 0
    • A c k n o w l e d g m e n t   = 1   ( 232129013 ) Acknowledgment \ = 1\ (232129013) Acknowledgment =1 (232129013)
    • A c k n o w l e d g m e n t Acknowledgment Acknowledgment 为 客户端的 S e q u e n c e N u m b e r   ( 232129012 ) + 1 Sequence Number \ (232129012) + 1 SequenceNumber (232129012)+1
    • 意思是服务器接收到我的连接请求并且发 SYN-ACK 确认,这是三次握手的第二步。
  3. 包含 HTTP POST 命令的 TCP 区段的序列号是多少? 请注意,为了找到POST 命令,您需要深入了解 Wireshark 窗口底部的数据包内容⫿段,在其DATA 栏位中查找带有“POST”的区段。

    • S e q e n c e N u m b e r = 1 Seqence Number = 1 SeqenceNumber=1
    • Info 一栏中 [PSH, ACK] 里面的 PSH 即包含 HTTP POST 命令
    • 其中http post相关信息包含在[Reassembled PDU in frame: 199]
  4. 将包含 HTTP POST 的 TCP 区段视为 TCP 连接中的第一个区段。在这个TCP 连线中前六个 TCP 区段的序列号是什么(包括包含 HTTP POST 的段)? 每区段发送的时间是什么时候? 收到的每个区段的 ACK 是什么时候? 鉴于发送每个 TCP 区段的时间与收到确认的时间之间的差异,六个区段中每个区段的 RTT 值是多少? 收到每个 ACK 后,EstimatedRTT 值(参见本节中的第 3.5.3 节,第 242 页)是什么? 假设第一个 EstimatedRTT 的值等于第一个区段的测量 RTT,然后使用课本第 242 页的 EstimatedRTT 公式计算所有后续区段。(译注:中译本的页数可能不同)

    **注意:**Wireshark有一个很好的功能,允许您为发送的每个 TCP 区段绘制RTT。 在从客户端发送到gaia.cs.umass.edu服务器的“捕获的数据包列表”窗口中选择一个TCP段。 然后选择:Statistics-> TCP Stream Graph-> Round Trip Time Graph。

    ACK时间在SEQ/ACK analysis字段中,其中frame后的数字为对应的 PSH 帧的回应

    PSH No序列号发送时间回应 NoACK时间RTTEstimatedRTT
    410.02647760.0539370000.0274600000.02746
    55660.04173790.0772940000.0355570000.028472125
    720260.054026120.1240850000.0700590000.033670484375
    834860.054690140.1691180000.1144280000.043765173828125
    1049460.077405150.2172990000.1398940000.05578127709960937
    1164060.078157160.2678020000.1896450000.07251424246215821

    E s t i m a t e d R T T = 0.875 ∗ E s t i m a t e d R T T + 0.125 ∗ S a m p l e R T T EstimatedRTT = 0.875 * EstimatedRTT + 0.125 * SampleRTT EstimatedRTT=0.875EstimatedRTT+0.125SampleRTT

    EstimatedRTT after the receipt of the ACK of segment 1:

    E s t i m a t e d R T T = R T T f o r S e g m e n t 1 = 0.02746 s e c o n d EstimatedRTT = RTT for Segment 1 = 0.02746 second EstimatedRTT=RTTforSegment1=0.02746second

    EstimatedRTT after the receipt of the ACK of segment 2:

    E s t i m a t e d R T T = 0.875 ∗ 0.02746 + 0.125 ∗ 0.035557 = 0.0285 EstimatedRTT = 0.875 * 0.02746 + 0.125 * 0.035557 = 0.0285 EstimatedRTT=0.8750.02746+0.1250.035557=0.0285

    EstimatedRTT after the receipt of the ACK of segment 3:

    E s t i m a t e d R T T = 0.875 ∗ 0.0285 + 0.125 ∗ 0.070059 = 0.0337 EstimatedRTT = 0.875 * 0.0285 + 0.125 * 0.070059 = 0.0337 EstimatedRTT=0.8750.0285+0.1250.070059=0.0337

    EstimatedRTT after the receipt of the ACK of segment 4:

    E s t i m a t e d R T T = 0.875 ∗ 0.0337 + 0.125 ∗ 0.11443 = 0.0438 EstimatedRTT = 0.875 * 0.0337+ 0.125 * 0.11443 = 0.0438 EstimatedRTT=0.8750.0337+0.1250.11443=0.0438

    EstimatedRTT after the receipt of the ACK of segment 5:

    E s t i m a t e d R T T = 0.875 ∗ 0.0438 + 0.125 ∗ 0.13989 = 0.0558 EstimatedRTT = 0.875 * 0.0438 + 0.125 * 0.13989 = 0.0558 EstimatedRTT=0.8750.0438+0.1250.13989=0.0558

    EstimatedRTT after the receipt of the ACK of segment 6:

    E s t i m a t e d R T T = 0.875 ∗ 0.0558 + 0.125 ∗ 0.18964 = 0.0725 EstimatedRTT = 0.875 * 0.0558 + 0.125 * 0.18964 = 0.0725 EstimatedRTT=0.8750.0558+0.1250.18964=0.0725

  5. 前六个 TCP 区段的长度是多少?

    Segment 1 sequence length: 566 − 1 = 565 566 - 1 = 565 5661=565

    Segment 2 sequence length: 2026 − 566 = 1460 2026 - 566 = 1460 2026566=1460

    Segment 3 sequence length: 3486 − 2026 = 1460 3486 - 2026 = 1460 34862026=1460

    Segment 4 sequence length: 4946 − 3486 = 1460 4946 - 3486 = 1460 49463486=1460

    Segment 5 sequence length: 6406 − 4946 = 1460 6406 - 4946 = 1460 64064946=1460

    Segment 6 sequence length: 7866 − 6406 = 1460 7866 - 6406 = 1460 78666406=1460

  6. 对于整个跟踪包,收到的最小可用缓冲区空间量是多少? 缺少接收器缓冲区空间是否会限制发送方传送 TCP 区段?

    • The minimum amount of buffer space (receiver window) advertised at gaia.cs.umass.edu for the entire trace is 5840 bytes,which shows in the first acknowledgement from the server. This receiver window grows steadily until a maximum receiver buffer size of 62780 bytes. The sender is never throttled due to lacking of receiver buffer space by inspecting this trace.
    • 在gaia.cs.umass.edu为整个跟踪通告的最小缓冲区空间量(接收器窗口)是5840字节,这显示在来自服务器的第一个确认中。该接收器窗口稳步增长,直到最大接收器缓冲器大小达到62780字节。通过检查此跟踪,发送器永远不会因为接收器缓冲区空间不足而受到抑制。
  7. 在跟踪文件中是否有重传的区段? 为了回答这个问题,您检查了什么(在跟踪包中)?

    • There are no retransmitted segments in the trace file. We can verify this by checking the sequence numbers of the TCP segments in the trace file. In the TimeSequence-Graph (Stevens) of this trace, all sequence numbers from the source (192.168.1.102) to the destination (128.119.245.12) are increasing monotonically with respect to time. If there is a retransmitted segment, the sequence number of this retransmitted segment should be smaller than those of its neighboring segments.
    • 跟踪文件中没有重新传输的段。我们可以通过检查跟踪文件中TCP数据段的序列号来验证这一点。在该轨迹的时间序列图(Stevens)中,从源(192.168.1.102)到目的地(128.119.245.12)的所有序列号都随着时间单调递增。如果存在重传数据段,则该重传数据段的序列号应小于其相邻数据段的序列号。
  8. 接收器通常在 ACK 中确认多少数据? 您是否可以识别接收方每隔一个接收到的区段才发送确认的情况(参见本文第 250 页的表 3.2)。

    • The difference between the acknowledged sequence numbers of two consecutive ACKs indicates the data received by the server between these two ACKs. By inspecting the amount of acknowledged data by each ACK, there are cases where the receiver is ACKing every other segment. For example, segment of No. 80 acknowledged data with 2920 bytes = 1460*2 bytes.
    • 两个连续ACK的确认序列号之间的差异表示服务器在这两个ACK之间接收的数据。通过检查每个ACK确认的数据量,可能会出现接收方每隔一个数据段进行ACK的情况。例如,第80号确认数据的段,2920字节=1460*2字节。
  9. TCP 连接的吞吐量(每单位时间传输的⫿节数)是多少? 解释你如何计算这个值。

    • Solution: The computation of TCP throughput largely depends on the selection of averaging time period. As a common throughput computation, in this question, we select the average time period as the whole connection time. Then, the average throughput for this TCP connection is computed as the ratio between the total amount data and the total transmission time. The total amount data transmitted can be computed by the difference between the sequence number of the first TCP segment (i.e. 1 byte for No. 4 segment) and the acknowledged sequence number of the last ACK (164091 bytes for No. 202 segment). Therefore, the total data are 164091 - 1 = 164090 bytes. The whole transmission time is the difference of the time instant of the first TCP segment (i.e., 0.026477 second for No.4 segment) and the time instant of the last ACK (i.e., 5.455830 second for No. 202 segment). Therefore, the total transmission time is 5.455830 - 0.026477 = 5.4294 seconds. Hence, the throughput for the TCP connection is computed as 164090/5.4294 = 30.222 KByte/sec.
    • TCP吞吐量的计算在很大程度上取决于平均时间段的选择。作为一种常见的吞吐量计算,在本问题中,我们选择平均时间周期作为整个连接时间。然后,该TCP连接的平均吞吐量被计算为总数据量与总传输时间之间的比率。可以通过第一个TCP数据段的序列号(即,对于第4号数据段为1字节)和最后一个确认确认的序列号(对于第202号数据段,为164091字节)之间的差来计算发送的总数据量。因此,总数据为164091-1=164090字节。整个传输时间是第一个TCP报文段的时刻(即,对于4号报文段为0.026477秒)和最后一个确认的时刻(即,对于202号报文段为5.455830秒)的时间差。因此,总传输时间为5.455830-0.026477=5.4294秒。因此,tcp连接的吞吐量计算为164090/5.4294=30.222千字节/秒。
    • 统计图结果:

4.TCP congestion control in action (TCP 壅塞控制)

现在让我们检查从客户端服务器的每单位时间发送的数据量。 而不是(繁琐地!)从 Wireshark 窗口中的原始数据计算这些数值,我们将使用 Wireshark 的TCP 图形工具 – 时序图(Stevens) - 来绘制数据。

在 Wireshark 的“捕获数据包列表”窗口中选择一个 TCP 区段。然后选择菜单:Statistics-> TCP Stream Graph-> Time-Sequence-Graph(Stevens)。您应该看到一个类似于下图的图,该图是根据 http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip 中的跟踪数据包 tcp-ethereal-trace-1 中捕获的资料所创建的。(见前面的附注):

这里,每个点代表一个发送的 TCP 区段,绘制区段的序列号与发送的时间。 请注意,堆叠在一起的一组点表示发送方背靠背发送的一系列数据包。

根据在 http://gaia.cs.umass.edu/wireshark-labs/wireshark-traces.zip 中的数据跟踪包tcp-ethereal-trace-1 内容回答以下有关 TCP 区段的问题

  1. 使用时序图(Stevens)绘图工具查看从客户端发送到 gaia.cs.umass.edu 服务器的区段的序列号与时间关系图。您能否确定 TCP 的慢启动阶段的开始和结束位置,以及拥塞避免接管的位置? 评论测量数据与我们在文本中研究的 TCP 的理想化行为的不同之处。
    • 一开始是慢启动,后续应该没有拥塞的情况
  2. 根据你使用 Wireshark 所收集到的资料(将文件从计算机传输到gaia.cs.umass.edu 时的跟踪包信息),回答问题 13 中的两个问题。

有关Wireshark-Lab5:TCP的更多相关文章

  1. 计算机网络笔记:TCP三次握手和四次挥手过程 - 2

    TCP是面向连接的协议,连接的建立和释放是每一次面向连接的通信中必不可少的过程。TCP连接的管理就是使连接的建立和释放都能正常地进行。三次握手TCP连接的建立—三次握手建立TCP连接①若主机A中运行了一个客户进程,当它需要主机B的服务时,就发起TCP连接请求,并在所发送的分段中用SYN=1表示连接请求,并产生一个随机发送序号x,如果连接成功,A将以x作为其发送序号的初始值:seq=x。主机B收到A的连接请求报文,就完成了第一次握手。客户端发送SYN=1表示连接请求客户端发送一个随机发送序号x,如果连接成功,A将以x作为其发送序号的初始值:seq=x②主机B如果同意建立连接,则向主机A发送确认报

  2. ruby - yarn 未初始化常量 Socket::SOL_TCP - 2

    我在这里尝试使用yarn,遇到了一个可能与ruby​​相关的问题。在执行任何yarn命令,我收到错误.../.rvm/gems/ruby-2.3.0/gems/yarn-0.1.1/lib/yarn/server.rb:14:in':uninitializedconstantSocket::SOL_TCP(NameError)错误堆栈:$yarn.../.rvm/gems/ruby-2.3.0/gems/yarn-0.1.1/lib/yarn/server.rb:14:in':uninitializedconstantSocket::SOL_TCP(NameError)Didyoume

  3. ruby - 你如何使用 Ruby 找到空闲的 TCP 服务器端口? - 2

    我正在尝试创建一个使用一次的HTTP服务器来处理单个回调,并且需要帮助在Ruby中找到一个空闲的TCP端口。这是我正在做的事情的框架:require'socket't=STDIN.readport=8081whiles=TCPServer.new('127.0.0.1',port).acceptputss.getss.print"HTTP/1.1200/OK\rContent-type:text/plain\r\n\r\n"+ts.closeexitend(它回显标准输入到第一个连接然后死掉。)如何自动找到空闲端口进行监听?这似乎是在远程服务器上启Action业然后使用唯一作业ID回调

  4. ruby-on-rails - Rails for Zombies Lab 4 > 练习 3 - 2

    我在第三个练习中停留在第四个RailsforZombies实验室。这是我的任务:创建将创建新僵尸的操作,然后重定向到创建的僵尸的显示页面。我有以下参数数组:params={:zombie=>{:name=>"Greg",:graveyard=>"TBA"}}我写了下面的代码作为解决方案:defcreate@zombie=Zombie.create@zombie.name=params[:zombie[:name]]@zombie.graveyard=params[:zombie[:graveyard]]@zombie.saveredirect_to(create_zombie_path

  5. ruby-on-rails - 服务器是否在主机 "localhost"(::1) 上运行并在端口 5432 上接受 TCP/IP 连接? - 2

    首先请注意,我在StackOverflow和网络上的文章中发现了几个类似的问题,但没有一个能帮助我解决我的问题:PGErrorcouldnotconnecttoserver:ConnectionrefusedIstheserverrunningonport5432?PG::ConnectionBad-couldnotconnecttoserver:Connectionrefusedpsql:couldnotconnecttoserver:Connectionrefused问题来了:我有一个非常棒的Rails应用程序。我和我的合作者使用GitHub一起工作。我们有一个master和一个m

  6. 【操作系统】十分钟了解关于TCP/IP网络的基础知识(二)ARP、路由器、DHCP、DNS以及TCP/IP - 2

    承接上篇文章(十分钟了解关于TCP/IP网络的基础知识)五.ARP(地址解析协议)        虽说使用IP地址确实方便了我们使用者记忆以及整理归类、寻找信息的发送目的地,但是最终接收数据的地方,还是MAC地址,于是乎,为了实现有IP地址到MAC地址的转换,引入了名为ARP(AddressResolutionProtocol)又称之为地址解析协议。      ARP通过广播(Broadcast,这是个专业名词,后面还会继续提起)的方式对LAN中所有的计算机提问:“哎,谁IP地址是10.165.7.116(上篇文章中的例子)呀?你MAC地址多少啊,快过来登记一下!”,如果有哪台计算机回复了MA

  7. 【计算机网络】wireshark基本操作及ARP协议分析 - 2

    实验一wireshark基本操作及ARP协议分析一、实验目的1、熟悉并掌握Wireshark的基本使用;2、了解网络协议实体间进行交互以及报文交换的情况;3、分析以太网帧,MAC地址和ARP协议。二、实验环境与因特网连接的计算机,操作系统为Windows,安装有Wireshark、IE等软件。三、预备知识(1)wireshark安装下载地址:https://www.wireshark.org/#download注意操作系统版本,特别是32位操作系统和64位操作系统的区别。安装时选择默认设置即可。(2)分组嗅探器要深入理解网络协议,需要观察它们的工作过程并使用它们,即观察两个协议实体之间交换的报

  8. ruby - TCP 服务器错误 : Address already in use - bind(2) - 2

    几周前Jekyll对我来说工作正常,但现在突然出现以下错误:TCPServerError:Addressalreadyinuse-bind(2)INFOWEBrick::HTTPServer#start:pid=7300port=4000%lsof-i:4000即使端口上没有任何运行。以下是详细信息:%jekyll--versionJekyll0.11.2%wherejekyll/home/bhaarat/.rvm/gems/ruby-1.9.2-p290/bin/jekyll/usr/bin/jekyll%ruby--versionruby1.9.2p290(2011-07-09re

  9. javascript - 有没有办法用 javascript 建立到 IP 的 tcp 连接? - 2

    让我介绍一下我正在努力完成的事情的背景。我有一个具有本地IP地址的设备(芯片和pin终端),它已被编程为接收特定数据并处理它。示例:我发送十六进制格式的字符串"05""3035",终端读取它并重新启动。我试过使用SockJS-Client以及内置的WebSockets.但是使用Websockets我注意到浏览器正在发送:GET/HTTP/1.1Host:IP:PORTConnection:UpgradePragma:no-cacheCache-Control:no-cacheUpgrade:websocketOrigin:MYIPSec-WebSocket-Version:13User

  10. SpringBoot+Netty实现TCP客户端实现接收数据按照16进制解析并存储到Mysql以及Netty断线重连检测与自动重连 - 2

    场景在SpringBoot项目中需要对接三方系统,对接协议是TCP,需实现一个TCP客户端接收服务端发送的数据并按照16进制进行解析数据,然后对数据进行过滤,将指定类型的数据通过mybatis存储进mysql数据库中。并且当tcp服务端断连时,tcp客户端能定时检测并发起重连。全流程效果 注:博客:霸道流氓气质的博客_CSDN博客-C#,架构之路,SpringBoot领域博主实现1、SpringBoot+Netty实现TCP客户端本篇参考如下博客,在如下博客基础上进行修改Springboot+Netty搭建基于TCP协议的客户端(二):https://www.cnblogs.com/haolb

随机推荐