您现在的位置：首页 --> 查看专题： TCP
说道TCP滑动窗口协议，相信大家都很熟悉，但是说道 Window Scaling参数或许知道的和用过的人却不多，本文我们来谈谈Window Scaling的由来。
本文主要讨论如何设计一个可靠的RPC协议。TCP是可靠的传输协议，不会丢包，不会乱序，这是课本上讲述了无数遍的道理。基于TCP的传输理论上来说都是可靠的，但是实际这也得看场景。当我做网络游戏的时候也是一直把它当一个可靠的传输协议来用，从没考虑过TCP丢包的问题。直到当我面临像网络存储、机器学习这样领域时，我发现TCP变得“不可靠”了。
tcp_syn_retries：INTEGER。
默认值是5。
对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右时间。(对于大负载而物理通信良好的网络而言,这个值偏高,可修改为2.这个值仅仅是针对对外的连接,对进来的连接,是由tcp_retries1决定的)
上篇中，我们介绍了TCP的协议头、状态机、数据重传中的东西。但是TCP要解决一个很大的事，那就是要在一个网络根据不同的情况来动态调整自己的发包的速度，小则让自己的连接更稳定，大则让整个网络更稳定。在你阅读下篇之前，你需要做好准备，本篇文章有好些算法和策略，可能会引发你的各种思考，让你的大脑分配很多内存和计算资源，所以，不适合在厕所中阅读。
TCP是一个巨复杂的协议，因为他要解决很多问题，而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程，但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节，我还是推荐你去看W.Richard Stevens的《TCP/IP 详解 卷1：协议》（当然，你也可以去读一下RFC793以及后面N多的RFC）。另外，本文我会使用英文术语，这样方便你通过这些英文关键词来查找相关的技术文档。
前些天，一堆人在 TCPCopy 社区里闲扯蛋，有人提了一个问题：FIN_WAIT1 能持续多久？引发了一场讨论，期间我得到斌哥和多位朋友的点化，受益良多。 让我们热热身，通过一张旧图来回忆一下 TCP 关闭连接时的情况....
OSI (Open System Interconnection), 开放式系统互联参考模型。从下到上七层模型功能及其代表协议： 物理层(Physical) ：规定了激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。该层为上层协议提供了一个传输数据的物理媒体。Bit，比特。典型协议代表：EIA/TIA-232, EIA/TIA-499, V.35, V.24, RJ45, Ethernet, IEEE 802.3x(以太网) 物理层, FDDI(Fiber Distributed Data Interface, 光纤分布式数据接口) 物理层 。。。。
通过netstat命令，我们能获取TCP数据，监控它们有助于了解系统状态。 如果netstat版本比较老的话，那么运行时可能会遇到类似下面的错误信息： error parsing /proc/net/netstat: Success 假设操作系统是CentOS，首先让我们看看如何确认netstat隶属于哪个软件包。。
大部分程序员都听说过 TCP/IP 网络协议, 或者都写过 TCP socket 网络的程序, 甚至还学过 TCP 原理, 少部分看过 TCP 协议的某一个实现版本. 不过, 真正掌握 TCP 原理及思想的人, 我觉得不多. 只有理解了 TCP 原理及实现, 并且把它背后的思想和技术活学活用到其它的领域, 那才算是真正掌握了 TCP.
很多人常常对TCP优化有一种雾里看花的感觉，实际上只要理解了TCP的运行方式就能掀开它的神秘面纱。Ilya Grigorik 在「High Performance Browser Networking」中做了很多细致的描述，让人读起来醍醐灌顶，我大概总结了一下，以期更加通俗易懂。
SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，常用假冒的IP或IP号段发来海量的请求连接的第一个握手包(SYN包)，被攻击服务器回应第二个握手包(SYN+ACK包)，因为对方是假冒IP，对方永远收不到包且不会回应第三个握手包。导致被攻击服务器保持大量SYN_RECV状态的“半连接”，并且会重试默认5次回应第二个握手包，塞满TCP等待连接队列，资源耗尽(CPU满负荷或内存不足)，让正常的业务请求连接不进来。
面试一小伙，老生长叹的问题，介绍一下TCP flags，小伙说多了，SYN, FIN在ACK的时候需要占一个Byte的数据，而其他几个不需要。于是反问之，为什么不要？小伙支吾一阵说，可能是其他几个不重要吧。这个问题其实很简单，对于需要ACK确认收到的标记，需要占用一个Sequence值。例如，你发送一个仅有FIN没有数据的报文，TCP一定要确认收到一把，而这种确认只能通过sequence加加。这个同标记的重要与否无关。其他的Flag是单向的不需要确认，尤其对于ACK，协议设计上就不允许确认，因为如果ACK需要确认，则协议必然陷入死循环不可自拔。对于SYN, FIN由于需要确认，因此逻辑上是Data的一部分。其实TCP的多数option也是需要确认的，逻辑上也是data的一部分。但Option设计本身就有option级别的确认机制，不需要利用sequence在搞一把。
服务器上的一些统计数据：1)统计80端口连接数netstat -nat|grep -i "80"|wc -l2)统计httpd协议连接数ps -ef|grep httpd|wc -l3)、统计已连接上的，状态为“establishednetstat -na|grep ESTABLISHED|wc -l4)、查出哪个IP地址连接最多,将其封了.netstat -na|grep ESTABLISHED|awk {print $5}|awk -F: {print $1}|sort|uniq -c|sort -r +0nnetstat -na|grep SYN|awk {print $5}|awk -F: {print $1}sort -r +0n
网络防火墙会切断长时间空闲的TCP连接，这个空闲时间具体多长可以在防火墙内部进行设置。防火墙切断连接之后，会有下面的可能： 切断连接之前，连接对应的Oracle会话正在执行一个耗时特别长的SQL，比如存储过程而在此过程中没有任何数据输出到客户端，这样当SQL执行完成之后，向客户端返回结果时，如果TCP连接已经被防火墙中断，这时候显然会出现错误，连接中断，那么会话也就会中断。但是客户端还不知道，会一直处于等待服务器返回结果的状态。 切断连接之前，Oracle会话一直处于空闲状态，在防火墙中断之后，客户端向Oracle服务器提交SQL时，由于TCP连接已经中断，这时客户端侦测到连接中断，那么客户端就会报ORA-3113/ORA-3114这类错误，然后会话中断。但是在Oracle服务器端，会话一直在处于等待客户端消息的状态。
问题描述： 多隆同学在做网络框架的时候，发现一条tcp链接在close的时候，对端会收到econnrest,而不是正常的fin包. 通过抓包发现close系统调用的时候，我端发出rst报文, 而不是正常的fin。这个问题比较有意思，我们来演示下： 我们往baidu的首页发了个http请求，百度会给我们回应报文的,我们send完立即调用close. 然后我们在另...
John的总结是：TCP缓启动意味着网络延迟严格的限制了新链接的吞吐量。他针对这种情况给出以下的建议：非常小心的考虑每一个字节的内容考虑什么应该放在最前面的部分数据包保持你的cookie足够小在前面的三个数据包里为有用的资源打开链接先下载小的资源接受光的速度（使内容更贴近用户）
[ 共25篇文章 ][ 第1页/共2页 ][ 1 ][ 2 ]
近3天十大热文
-
[70] Twitter/微博客的学习摘要 -
[65] IOS安全–浅谈关于IOS加固的几种方法
-
[65] 如何拿下简短的域名
-
[65] find命令的一点注意事项
-
[63] Go Reflect 性能
-
[63] android 开发入门
-
[61] 流程管理与用户研究
-
[59] 读书笔记-壹百度:百度十年千倍的29条法则
-
[59] Oracle MTS模式下 进程地址与会话信
-
[59] 图书馆的世界纪录
赞助商广告
