传输层
yang_oh
90后小学生
展开
-
TCP拥塞控制:从NewReno到PRR
在面临TCP丢包时,标准的拥塞控制[RFC5681]要求减小cwnd。本文描述的快速回复,也会减小cwnd,这种算法,通过DeliveredData:目前ACK表示的已经传给对端的总字节数。如果没在恢复阶段,DeliveredData表示snd.una的变化。使能SACK,DeliveredData将计算的更加准确,即用snd.una加SACKd的变化表示。在没有使能SACK的恢复阶段,每...原创 2019-06-19 21:54:27 · 1459 阅读 · 2 评论 -
TCP缓存设置及自调节
工作的原因,同事在单条流的性能测试中出现性能值低的问题,最后的问题点确认为缓存设置不合理。为什么要设置缓存?如何设置缓存?缓存和带宽时延积读缓存的上限应该由TCP接收窗口的最大值确定,过大或过小的接收窗口(通告窗口),都会造成网络问题。发送端可以发送的一窗数据大小,由拥塞窗口(cwmd)和通告窗口的最小值决定,如果接收窗口过小,将使发送端发送速度缓慢,即使再理想的带宽和网络状况,也无法增加连接...原创 2019-07-02 21:59:34 · 5418 阅读 · 0 评论 -
解析Snort的TCP流重组
关于TCP重组TCP报文段在网络中传输常见的问题包括,因丢包造成的重传,因网络情况造成的报文乱序,为增加性能重传更大的报文段造成报文重叠,等等,通常情况下,内核TCP协议栈会解决这些问题,保证应用层数据的可靠有序。但对于运行在非应用层模块例如传输层以下或不经过内核的功能模块,就应该考虑是否需要解决TCP重传、重叠、乱序等问题,例如这些功能模块希望http协议被正常解析,那么必然要解决上述问题。...原创 2019-07-11 23:04:17 · 3468 阅读 · 0 评论 -
谈TCP BBR拥塞控制算法
说是tcp拥塞控制,也不完全是,因为quic也使用bbr作为拥塞控制算法。quic当道,其而bbr发布前,也已经在google和youtube证明了其在吞吐和延迟上优良的性能,标准TCP的问题基于丢包的拥塞控制算法,来说标准TCP拥塞控制存在的问题。标准TCP将网络丢包的原因归结为拥塞,而忽略链路错误造成的丢包,这在高速网络环境中是不可取的。而传统的拥塞控制算法为了保证其公平性,采用了“加性增...原创 2019-07-17 00:48:46 · 13149 阅读 · 1 评论 -
谈Timewait和NAT环境下的TW快速回收
关于NAT后端服务端使能TW(Timewait)连接快速回收造成用户连接成功率降低的问题,来捋一捋。TW的意义对于主动关闭连接的一方,总是在FIN_WAIT2状态收到FIN并回复ACK(或在FIN_WAIT1收到FIN/ACK并回复ACK),因为回复的ACK无序列号无法得到对端的确认,所以主动关闭一方无法知道最后的ACK是否到达对端。所以主动关闭一端在回复ACK后进入TW状态,保留2MSL时间...原创 2019-07-21 13:31:42 · 1063 阅读 · 0 评论 -
一个问题引发的Linux端口选择算法思考
问题是这样的:在并发并不高的反向代理环境下,用户连接出现失败。因为服务器主动关闭上游连接,并处于TIMEWAIT状态,代理在新建上游连接时,复用了服务器上处于TIMEWAIT状态的五元组源端口。虽然代理上游客户端没有bind操作,但为什么代理上刚被释放的端口这么快又被复用了,查代码,原因是系统使用的某应用层协议栈在不bind端口情况下,采用random随机去选择端口,那么即使可用端口很多,仍存在刚...原创 2019-07-24 23:20:02 · 633 阅读 · 0 评论 -
QUIC随笔
说QUIC前,先说说TCP的拥塞控制。在短瘦管道的时代,小并发、窄带宽和短距离传输使传输层不用过多关注传输速率和响应速度,传输层需要做的是保证数据的可靠到达,有一定的带宽探测能力,保证多条连接之间的绅士(拥塞控制)和公平(AIMD),这也是RENO所实现的。随着网络的发展,管道由短变长,带宽由窄变宽,人们开始关注长管道的传输速度,因为管道变长,RENO基于ACK反馈的AIMD特性造成了慢启动速度慢...原创 2019-10-10 22:48:24 · 490 阅读 · 0 评论