哪些常见的网络情况会造成tcp同步包与tcp同步确认包异常
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了哪些常见的网络情况会造成tcp同步包与tcp同步确认包异常相关的知识，希望对你有一定的参考价值。
参考技术A 传输控制协议（TransmissionControlProtocol,TCP）TCP协议主为了在主机间实现高可靠性的包交换传输协议。本文将描述协议标准和实现的一些方法。因为计算机网络在现代社会中已经是不可缺少的了，TCP协议主要在网络不可靠的时候完成通信，对军方可能特别有用，但是对于政府和商用部门也适用。TCP是面向连接的端到端的可靠协议。它支持多种网络应用程序。TCP对下层服务没有多少要求，它假定下层只能提供不可靠的数据报服务，它可以在多种硬件构成的网络上运行。下面的图是TCP在层次式结构中的位置，它的下层是IP协议，TCP可以根据IP协议提供的服务传送大小不定的数据，IP协议负责对数据进行分段，重组，在多种网络中传送。TCP的上面就是应用程序，下面是IP协议，上层接口包括一系列类似于操作系统中断的调用。对于上层应用程序来说，TCP应该能够异步传送数据。下层接口我们假定为IP协议接口。为了在并不可靠的网络上实现面向连接的可靠的传送数据，TCP必须解决可靠性，流量控制的问题，必须能够为上层应用程序提供多个接口，同时为多个应用程序提供数据，同时TCP必须解决连接问题，这样TCP才能称得上是面向连接的，最后，TCP也必须能够解决通信安全性的问题。网络环境包括由网关（或其它设备）连接的网络，网络可以是局域网也可以是一些城域网或广域网，但无论它们是什么，它们必须是基于包交换的。主机上不同的协议有不同的端口号，一对进程通过这个端口号进行通信。这个通信不包括计算机内的I/O操作，只包括在网络上进行的操作。网络上的计算机被看作包传送的源和目的结点。特别应该注意的是：计算机中的不同进程可能同时进行通信，这时它们会用端口号进行区别，不会把发向A进程的数据由B进程接收的。进程为了传送数据会调用TCP，将数据和相应的参数传送给TCP，于是TCP会将数据传送到目的TCP那里，当然这是通过将TCP包打包在IP包内在网络上传送达到的。接收方TCP在接收到数据后会通信上层应用程序，TCP会保证接收数据顺序的正确性。虽然下层协议可能不会保证顺序是正确的。这里需要说明的是网关在接收到这个包后，会将包解开，看看是不是已经到目的地了，如果没有到，应该走什么路由达到目的地，在决定后，网关会根据下一个网络内的协议情况再次将TCP包打包传送，如果需要，还要把这个包再次分成几段再传送。这个落地检查的过程是一个耗时的过程。从上面，我们可以看出TCP传送的基本过程，当然具体过程可能要复杂得多。在实现TCP的主机上，TCP可以被看成是一个模块，和文件系统区别不大，TCP也可以调用一些操作系统的功能，TCP不直接和网络打交道，控制网络的任务由专门的设备驱动模块完成。TCP只是调用IP接口，IP向TCP提供所有TCP需要的服务。通过下图我们可以更清楚地看到TCP协议的结构。上面已经说过了，TCP连接是可靠的，而且保证了传送数据包的顺序，保证顺序是用一个序号来保证的。响应包内也包括一个序列号，表示接收方准备好这个序号的包。在TCP传送一个数据包时，它同时把这个数据包放入重发队列中，同时启动记数器，如果收到了关于这个包的确认信息，将此包从队列中删除，如果计时超时则需要重新发送此包。请注意，从TCP返回的确认信息并不保证最终接收者接收到数据，这个责任由接收方负责。每个用于传送TCP的通道都有一个端口标记，因为这个标记是由每个TCP终端确定的，因此TCP可能不唯一，为了保证这个数值的唯一，要使用网络地址和端口号的组合达到唯一标识的目的，我们称这个为了套接字（Socket），一个连接由连接两端的套接字标识，本地的套接字可能和不同的外部套接字通信，这种通信是全双工的。通过向本地端口发送OPEN命令及外部套接字参数建立连接，TCP返回一个标记这个连接的名称，以后如果用户需要使用这个名称标记这个连接。为了保存这个连接的信息，我们假设有一个称为传输控制块（TransmissionControlBlock，TCB）的东西来保存。OPEN命令还指定这个连接的建立是主动请求还是被动等待请求。下面我们要涉及具体的功能了，TCP段以internet数据报的形式传送。IP包头传送不同的信息域，包括源地址和目的地址。TCP头跟在internet包头后面，提供了一些专用于TCP协议的信息。下图是TCP包头格式图：源端口：16位；目的端口：16位序列码：32位，当SYN出现，序列码实际上是初始序列码（ISN），而第一个数据字节是ISN+1；确认码：32位，如果设置了ACK控制位，这个值表示一个准备接收的包的序列码；数据偏移量：4位，指示何处数据开始；保留：6位，这些位必须是0；控制位：6位；窗口：16位；校验位：16位；优先指针：16位，指向后面是优先数据的字节；选项：长度不定；但长度必须以字节记；选项的具体内容我们结合具体命令来看；填充：不定长，填充的内容必须为0，它是为了保证包头的结合和数据的开始处偏移量能够被32整除；我们前面已经说过有一个TCB的东西了，TCB里有存储了包括发送方，接收方的套接字，用户的发送和接收的缓冲区指针等变量。除了这些还有一些变量和发送接收序列号有关：发送序列变量SND.UNA-发送未确认SND.NXT-发送下一个SND.WND-发送窗口SND.UP-发送优先指针SND.WL1-用于最后窗口更新的段序列号SND.WL2-用于最后窗口更新的段确认号ISS-初始发送序列号接收序列号RCV.NXT-接收下一个RCV.WND-接收下一个RCV.UP-接收优先指针IRS-初始接收序列号下图会帮助您了解发送序列变量间的关系：当前段变量SEG.SEQ-段序列号SEG.ACK-段确认标记SEG.LEN-段长SEG.WND-段窗口SEG.UP-段紧急指针SEG.PRC-段优先级连接进程是通过一系列状态表示的，这些状态有：LISTEN，SYN-SENT，SYN-RECEIVED，ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT和CLOSED。CLOSED表示没有连接，各个状态的意义如下：LISTEN-侦听来自远方TCP端口的连接请求；SYN-SENT-在发送连接请求后等待匹配的连接请求；SYN-RECEIVED-在收到和发送一个连接请求后等待对连接请求的确认；ESTABLISHED-代表一个打开的连接，数据可以传送给用户；FIN-WAIT-1-等待远程TCP的连接中断请求，或先前的连接中断请求的确认；FIN-WAIT-2-从远程TCP等待连接中断请求；CLOSE-WAIT-等待从本地用户发来的连接中断请求；CLOSING-等待远程TCP对连接中断的确认；LAST-ACK-等待原来发向远程TCP的连接中断请求的确认；TIME-WAIT-等待足够的时间以确保远程TCP接收到连接中断请求的确认；CLOSED-没有任何连接状态；TCP连接过程是状态的转换，促使发生状态转换的是用户调用：OPEN，SEND，RECEIVE，CLOSE，ABORT和STATUS；传送过来的数据段，特别那些包括以下标记的数据段SYN，ACK，RST和FIN；还有超时，上面所说的都会时TCP状态发生变化。下面的图表示了TCP状态的转换，但这图中没有包括错误的情况和错误处理，不要把这幅图看成是总说明了。3.3.序列号请注意，我们在TCP连接中发送的字节都有一个序列号。因为编了号，所以可以确认它们的收到。对序列号的确认是累积性的，也就是说，如果用户收到对X的确认信息，这表示在X以前的数据（不包括X）都收到了。在每个段中字节是这样安排的：第一个字节在包头后面，按这个顺序排列。我们需要认记实际的序列空间是有限的，虽然很大，但是还是有限的，它的范围是0到2的32次方减1。我想熟悉编程的一定知道为什么要在计算两个段是不是相继的时候要使用2的32次方为模了。TCP必须进行的序列号比较操作种类包括以下几种：(a)决定一些发送了的但未确认的序列号；(b)决定所有的序列号都已经收到了；(c)决定下一个段中应该包括的序列号。对于发送的数据TCP要接收确认，处理确认时必须进行下面的比较操作：SND.UNA=最老的确认了的序列号；SND.NXT=下一个要发送的序列号；SEG.ACK=接收TCP的确认，接收TCP期待的下一个序列号；SEG.SEQ=一个数据段的第一个序列号；SEG.LEN=数据段中包括的字节数；SEG.SEQ+SEG.LEN-1=数据段的最后一个序列号。请注意下面的关系：SND.UNA0RCV.NXT=00不可接受>0>0RCV.NXT=BSYN本方序列号是X2)ABACK确认对方序列号上面的第2步和第3步可以合并，这时可以成为3阶段，所以我们可以称它为三消息握手。这个过程是必须的，因为序列号不和全局时钟关联，TCP也可以有不同的机制选择ISN。接收到第一个SYN的接收方不可能知道这个数据段是不是被延时，除非它记住了在连接上使用的最近的序列号（这通常是不可能的），因此它必须要求发送者确认。为了保证TCP获得的确认是刚才发送的段产生的，而不是仍然在网络中的老数据段产生的，因此TCP必须在MSL时间之内保持沉默。在本文中，我们假设MSL=2小时，这是出于工程的需要，如果用户觉得可以，他可以改变MSL。请注意如果TCP重新初始化，而内存中的序列号正在使用，不需要等待，但必须确认使用的序列号比当前使用的要大。如果一台主机在未保留任何序列号的情况下失败，那么它应该在MSL时间之内不发出任何数据段。下面将会这一情况进行说明。TCP的实现可以不遵守这个规定，但是这会造成老数据被当成新数据接收，而新数据被当成老数据拒绝的情况。每当数据段形成并进入输出队列，TCP会为它指定序列空间中的一个值。TCP中多复本检测和序列算法都依赖于这个地址空间，在对方发送或接收之前不会超过2的32次方个包存在于输出队列中。所有多余的数据段都会被删除。如果没有这个规定，会出现多个数据段被指定同一个序列号的情况，会造成混乱。数据段中序列号的多少和数据段中的字节数一样多。在通常情况下，TCP保留下一个要发送的序列号和还未确认的最老的序列号，不要在没有确认的时候就再次使用，这样会有些风险，也正是因为这样的目的，所以序列空间很大。对于2M的网络，要4.5小时来耗尽序列空间，因为一个数据段可能的最大生存时间也不过十几分之一秒，这就留下了足够的空间；而在100M的网络上需要5.4分钟，虽然少了点，但也可以了。如果在实现TCP时没有为保存序列号留下空间，那清除多余的包可能就不能实现了，因此推荐这种类型的TCP实现最好在失败后等待MSL时间，这样保证多余的包被删除。这种情况有时候也可能会出现在保留序列号的TCP实现中。如果TCP在选择一个另一个TCP连接正在使用的序列号时，这台主机突然失败了，这就产生了问题。这个问题的实质在于主机不知道它失败了多久，也不知道多余的复本是不是还在网络中。处理这种问题的方法是等待MSL时间，如果不这样就要冒着对方错误接收数据的危险，要等待的时间也就称为“沉默时间”。实现者可以让用户选择是不是等待，但是无论用户如何也不见得非要等待MSL时间。3.4.建立一个连接建立连接应用的是三消息握手。如果双方同时都发送SYN也没有关系，双方会发现这个SYN中没有确认，于是就知道了这种情况，通常来说，应该发送一个"reset"段来解决这种情况。三消息握手减少了连接失败的可能性。下面就是一个例子，在尖括号是的就是数据段中的内容和标记。其它的就不多说了。在第2行，TCPA发送SYN初始化序列号，表示它要使用序列号100；第3行中，TCPB给出确认，并且期待着A的带有序列号101的数据段；第4行，TCPA给出确认，而在第5行，它也给出确认，并发送了一些数据，注意第4行的序列号与第5号的一样，因为ACK信息不占用序列号空间内的序列号。同时产生请求的情况如下图所示，只复杂一点。使用三消息握手的主要原因是为了防止使用过期的数据段。为了这个目的，必须引入新的控制消息，RESET。如果接收TCP处理非同步状态，在接收到RESET后返回到LISTEN状态。如果TCP处理下面几种状态ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT时，放弃连接并通过用户。我们下面就详细说明后一种情况。通过上面的例子，我们可以看出TCP连接是如何从过期数据段的干扰下恢复的。请注意第4行和第5行中的RST（RESET信号）。半开连接和其它非正常状态如果一方在未通过另一方的情况下关闭连接，或双方虽然失败而不同步的情况我们称为半开连接状态。在一方试图发送数据时连接会自动RESET。然而这种情况毕竟属于不正常情况。应该做出相应的处理。如果A处的连接已经关闭，B处并不知道。当B希望发送数据到A时，就会收到RESET信号，表示这个TCP连接有误，要中止当前连接。假设A和B两个进程相互通信的时候A的TCP发生了失败，A依靠操作系统支持TCP的存在，通常这种情况下会有恢复机制起作用，当TCP重新恢复的时候，A可能希望从恢复点开始工作。这样A可能会试图OPEN连接，然后在这个它认为还是打开的连接上传送数据，这时A会从本地（也就是A的）TCP上获得错误消息“未打开连接”。A的TCP将发送包括SYN的数据段。下面的例子将显示这一过程：上面这个例子中，A方收到的信息并没有确认任何东西，这时候A发现出了问题，于是发送了RST控制信息。另一种情况是发生在A失败，而B方仍然试图发送数据时，下面的例子可以表示这种情况，请注意第2行中A对B发送来的信息不知所云。在下面的例子中，A方和B方进行的被动连接，它们都在等待SYN信息。过期的包传送到B方使B回应了，而收到回应的A却发现不对头，传送RST控制信息，B方返回被动LISTEN状态。现实中的情况太多了，我们列举一些产生RST控制信息的规则如下：通常情况下，RST在收到的信息不是期待的信息时产生。如果在不能确定时不要轻易发送RST控制信息。下面有三类情况：如果连接已经不存在，而发送来的消息又不是RST，那么要返回RST。如果想拒绝对不存在的连接进行SYN，可以使用这种法。如果到达的信息有一个ACK域，返回的RST信息可以从ACK域中取得序列号，如果没有这个域，就把RST的序列号设置为0，ACK域被设备为序列号和到达段长度之和。连接仍然处于CLOSE状态。如果连接处于非同步状态（LISTEN，SYN-SENT，SYN-RECEIVED），而且收到的确认是对未发出包的确认或是接收到数据段的安全级别与不能连接要求的相一一致时，就发送RST。如果SYN未被确认时，而且收到的数据段的优先级比要求的优先级要高，那么要么提高本地优先级（得事先征得用户和系统的许可）要么发送RST；如果接收数据段的优先级比要求的优先级低，就算是匹配了，当然如果对方发现优先级不对提高了优先级，在下一个包中提高了优先级，这就不算是匹配了。如果连接已经进入SYN，那么接收到数据段的优先级必须和本地优先级一样，否则发送RST。如果到达的信息有一个ACK域，返回的RST信息可以从ACK域中取得序列号，如果没有这个域，就把RST的序列号设置为0，ACK域被设备为序列号和到达段长度之和。连接仍然处于与原来相同的状态。如果连接处于同步状态（ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT），任何超出接收窗口的序列号的数据段都产生如下结果：发出一个空确认数据段，此段中包括当前发送序列号，另外还包括一个确认指出希望接收的下一个数据段的序列号，连接仍然保存在原来的状态。如果因为安全级，优先级之类的问题，那就发送RST信号然后进入CLOSED状态。[网络知识]TCP协议中的粘包与拆包
在平时客户端socket开发中，如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况，这就是TCP协议中经常会遇到的粘包以及拆包的问题。
我们都知道TCP属于传输层的协议，传输层除了有TCP协议外还有UDP协议。那么UDP是否会发生粘包或拆包的现象呢？答案是不会。UDP是基于报文发送的，从UDP的帧结构可以看出，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；另外从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。
TCP为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。
粘包/拆包表现形式
现在假设客户端向服务端连续发送了两个数据包，用packet1和packet2来表示，那么服务端收到的数据可以分为三种，现列举如下：
第一种情况，接收端正常收到两个数据包，即没有发生拆包和粘包的现象，此种情况不在本文的讨论范围内。
第二种情况，接收端只收到一个数据包，由于TCP是不会出现丢包的，所以这一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。这种情况由于接收端不知道这两个数据包的界限，所以对于接收端来说很难处理。
第三种情况，这种情况有两种表现形式，如下图。接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。
粘包/拆包发生原因
发生TCP粘包或拆包有很多原因，现列出常见的几点，可能不全面，欢迎补充
- 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
- 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
- 要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
- 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。
发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据了很小，会当做一个包发出去，产生粘包）
########################
#服务端
from socket import *
phone = socket(AF_INET,SOCK_STREAM)
phone.setsockopt(SOL_SOCKET,SOCK_STREAM,1)
phone.bind(('127.0.0.1',8080))
phone.listen(5)
print('start running...')
coon,addr = phone.accept() #等待连接
data1 = coon.recv(10)
data2 = coon.recv(10)
print('------------>',data1.decode('utf-8'))
print('------------>',data2.decode('utf-8'))
coon.close()
phone.close()
###############################
#客户端
from socket import *
import time
phone = socket(AF_INET,SOCK_STREAM)
phone.connect(('127.0.0.1',8080))
phone.send('hello'.encode('utf-8'))
phone.send('helloworld'.encode('utf-8'))
phone.close()接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包）
########################
#服务端
from socket import *
phone = socket(AF_INET,SOCK_STREAM)
phone.setsockopt(SOL_SOCKET,SOCK_STREAM,1)
phone.bind(('127.0.0.1',8080))
phone.listen(5)
print('start running...')
coon,addr = phone.accept() #等待连接
data1 = coon.recv(2) #一次没有接收完整
data2 = coon.recv(10) #下一次接收的时候会先取旧的数据,然后取新的
# data3 = coon.recv(1024) #接收等5秒后的信息
print('------------>',data1.decode('utf-8'))
print('------------>',data2.decode('utf-8'))
# print('------------>',data3.decode('utf-8'))
coon.close()
phone.close()
###############################
#客户端
from socket import *
import time
phone = socket(AF_INET,SOCK_STREAM)
phone.connect(('127.0.0.1',8080))
phone.send('hello'.encode('utf-8'))
time.sleep(5)
phone.send('haiyan'.encode('utf-8'))
phone.close()
粘包/拆包解决办法
通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：
- 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
- 发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
- 可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。
问题的根源在于，接收端不知道发送端将要传送的字节流的长度，所以解决粘包的方法就是围绕，如何让发送端在发送数据前，把自己将要发送的字节流总大小让接收端知晓，然后接收端来一个死循环接收完所有数据
########################
#服务端
import socket
import subprocess
import struct
phone = socket.socket(socket.AF_INET,socket.SOCK_STREAM) #买手机
phone.bind(('127.0.0.1',8080)) #绑定手机卡
phone.listen(5) #阻塞的最大数
print('start runing.....')
while True: #链接循环
coon,addr = phone.accept()# 等待接电话
print(coon,addr)
while True: #通信循环
# 收发消息
cmd = coon.recv(1024) #接收的最大数
print('接收的是：%s'%cmd.decode('utf-8'))
#处理过程
res = subprocess.Popen(cmd.decode('utf-8'),shell = True,
stdout=subprocess.PIPE, #标准输出
stderr=subprocess.PIPE #标准错误
)
stdout = res.stdout.read()
stderr = res.stderr.read()
#先发报头(转成固定长度的bytes类型，那么怎么转呢？就用到了struct模块)
#len(stdout) + len(stderr)#统计数据的长度
header = struct.pack('i',len(stdout)+len(stderr))#制作报头
coon.send(header)
#再发命令的结果
coon.send(stdout)
coon.send(stderr)
coon.close()
phone.close()
###############################
#客户端
import socket
import struct
phone = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
phone.connect(('127.0.0.1',8080)) #连接服
while True:
# 发收消息
cmd = input('请你输入命令>>：').strip()
if not cmd:continue
phone.send(cmd.encode('utf-8')) #发送
#先收报头
header_struct = phone.recv(4) #收四个
unpack_res = struct.unpack('i',header_struct)
total_size = unpack_res[0] #总长度
#后收数据
recv_size = 0
total_data=b''
while recv_size<total_size: #循环的收
recv_data = phone.recv(1024) #1024只是一个最大的限制
recv_size+=len(recv_data) #
total_data+=recv_data #
print('返回的消息：%s'%total_data.decode('gbk'))
phone.close()解决粘包问题升级版
########################
#服务端
import socket
import subprocess
import struct
import json
phone = socket.socket(socket.AF_INET,socket.SOCK_STREAM) #买手机
phone.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)
phone.bind(('127.0.0.1',8080)) #绑定手机卡
phone.listen(5) #阻塞的最大数
print('start runing.....')
while True: #链接循环
coon,addr = phone.accept()# 等待接电话
print(coon,addr)
while True: #通信循环
# 收发消息
cmd = coon.recv(1024) #接收的最大数
print('接收的是：%s'%cmd.decode('utf-8'))
#处理过程
res = subprocess.Popen(cmd.decode('utf-8'),shell = True,
stdout=subprocess.PIPE, #标准输出
stderr=subprocess.PIPE #标准错误
)
stdout = res.stdout.read()
stderr = res.stderr.read()
# 制作报头
header_dic =
'total_size': len(stdout)+len(stderr), # 总共的大小
'filename': None,
'md5': None
header_json = json.dumps(header_dic) #字符串类型
header_bytes = header_json.encode('utf-8') #转成bytes类型(但是长度是可变的)
#先发报头的长度
coon.send(struct.pack('i',len(header_bytes))) #发送固定长度的报头
#再发报头
coon.send(header_bytes)
#最后发命令的结果
coon.send(stdout)
coon.send(stderr)
coon.close()
phone.close()
###############################
#客户端
import socket
import struct
import json
phone = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
phone.connect(('127.0.0.1',8080)) #连接服务器
while True:
# 发收消息
cmd = input('请你输入命令>>：').strip()
if not cmd:continue
phone.send(cmd.encode('utf-8')) #发送
#先收报头的长度
header_len = struct.unpack('i',phone.recv(4))[0] #吧bytes类型的反解
#在收报头
header_bytes = phone.recv(header_len) #收过来的也是bytes类型
header_json = header_bytes.decode('utf-8') #拿到json格式的字典
header_dic = json.loads(header_json) #反序列化拿到字典了
total_size = header_dic['total_size'] #就拿到数据的总长度了
#最后收数据
recv_size = 0
total_data=b''
while recv_size<total_size: #循环的收
recv_data = phone.recv(1024) #1024只是一个最大的限制
recv_size+=len(recv_data) #有可能接收的不是1024个字节，或许比1024多呢，
# 那么接收的时候就接收不全，所以还要加上接收的那个长度
total_data+=recv_data #最终的结果
print('返回的消息：%s'%total_data.decode('gbk'))
phone.close()struct模块
#该模块可以把一个类型，如数字，转成固定长度的bytes类型
import struct
res = struct.pack('i',12345)
print(res,len(res),type(res)) #长度是4
res2 = struct.pack('i',12345111)
print(res,len(res),type(res2)) #长度也是4
unpack_res =struct.unpack('i',res2)
print(unpack_res) #(12345111,)
print(unpack_res[0]) #12345111
以上是关于哪些常见的网络情况会造成tcp同步包与tcp同步确认包异常的主要内容，如果未能解决你的问题，请参考以下文章