TCP 连接，

标签：http   strong   数据   io   art   问题   html   代码   

建立连接：

1，在不在，收到么

2，在，收到么

1，收到

断开连接：

1，挂了啊

2，好

1，拜拜（挂了）

2，拜拜（挂了）

a,如果 1拨打了，然后2没有收到，然后 1会不遗余力的 拨打 5次，每次时间间隔还不同，总共 有63秒呢，最后还不通就放弃了，

b，2接通后，说了一句话 下线了，没有说 拜拜 就不说话了，然后 1 不遗余力的 用 63秒，

c，假如是并行的，我同时跟 10个人说话，必须分别记住他们 每个人，如果 10个都断开连接了，到时候 需要识别出来 他们分别是 谁，

d，1挂完电话 还需要等一会，因为 挂了，那句话 可能 发到 新接通的人 哪里，然后 就串了，但是 有一个问题 如果 连接 1000个的话，那么 断开 需要等多长时间啊，所以还是需要有数目时间的限制，

e,所以 让对方 挂电话，让对方等，哈哈，可以对方 总是不挂电话，

f,给你说了 十句话，你听了九句，拉下关键的一句，然后 我就重新说了一遍，

g,说了半天，没有说话，我就会以为 你没有收到，你后来说收到了，那 好吧，我说了两遍，

h,你需要告诉我 你一次 能 收到多少句话，以及 语速，不然 你说的多了你会消化不良的，

i, 关于攻击的时候 都是 我们 不知道对方 的状态的时候，

j,所谓的滑动窗口 就是 我可以接受几个 数据，

k, 你可以想像成一个MTU就相当于一个飞机的最多可以装的人，如果这飞机里满载的话，带宽最高，如果一个飞机只运一个人的话，无疑成本增加了，也而相当二。哈哈，坐飞机，传数据，

l,你发我发他发，然后拥堵了，完全处理不过来了，各种延时延时，如果网络上的延时突然增加，那么，TCP对这个事做出的应对只有重传数据，但是，重传会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，于是，这个情况就会进入恶性循环被不断地放大。试想一下，如果一个网络内有成千上万的TCP连接都这么行事，那么马上就会形成“网络风暴”，TCP这个协议就会拖垮整个网络

M,拥塞控制主要是四个算法：1）慢启动，2）拥塞避免，3）拥塞发生，4）快速恢复。这四个算法不是一天都搞出来的，这个四算法的发展经历了很多时间，到今天都还在优化中。 备注:

• 1988年，TCP-Tahoe 提出了1）慢启动，2）拥塞避免，3）拥塞发生时的快速重传
• 1990年，TCP Reno 在Tahoe的基础上增加了4）快速恢复

n，车拥堵 是怎样一回事，是 避免拥堵，还是拥堵后 处理呢，

nobody

Jacobson / Karels 算法

前面两种算法用的都是“加权移动平均”，这种方法最大的毛病就是如果RTT有一个大的波动的话，很难被发现，因为被平滑掉了。所以，1988年，又有人推出来了一个新的算法，这个算法叫Jacobson / Karels Algorithm（参看RFC6289）。这个算法引入了最新的RTT的采样和平滑过的SRTT的差距做因子来计算。 公式如下：（其中的DevRTT是Deviation RTT的意思）

SRTT = SRTT + α (RTT – SRTT)  —— 计算平滑RTT

DevRTT = (1-β)*DevRTT + β*(|RTT-SRTT|) ——计算平滑RTT和真实的差距（加权移动平均）

RTO= µ * SRTT + ∂ *DevRTT —— 神一样的公式

（其中：在Linux下，α = 0.125，β = 0.25， μ = 1，∂ = 4 ——这就是算法中的“调得一手好参数”，nobody knows why, it just works…） 最后的这个算法在被用在今天的TCP协议中（Linux的源代码在：tcp_rtt_estimator）。

TCP 连接，,布布扣,bubuko.com

TCP 连接，

标签：http   strong   数据   io   art   问题   html   代码   

原文地址：http://www.cnblogs.com/guligei/p/3873767.html