问题描述:
登陆就遇到这样的问题
*** 作系统Microsoft Windows XP Service Pack 2 [Build 512600]
网络设置局域网内使用透明代理
登录过程
---------------------------------------------------------------------------
开始第一次号码注册登录时间[2006-09-16 12:38:51]
初始化登录服务器列表，上次的登录方式为初始登录方式
尝试UDP方式登录,先创建UDP网络组件
创建UDP网络组件成功，本地IP172195269,端口4000，准备连接登录服务器
UDP登录服务器sztencent需要域名解析
UDP登录服务器sz2tencent需要域名解析
UDP登录服务器sz3tencent需要域名解析
UDP登录服务器sz4tencent需要域名解析
UDP登录服务器sz5tencent需要域名解析
UDP登录服务器sz6tencent需要域名解析
UDP登录服务器sz7tencent需要域名解析
UDP登录服务器sz8tencent需要域名解析
UDP登录服务器sz9tencent需要域名解析
UDP登录服务器sztencent域名解析成功,解析为21913349171
UDP登录服务器sz2tencent域名解析成功,解析为2191336031
UDP登录服务器sz3tencent域名解析成功,解析为2191334887
UDP登录服务器sz4tencent域名解析成功,解析为58601432
UDP登录服务器sz5tencent域名解析成功,解析为58601433
UDP登录服务器sz6tencent域名解析成功,解析为2191336037
UDP登录服务器sz7tencent域名解析成功,解析为2191334889
UDP登录服务器sz8tencent域名解析成功,解析为2191334037
UDP登录服务器sz9tencent域名解析成功,解析为2191336039
UDP服务器域名解析过程完成，开始连接服务器
尝试连接UDP服务器IP58601432,端口8000
尝试连接UDP登录服务器超时,转尝试连接下一组服务器
尝试连接UDP服务器IP2191334889,端口8000
尝试连接UDP服务器IP2191336031,端口8000
尝试连接UDP登录服务器超时,转尝试连接下一组服务器
尝试连接UDP服务器IP21913349171,端口8000
尝试连接UDP服务器IP2191336037,端口8000
尝试连接UDP服务器IP2191336039,端口8000
尝试连接UDP服务器IP2191334887,端口8000
尝试连接UDP登录服务器超时,转尝试连接下一组服务器
尝试连接UDP服务器IP58601433,端口8000
尝试连接UDP服务器IP2191334037,端口8000
尝试连接UDP登录服务器超时,转尝试连接下一组服务器
UDP登录服务器全部尝试连接失败,尝试下一种登录方式
尝试TCP方式登录,准备连接TCP服务器IPtcpconn4tencent,端口80,先进行域名解析
TCP登录服务器tcpconn4tencent域名解析成功,解析为58601445,准备连接该服务器
连接TCP登录服务器成功,服务器IPtcpconn4tencent,端口80
确定登录TCP服务器IPtcpconn4tencent,端口80
开始下载好友数据步骤1
下载好友信息步骤2
收到登录服务器下载好友信息步骤2的回应，拉信息失败，原因：服务器拒绝,提示信息：密码不正确
可是我的密码没有错，在其他的机子上可以正常登陆，而且其他同学的QQ号在我机子上登陆也是的，只有几个人的QQ可以正常登陆，其他的人的QQ出现同样的问题，。。。。。。
解析:
我也碰到过 也求助过 不管用
只好重新恢复系统UDP是一个简单的面向数据报的传输层协议:进程的每个输出 *** 作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报。这与面向流字符的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。
UDP数据报封装成一份IP数据报的格式如下图:
UTP不提供可靠性:它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。
应用程序必须注意IP数据报的长度。如果它超过网络MTU(最大传输单元)，那么就要对IP数据报进行分片。如果需要源端到目的端的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。
首部结构如下图:
端口号表示发送进程和接受进程，由于IP层已经把IP数据报分配给TCP或UDP（根据IP首部中协议字段值），因此TCP端口号由TCP来查看，而UDP端口号由UDP来查看。TCP端口号与UDP端口号是相互独立的。
UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节(发送一份0字节的UDP数据报是OK的)。这个UDP长度是有冗余的，IP数据报长度指的是数据报全长，因此UDP数据报长度等于IP数据报长度减去IP首部的长度。
UDP校验和覆盖UDP首部和UDP数据。回想IP首部的校验和，它只覆盖IP的首部----并不覆盖IP数据报的任何数据。
UDP和TCP在首部都有覆盖它们首部和数据的校验和。UDP校验和是可选的，而TCP的校验和是必需的。
尽管U D P检验和的基本计算方法与我们之前第三节中描述的IP首部检验和计算方法相类似（16bit字的二进制反码和），但是它们之间存在不同的地方。首先，UDP数据报的长度可以为奇数字节，但是检验和算法是把若干个16bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。
如果发送端没有计算检验和而接收端检测到检验和有差错，那么UDP数据报就要被悄悄地丢弃。不产生任何差错报文（当IP层检测到IP首部检验和有差错时也这样做）。
UDP检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。
物理网络层一般要限制每次发送数据帧的最大长度。任何时候IP层接收到一份要发送的IP数据报时，它要判断向本地哪个接口发送数据(选路)，并查询该接口获得其MTU。IP把MTU与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。
把一份IP数据报进行分片以后，只有到达目的地才进行重新组装(这里的重新组装与其他网络协议不同，它们要求在下一站就进行重新组装，而不是在最终目的地)。重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对传输层(TCP和UDP)是透明的。已经分片过得数据报可能会再次进行分片，IP首部中包含的数据为分片和重新组装提供了足够的信息。
对于发送端发送的每份IP数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中。标志字段其中一个比特来表示"更多的片"。除了最后一片外，其他每个组成数据报的片都要把比特置1。片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。
最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，IP将不对数据报进行分片。相反把数据报丢弃并发送一个ICMP差错报（“需要进行分片但设置了不分片比特”）给起始端。
当IP数据报被分片后，每一片都成为一个分组，具有自己的IP首部，并在选择路由时与其他分组独立。这样，当数据报的这些片到达目的端时可能会失序，但是在IP首部中有足够的信息让接收端能正确组装这些数据报片。
IP分片有一个问题:丢失掉一片数据也要重新传输整个数据报。
原因:IP层没有超时重传机制---由更高层负责超时和重传。当来自TCP报文段的某一片丢失后，TCP超时会重发整个TCP报文段，该报文段对应于一份IP数据报。没有办法重传数据报中的一个数据报片。
使用UDP很容易导致IP分片。下图是UDP分片示例:
发现ICMP不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而在IP首部又设置了不分片(DF)的标志比特。如果某个程序需要判断到达目的端的路途中最小MTU是多少----称作路径MTU发现机制，那么这个差错就可以被该程序使用。
这个情况下ICMP不可达差错报文格式如下图：
如果路由器没有提供这种新的ICMP差错报文格式，那么下一站的MTU就为0。
理论上，IP数据报的最大长度是65535字节，这是由IP首部16比特总长度字段所限制的。去除20字节的IP首部和8个字节的UDP首部，UDP数据报中用户数据的最长长度为65507字节。但是，大多数实现所提供的长度比这个最大值小。
其中有两个限制因素:
1应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。
2第二个限制来自于TCP/IP的内核实现。可能存在一些实现特性(或差错)，是IP数据报长度小于65535字节。
我们同样可以使用UDP缠上ICMP"源站抑制"差错。当一个系统(路由器或主机)接受数据报的速度比其处理速度快时，可能产生这个差错。
当在以太网传播的数据需要经过SLIP链路时，可能产生该差错报文。因为SLIP链路的速度大约只有以太网的千分之一，所以，很容易使其缓存用完。
在本例中，应用程序要么没有接收到源站抑制差错信号，要么接收到却将其忽略了。结果是如果采用UDP协议，那么BSD实现通常忽略其接收到的源站抑制报文。其部分原因在于，在接收到源站抑制差错报文时，导致源站抑制的进程可能已经中止了。
不处理ICMP源站抑制差错，说明了UDP是一个非可靠的协议，它只控制端到端的流量控制。除非在应用程序中建立一些应答机制，否则发送端并不知道接收端是否收到了这些数据。
来自客户的是UDP数据报。IP首部包含源端和目的端IP地址，UDP首部包含了源端和目的端的UDP端口号。当一个应用程序接收到UDP数据报时， *** 作系统必须告诉它是谁发送了这份消息，即源IP地址和端口号。
这个特性允许一个交互UDP服务器对多个客户进行处理。给每个发送请求的客户发回应答。
一些应用程序需要知道数据报是发给谁的，即目的地址。这要求 *** 作系统从接收到的UDP数据报中将目的IP地址交给应用程序。
大多数UDP服务器是交互服务器，单个服务器进程对单个UDP端口上的所有客户请求进行处理。
通常程序所使用的每个UDP端口都与一个有限大小的输入队列向联系。这意味着，来自不同客户的差不多同时到达的请求将有UDP自动排队。接收到UDP数据报以其接收顺序交给应用程序。
因此，由于队列溢出导致的UDP数据报的丢失不可避免。应用程序不知道其输入队列什么时候会溢出，只能有UDP对超出数据报进行丢弃处理。同时，不会发挥任何消息告诉客户其数据报被丢弃。
大多数UDP服务器在创建UDP端点时都使其本地IP地址具有通配符的特点。这表明进入的UFP数据报如果其目的地为服务端端口，那么任何本地接口均可接收到它。
大多数系统允许UDP端点对远端地址进行限制。
下面是UDP服务器本身可以创建的三类地址绑定:
在所有情况下，lport指的是服务器有名端口号，localIP必须是本地接口的IP地址。表中这三行的排序是UDP模块在判断用哪个端点接收数据报时所采用的顺序。最为确定的地址（第一行）首先被匹配，最不确定的地址（最后一行IP地址带有两个星号）最后进行匹配。
当UDP数据报到达的目的IP地址为广播地址或多播地址，而且在目的IP地址和端口号处有多个端点时，就向每个端点传送一份数据报的复制（端点的本地IP地址可以含有星号，它可匹配任何目的IP地址）。但是，如果UDP数据报到达的是一个单播地址，那么只向其中一个端点传送一份数据报的复制。选择哪个端点传送数据取决于各个不同的系统实现。
UDP是一个简单协议。它想用户进程提供的服务位于IP层之上，包括端口号和可选的校验和，我们用UDP老检查校验和并观察分片是如何进行的。
当系统接收IP数据报的速率超过这些数据报被处理的速率时，系统可能发送ICMP源站抑制差错报文。使用UDP时很容易产生这样的ICMP差错。
CoAP的URL
在>随着越来越多的人通过PC、手机等设备相互连接，现代互联网蓬勃发展使得人们的生活发生了翻天覆地的变化。很多人预测将会有更多其他的设备相互连接，这些设备的数量将远远超过人类的数量，到时候形成的网络将是现有网络的N个量级，这个网络带给世界的变化将是无法估量的。
不像人接入互联网的简单方便，由于物联网设备大多都是资源限制型的，有限的CPU、RAM、Flash、网络宽带等。对于这类设备来说，想要直接使用现有网络的TCP和>1、\x0d\IP数据包包含 tcp数据包 udp数据包，IP是第三层（网络层）的协议，TCP与UDP都属于第四层（传输层）的协议。\x0d\\x0d\TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。\x0d\UDP---用户数据报协议，是一个简单的面向数据报的运输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快\x0d\2、关键点区分：\x0d\ A。基于连接与无连接 \x0d\ B。对系统资源的要求（TCP较多，UDP少） \x0d\ C。UDP程序结构较简单 \x0d\ D。流模式与数据报模式 \x0d\ E。TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证\x0d\3、\x0d\TCP发送的包有序号，对方收到包后要给一个反馈，如果超过一定时间还没收到反馈就自动执行超时重发，因此TCP最大的优点是可靠。一般网页（>
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）