TCP/IP 需要一本书：《TCP/IP 详解 卷一》&br&HTTP 需要另一本书：《HTTP 权威指南》&br&Sockets 还需要一本书：《Unix 网络编程 卷一》&br&以上三本书不需要看完，各看半本就行。然后才谈得到“它们之间的逻辑关系”。&br&&br&Servlet 可能需要不止一本书。因为估计现在也很少有人直接裸写 Servlet ，一般都基于某个 Web 框架来开发。
TCP/IP 需要一本书：《TCP/IP 详解 卷一》 HTTP 需要另一本书：《HTTP 权威指南》 Sockets 还需要一本书：《Unix 网络编程 卷一》 以上三本书不需要看完，各看半本就行。然后才谈得到“它们之间的逻辑关系”。 Servlet 可能需要不止一本书。因为估计现在也…
你ssh连上服务器的情况下，拔掉网线，你任然检测不到网络断开了（没有FIN），这时候把网线插回去，敲两下键盘，终端一样有反应，链接还活着。因为tcp的链接是否有效，依赖链接两端的状态确定，你在你机器上拔掉网线，你是知道这件事情的，但是中间网络设备拔掉网线，或者出现什么问题，你完全无法得知链接是否还有效，依赖tcp本身的keepalive机制需要半个小时以上才能检测得出来。&br&&br&所幸，keepalive如今也可以设置检测时间了：&br&&div class=&highlight&&&pre&&code class=&language-c&&&span class=&cm&&/* ikeepalive: tcp keep alive option */&/span&
&span class=&kt&&int&/span& &span class=&nf&&ikeepalive&/span&&span class=&p&&(&/span&&span class=&kt&&int&/span& &span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&kt&&int&/span& &span class=&n&&keepcnt&/span&&span class=&p&&,&/span& &span class=&kt&&int&/span& &span class=&n&&keepidle&/span&&span class=&p&&,&/span& &span class=&kt&&int&/span& &span class=&n&&keepintvl&/span&&span class=&p&&)&/span&
&span class=&p&&{&/span&
&span class=&kt&&int&/span& &span class=&n&&enable&/span& &span class=&o&&=&/span& &span class=&p&&(&/span&&span class=&n&&keepcnt&/span& &span class=&o&&&&/span& &span class=&mi&&0&/span& &span class=&o&&||&/span& &span class=&n&&keepidle&/span& &span class=&o&&&&/span& &span class=&mi&&0&/span& &span class=&o&&||&/span& &span class=&n&&keepintvl&/span& &span class=&o&&&&/span& &span class=&mi&&0&/span&&span class=&p&&)&/span&&span class=&o&&?&/span& &span class=&mi&&0&/span& &span class=&o&&:&/span& &span class=&mi&&1&/span&&span class=&p&&;&/span&
&span class=&kt&&unsigned&/span& &span class=&kt&&long&/span& &span class=&n&&value&/span&&span class=&p&&;&/span&
&span class=&cp&&#if (defined(WIN32) || defined(_WIN32) || defined(_WIN64) || defined(WIN64))&/span&
&span class=&cp&&#define _SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR, 4)&/span&
&span class=&kt&&unsigned&/span& &span class=&kt&&long&/span& &span class=&n&&keepalive&/span&&span class=&p&&[&/span&&span class=&mi&&3&/span&&span class=&p&&],&/span& &span class=&n&&oldkeep&/span&&span class=&p&&[&/span&&span class=&mi&&3&/span&&span class=&p&&];&/span&
&span class=&n&&OSVERSIONINFO&/span& &span class=&n&&info&/span&&span class=&p&&;&/span&
&span class=&kt&&int&/span& &span class=&n&&candoit&/span& &span class=&o&&=&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&n&&info&/span&&span class=&p&&.&/span&&span class=&n&&dwOSVersionInfoSize&/span& &span class=&o&&=&/span& &span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&n&&info&/span&&span class=&p&&);&/span&
&span class=&n&&GetVersionEx&/span&&span class=&p&&(&/span&&span class=&o&&&&/span&&span class=&n&&info&/span&&span class=&p&&);&/span&
&span class=&k&&if&/span& &span class=&p&&(&/span&&span class=&n&&info&/span&&span class=&p&&.&/span&&span class=&n&&dwPlatformId&/span& &span class=&o&&==&/span& &span class=&n&&VER_PLATFORM_WIN32_NT&/span&&span class=&p&&)&/span& &span class=&p&&{&/span&
&span class=&k&&if&/span& &span class=&p&&((&/span&&span class=&n&&info&/span&&span class=&p&&.&/span&&span class=&n&&dwMajorVersion&/span& &span class=&o&&==&/span& &span class=&mi&&5&/span& &span class=&o&&&&&/span& &span class=&n&&info&/span&&span class=&p&&.&/span&&span class=&n&&dwMinorVersion&/span& &span class=&o&&&=&/span& &span class=&mi&&1&/span&&span class=&p&&)&/span& &span class=&o&&||&/span&
&span class=&p&&(&/span&&span class=&n&&info&/span&&span class=&p&&.&/span&&span class=&n&&dwMajorVersion&/span& &span class=&o&&&=&/span& &span class=&mi&&6&/span&&span class=&p&&))&/span& &span class=&p&&{&/span&
&span class=&n&&candoit&/span& &span class=&o&&=&/span& &span class=&mi&&1&/span&&span class=&p&&;&/span&
&span class=&p&&}&/span&
&span class=&p&&}&/span&
&span class=&n&&value&/span& &span class=&o&&=&/span& &span class=&n&&enable&/span&&span class=&o&&?&/span& &span class=&mi&&1&/span& &span class=&o&&:&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&n&&isetsockopt&/span&&span class=&p&&(&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&SOL_SOCKET&/span&&span class=&p&&,&/span& &span class=&n&&SO_KEEPALIVE&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&kt&&char&/span&&span class=&o&&*&/span&&span class=&p&&)&/span&&span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span&
&span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&n&&value&/span&&span class=&p&&));&/span&
&span class=&k&&if&/span& &span class=&p&&(&/span&&span class=&n&&candoit&/span& &span class=&o&&&&&/span& &span class=&n&&enable&/span&&span class=&p&&)&/span& &span class=&p&&{&/span&
&span class=&kt&&int&/span& &span class=&n&&ret&/span& &span class=&o&&=&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&n&&keepalive&/span&&span class=&p&&[&/span&&span class=&mi&&0&/span&&span class=&p&&]&/span& &span class=&o&&=&/span& &span class=&n&&enable&/span&&span class=&o&&?&/span& &span class=&mi&&1&/span& &span class=&o&&:&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&n&&keepalive&/span&&span class=&p&&[&/span&&span class=&mi&&1&/span&&span class=&p&&]&/span& &span class=&o&&=&/span& &span class=&p&&((&/span&&span class=&kt&&unsigned&/span& &span class=&kt&&long&/span&&span class=&p&&)&/span&&span class=&n&&keepidle&/span&&span class=&p&&)&/span& &span class=&o&&*&/span& &span class=&mi&&1000&/span&&span class=&p&&;&/span&
&span class=&n&&keepalive&/span&&span class=&p&&[&/span&&span class=&mi&&2&/span&&span class=&p&&]&/span& &span class=&o&&=&/span& &span class=&p&&((&/span&&span class=&kt&&unsigned&/span& &span class=&kt&&long&/span&&span class=&p&&)&/span&&span class=&n&&keepintvl&/span&&span class=&p&&)&/span& &span class=&o&&*&/span& &span class=&mi&&1000&/span&&span class=&p&&;&/span&
&span class=&n&&ret&/span& &span class=&o&&=&/span& &span class=&n&&WSAIoctl&/span&&span class=&p&&((&/span&&span class=&kt&&unsigned&/span& &span class=&kt&&int&/span&&span class=&p&&)&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&_SIO_KEEPALIVE_VALS&/span&&span class=&p&&,&/span&
&span class=&p&&(&/span&&span class=&n&&LPVOID&/span&&span class=&p&&)&/span&&span class=&n&&keepalive&/span&&span class=&p&&,&/span& &span class=&mi&&12&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&n&&LPVOID&/span&&span class=&p&&)&/span&&span class=&n&&oldkeep&/span&&span class=&p&&,&/span& &span class=&mi&&12&/span&&span class=&p&&,&/span& &span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span& &span class=&nb&&NULL&/span&&span class=&p&&,&/span& &span class=&nb&&NULL&/span&&span class=&p&&);&/span&
&span class=&k&&if&/span& &span class=&p&&(&/span&&span class=&n&&ret&/span& &span class=&o&&==&/span& &span class=&n&&SOCKET_ERROR&/span&&span class=&p&&)&/span& &span class=&p&&{&/span&
&span class=&k&&return&/span& &span class=&o&&-&/span&&span class=&mi&&1&/span&&span class=&p&&;&/span&
&span class=&p&&}&/span&
&span class=&p&&}&/span& &span class=&k&&else&/span& &span class=&p&&{&/span&
&span class=&k&&return&/span& &span class=&o&&-&/span&&span class=&mi&&2&/span&&span class=&p&&;&/span&
&span class=&p&&}&/span&
&span class=&cp&&#elif defined(SOL_TCL) && defined(TCP_KEEPIDLE) && defined(TCP_KEEPINTVL)&/span&
&span class=&n&&value&/span& &span class=&o&&=&/span& &span class=&n&&enable&/span&&span class=&o&&?&/span& &span class=&mi&&1&/span& &span class=&o&&:&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&n&&isetsockopt&/span&&span class=&p&&(&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&SOL_SOCKET&/span&&span class=&p&&,&/span& &span class=&n&&SO_KEEPALIVE&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&kt&&char&/span&&span class=&o&&*&/span&&span class=&p&&)&/span&&span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span& &span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&kt&&long&/span&&span class=&p&&));&/span&
&span class=&n&&value&/span& &span class=&o&&=&/span& &span class=&n&&keepcnt&/span&&span class=&p&&;&/span&
&span class=&n&&isetsockopt&/span&&span class=&p&&(&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&SOL_TCP&/span&&span class=&p&&,&/span& &span class=&n&&TCP_KEEPCNT&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&kt&&char&/span&&span class=&o&&*&/span&&span class=&p&&)&/span&&span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span& &span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&kt&&long&/span&&span class=&p&&));&/span&
&span class=&n&&value&/span& &span class=&o&&=&/span& &span class=&n&&keepidle&/span&&span class=&p&&;&/span&
&span class=&n&&isetsockopt&/span&&span class=&p&&(&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&SOL_TCP&/span&&span class=&p&&,&/span& &span class=&n&&TCP_KEEPIDLE&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&kt&&char&/span&&span class=&o&&*&/span&&span class=&p&&)&/span&&span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span& &span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&kt&&long&/span&&span class=&p&&));&/span&
&span class=&n&&value&/span& &span class=&o&&=&/span& &span class=&n&&keepintvl&/span&&span class=&p&&;&/span&
&span class=&n&&isetsockopt&/span&&span class=&p&&(&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&SOL_TCP&/span&&span class=&p&&,&/span& &span class=&n&&TCP_KEEPINTVL&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&kt&&char&/span&&span class=&o&&*&/span&&span class=&p&&)&/span&&span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span& &span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&kt&&long&/span&&span class=&p&&));&/span&
&span class=&cp&&#elif defined(SO_KEEPALIVE)&/span&
&span class=&n&&value&/span& &span class=&o&&=&/span& &span class=&n&&enable&/span&&span class=&o&&?&/span& &span class=&mi&&1&/span& &span class=&o&&:&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&n&&isetsockopt&/span&&span class=&p&&(&/span&&span class=&n&&sock&/span&&span class=&p&&,&/span& &span class=&n&&SOL_SOCKET&/span&&span class=&p&&,&/span& &span class=&n&&SO_KEEPALIVE&/span&&span class=&p&&,&/span& &span class=&p&&(&/span&&span class=&kt&&char&/span&&span class=&o&&*&/span&&span class=&p&&)&/span&&span class=&o&&&&/span&&span class=&n&&value&/span&&span class=&p&&,&/span& &span class=&k&&sizeof&/span&&span class=&p&&(&/span&&span class=&kt&&long&/span&&span class=&p&&));&/span&
&span class=&cp&&#else&/span&
&span class=&k&&return&/span& &span class=&o&&-&/span&&span class=&mi&&1&/span&&span class=&p&&;&/span&
&span class=&cp&&#endif&/span&
&span class=&k&&return&/span& &span class=&mi&&0&/span&&span class=&p&&;&/span&
&span class=&p&&}&/span&
&/code&&/pre&&/div&&br&如今，大部分平台下，确实可以不用自己做心跳了，直接调整下KeepAlive的参数到你期望的水平即可。然而如你所见，代码中大量的条件判断。KeepAlive参数调整的实现对平台依赖很大，并非所有平台都支持这样的，你如果能够确定自己代码运行的平台，那么放心大胆的用这个keepalive。你如果无法确定平台，不想依赖平台的keepalive，又需要自己精确控制链接超时，那么请自己实现心跳。
你ssh连上服务器的情况下，拔掉网线，你任然检测不到网络断开了（没有FIN），这时候把网线插回去，敲两下键盘，终端一样有反应，链接还活着。因为tcp的链接是否有效，依赖链接两端的状态确定，你在你机器上拔掉网线，你是知道这件事情的，但是中间网络设备…
登陆采用TCP协议和HTTP协议，你和好友之间发送消息，主要采用UDP协议，内网传文件采用了P2P技术。总来的说：&br&1.登陆过程，客户端client 采用TCP协议向服务器server发送信息，HTTP协议下载信息。登陆之后，会有一个TCP连接来保持在线状态。&br&2.和好友发消息，客户端client采用UDP协议，但是需要通过服务器转发。腾讯为了确保传输消息的可靠，采用上层协议来保证可靠传输。如果消息发送失败，客户端会提示消息发送失败，并可重新发送。&br&3.如果是在内网里面的两个客户端传文件，QQ采用的是P2P技术，不需要服务器中转。
登陆采用TCP协议和HTTP协议，你和好友之间发送消息，主要采用UDP协议，内网传文件采用了P2P技术。总来的说： 1.登陆过程，客户端client 采用TCP协议向服务器server发送信息，HTTP协议下载信息。登陆之后，会有一个TCP连接来保持在线状态。 2.和好友发消息，…
首先明确：&br&1)TCP滑动窗口分为接受窗口，发送窗口&br&滑动窗口协议是&b&传输层进行流控&/b&的一种措施，&b&接收方通过通告发送方自己的窗口大小&/b&，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。&br&&br&对ACK的再认识，ack通常被理解为收到数据后给出的一个确认ACK，ACK包含两个非常重要的信息：&br&&b&一是期望接收到的下一字节的序号n，该n代表接收方已经接收到了前n-1字节数据，此时如果接收方收到第n+1字节数据而不是第n字节数据，&/b&&b&接收方是不会发送序号为n+2的ACK的。&/b&举个例子，假如接收端收到1-1024字节，它会发送一个确认号为1025的ACK,但是接下来收到的是，它是不会发送确认号为3072的ACK,而依旧发送1025的ACK。&br&&br&&b&二是当前的窗口大小m，如此发送方在接收到ACK包含的这两个数据后就可以计算出还可以发送多少字节的数据给对方，假定当前发送方已发送到第x字节，则可以发送的字节数就是y=m-(x-n).这就是滑动窗口控制流量的基本原理&/b&&br&&br&&br&&br&&br&&b&重点：发送方根据收到ACK当中的期望收到的下一个字节的序号n以及窗口m，还有当前已经发送的字节序号x，算出还可以发送的字节数。&/b&&br&&br&&br&&b&发送端窗口的第一个字节序号一定是ACK中期望收到的下一个字节序号，比如下图：&/b&&br&&b&&img src=&/9cafa47bfa2e_b.png& data-rawwidth=&667& data-rawheight=&216& class=&origin_image zh-lightbox-thumb& width=&667& data-original=&/9cafa47bfa2e_r.png&&上图52 53 54 55 字节都是可以新发送的字节序&/b&&br&&br&&br&&b&接受端窗口的第一个字节序之前一定是已经完全接收的，后面窗口里面的数据都是希望接受的，窗口后面的数据都是不希望接受的。&/b&&br&&br&&br&&br&&div class=&highlight&&&pre&&code class=&language-text&&http://blog.chinaunix.net/uid--id-539945.html
.cn/flows/2012/08/tcp-%E6%BB%91%E
5%8A%A8%E7%AA%97%E5%8F%A3%E7%9A%84%E7%AE%80%E4%BB%8B/
&/code&&/pre&&/div&&br&&br&TCP的滑动窗口分为接收窗口和发送窗口&br&不分析这两种窗口就讨论是不妥当的。&br&&br&TCP的滑动窗口主要有两个作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路。TCP 段中窗口的相关字段。&br&&img src=&/d6b970fb6d44aafeeec4a4c9d61a9225_b.png& data-rawwidth=&620& data-rawheight=&197& class=&origin_image zh-lightbox-thumb& width=&620& data-original=&/d6b970fb6d44aafeeec4a4c9d61a9225_r.png&&&p&TCP的Window是一个16bit位字段，它代表的是窗口的字节容量，也就是TCP的标准窗口最大为2^16-1=65535个字节。&/p&&p&另外在TCP的选项字段中还包含了一个TCP窗口扩大因子，option-kind为3，option-length为3个字节，option-data取值范围0-14。窗口扩大因子用来扩大TCP窗口，可把原来16bit的窗口，扩大为31bit。&/p&&p&&strong&滑动窗口基本原理&/strong&&/p&&p&1）对于TCP会话的发送方，任何时候在其发送缓存内的数据都可以分为4类，“已经发送并得到对端ACK的”，“已经发送但还未收到对端ACK的”，“未发送但对端允许发送的”，“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口。&/p&&p&&img src=&/a1d5c050adf003b1ccd24_b.png& data-rawwidth=&664& data-rawheight=&177& class=&origin_image zh-lightbox-thumb& width=&664& data-original=&/a1d5c050adf003b1ccd24_r.png&&当收到接收方新的ACK对于发送窗口中后续字节的确认是，窗口滑动，滑动原理如下图。&br&&/p&&br&&img src=&/9cafa47bfa2e_b.png& data-rawwidth=&667& data-rawheight=&216& class=&origin_image zh-lightbox-thumb& width=&667& data-original=&/9cafa47bfa2e_r.png&&&p&当收到ACK=36时窗口滑动。&/p&&p&2）对于TCP的接收方，在某一时刻在它的接收缓存内存在3种。“已接收”，“未接收准备接收”，“未接收并未准备接收”（由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”）。其中“未接收准备接收”称之为接收窗口。&/p&&p&&strong&发送窗口与接收窗口关系&/strong&&/p&&p&TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。&/p&&img src=&/c798dd393fcf7c03b1db78f5bcf0304b_b.png& data-rawwidth=&675& data-rawheight=&527& class=&origin_image zh-lightbox-thumb& width=&675& data-original=&/c798dd393fcf7c03b1db78f5bcf0304b_r.png&&&p&&strong&滑动窗口实现面向流的可靠性&/strong&&/p&&p&1）最基本的传输可靠性来源于“确认重传”机制。&/p&&p&2）TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。&/p&&p&3）发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。&/p&&p&4）接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。&/p&&br&&p&&strong&滑动窗口的流控特性&/strong&&/p&&p&TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。&/p&&p&应用程序在需要（如内存不足）时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。&/p&
首先明确： 1)TCP滑动窗口分为接受窗口，发送窗口 滑动窗口协议是传输层进行流控的一种措施，接收方通过通告发送方自己的窗口大小，从而控制发送方的发送速度，从而达到防止发送方发送速度过快而导致自己被淹没的目的。 对ACK的再认识，ack通常被理解为收到…
谢谢邀请。&br&&br&TCP连接速度慢90%是由于丢包！&br&&br&无线信号差，信号差就会造成波形失真，一旦失真基站或AP就无法将波形转换为数据而丢弃，一旦丢弃，TCP两端就会超时重传丢失的包，同时将传输速率减半，如果重传的包也被丢弃，再重传，速率再减半，用户的感觉就是传输速度很慢很慢，和蜗牛爬一样。其实很多时候网络属于虚假连接，手机显示连接，信号差的几乎不可用。&br&&br&你说的情况就属于这90%范围内，重新绑定AP或者基站，绑定成功一般信号都比较好，这时你的TCP连接没有丢包，感觉就会快很多。&br&&br&另外10%服务器过载，服务器处理不过来直接就丢了，然后造成重传，启动传输速率减半机制。即然你说重启连接就会很快，服务器应该不会过载。&br&&br&你说的流量控制不会造成传输速度低，流量控制是为了避免快速的一方传输速度太快，超出慢速的一方的处理能力而丢包，然后快速一方重传，再被丢的恶性循环，所以流量控制是一种匹配双方传输速度的机制，最终找到一个平衡点，既不快也不慢，刚刚好。
谢谢邀请。 TCP连接速度慢90%是由于丢包！ 无线信号差，信号差就会造成波形失真，一旦失真基站或AP就无法将波形转换为数据而丢弃，一旦丢弃，TCP两端就会超时重传丢失的包，同时将传输速率减半，如果重传的包也被丢弃，再重传，速率再减半，用户的感觉就是…
在回答这个问题之前，先来思考另外一个问题。&br&&br&如果给你一个黑盒子，类似路由器的设备，有一个入口，有一个出口，入口和出口连接有可以发送和接收流量的测试仪器：&br&&br&&b&Traffic sender ---& black box ---& Traffic receiver&/b&&br&&br&假设入口、出口的带宽足够大到无限，测试仪器可以发送任意速率的数据，现在让你测试这个黑盒子的最大发送速率，用什么方法可以最快得到这个最大发送速率？&br&&br&我有两种方法：&br&&br&&b&方法一：从小到大，指数增长&/b&&br&&br&最初发送1Mbps，没丢包，发2Mbps，没丢包，发4M，没丢包…512M也没丢包，1024M开始丢包了。&br&&br&发 512 + （&a href=&tel:24-512&/a&）/2= 768，没有丢包&br&&br&发 768 + （&a href=&tel:&&&/a&）/2 = 896 没有丢包&br&&br&继续发 896 + （&a href=&tel:&&&/a&）/2 = 960 丢包&br&&br&继续发 896 + （960-896）/2 = 928 没有丢包&br&&br&继续发 928 + （960-928）/2 = 944 丢包&br&&br&继续发 928 + （944-928）/2 = 936 没有丢包&br&&br&继续发 936 + （944-936）/2 = 940 丢包&br&&br&继续发 936 + （940-936）/2 = 938 没有丢包&br&&br&继续发 938 + （940-938）/2 = 939 没有丢包&br&&br&可以得到最大发送速率为939 Mbps &br&&br&&b&方法二：从大到小，指数减半收敛&/b&&br&&br&方法与一类似，只是从大到小，最后也会找到最大发送速率为 939 Mbps。&br&&br&&br&方法一从 1M 到1024M发送速率翻倍的过程就是TCP &b&slow start &/b&过程，此过程可以以最快的速度摸清网络（黑盒子）的&b&最大上限（开始丢包）&/b&，然后以网络不丢包对应的速率为&b&基准线（即方法一中512M）&/b&，以线性步长（每次增加一个packet，而不是翻倍增长）逼近最高发送速率，即这里的939 Mbps。从 512M-939M的收敛过程有点类似&b&TCP congestion avoidance&/b&，但是又不完全相同，因为一方的发送速率不仅受制于己方的 &b&send_window_size&/b&，还要受制于对方的&b&adertised_window_size&/b&。&br&&br&回到这个问题的答案，如果采用方法二，将会有&b&绝大多数的流量会被丢弃&/b&，造成网络资源的浪费，如果每个主机都采用类似算法，网络将永远处于拥塞状态。&br&&br&而采用方法一，开始时候主机都小心翼翼（slow start）发很小的流量来探测网络带宽的峰值，很显然这个过程&b&大多数流量都会被转发&/b&，只有到达峰值会被丢弃超过峰值的部分，然后启用congestion avoidance 算法小幅度逼近最大传输速率。&b&一句白话：TCP传输的各种算法不就是以最快、丢的最少的方式探寻到网络的最大传输速率吗？ Yes，I think so!&/b&
在回答这个问题之前，先来思考另外一个问题。 如果给你一个黑盒子，类似路由器的设备，有一个入口，有一个出口，入口和出口连接有可以发送和接收流量的测试仪器： Traffic sender ---& black box ---& Traffic receiver 假设入口、出口的带宽足够大到无限，…
TCP 链接就是两边 end point 各维护一个队列，然后各维护一组状态来说明这两个队列之间的联系。只要队列和状态信息还在，就算物理链路断开一千年，最后还能继续通信。TCP 断开呢？是 end point 自己失去了信心，把队列和状态信息完全丢掉，之后物理链路再恢复也没用了。
TCP 链接就是两边 end point 各维护一个队列，然后各维护一组状态来说明这两个队列之间的联系。只要队列和状态信息还在，就算物理链路断开一千年，最后还能继续通信。TCP 断开呢？是 end point 自己失去了信心，把队列和状态信息完全丢掉，之后物理链路再恢…
美丽而迷人的海南岛亚龙湾，坐落着一奢华五星酒店L，到酒店前台check-in之后，接下来会有一位&b&24小时客房管家&/b&会全面接手客人的接待任务，会给客人戴上花环，&br&&br&&br&&img data-rawwidth=&450& data-rawheight=&338& src=&/v2-edb_b.jpg& class=&origin_image zh-lightbox-thumb& width=&450& data-original=&/v2-edb_r.jpg&&&br&&br&&br&送上温润的湿巾，还有纯正的椰汁，等客人稍事休息后，会引领客人到酒店房间，途中介绍早餐餐厅、中式餐厅、西式餐厅的位置及服务时间，还会介绍几个游泳池的位置，以及做精油SPA的特色及服务流程，说着说着就来到了房间，会一一介绍房间设施的使用，到最后还会有结束辞：有什么需要帮助您的，请直接一键呼叫我，预祝大家入住愉快！然后甜甜地站在一边，然后车小胖拿出早就准备好的小费递了过去…&br&&br&24小时管家服务熟知客户的入住时间、离店时间、行李的托运、餐厅预约、SPA预约、送机服务、房间使用过程中的任何问题，这是1对1的VIP服务，让客人有宾至如归的超凡体验。让我们再来看看经济型的快捷酒店的入住流程。&br&&br&你来到快捷酒店的前台，办理完身份核验及押金之后，前台给你一张房卡，房间号302，然后你就拖着行李去了房间，至于其它服务没有，至于你什么时候离店，只要押金够多，随便你住到什么时候。&br&&br&上文中的奢华酒店L的前台充当TCP 监听端口&b&（Listening Socket）&/b&，新的客人（incoming new TCP connection)入住手续全部由前台处理，如果前台不光要处理入住手续，还要帮客人介绍服务，&b&记录一些客人状态信息（TCP连接状态、接收发送字节流的序号）&/b&，会耗费很多CPU时间，当有新的客人入住时，前台如果还喋喋不休&b&（监听进程忙）&/b&地忙于上一位客人的解释工作，那新的客人就无法及时入住，这不是一个好的体验。&br&&br&于是就有了一对一的客房管家服务，一旦前台办理了入住手续&b&（Accept）&/b&，就创建&b&（Fork）&/b&一个新的&b&连接Socket&/b&，这个Socket拥有完整的TCP五元组，即：&br&&br&客户的IP + 客户的端口号 + TCP + 酒店的IP + 酒店的端口号（和listening端口相同）&br&&br&&b&这个Socket只提供唯一一位客人的连接请求。&/b&&br&&br&咱们再来看看监听Socket是什么样的？&br&&br& * + * + TCP + 酒店的IP + 酒店的端口号&br&&br&有同学肯定已经发现了，前面的两项怎么变成了星号？是什么意思呢？意思是这个socket 可以接受来自任何客户IP、任何端口号的连接请求（类似酒店前台，只服务新的接入连接）。&br&&br&而UDP则类似快捷酒店，只提供一个前台服务（Listening Socket），因为&b&不需要记录客户状态信息（UDP 是无状态的）&/b&，所以一个监听端口号足矣：&br&&br& * + * + UDP + 快捷酒店的IP + 快捷酒店的端口号
美丽而迷人的海南岛亚龙湾，坐落着一奢华五星酒店L，到酒店前台check-in之后，接下来会有一位24小时客房管家会全面接手客人的接待任务，会给客人戴上花环， 送上温润的湿巾，还有纯正的椰汁，等客人稍事休息后，会引领客人到酒店房间，途中介绍早餐餐厅、中…
理论上，如果你发了100个包，第一个没到，后面的先到了，那就都缓存着，API表现为你什么都没收到。要么第一个包重发后尽快到达，要么buffer满了傻逼，要么服务器自己觉得太久了决定掉线。
理论上，如果你发了100个包，第一个没到，后面的先到了，那就都缓存着，API表现为你什么都没收到。要么第一个包重发后尽快到达，要么buffer满了傻逼，要么服务器自己觉得太久了决定掉线。
原题：「当数据包到达局域网后，完全可以直接送到对应的IP地址主机，为什么还要询问一下对应IP主机的MAC地址？」&br&真的这样了还需要费心尽力地搞IPv6干嘛。&br&&br&题主：「你的前提是认为交换机是这样处理的，理所当然认为这样处理是正确的。交换机处理mac，路由器处理ip，为什么要这样设计？交换机为什么不可以处理ip？为什么要分层？」&br&交换机工作在二层，只认识MAC地址。如果交换机要处理IP，把二层砍掉只剩三层？呃，不觉得处理速度会很慢吗？&br&&br&网络是过去几十年一步一步搭建的，兼容性什么的都要考虑。你不能说现在都有微信了，还要固定电话号码干嘛～&br&&br&---------------------------------------------------------------------------------------------------------------------------&br&简单地说两句：&br&二层是这样工作的：每个接入设备口分配一个地址，一般的星形结构的网络，每台设备发出的数据所有其他设备都能收到，然后根据目标地址看是否是发给自己的。这个地址是谓MAC地址，因为身在最底层，没有设置分配机制或者自动获取机制，每台设备制作的时候固定写在里面，并且确保全球不重复，这样就不会有冲突。&br&&br&当然后来也就有了交换机，也就是带有存储转发功能的集线器，可以把包存一下，看一看目标地址，然后选择某一条线路发出去。怎么知道哪条线路是哪个MAC？学咯，每条线路发来的包看一下来源地址，然后记到表里面。&br&&br&二层还要解决多个设备同时发送冲突的问题，要检测，要处理，要重发等等。&br&&br&三层是这样工作的：每个设备有一个IP地址，也要保证唯一。这个IP地址可以手工分配，也可以通过DHCP获取。手工分配的时候需要注意保证唯一。局域网内想联系一个IP地址，先要知道对应的MAC地址，这时候走二层的ARP全网问一下就可以了。反过来，自己作为新设备想要一个IP地址，要么RARP要一个，要么走基于UDP的DHCP要一个，当然都只限于局域网内。&br&&br&有了这些底层的东东，每台设备都有了自己的IP地址，这样就可以互相通信。三层的关键在于，有了路由器，路由器用于将不同的网段连接在一起，并对两个网段间的通信进行存储转发。比如A网络10.0.0.0/24，B网络10.0.1.0/24，中间有一路由器隔着，两边的网关都是.1。10.0.0.2要发信给10.0.1.2，那么先看子网掩码，发现不在自己网络内，然后交给10.0.0.1，路由器看到在网络B内，从10.0.1.1发出，然后到达10.0.1.2。&br&&br&假如这俩网络没有路由器，直接走二层，那么多电脑连在一起，广播包就会占掉大量的网络带宽。&br&&br&路由器，顾名思义就是要找路用的。比如B网络还用一个路由器连接着C网络10.0.2.0/24，那么A网络一台机器要发包给C网络的一台机器，路由器怎么知道怎么走法呢，于是需要路由协议，路由器之间要说说话，了解一下对方的状态。&br&&br&再往大了去，就是互联网了。中国的一台电脑要连接美国微软，那么发出的包先到宽带运营商，然后到北京出口，然后觉得现在走欧洲到美国慢，于是转到上海，走海底光缆到了美国，再走旧金山，到西雅图，再到雷德蒙。如果只有MAC地址，是无法支撑起这么大的网络的，你觉得直接访问到MAC地址就行了，问题是你让路由器怎么给你找到路线呢？&br&&br&所以，对于原题「都只是描述IP是什么，MAC是什么。当数据包到达局域网后，完全可以直接送到对应的IP地址主机，为什么还要询问一下对应IP主机的MAC地址？」&br&你缺乏网络知识，搞不清NAT的含义，只以为公网就是用IP的，局域网就是用MAC地址的。&br&&br&如果你本身用的公网IP，那么全部走IP访问即可。如果是局域网多台电脑共用公网出口，那么首先要做的是NAT转换，这个是要在4层TCP和UDP上做的。只在二层无法完成。&br&&br&你说的东西更像IPv6，这样不需要再做NAT，所有内网设备都可以分配一个IPv6地址。&br&&br&不知道题主想的明白不，我猜肯定想不明白，哼哼～
原题：「当数据包到达局域网后，完全可以直接送到对应的IP地址主机，为什么还要询问一下对应IP主机的MAC地址？」 真的这样了还需要费心尽力地搞IPv6干嘛。 题主：「你的前提是认为交换机是这样处理的，理所当然认为这样处理是正确的。交换机处理mac，路由器…
感谢TK教主通俗易懂的回答。受邀来回答这个问题，也是我在知乎上的一血了。&br&这个工作是由我们加州大学河滨分校的安全研究团队完成。除了网络安全方向，我们团队也有进行系统安全方面的研究。团队目前还非常年轻，非常欢迎有兴趣有志向的朋友能够加入我们团队。&br&&br&回到正题。因为攻击相关的报道也很多了，那这里长话短说：&br&1. 该攻击是真的。&br&2. 该攻击与中间人攻击无关，攻击者不需要获得任何通信双方的报文。&br&3. 在Geekpwn大会上展示的攻击分为两步：TCP连接劫持，TCP连接注入。第一步TCP劫持是对于TCP连接本身的劫持，是我们最大的创新贡献(contribution)。而第二步可以理解为对TCP协议上层的应用程序所做的攻击。因为每个程序的执行逻辑不同，注入的数据必须要依据程序本身的规则被理解，所以攻击者还必须要对应用程序的请求报文行为有个正确的预估。(TK教主所说的扔鸡蛋难题也正是针对这一步)。还有个限制是该报文不能被加密，也是由于注入的报文需要被理解这一个基本要求。&br&4. 攻击影响&br&因为时间有限，我们团队并没有花很大的精力去寻找相关的应用。当前已经找到的能预估的应用场景有部分网页，以及部分app的推送消息。我们非常怀疑有更多的应用程序，甚至是一些IOT设备（智能家居）能够被劫持。但很可惜在比赛中我们并没能展示这一点。&br&&br&总体上来说这个工作还是偏研究，在实际的应用攻击方面我们并没有做足够深入的探索。但这并不代表没有其他安全人员甚至恶意黑客能找到对应的应用程序并进行攻击。而国内很多网页，应用程序重功能效果而轻安全，从而使得该攻击更容易达成。&br&而我们能做的就是马上上报该漏洞给linux开发者协会并期待他们尽快打补丁来弥补这个漏洞。而对于个人或者企业的影响是希望到时候能尽快更新补丁。对于开发者来说，在考虑到performance的同时，希望尽量加密报文从而杜绝攻击的可能性。
感谢TK教主通俗易懂的回答。受邀来回答这个问题，也是我在知乎上的一血了。 这个工作是由我们加州大学河滨分校的安全研究团队完成。除了网络安全方向，我们团队也有进行系统安全方面的研究。团队目前还非常年轻，非常欢迎有兴趣有志向的朋友能够加入我们团…
我推测大概是翻译的问题误导你了，TCP协议的流量控制不是你理解的那种traffic control，这个名字容易让人联想到交通上对于流量的管制，像是对于整个交通网络的调节。实际上你的这个理解确实更接近拥塞控制（congestion control），仅仅在对全局网络的控制上。&br&&br&先从简单的流量控制说起。&br&&img src=&/51e73d7e56f4b_b.png& data-rawwidth=&561& data-rawheight=&220& class=&origin_image zh-lightbox-thumb& width=&561& data-original=&/51e73d7e56f4b_r.png&&&br&流量控制（flow control）所说的端到端（end to end）针对的是&b&发送方和接收方速度不匹配&/b&的问题（比如经典的fast sender and slow receiver问题，接收方缓存大小与发送速率不匹配），提供一种速度匹配服务遏制发送速率使接收方应用程序的读取速率与之相适应。主要的方法有：&br&&ul&&li&Stop-and-wait 这个也是最简单粗暴的，发一个分组就等对方一个ACK回应然后再发，收不到ACK就不发了&/li&&li&滑动窗口（包括go back N和选择重传） 接收方在一个窗口都满了以后才会发送ACK确认并要求发送下一个窗口。Go back N中接收方发送NAK表示接收前N-1个分组失败然后由发送方退回N步继续发送；选择重传双方都维护窗口，引入序列号，发现超时未收到序列号则由发送方重传。&/li&&/ul&所以你可以很明显看到流量控制是&b&由接收方控制的&/b&，发送方始终是被迫调整至与接收方同步。正如你所说发生了拥塞那么减小发送方的发送速率也可以是一种拥塞控制的手段，但不是拥塞控制的唯一方式。&br&&br&拥塞控制无论原因还是方法都复杂的多。有一个说法也就是&i&Computer network: A top-down approach&/i& [1] 中提到的&br&&blockquote&a TCP sender can also be throttled due to congestion within the IP this form of sender control is referred to as congestion control.&br&Even though the actions taken by flow and congestion control are similar (the throttling of&br&the sender), they are obviously taken for very different reasons.&/blockquote&TCP发送方也可能因为IP层网络的原因被遏制，这种遏制就是一种拥塞控制的方法。流量控制和拥塞控制在手段上相似，比如都是遏制发送方，但是使用它们显然是出于不同的原因。&br&&br&流量控制解决的只是过快的发送方的问题，思路也很简单，得到ACK确认来调整发送速率，对于未收到的包再重传。这里考虑的只是一组端到端的情况，所以有点理所当然，发送方发送速率过快，那就遏制一下这个发送方的发送速率。举个非常不恰当的例子，这种思路就是“人的命运靠自我奋斗就可以”，于是你觉得成绩差那你好好学习名次一定会上升，事实上把你个人放到历史的洪流中，你就会发现“自我奋斗固然重要，但也要考虑历史的行程。”，除了一组发送端和接收端，共享一个路由的其他发送端和接收端也会对该组网络通信造成影响，路由的决定权（缓存大小）也是很重要的，就像努力学习不一定就能考到好大学一样，有可能你的对手比你更努力，也有可能你所在的省份的录取率本来就低。这个时候，发送方的速率就需要根据整个网络的条件进行调整了，而不仅仅是接收方的接收速率问题了。&br&&br&拥塞控制可以针对以下几种典型的情景：&br&&img src=&/46b1541afc299be311cf83dba1cebcc5_b.png& data-rawwidth=&685& data-rawheight=&272& class=&origin_image zh-lightbox-thumb& width=&685& data-original=&/46b1541afc299be311cf83dba1cebcc5_r.png&&两组通信共享一个无限缓存的路由器，那么这里的拥塞问题仅仅是由于链路容量，分组到达速率接近链路容量时会出现巨大的&i&排队时延&/i&。&br&&img src=&/c457d96ef1e_b.png& data-rawwidth=&635& data-rawheight=&287& class=&origin_image zh-lightbox-thumb& width=&635& data-original=&/c457d96ef1e_r.png&&当路由器的缓存有限时，还可能因为发送速率过快导致缓存溢出，这时会增加一个&i&分组重传开销&/i&。&br&&img src=&/33dd3cc447dfd0bc3bf2d3_b.png& data-rawwidth=&584& data-rawheight=&468& class=&origin_image zh-lightbox-thumb& width=&584& data-original=&/33dd3cc447dfd0bc3bf2d3_r.png&&在路由器缓存容量有限的多跳网络中，如果一个分组沿着一条路径被丢弃，那么该路径上其他参与转发该分组的路由的缓存资源也被浪费了，这在一定程度上也引起了拥塞。&br&&br&这三种情景非常有代表意义，这里的三个代表分别说明了考虑网络层的各种原因引起的拥塞可能。即使slow receiver的问题不存在，也就是即使&b&接收方的缓存无限大，依然会因为网络层的原因发生拥塞&/b&，接收窗口对于拥塞的影响可以忽略，所以我们要关注的只是拥塞窗口（CongWin）的大小，发送方未被确认的分组数量仅仅受限于CongWin的大小，发送方在感知拥塞时对发送速率的调整，即对CongWin大小调整，怎样调整就是TCP拥塞控制依据的算法，比如加性增、减性乘、慢启动等，在此我就不再赘述了，你可以看看代码，都包含对相应的拥塞窗口变量重新赋值。&br&&br&举个例子，谈一下慢启动，代码来源于BSD4.4的tcp_input函数&br&&div class=&highlight&&&pre&&code class=&language-c&&&span class=&k&&register&/span& &span class=&n&&u_int&/span& &span class=&n&&cw&/span& &span class=&o&&=&/span& &span class=&n&&tp&/span&&span class=&o&&-&&/span&&span class=&n&&snd_cwnd&/span&&span class=&p&&;&/span&
&span class=&k&&register&/span& &span class=&n&&u_int&/span& &span class=&n&&incr&/span& &span class=&o&&=&/span& &span class=&n&&tp&/span&&span class=&o&&-&&/span&&span class=&n&&t_maxseg&/span&&span class=&p&&;&/span&
&span class=&k&&if&/span& &span class=&p&&(&/span&&span class=&n&&cw&/span& &span class=&o&&&&/span& &span class=&n&&tp&/span&&span class=&o&&-&&/span&&span class=&n&&snd_ssthresh&/span&&span class=&p&&)&/span&
&span class=&n&&incr&/span& &span class=&o&&=&/span& &span class=&n&&incr&/span& &span class=&o&&*&/span& &span class=&n&&incr&/span& &span class=&o&&/&/span& &span class=&n&&cw&/span& &span class=&p&&;&/span&
&span class=&n&&tp&/span&&span class=&o&&-&&/span&&span class=&n&&snd_cwnd&/span& &span class=&o&&=&/span& &span class=&n&&min&/span&&span class=&p&&(&/span&&span class=&n&&cw&/span& &span class=&o&&+&/span& &span class=&n&&incr&/span&&span class=&p&&,&/span& &span class=&n&&TCP_MAXWIN&/span&&span class=&o&&&&&/span&&span class=&n&&tp&/span&&span class=&o&&-&&/span&&span class=&n&&snd_scale&/span&&span class=&p&&);&/span&
&/code&&/pre&&/div&慢启动的原则就是收到一个ACK窗口大小就续一个。但是如果当前的拥塞窗口大小小于慢启动的阈值，增加值为1除以拥塞窗口大小并加上一个常量，而拥塞窗口的上限又等于连接发送窗口的最大值，所以使用这样一个过程进行拥塞控制，&b&更新拥塞窗口的大小&/b&。&br&&br&另外，题主你觉得和流量控制在定义和方法上存在重复的那是&i&端到端拥塞控制，&/i&这是在网络层没有提供对于拥塞控制的显式支持。所以只能通过对传输层的网络行为（丢包、时延）观察判定拥塞是否发生，如果发生就相应的减小窗口值。但还存在&i&网络辅助的拥塞控制&/i&，比如网络组件（路由器）向发送方提供关于拥塞的反馈。&br&&img src=&/4b1c7d0c917e4c78bc30a84e04c29461_b.png& data-rawwidth=&597& data-rawheight=&301& class=&origin_image zh-lightbox-thumb& width=&597& data-original=&/4b1c7d0c917e4c78bc30a84e04c29461_r.png&&&br&[1] Kurose, James F. &i&Computer Networking: A Top-Down Approach Featuring the Internet, 3/E&/i&. Pearson Education India, 2005.&br&[2] Wright, Gary R., and W. Richard Stevens. &i&TcP/IP Illustrated&/i&. Vol. 2. Addison-Wesley Professional, 1995.
我推测大概是翻译的问题误导你了，TCP协议的流量控制不是你理解的那种traffic control，这个名字容易让人联想到交通上对于流量的管制，像是对于整个交通网络的调节。实际上你的这个理解确实更接近拥塞控制（congestion control），仅仅在对全局网络的控制上…
Cisco私有路由协议EIGRP所实现的组播可靠传输可以拿来借鉴。&br&&br&&b&EIGRP工作原理&/b&&br&1）在以太网广播网段使用组播地址224.0.0.10发送hello，发现所有的邻居，建立neighbor list table&br&&br&2）发送路由更新&b&（大块数据）&/b&到224.0.0.10这个地址，neighbor list 里所有邻居接收到路由更新之后，都需要发送ACK给源路由器，如果源路由器接收到所有邻居的ACK，说明一切OK，继续发送；&br&&br&如果没有接收到某些路由器的ACK（丢包、路由器挂了），则启动超时等待，如果定时器超时还没有收到ACK，则用单播重传给 NON-ACK 所有路由器，直到接收到ACK为止。&br&&br&通过以上的&b&组播发送/确认&/b&，&b&单播重传/确认&/b&的方式保证传输的可靠性。&br&&br&如果想使用现有的工具，使用&b&P2P软件&/b&是一个不错的选择，刚开始可能有点慢，因为数据源只有一个，但一旦别的主机有了文件的copy，也成为数据源，将会有多个P2P、P2MP辐射，传输速度会越来越快。&br&&br&无论组播传输、还是P2P，最终的瓶颈是交换机，也就是说，&b&交换机的转发性能（一秒钟可以转发多少G的数据）将是传输速率的最终极限。&/b&&br&&br&咱们先看看如果用FTP传输的瓶颈在哪里，服务器的物理接口带宽是瓶颈，最终交换机传输的数据为50*50
= 2500 M；采用组播，交换机最终传输的数据也是2500M（交换机replicate给50个客户端），但速度肯定比FTP要快；采用P2P最终也是传输2500M数据，但由于有多个数据源，即多个物理链路带宽，所以也会比FTP采用单个物理带宽速度快。
Cisco私有路由协议EIGRP所实现的组播可靠传输可以拿来借鉴。 EIGRP工作原理 1）在以太网广播网段使用组播地址224.0.0.10发送hello，发现所有的邻居，建立neighbor list table 2）发送路由更新（大块数据）到224.0.0.10这个地址，neighbor list 里所有邻居接…
客户端发图片过来的正确做法是：&br&&br&1. 客户端先使用 HTTP PUT 方式把图片上传到你自己的分布式文件系统，或者云文件系统。&br&2. 客户端得到刚才上传的图片的 URL（或者服务端事先已确定 URL告诉客户端往那传）&br&3. 客户端把 URL 使用 TCP 发给你的 epoll 服务器&br&4. 你的服务器可以把 URL 传递给其他人，让他们下载查看&br&5. 你的服务器还可以后台启动一个线程，用 HTTP 把图片下到本地，然后跑一些处理程序，再通知你的 epoll 主线程，事先要在 epoll 里面放一个 pipe，然后往里面写一个字节，唤醒主线程。&br&&br&----&br&HTTP PUT 是通用传文件协议，可以支持标准的 HTTP server，可以支持断点续传，可以用 HTTPS加密，还可以支持各种云服务器，分布式文件系统，别自己写个 TCP 来接收图片，实在图简单，可以本机起一个 HTTP收文件，客户端发好了通知下服务端，TCP服务端直接打开上传过来的本地文件。
客户端发图片过来的正确做法是： 1. 客户端先使用 HTTP PUT 方式把图片上传到你自己的分布式文件系统，或者云文件系统。 2. 客户端得到刚才上传的图片的 URL（或者服务端事先已确定 URL告诉客户端往那传） 3. 客户端把 URL 使用 TCP 发给你的 epoll 服务器 …
&a data-hash=&02877c4fde3b2e9dbd938f1a8eef598d& href=&///people/02877c4fde3b2e9dbd938f1a8eef598d& class=&member_mention& data-editable=&true& data-title=&@李博杰& data-hovercard=&p$b$02877c4fde3b2e9dbd938f1a8eef598d&&@李博杰&/a&的回答，写得很棒，已经回答得很详细了，我也来粗略说一下我的理解，有不妥之处还请指出。&br&
我自己对BBR的总结就是：终于转变了对“拥塞“这个概念的理解，经典的拥塞控制算法比如reno/newReno/Cubic无一例外都是将丢包作为拥塞的信号，然后降低发送速率。而在该算法中，不考虑丢包，而是基于这样一个定义：当网络上的包数大于BDP(带宽时延乘积)时，就认为出现了拥塞。所以重点就在于如何准确地测量出瓶颈链路的带宽和整个链路的传播时延。&br&在1980年设计拥塞控制算法的时候，将拥塞等同于丢包没有很大问题的，当时路由器的缓存小，链路带宽也不高。但是现在，路由器的缓存已经很大了，基于丢包的拥塞算法会一直增加窗口，直至把瓶颈路径上的路由缓存填满，然后出现丢包。但是，在这个过程中时延已经增大到我们无法容忍的程度了，所以需要反思这种基于丢包的拥塞控制思想。&br&
因为网络对TCP连接的两端来说是一个黑盒，没有明显的信息告诉我们说网络出现了拥塞(支持ECN的路由设备在现网中的普及率不高 )，所以我们只能通过反馈来推测的，这也就是为啥需要拥塞控制算法的原因之一了。&br&
这个算法的实现也有一个重大的思路转变，那就是不能仅仅只控制发多少包，也就是用拥塞窗口cwnd和慢启动门限值ssthresh来控制发包的多少，我们还应该控制发包的速率，所以pacing_rate成为主要控制因素。&br&
另外，这篇论文的出现也印证了我们的一个思路是可行的：丢包恢复和窗口管理解耦。如果我们发现有丢包，重传就好了嘛，至于发送速率如何调整，全部交给拥塞控制算法就好了。&br&&br&这里回答一下 &a data-hash=&fe2239f72aca1b951e521aaeb13fba81& href=&///people/fe2239f72aca1b951e521aaeb13fba81& class=&member_mention& data-editable=&true& data-title=&@行功& data-hovercard=&p$b$fe2239f72aca1b951e521aaeb13fba81&&@行功&/a&的几个问题。&br&&b&2. BBR的“测不准”是个什么鬼？&/b&&br&这里指的是RTprop和BtlBW不能同时测得。&br&&img src=&/v2-475d3abe12fbaeab382ad_b.png& data-rawwidth=&537& data-rawheight=&719& class=&origin_image zh-lightbox-thumb& width=&537& data-original=&/v2-475d3abe12fbaeab382ad_r.png&&RTprop指的是链路的传播时延，也就是等于路径长度 / 信号传播速率，只有在链路上没有任何排队和其他时延的时候，才能有RTT来近似。因此， inflight(在途数据包数)要小于BDP。而BtlBW是瓶颈链路的带宽，只有当发的包数&= BDP时，才能用发送速率来近似。因此这个两个值不能同时得到。从这幅图可以很清楚地看出，RTprop是当amout inflight & 最优点测得；BtlBw是 amout inflight & 最优点测得。&br&&b&3. BBR号称的primary control的探测带宽有用么？&/b&&br&首先我们要知道对于一条连接来说，它的可用带宽是什么，当它独占整个链路时，它的可用带宽就近似为链路的物理带宽，但多条流共享链路时，最理想最公平的肯定是BW/n。但是这个我们并不知道，只能通过一点一点地发包探测，比如可以先发快一点，发现出现拥塞了就发慢一点，这样反复探测直到收敛。就如下图所示：&br&&img src=&/v2-e8f666cc29cb9c2ff91350_b.png& data-rawwidth=&749& data-rawheight=&423& class=&origin_image zh-lightbox-thumb& width=&749& data-original=&/v2-e8f666cc29cb9c2ff91350_r.png&&&b&4. BBR到底是什么？&/b&&br&&blockquote&“BBR真正起作用是它放第二位的CWND=bw*PropRTT控制。“&/blockquote&这句话我不敢苟同。因为在论文中说的以pacing_rate作为主要控制手段。在内核代码中我们可以看到sock结构体中有一个域是sk_pacing_rate。&br&同时我们也看到tcp_bbr.c里有这么一段注释：&br&&blockquote& * NOTE: BBR *must* be used with the fq qdisc (&man tc-fq&) with pacing enabled,&br& * since pacing is integral to the BBR design and implementation.&br& * BBR without pacing would not function properly, and may incur unnecessary&br& * high packet loss rates.&br& */&/blockquote&并参考该链接：&a href=&///?target=https%3A//lwn.net/Articles/564978/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&TSO sizing and the FQ scheduler&i class=&icon-external&&&/i&&/a&里有这么一句话：&br&&blockquote&That transmission time is used to implement the TCP pacing support. If a given socket has a pace specified for it, FQ will calculate how far the packets should be spaced in time to conform to that pace.&/blockquote&所以我个人目前理解的是pacing是通过将sock中的sk_pacing_rate传递给FQ scheduler来实现的。由于我没有完全跟过这个代码实现的全过程，所以不能完全肯定pacing是如何具体实现的。但是可以看出用pacing来控制发包速率是完全可行的。
的回答，写得很棒，已经回答得很详细了，我也来粗略说一下我的理解，有不妥之处还请指出。 我自己对BBR的总结就是：终于转变了对“拥塞“这个概念的理解，经典的拥塞控制算法比如reno/newReno/Cubic无一例外都是将丢包作为拥塞的信号，然后降低发送…
TCP slow start.
TCP slow start.
很多人有一个误区，即认为TCP连接是通信的全部，其实并不是这样，让我们来复习一下TCP连接断开的过程。&br&&br&假定TCP client端主动发起断开连接&br&&br&1 client端的application 接受用户断开TCP连接请求，这个是由用户触发的请求，以消息的方式到达client TCP&br&&br&2 client TCP 发送 FIN=1 给 server 端 TCP&br&&br&3 server 端TCP 接收到FIN=1 断开连接请求，&b&需要咨询 application的意见，需要发消息给application，消息内容：对方要断开连接，请问您老人家还有数据要发送吗？&/b&如果有数据请告知，没有数据也请告知！然后就是等待application 的回应。既然需要等待application的回复，为何不早点把对client FIN 的ACK发出去呢？ 事实上TCP也是这么做的，收到对方的断开连接请求，立马发ACK予以确认，&b&client --& server 方向连接断开。&/b&&br&&br&4.1 如果 server端有数据需要发送，则继续发送一直到数据发送完毕，然后application 发close消息给TCP，现在可以关闭连接，&b&然后Server TCP 发FIN=1 断开 server --&client方向的连接。&/b&&br&&br&4.2 如果 server端没有数据发送，application回应close消息给TCP，现在可以关闭连接，&b&然后Server TCP 发FIN=1 断开 server --&client方向的连接。&/b&&br&&br&&br&如果我的答案对您有帮助，请投票支持我，非常感谢！&br&&a href=&/votes?domain=internet& class=&internal&&&span class=&invisible&&https://&/span&&span class=&visible&&/votes?&/span&&span class=&invisible&&domain=internet&/span&&span class=&ellipsis&&&/span&&/a&
很多人有一个误区，即认为TCP连接是通信的全部，其实并不是这样，让我们来复习一下TCP连接断开的过程。 假定TCP client端主动发起断开连接 1 client端的application 接受用户断开TCP连接请求，这个是由用户触发的请求，以消息的方式到达client TCP 2 client…
&b&首先，主机可否发送IP包全是FF的数据包？&br&可以的！&/b&&br&&br&第一步：假设一个主机发送出这样全FF的包，网卡使用&b&自己的硬件MAC地址做源&/b&，FF.FF.FF.FF.FF.FF做目的MAC&br&&br&第二步：凡是接收到此帧的设备网卡都会正常接收，默认其为广播地址，根据ether-type = 0x0800通知IP来处理&br&&br&第三步：IP模块先进行&b&“完整性检查”（Sanity Check)&/b&，主要针对关键字段如version、head of length、length、source IP、TTL、checksum看是否合法，IPv4 version 应该 = 4，IP包里为F，很显然检查失败，会被丢弃。&br&&br&同学们会说这些字段如果伪造的都是合法的，只有目的IP= 255.255.255.255=FF.FF.FF.FF，这就是一个正常的广播，比如DHCP Discovery就是这样的，路由器不会对目的“255.255.255.255”的路由转发，只会默默地丢。&br&&br&当然也不排除一些naive路由器基于IP包的目的IP“255.255.255.255”路由查找，最后匹配个默认路由“0.0.0.0/0”，发给自己的默认网关，只要默认网关不naive，还是会把这个广播包丢弃。&br&&br&&b&结论&br&这个广播包会在第一跳三层设备处被丢弃！&/b&
首先，主机可否发送IP包全是FF的数据包？ 可以的！ 第一步：假设一个主机发送出这样全FF的包，网卡使用自己的硬件MAC地址做源，FF.FF.FF.FF.FF.FF做目的MAC 第二步：凡是接收到此帧的设备网卡都会正常接收，默认其为广播地址，根据ether-type = 0x0800通知I…
在探讨这个问题之前，关于网络中的&b&Bufferbloat&/b&问题需要了解，详细信息在这里（&a href=&///?target=https%3A///url%3Fq%3Dhttps%253A%252F%252Fwww.bufferbloat.net%252Fprojects%252Fbloat%252Fwiki%252FIntroduction%252F%26sa%3DD%26sntz%3D1%26usg%3DAFQjCNHDs2WEHlt0FKGBusWyj-4xDLiKHg& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&https://www.bufferbloat.net/projects/bloat/wiki/Introduction/&i class=&icon-external&&&/i&&/a&），&a data-hash=&02877c4fde3b2e9dbd938f1a8eef598d& href=&///people/02877c4fde3b2e9dbd938f1a8eef598d& class=&member_mention& data-editable=&true& data-title=&@李博杰& data-hovercard=&p$b$02877c4fde3b2e9dbd938f1a8eef598d&&@李博杰&/a& 的回答也说得比较清楚了。&br&&br&在这里做一些补充吧。&br&流量控制分为两部分：&br&* &b&接收方的流量控制（即滑动窗口）&/b&-- 由接收方告知，只关注自身缓存情况，不关注网络，这里不讨论。&br&* &b&发送方的流量控制（即拥塞控制）&/b&&br&现在广泛使用的CUBIC/(new)Reno都是基于丢包的，在算法上重点输出拥塞窗口（cwnd）；&br&而BBR输出&b&cwnd&/b&和&b&pacing_rate&/b&，且pacing_rate为主，cwnd为辅，参考(&a href=&///?target=https%3A///d/msg/bbr-dev/bIIdBU4feD8/sfmbh4W_DgAJ& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/d/msg&/span&&span class=&invisible&&/bbr-dev/bIIdBU4feD8/sfmbh4W_DgAJ&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&)&br&&br&&b&什么是pacing？看下图：&/b&&br&&img src=&/v2-033f77e6f6ef_b.jpg& data-rawwidth=&981& data-rawheight=&573& class=&origin_image zh-lightbox-thumb& width=&981& data-original=&/v2-033f77e6f6ef_r.jpg&&&i&图片引用来自 QUIC @ Google Developers Live, February 2014&/i&&br&也就是说早期的拥塞控制输出cwnd只是告诉tcp可以发多少数据，而没有说怎么发，恰好，&b&BBR输出的pacing_rate就是告诉TCP怎么发&/b&。&br&&br&&br&&b&BBR对TCP的大胆改动：&/b&&br&&br&&br&&img src=&/v2-b742e172ed1ae802bab8ec_b.jpg& data-rawwidth=&563& data-rawheight=&328& class=&origin_image zh-lightbox-thumb& width=&563& data-original=&/v2-b742e172ed1ae802bab8ec_r.jpg&&红框中是BBR加入时添加的，这里很明显，BBR从TCP接管了充分的控制权。&br&之前的拥塞控制并不总是能起作用，换句话说就是会被夺权。TCP走进PRR算法（&i&参考论文：Proportional Rate Reduction for TCP&/i&）后，拥塞控制无能为力。&br&从工程实现的角度来看，BBR这个小小的修改把TCP的 &b&可靠传输&/b& / &b&拥塞控制&/b& 解耦了 —— TCP你专注于自己的可靠性（当然还有很多其它细节），我BBR总是会负责任地告诉你（TCP）现在可以发多少数据，以什么速度发出这些数据。&br&&br&&b&丢包对BBR有什么影响？&/b&&br&&img src=&/v2-2fe40d036eae2fe6f8f86_b.jpg& data-rawwidth=&928& data-rawheight=&481& class=&origin_image zh-lightbox-thumb& width=&928& data-original=&/v2-2fe40d036eae2fe6f8f86_r.jpg&&&br&&i&图片来自 BBR-TCP-Opportunities&/i&&br&从算法上来讲，丢包对BBR的影响微乎其微。BBR只管告诉TCP cwnd/pacing_rate，&b&不管需要发送的包是重传的还是正常发送的&/b&。看上图，丢包率在20%的时候BBR的输出骤降，导致这个现象其实是从实现层面考虑设置的一个&b&阈值&/b&。&br&&div class=&highlight&&&pre&&code class=&language-text&&/* If lost/delivered ratio & 20%, interval is &lossy& and we may be policed: */
static const u32 bbr_lt_loss_thresh = 50;
&/code&&/pre&&/div&这里还考虑了被限速的场景，不展开。&br&&br&&b&友好性测试&/b&&br&&a data-hash=&3ae27cc4dd3283eef8f3a& href=&///people/3ae27cc4dd3283eef8f3a& class=&member_mention& data-editable=&true& data-title=&@jamesr& data-hovercard=&p$b$3ae27cc4dd3283eef8f3a&&@jamesr&/a& 提到的友好性问题，google groups里有测试数据&br&&a href=&///?target=https%3A///d/msg/bbr-dev/zyvKgjjOYr8/pN20-CmVBQAJ& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/d/msg&/span&&span class=&invisible&&/bbr-dev/zyvKgjjOYr8/pN20-CmVBQAJ&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&----------------&br&10 Mbps link with 40ms RTT&br&带宽，RTT固定的情况下，测试不同Buffer大小的情况：&br&&div class=&highlight&&&pre&&code class=&language-text&&buf以n倍BDP表示，CUBIC/Vegas/BBR输出单位Mbps
(1) 1 CUBIC flow vs. 1 Vegas flow:
---- -----
(2) 1 CUBIC flow vs. 1 BBR flow:
---- -----
&/code&&/pre&&/div&说明：&br&Vegas是基于延迟的拥塞控制，现在几乎不用了，因为它们跟基于丢包的拥塞控制发生竞争时会处于几乎饿死的状态。&br&另外，关于Ledbat（基于延迟的）用于BT，是理所应当的（挂BT下载的急迫性一般是低于常规网络流量的，当有常规流量介入时，主动退避是符合常理的）。&br&&br&v------------更新--------------v&br&bbr-dev邮件组中一组测试数据（ &a data-hash=&844e274a5e578fac57e2d5d703b0863f& href=&///people/844e274a5e578fac57e2d5d703b0863f& class=&member_mention& data-editable=&true& data-title=&@Leo Zhang& data-hovercard=&p$b$844e274a5e578fac57e2d5d703b0863f&&@Leo Zhang&/a& 的回答中也提供了）引起了大家的关注。&br&最开始，Leo Zhang的回答所提到的测试报告我并未详细阅读。今天抽时间详细看了一下，感到意外。&br&比如出现BBR饿死CUBIC，BBR饿死同类。这和其它测试数据出入很大。&br&&br&我第一反应就是环境不对，BBR挑环境。然而这方面却没找到说明，BBR相关的文档都没有提到专用场景。&br&&br&接着， &a data-hash=&d69542bb0cae6daf4affca& href=&///people/d69542bb0cae6daf4affca& class=&member_mention& data-editable=&true& data-title=&@NeterOster& data-hovercard=&p$b$d69542bb0cae6daf4affca&&@NeterOster&/a& 抛出了另一个问题（&a href=&/question/& class=&internal&&如何评价文章《令人躁动一时且令人不安的TCP BBR算法》？&/a&）。看过文章（该作者之前的文章也看了），写了简答，才发现自己似乎错过了什么，同时自己其实也对20%的丢包率阈值设置有疑问，偷懒的理解就是大量测试统计的结果吧。&br&&br&这些天bbr-dev中关于BBR Report（&a href=&///?target=https%3A///forum/%23%21topic/bbr-dev/Ps4zyM5AD9g& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/forum&/span&&span class=&invisible&&/#!topic/bbr-dev/Ps4zyM5AD9g&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&）这份精彩的邮件列表我错过了，赶紧补一下！&br&Neal Cardwell 说到：&br&&blockquote&We are actively working on reducing the buffer pressure exerted by BBR,
which should help in the sorts of CUBIC vs BBR scenarios you describe
(as well as BBR vs BBR scenarios).&br&&/blockquote&这份刚刚诞生的拥塞控制的确还是存在不少缺陷，不过依然在持续改进中，期待美好的事情总会发生吧！&br&^-------------更新-------------^&br&&br&根据 &a data-hash=&02877c4fde3b2e9dbd938f1a8eef598d& href=&///people/02877c4fde3b2e9dbd938f1a8eef598d& class=&member_mention& data-editable=&true& data-title=&@李博杰& data-hovercard=&p$b$02877c4fde3b2e9dbd938f1a8eef598d&&@李博杰&/a& 的回答中已经提到的实测延迟改善数据，我们可以看到目前互联网整体上Bufferbloat问题是比较严重的，即我们的网络请求延迟总体被拉高很多。&br&为了降低延迟，如果：&br&1、我们改用基于延迟的拥塞控制，因为不可能一时间全部更新，先替换的那部分网络体验会很糟糕；&br&2、逐步改用BBR这类拥塞控制，我们的网络高延迟问题将会逐渐得到改善。&br&&br&以上并非说一定是BBR，但是BBR在拥塞控制上开辟了一条新的路（也许早就有人做过类似的尝试，但是因为工程实现，或者测试环境受限不能得到广泛验证，石沉大海），相信以后关于拥塞控制的研究改进更多会基于这条路去走。&br&&br&&b&最后，BBR是基于什么的拥塞控制？&/b&&br&根据论文，是基于拥塞的拥塞控制（Congestion-based Congestion Control），但是看起来感觉不好理解。&br&根据我的理解，我更倾向于称它为 基于带宽延迟的拥塞控制（&b&BDP-based Congestion Control&/b&）。&br&因为，BBR总是在测量最小RTT（10s内），最大Bandwidth（10 Round Trips），并且尽量控制输出到网络的数据包（in-flight）靠近 BDP（without buffer），这样既能保证带宽利用率，又能避免Bufferbloat问题。&br&&br&PS. BBR也已经被实现在QUIC协议中，参考（&a href=&///?target=https%3A//cs.chromium.org/chromium/src/net/quic/core/congestion_control/bbr_sender.h& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&cs.chromium.org/chromiu&/span&&span class=&invisible&&m/src/net/quic/core/congestion_control/bbr_sender.h&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&）。&br&&br&我也并非完全理解了BBR的实现细节，并且其中还牵扯到TCP的实现，也不熟悉。&br&如果以上理解有错，或者不到位，欢迎指正。&br&&br&完。&br&&br&---&br&XTao
在探讨这个问题之前，关于网络中的Bufferbloat问题需要了解，详细信息在这里（）， 的回答也说得比较清楚了。 在这里做一些补充吧。 流量控制分为两部分： * 接收方的流量控制（即滑…
1、请学会给 ssh 命令添加 -v / -vv 并理解输出信息；&br&2、请学会使用 netcat 工具并理解输出信息；&br&3、请阅读 TCP/IP Illustrated、翻阅 HTTP: The Definitive Guide 以获得必须的基础网络知识，帮助理解上述工具的工作原理。
1、请学会给 ssh 命令添加 -v / -vv 并理解输出信息； 2、请学会使用 netcat 工具并理解输出信息； 3、请阅读 TCP/IP Illustrated、翻阅 HTTP: The Definitive Guide 以获得必须的基础网络知识，帮助理解上述工具的工作原理。
已有帐号？
无法登录？
社交帐号登录