为什么我的QQ不能运行了？

原因有以下几点：
网络故障。
防火墙阻挡。关闭防火墙或设置允许QQ软件通行。真的不行把QQ重装了
DCOM服务被禁用或存在问题。启用DCOM服务
关于115713的另一个问题不在QQ软件本身的问题，建议你用反P2P软件杀掉终结者，或者重启动计算机就可以解决了，要是这样不行也不排除QQ软件在系统中的本身问题。
QQ是腾讯QQ的简称，是腾讯公司开发的一款基于Internet的即时通信（IM）软件。目前QQ已经覆盖MicrosoftWindows、OSX、Android、iOS、WindowsPhone等多种主流平台。其标志是一只戴着红色围巾的小企鹅。
腾讯QQ支持在线聊天、视频通话、点对点断点续传文件、共享文件、网络硬盘、自定义面板、QQ邮箱等多种功能，并可与多种通讯终端相连。
2017年1月5日，腾讯QQ和美的集团在深圳正式签署战略合作协议，双方将共同构建基于IP授权与物联云技术的深度合作，实现家电产品的连接、对话和远程控制。双方合作的第一步，是共同推出基于QQfamilyIP授权和腾讯物联云技术的多款智能家电产品。

Transmission Control Protocol，传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议

TCP协议的目的是： 在不可靠传输的IP层之上建立一套可靠传输的机制。 TCP的可靠只是对于它自身来说的, 甚至是对于socket接口层, 两个系统就不是可靠的了, 因为发送出去的数据, 没有确保对方真正的读到（所以要在业务层做重传和确认机制）。

可靠传输的第一要素是 确认 , 第二要素是 重传 , 第三要素是 顺序 。 任何一个可靠传输的系统, 都必须包含这三个要素。 数据校验 也是必要的。

传输是一个广义的概念, 不局限于狭义的网络传输, 应该理解为通信和交互 任何涉及到通信和交互的东西, 都可以借鉴TCP的思想。无论是在UDP上实现可靠传输或者创建自己的通信系统，无论这个系统是以API方式还是服务方式，只要是一个通信系统，就要考虑这三个要素。

SeqNum的增加是和传输的字节数相关的。 上图中，三次握手后，来了两个Len:1440的包，而第二个包的SeqNum就成了1441。然后第一个ACK回的是1441（下一个待接收的字节号），表示第一个1440收到了。

网络上的传输是没有连接的，包括TCP也是一样的 。而TCP所谓的“连接”，其实只不过是在通讯的双方维护一个“连接状态”，让它看上去好像有连接一样。所以，TCP的状态变换是非常重要的。

查看各种状态的数量
ss -ant | awk '{++s[$1]} END {for(k in s) print k,s[k]}'

通过三次握手完成连接的建立

三次握手的目的是交换通信双方的初始化序号，以保证应用层接收到的数据不会乱序，所以叫SYN(Synchronize Sequence Numbers)。

ISN是不能hard code的，不然会出问题的。比如：如果连接建好后始终用1来做ISN，如果client发了30个segment过去，但是网络断了，于是client重连，又用了1做ISN，但是之前连接的那些包到了，于是就被当成了新连接的包，此时，client的Sequence Number可能是3，而Server端认为client端的这个号是30了。全乱了。RFC793中说，ISN会和一个假的时钟绑在一起，这个时钟会在每4微秒对ISN做加一 *** 作，直到超过232，又从0开始。这样，一个ISN的周期大约是455个小时。因为，我们假设我们的TCP Segment在网络上的存活时间不会超过Maximum Segment Lifetime（MSL），所以，只要MSL的值小于455小时，那么，我们就不会重用到ISN。

如果Server端接到了Clien发的SYN后回了SYN-ACK，之后Client掉线了，Server端没有收到Client返回的ACK，那么，这个连接就处于一个中间状态，即没成功，也没失败。于是，Server端如果在一定时间内没有收到的ACK会重发SYN-ACK。在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻番，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s都知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 26 -1 = 63s，TCP才会断开这个连接。

客户端给服务器发了一个SYN后，就下线了，于是服务器需要默认等63s才会断开连接，这样，攻击者就可以把服务器的SYN连接的队列耗尽，让正常的连接请求不能处理。
于是，Linux下给了一个叫tcp_syncookies的参数来应对这个事：当SYN队列满了后，TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去（又叫cookie），此时服务器并没有保留客户端的SYN包。如果是攻击者则不会有响应，如果是正常连接，则会把这个SYN Cookie发回来，然后服务端可以通过cookie建连接（即使你不在SYN队列中）。
千万别用tcp_syncookies来处理正常的大负载的连接的情况。因为sync cookies是妥协版的TCP协议，并不严谨。应该调整三个TCP参数：tcp_synack_retries减少重试次数，tcp_max_syn_backlog增大SYN连接数，tcp_abort_on_overflow处理不过来干脆就直接拒绝连接

因为TCP是全双工的，因此断开连接需要4次挥手，发送方和接收方都需要发送Fin和Ack。如果两边同时断连接，那就会就进入到CLOSING状态，然后到达TIME_WAIT状态。

指的是报文段的最大生存时间，如果报文段在网络中活动了MSL时间，还没有被接收，那么会被丢弃。关于MSL的大小，RFC 793协议中给出的建议是两分钟，不过实际上不同的 *** 作系统可能有不同的设置，以Linux为例，通常是半分钟，两倍的MSL就是一分钟，也就是60秒

主动关闭的一方会进入TIME_WAIT状态，并且在此状态停留两倍的MSL时长。由于TIME_WAIT的存在，大量短连接会占有大量的端口，造成无法新建连接。

主动关闭的一方发出 FIN包，被动关闭的一方响应ACK包，此时，被动关闭的一方就进入了CLOSE_WAIT状态。如果一切正常，稍后被动关闭的一方也会发出FIN包，然后迁移到LAST_ACK状态。

CLOSE_WAIT状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT状态，那么就意味着被动关闭的一方没有及时发出FIN包。

TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。

接收端给发送端的Ack确认只会确认最后一个连续的包 ，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注意此时3没收到），此时的TCP会怎么办？我们要知道，因为正如前面所说的，SeqNum和Ack是以字节数为单位，所以ack的时候，不能跳着确认，只能确认最大的连续收到的包，不然，发送端就以为之前的都收到了

但总体来说都不好。因为都在等timeout，timeout可能会很长

不以时间驱动，而以数据驱动重传
如果包没有连续到达，就ack最后那个可能被丢了的包，如果发送方连续收到3次相同的ack，就重传

Selective Acknowledgment, 需要在TCP头里加一个SACK的东西，ACK还是Fast Retransmit的ACK，SACK则是汇报收到的数据碎版，在发送端就可以根据回传的SACK来知道哪些数据到了，哪些没有收到

重复收到数据的问题，使用了SACK来告诉发送方有哪些数据被重复接收了

经典算法：Karn/Partridge算法，Jacobson/Karels算法

TCP必需要知道网络实际的数据处理带宽或是数据处理速度，这样才不会引起网络拥塞，导致丢包

Advertised-Window ：接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来

接收端LastByteRead指向了TCP缓冲区中读到的位置，NextByteExpected指向的地方是收到的连续包的最后一个位置，LastByteRcved指向的是收到的包的最后一个位置，我们可以看到中间有些数据还没有到达，所以有数据空白区。

发送端的LastByteAcked指向了被接收端Ack过的位置（表示成功发送确认），LastByteSent表示发出去了，但还没有收到成功确认的Ack，LastByteWritten指向的是上层应用正在写的地方。

接收端在给发送端回ACK中会汇报自己的AdvertisedWindow = MaxRcvBuffer – LastByteRcvd – 1;

收到36的ack，并发出了46-51的字节

如果Window变成0了，发送端就不发数据了

如果发送端不发数据了，接收方一会儿Window size 可用了，怎么通知发送端呢：TCP使用了Zero Window Probe技术，缩写为ZWP，也就是说，发送端在窗口变成0后，会发ZWP的包给接收方，让接收方来ack他的Window尺寸，一般这个值会设置成3次，每次大约30-60秒。如果3次过后还是0的话，有的TCP实现就会发RST把链接断了。

如果你的网络包可以塞满MTU，那么你可以用满整个带宽，如果不能，那么你就会浪费带宽。避免对小的window size做出响应，直到有足够大的window size再响应。

如果这个问题是由Receiver端引起的，那么就会使用David D Clark’s 方案。在receiver端，如果收到的数据导致window size小于某个值，可以直接ack(0)回sender，这样就把window给关闭了，也阻止了sender再发数据过来，等到receiver端处理了一些数据后windows size大于等于了MSS，或者receiver buffer有一半为空，就可以把window打开让send 发送数据过来。

如果这个问题是由Sender端引起的，那么就会使用著名的 Nagle’s algorithm。这个算法的思路也是延时处理，他有两个主要的条件：1）要等到 Window Size >= MSS 或是 Data Size >= MSS，2）等待时间或是超时200ms，这两个条件有一个满足，他才会发数据，否则就是在攒数据。

TCP_CORK是禁止小包发送，而Nagle算法没有禁止小包发送，只是禁止了大量的小包发送

TCP不是一个自私的协议，当拥塞发生的时候，要做自我牺牲

拥塞控制的论文请参看 《Congestion Avoidance and Control》

主要算法有：慢启动，拥塞避免，拥塞发生，快速恢复，TCP New Reno，FACK算法，TCP Vegas拥塞控制算法

TCP网络协议及其思想的应用
TCP 的那些事儿（上）
TCP 的那些事儿（下）
tcp为什么是三次握手，为什么不是两次或四次？
记一次TIME_WAIT网络故障
再叙TIME_WAIT
tcp_tw_recycle和tcp_timestamps导致connect失败问题
tcp短连接TIME_WAIT问题解决方法大全（1）- 高屋建瓴
tcp短连接TIME_WAIT问题解决方法大全（2）- SO_LINGER
tcp短连接TIME_WAIT问题解决方法大全（3）- tcp_tw_recycle
tcp短连接TIME_WAIT问题解决方法大全（4）- tcp_tw_reuse
tcp短连接TIME_WAIT问题解决方法大全（5）- tcp_max_tw_buckets
TCP的TIME_WAIT快速回收与重用
浅谈CLOSE_WAIT
又见CLOSE_WAIT
PHP升级导致系统负载过高问题分析
Coping with the TCP TIME-WAIT state on busy Linux servers

分类: 电脑/网络 >> 互联网
问题描述:

弄了半天就是上不去

详细信息显示:

网络设置局域网内使用透明代理

登录过程
---------------------------------------------------------------------------

开始登录时间[2006-11-10 22:23:07]

初始化登录服务器列表，上次的登录方式为初始登录方式

尝试UDP方式登录,先创建UDP网络组件

创建UDP网络组件成功，本地IP1921681101,端口4000，准备连接登录服务器

UDP登录服务器sztencent需要域名解析

UDP登录服务器sztencent域名解析成功,解析为21913349171

UDP服务器域名解析过程完成，开始连接服务器

尝试连接UDP服务器IP21913349171,端口8000

尝试连接UDP登录服务器超时,转尝试连接下一组服务器

UDP登录服务器全部尝试连接失败,尝试下一种登录方式

尝试TCP方式登录,准备连接TCP服务器IPtcpconn6tencent,端口80,先进行域名解析

TCP登录服务器tcpconn6tencent域名解析成功,解析为21913360173,准备连接该服务器

连接TCP登录服务器成功,服务器IPtcpconn6tencent,端口80

确定登录TCP服务器IPtcpconn6tencent,端口80

向登录服务器发送新登录第一步骤数据

尝试TCP方式登录,准备连接TCP服务器IPtcpconn2tencent,端口80,先进行域名解析

TCP登录服务器tcpconn2tencent域名解析成功,解析为21913338230,准备连接该服务器

连接TCP登录服务器成功,服务器IPtcpconn2tencent,端口80

确定登录TCP服务器IPtcpconn2tencent,端口80

向登录服务器发送新登录第一步骤数据

尝试TCP方式登录,准备连接TCP服务器IPtcpconn3tencent,端口80,先进行域名解析

TCP登录服务器tcpconn3tencent域名解析成功,解析为219133385,准备连接该服务器

连接TCP登录服务器成功,服务器IPtcpconn3tencent,端口80

确定登录TCP服务器IPtcpconn3tencent,端口80

向登录服务器发送新登录第一步骤数据

尝试TCP方式登录,准备连接TCP服务器IPtcpconn5tencent,端口80,先进行域名解析

TCP登录服务器tcpconn5tencent域名解析成功,解析为21913349211,准备连接该服务器

连接TCP登录服务器成功,服务器IPtcpconn5tencent,端口80

确定登录TCP服务器IPtcpconn5tencent,端口80

向登录服务器发送新登录第一步骤数据

尝试TCP方式登录,准备连接TCP服务器IPtcpconn4tencent,端口80,先进行域名解析

TCP登录服务器tcpconn4tencent域名解析成功,解析为58601445,准备连接该服务器

连接TCP登录服务器成功,服务器IPtcpconn4tencent,端口80

确定登录TCP服务器IPtcpconn4tencent,端口80

向登录服务器发送新登录第一步骤数据

尝试TCP方式登录,准备连接TCP服务器IPtcpconntencent,端口80,先进行域名解析

TCP登录服务器tcpconntencent域名解析成功,解析为21913348103,准备连接该服务器

连接TCP登录服务器成功,服务器IPtcpconntencent,端口80

确定登录TCP服务器IPtcpconntencent,端口80

向登录服务器发送新登录第一步骤数据

TCP登录服务器全部尝试失败

最终登录失败,时间:2006-11-10 22:23:50

请高手帮忙!!!

解析:

服务器超时。

就是你的机器与服务器连接时。为了保障多人同时登陆服务器而不使服务器资源用尽。这时服务器就会对准备登陆服务器的计算机进行测试，如果在一定时间里不能正常登陆，那么服务器就会自动断开与这台计算机的连接。导致‘服务器超时’消息的发生。

服务器超时的QQ登录方法

QQ 服务器太忙无法登录或者超时 这里有灵验的登录方法 包你登陆上QQ

'DC(uN0i'%l 相信大家或多或少都有过这样的体验，在上网高峰时段登录QQ时，小企鹅在屏幕上徒劳地闪动半天之后，d出来的却是服务器太忙无法登录或者超时的提示框，接连试几次都是这样的，真的有点烦人。别着急，用下面的方法一定能让你顺利登录上去的。

1DM&Y4\C 先说第一种方法。如果你使用的是默认登录面板登录的话，那么你可以改用“注册向导”试试，一般情况下都能成功。还不管用的话，就得使用更绝的第二种方法了——打开多个QQ窗口来同时登录同一个号码。我遇到上述情况就会同时打开三个窗口，这里面肯定会有一个能登录上去的，百试不爽。不过也有一种情况是例外的，那就是：网络断线的时候:)。

如果你用Realpalyer看在线影片的时候超时 应该是你掉线了

重新拨号或者重新启动都可以

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次连接通信过程中必不可少的。
因此，运输连接就有三个阶段： 连接建立 ， 数据传送 和 连接释放 。

需要解决以下3个问题：

连接建立 这个过程，需要在客户端和服务器之间，交换3个TCP报文段，也就是 三次握手