TCP 连接,

建立连接:

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

时间: 2024-10-10 09:59:08

TCP 连接,的相关文章

如何在socket编程的Tcp连接中实现心跳协议

心跳包的发送,通常有两种技术 方法1:应用层自己实现的心跳包 由应用程序自己发送心跳包来检测连接是否正常,大致的方法是:服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包,然后启动一个低级别的线程,在该线程中不断检测客户端的回应, 如果在一定时间内没有收到客户端的回应,即认为客户端已经掉线:同样,如果客户端在一定时间内没 有收到服务器的心跳包,则认为连接不可用. 方法2:TCP的KeepAlive保活机制 因为要考虑到一个服务器通常会连接多个客户端,因此由用户在应用层自己实现心

TCP连接的状态详解以及故障排查

转载自CSDN博客:http://blog.csdn.net/hguisu/article/details/38700899 TCP状态 TCP状态迁移路线图 TCP连接建立三次握手 TCP连接的终止四次握手释放 同时打开 同时关闭 TCP通信中服务器处理客户端意外断开 Linux错误信息errno列表 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 了解TCP之前,先了解几个命令:   linux查看tcp的状态命令: 1).netst

解决不对称流量经过JUNIPER防火墙,tcp连接重置丢失问题

背景:公司网络增加一台JUNIPER防火墙,用于外网网关使用,其实配置上网配置很简单,配置完成后,外网连接测试也都正常,但在特殊的测试环境中会出现一种情况,该环境如图所示: 现象:当PC机的网关指定为防火墙的内网接口后(而不是核心交换机地址),当pc在telnet或者ssh连接10.10.2.*网段的服务器(网关在核心交换机上)等时,tcp连接均会在20s后重置.我的环境中其实存在一些问题的,就是流经防火墙的流量并不对称,其中pc→服务器的流量经过防火墙,而服务器→pc的流量不经过防火墙,造成的

TCP连接状态及TIME_WAIT

参考: TCP连接中的TIME_WAIT状态 - sunnydogzhou的专栏 - 博客频道 - CSDN.NET http://blog.csdn.net/sunnydogzhou/article/details/6572071 TCP连接状态详解及TIME_WAIT过多的解决方法_小强_新浪博客 http://blog.sina.com.cn/s/blog_8e5d24890102w9yi.html TCP协议三次握手连接四次握手断开和DOS攻击 - NowOrNever - 博客频道 -

TCP连接检测机制

采用TCP连接的C/S模式软件,连接的双方在连接空闲状态时,如果任意一方意外崩溃.当机.网线断开或路由器故障,另一方无法得知TCP连接已经失效,除非继续在此连接上发送数据导致错误返回.很多时候,这不是我们需要的.我们希望服务器端和客户端都能及时有效地检测到连接失效,然后优雅地完成一些清理工作并把错误报告给用户. 客户端采用如下步骤: 1, 连接 2, 拔掉网线 经过以上两步: 从上图中可以看到,此时服务端的连接依然存在. 所以,tcp只是数据的发送与接收,包括握手,断开以及rst,time_wa

服务器后台TCP连接存活问题

0. 背景 公司的服务器后台部署在某一个地方,接入的是用户的APP,而该地方的网络信号较差,导致了服务器后台在运行一段时间后用户无法接入,那边的同事反馈使用netstat查看系统,存在较多的TCP连接. 1. 问题分析 首先在公司内部测试服务器上部署,使用LoadRunner做压力测试,能正常运行,然后那边的同事反馈该地方信号较差.考虑到接入的问题,有可能接入进程的FD资源耗尽,导致accept失败.推论的依据是对于TCP连接来说,如果客户端那边由于一些异常情况导致断网而未能向服务器发起FIN关

TCP 连接与TCP keep alive 保活检测机制

生产环境中一台2核4G的linux服务器TCP连接数时常保持在5-7w间徘徊,查看日志每秒的请求数也就100-200,怎么会产生这么大的TCP连接数.检查了下客户端上行的HTTP协议,Connection 头字段是Keep-Alive,并且客户端在请求完之后没有立即关闭连接.而服务端的设计也是根据客户端来的,客户端上行如果Connection:Keep-Alive,服务端是不会主动关闭连接的.在客户端与服务端交互比较频繁的时候,这样的设计还是比较合理的,可以减少TCP的重复握手.显然如果只交互一

socket连接和TCP连接的关系

我们在传输数据时,可以只使用(传输层)TCP/IP协议,但是那样的话,如果没有应用层,便无法识别数据内容,如果想要使传输的数据有意义,则必须使用到应用层协议,应用层协议有很多,比如HTTP.FTP.TELNET等,也可以自己定义应用层协议.WEB使用HTTP协议作应用层协议,以封装HTTP文本信息,然后使用TCP/IP做传输层协议将它发到网络上. 1)Socket是一个针对TCP和UDP编程的接口,你可以借助它建立TCP连接等等.而TCP和UDP协议属于传输层 . 而http是个应用层的协议,它

tcp连接、断开过程

TIME_WAIT状态在等2MSL后closed,存在的原因:1.ack n+1可能丢失,FIN N超时重发,如果不存在time_wait状态,则C端下次收到会响应RST报文,S端收到则会解释为是错误.因而,要实现TCP全双工连接的正常终止,必须正确处理终止过程中四个分节任何一个分节的丢失情况,主动关闭连接的A端必须维持TIME_WAIT状态 . 2.允许老的重复分节在网络中消失(消失前不允许启动新的化身).比如在没消失前启动一个新连接,那么老连接的一些报文可能在新连接的时候到来,这个时候就会发

TCP连接解释及连接过程描述

1.TCP连接的建立 设主机B运行一个服务器进程,它先发出一个被动打开命令,告诉它的TCP要准备接收客户进程的连续请求,然后服务进程就处于听的状态.不断检测是否有客户进程发起连续请求,如有,作出响应.设客户进程运行在主机A中,他先向自己的TCP发出主动打开的命令,表明要向某个IP地址的某个端口建立运输连接,过程如下: 1)主机A的TCP向主机B的TCP发出连接请求报文段,其首部中的同步比特SYN应置1,同时选择一个序号x,表明在后面传送数据时的第一个数据字节的序号是x. 2)主机B的TCP收到连