怎么知道UDP用户数据报是从客户发给服务器的?和服务器程序是TFTP?
呵呵,UDP首部格式如下: (具体看TCP/IP详解第11章) 2字节源端口;2字节目的端口;2字节UDP长度(数据部分长度+首部长度);2字节校验和00 1C 代表UDP长度为十进制的28 所以数据部分的长度为:28-8=20,这里的8代表UDP首部长度
想问问客户进程是什么?

TCP和UPD详解
UDP 首部格式首部字段只有 8 个字节,包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。TCP 首部格式序号:用于对字节流进行编号,例如序号为 301,表示第一个字节的编号为 301,如果携带的数据长度为 100 字节,那么下一个报文段的序号应为 401。确认号:期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段,序号为 501,携带的数据长度为 200 字节,因此 B 期望下一个报文段的序号为 701,B 发送给 A 的确认报文段中确认号就为 701。数据偏移 :指的是数据部分距离报文段起始处的偏移量,实际上指的是首部的长度。确认 ACK:当 ACK=1 时确认号字段有效,否则无效。TCP 规定, 在连接建立后所有传送的报文段都必须把 ACK 置 1。同步 SYN:在连接建立时用来同步序号。 当 SYN=1,ACK=0 时表示这是一个连接请求报文段 。若对方同意建立连接,则响应报文中 SYN=1,ACK=1。终止 FIN:用来释放一个连接,当 FIN=1 时,表示此报文段的发送方的数据已发送完毕,并要求释放连接。窗口:窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制,是因为接收方的数据缓存空间是有限的。假设 A 为客户端,B 为服务器端。三次握手的原因第三次握手是为了防止失效的连接请求到达服务器,让服务器错误打开连接。客户端发送的连接请求如果在网络中滞留,那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后,就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器,==如果不进行三次握手,那么服务器就会打开两个连接==。如果有第三次握手,客户端会忽略服务器之后发送的对滞留连接请求的连接确认,不进行第三次握手,因此就不会再次打开连接。以下描述不讨论序号和确认号,因为序号和确认号的规则比较简单。并且不讨论 ACK,因为 ACK 在连接建立之后都为 1。四次挥手的原因客户端发送了 FIN连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。也就是说为了==防止数据丢失==。TIME_WAIT作用客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:TCP 使用超时重传来实现可靠传输:如果一个已经发送的报文段在超时时间内没有收到确认,那么就重传这个报文段。一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT,加权平均往返时间 RTTs 计算如下:其中,0 ≤ a < 1,RTTs 随着 a 的增加更容易受到 RTT 的影响。超时时间 RTO 应该略大于 RTTs,TCP 使用的超时时间计算如下:其中 RTTd 为偏差的加权平均值。窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。发送窗口内的字节都允许被发送,接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认,那么就将发送窗口向右滑动一定距离,直到左部第一个字节不是已发送并且已确认的状态;接收窗口的滑动类似,接收窗口左部字节已经发送确认并交付主机,就向右滑动接收窗口。接收窗口只会对窗口内最后一个==按序到达==的字节进行确认,例如接收窗口已经收到的字节为 {31, 34, 35},其中 {31} 按序到达,而 {34, 35} 就不是,因此只对字节 31 进行确认。发送方得到一个字节的确认之后,就知道这个字节之前的所有字节都已经被接收。流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。也就是说是通过滑动窗口实现的。如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。TCP 主要通过四个算法来进行拥塞控制:慢开始、拥塞避免、快重传、快恢复。发送方需要维护一个叫做拥塞窗口(cwnd)的状态变量,注意拥塞窗口与发送方窗口的区别:拥塞窗口只是一个状态变量,实际决定发送方能发送多少数据的是发送方窗口。为了便于讨论,做如下假设:接收方有足够大的接收缓存,因此不会发生流量控制;虽然 TCP 的窗口基于字节,但是这里设窗口的大小单位为报文段。发送的最初执行慢开始,令 cwnd = 1,发送方只能发送 1 个报文段;当收到确认后,将 cwnd 加倍,因此之后发送方能够发送的报文段数量为:2、4、8 ...注意到慢开始每个轮次都将 cwnd 加倍,这样会让 cwnd 增长速度非常快,从而使得发送方发送的速度增长速度过快,网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh,当 cwnd >= ssthresh 时,进入拥塞避免,每个轮次只将 cwnd 加 1。如果出现了超时,则令 ssthresh = cwnd / 2,然后重新执行慢开始。在接收方,要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2,此时收到 M4,应当发送对 M2 的确认。在发送方,如果收到三个重复确认,那么可以知道下一个报文段丢失,此时执行快重传,立即重传下一个报文段。例如收到三个 M2,则 M3 丢失,立即重传 M3。在这种情况下,只是丢失个别报文段,而不是网络拥塞。因此执行快恢复,令 ssthresh = cwnd / 2 ,cwnd = ssthresh,注意到此时直接进入拥塞避免。慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。参考链接:https://github.com/CyC2018/CS-Notes/blob/master/notes/ 计算机网络%20-%20传输层.md

一UDP用户数据报的首部的十六进制表示是:06 32 00 45 00 1C E2 17试求源端口
源端口占2个字节,即06 32 ,化为十进制是1586。过程:(06 32)16=(00000110 00110010)₂=2+16+32+512+1024=(1586)10或者直接用16进制转为十进制:(06 32)16=0x16³+6x16²+3x16¹+2x16º=1536+48+2=1586扩展资料:UDP报头由4个域组成,其中每个域各占用2个字节,具体如下:1、源端口号。2、目标端口号。3、数据报长度。4、校验值。UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将UDP数据包通过源端口发送出去,而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号,所以端口号的有效范围是从0到65535。一般来说,大于49151的端口号都代表动态端口。扩展资料来源:百度百科—UDP
参照图片 0632是源端口 0045是目的端口 001c是数据长度 因为采用的是6进制所以计算值如下 0632为06=6, 32=3*16+2=50,所以0632=650,同理求得0045=69,,001c=28(16进制中A=10,B=11......F=15) 所以源端口为650,目的端口69,数据包长度28字节
06 32是源口 十六进制转十进制6*16^2+3*16^1+2*16^0=1586. 00 45是目的端口 转十进制4*16^1+5*16^0=6900 1c是用户数据包的总长度=16+12=28数据部分长度为:28-首部长度=28-8=20 由于目的端口69<1023是熟知端口(服务器端使用的端口号),因此该UDP数据报是从客户发给服务器的,程序是TFFTP
UDP首部由源端口,目的端口,数据报长度,检验四部分组成,每部分占2字节 所以源端口为06 32化十进制为1586;目的端口为00 45化十进制为69;数据报总长度为00 1C化十进制为28 数据部分长度=总长度-首部长度=28-8=20
答案中的源端口号求解错误。正确的端口号是6乘以16乘以16+3乘以16+2=1586

计算机网络,UDP数据报的校验和字段是通过什么来校验源和目的IP的呢??
其实这是一种加密技术用于对文件内容进行审计的方法,使用 精通读文件把文件读到内存中,再对文件内容作一个 MD5 校验得到一串密码,就是校验和。 补充:1、IP首部校验和字段是根据IP首部计算的校验和码,它不对首部后面的数据进行计算。ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时覆盖首部和数据校验和码。2、IP首部校验和计算:为了计算一份数据报的IP检验和,首先把检验和字段置为0。然后,对首部中每个16bit进行二进制反码求和(整个首部看成是由一串16bit的字组成),结果存在检验和字段中。当收到一份IP数据报后,同样对首部中每个16bit进行二进制反码的求和。由于接收方在计算过程中包含了发送方存在首部中的检验和,因此,如果首部在传输过程中没有发生任何差错,那么接收方计算的结果应该为全1。如果结果不是全1(即检验和错误),那么IP就丢弃收到的数据报。但是不生成差错报文,由上层去发现丢失的数据报并进行重传。3、TCP和UDP校验和计算(两者相同)校验和还包含—个96位的伪首标,理论上它位于TCP首标的前面。这个伪首标包含了源地址、目的地址、协议和TCP长度等字段,这使得TCP能够防止出现路由选择错误的数据段。这些信息由网际协议(IP)承载,通过TCP/网络接口,在IP上运行的TCP调用参数或者结果中传递。伪首部并非UDP数据报中实际的有效成分。伪首部是一个虚拟的数据结构,其中的信息是从数据报所在IP分组头的分组头中提取的,既不向下传送也不向上递交,而仅仅是为计算校验和。 这样的校验和,既校验了UDP用户数据的源端口号和目的端口号以及UDP用户数据报的数据部分,又检验了IP数据报的源IP地址和目的地址。(伪报头保证UDP和TCP数据单元到达正确的目的地址。因此,伪报头中包含IP地址并且作为计算校验和需要考虑的一部分。最终目的端根据伪报头和数据单元计算校验和以验证通信数据在传输过程中没有改变而且到达了正确的目的地址。
UDP报头由4个域组成,其中每个域各占用2个字节,目标端口号,数据报长度,校验值
通过12位的伪首部,《计算机网络 第5版》谢希仁 的P186、187有说明的。

如何判断udp端口可达
TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前,必须先在双方之间建立一个TCP连接,之后才能传输数据。TCP提供超时重发,丢弃重复数据,检验数据,流量控制等功能,保证数据能从一端传到另一端。 TCP是面向连接的,有比较高的可靠性。
UDP---用户数据报协议,是一个简单的面向数据报的运输层协议。UDP不提供可靠性,它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接,且没有超时重发等机制,故而传输速度很快。
TCP是当应用程序要得到完整且可信赖的数据时所采用的传输控制协议,由于必须绝对完整无误,因此TCP会在传输的过程中多了许多确认的动作以确定数据的正确性;而UDP比起TCP是要简单许多,UDP传输数据通常会遗失却不见得再重新传输一次,因此使用UDP的应用程序着重于简洁和效率以完成工作,它不需要像TCP一般复杂的手续就可以达到交换信息的目的。

本文由 在线网速测试 整理编辑,转载请注明出处。