你真的懂TCP和UDP？

UDP协议疑难杂症全景解析

https://blog.csdn.net/dog250/article/details/6896949

TCP协议疑难杂症全景解析

https://blog.csdn.net/dog250/article/details/6612496

为什么QQ用的是UDP协议而不是TCP协议？

说法1

登陆采用TCP协议和HTTP协议，你和好友之间发送消息，主要采用UDP协议，内网传文件采用了P2P技术。总来的说：
1.登陆过程，客户端client 采用TCP协议向服务器server发送信息，HTTP协议下载信息。登陆之后，会有一个TCP连接来保持在线状态。
2.和好友发消息，客户端client采用UDP协议，但是需要通过服务器转发。腾讯为了确保传输消息的可靠，采用上层协议来保证可靠传输。如果消息发送失败，客户端会提示消息发送失败，并可重新发送。
3.如果是在内网里面的两个客户端传文件，QQ采用的是P2P技术，不需要服务器中转。

说法2

QQ既有UDP也有TCP！
不管UDP还是TCP，最终登陆成功之后，QQ都会有一个TCP连接来保持在线状态。这个TCP连接的远程端口一般是80，采用UDP方式登陆的时候，端口是8000。

UDP协议是无连接方式的协议，它的效率高，速度快，占资源少，但是其传输机制为不可靠传送，必须依靠辅助的算法来完成传输控制。QQ采用的通信协议以UDP为主，辅以TCP协议。由于QQ的服务器设计容量是海量级的应用，一台服务器要同时容纳十几万的并发连接，因此服务器端只有采用UDP协议与客户端进行通讯才能保证这种超大规模的服务。

QQ客户端之间的消息传送也采用了UDP模式，因为国内的网络环境非常复杂，而且很多用户采用的方式是通过代理服务器共享一条线路上网的方式，在这些复杂的情况下，客户端之间能彼此建立起来TCP连接的概率较小，严重影响传送信息的效率。而UDP包能够穿透大部分的代理服务器，因此QQ选择了UDP作为客户之间的主要通信协议。

采用UDP协议，通过服务器中转方式。因此，现在的IP侦探在你仅仅跟对方发送聊天消息的时候是无法获取到IP的。大家都知道，UDP 协议是不可靠协议，它只管发送，不管对方是否收到的，但它的传输很高效。但是，作为聊天软件，怎么可以采用这样的不可靠方式来传输消息呢？于是，腾讯采用了上层协议来保证可靠传输：如果客户端使用UDP协议发出消息后，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况，就是因为客户端发出的消息服务器已经收到并转发成功，但客户端由于网络原因没有收到服务器的应答包引起的。

http://www.52im.net/thread-279-1-1.html

现在

早期的腾讯QQ也同样面临C10K问题，只不过他们是用了UDP这种原始的包交换协议来实现的，绕开了这个难题，当然过程肯定是痛苦的。如果当时有epoll技术，他们肯定会用TCP。众所周之，后来的手机QQ、微信都采用TCP协议。

QQ通信原理

聊天消息通信。采用UDP协议，通过服务器中转方式。因此，现在的IP侦探在你仅仅跟对方发送聊天消息的时候是无法获取到IP的。大家都知道，UDP协议是不可靠协议，它只管发送，不管对方是否收到的，但它的传输很高效。但是，作为聊天软件，怎么可以采用这样的不可靠方式来传输消息呢？于是，腾讯采用了上层协议来保证可靠传输：如果客户端使用UDP协议发出消息后，服务器收到该包，需要使用UDP协议发回一个应答包。如此来保证消息可以无遗漏传输。之所以会发生在客户端明明看到“消息发送失败”但对方又收到了这个消息的情况，就是因为客户端发出的消息服务器已经收到并转发成功，但客户端由于网络原因没有收到服务器的应答包引起的。

发送消息的时候是UDP打洞,登陆的时候使用HTTP
https://blog.csdn.net/gcc_sky/article/details/18663069
用UDP协议通讯时怎样得知目标机是否获得了数据包？
大家都知道，UDP协议通信必须在同一个局域网内
UDP包中包括一个TimeStamp,如果接收者收到,将TimeStamp返回.
在UDP之上自定义一个通讯协议：每个数据包中包含一个唯一标识，可以用编号也可以用时间；接收端收到数据包后回发一个数据包，包含收到的这个唯一标识；发送端在预定时间内没有收到回执则自动重发，重发一定次数后仍未收到回执则认为发送失败。

迅雷是UDP? UDP打洞和TCP打洞？

就是udp的，视频传输数量大，速度要求高，所以用udp，tcp如果出现错误要重传，这是不符合效率要求的，你说的tcp连接的是ftp服务
http://www.cnblogs.com/LeoWong/archive/2009/09/25/1574265.html

server最大tcp连接数：

server通常固定在某个本地端口上监听，等待client的连接请求。不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4元组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数，对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。

C10m的问题

Robert Graham的结论是：OS的内核不是解决C10M问题的办法，恰恰相反OS的内核正是导致C10M问题的关键所在。这也就意味着：

不要让OS内核执行所有繁重的任务：将数据包处理、内存管理、处理器调度等任务从内核转移到应用程序高效地完成，让诸如Linux这样的OS只处理控制层，数据层完全交给应用程序来处理。

最终就是要设计这样一个系统，该系统可以处理千万级别的并发连接，它在200个时钟周期内处理数据包，在14万个时钟周期内处理应用程序逻辑。由于一次主存储器访问就要花费300个时钟周期，所以这是最大限度的减少代码和缓存丢失的关键。

面向数据层的系统可以每秒处理1千万个数据包，面向控制层的系统，每秒只能处理1百万个数据包。这似乎很极端，请记住一句老话：可扩展性是专业化的，为了做好一些事情，你不能把性能问题外包给操作系统来解决，你必须自己做。
http://www.52im.net/thread-568-1-1.html

解决C10M问题的思路总结

综上所述，解决C10M问题的关键主要是从下面几个方面入手：

网卡问题：通过内核工作效率不高
解决方案：使用自己的驱动程序并管理它们，使适配器远离操作系统。

CPU问题：使用传统的内核方法来协调你的应用程序是行不通的。
解决方案：Linux管理前两个CPU，你的应用程序管理其余的CPU，中断只发生在你允许的CPU上。

内存问题：内存需要特别关注，以求高效。
解决方案：在系统启动时就分配大部分内存给你管理的大内存页。

以Linux为例，解决的思咯就是将控制层交给Linux，应用程序管理数据。应用程序与内核之间没有交互、没有线程调度、没有系统调用、没有中断，什么都没有。然而，你有的是在Linux上运行的代码，你可以正常调试，这不是某种怪异的硬件系统，需要特定的工程师。你需要定制的硬件在数据层提升性能，但是必须是在你熟悉的编程和开发环境上进行。