在前面的内容中我们依次介绍了TCP的连接建立和终止过程和TCP的各种重传方式.接着我们在这部分首先关注交互式应用TCP连接相关内容如延迟ACK.Nagle算法.Cork算法等,接着我们引入流控机制(flow control)和关联的窗口管理(window management)过程.在开篇之前我们先介绍几个相关的概念. 交互式TCP连接(interactive TCP connection):交互式TCP连接是指用户输入需要在client和server间传递的这种.用户的输入可能是一次键盘按键或

一.SWS介绍 前面我们已经通过示例看到如果接收端的应用层一直没有读取数据,那么window size就会慢慢变小最终可能变为0,此时我们假设一种场景,如果应用层读取少量数据(比如十几bytes),接收端TCP有了少量的新的接收缓存后如果立即进行window update把新的window size通告发送端的话,发送端如果立即发送数据,那么接收端缓存可能又会立即耗尽,window size又变为0,接着应用层重复读取少量数据,这个过程重复的话,那么发送端就会频繁的发送大量的小包,这种场景我们就

一.TCP流控 之前我们介绍过TCP是基于窗口的流量控制,在TCP的发送端会维持一个发送窗口,我们假设发送窗口的大小为N比特,网络环回时延为RTT,那么在网络状况良好没有发生拥塞的情况下,发送端每个RTT就可以发送N比特的数据,发送端的速率应该与N/RTT成正比,因此通过改变发送窗口的大小就可以控制发送端的发送速率,那么接收端就可以通过控制发送端发送窗口的大小来控制发送速率.这样接收端需要有一种方式通告发送端接收端期望的发送窗口大小,这种方式就叫做窗口通告(window advertisemen

在这篇文章中我们看一下server端在接收到异常数据系列时的处理,主要目的是通过wireshark示例对这些异常数据系列的处理有一个直观的认识,感兴趣的自行阅读相关代码和协议,这里不再进行详细介绍 在进行下面的测试前,首先如下设置相关的参数,其中window参数指定了到127.0.0.2的tcp连接的最大接收窗口. root@Inspiron:/home/******/tcp12# ip route change local 127.0.0.2 dev lo window 40 一.wiresh

一.概述 我们在最开始介绍TCP头结构的时候,里面有个URG的标志位,还有一个Urgent Pointer的16bits字段.当URG标志位有效的时候,Urgent Poinert用来指示紧急数据的相对于TCP头中系列号Seq的位置,系列号和紧急指针值的和我们称呼为退出点(exit point).应用程序写入数据的时候可以通过MSG_OOB的socket选项来指定紧急数据.实际上因为紧急数据只有一个指针来指示并没类似长度的字段,因此紧急数据也只能有1bytes.RFC6093已经建议不要在继续使

一.简介 我们之前介绍过,TCP报文中的window size表示发出这个报文的一端准备多少bytes的数据,当TCP的一端一直接收数据,但是应用层没有及时读取的话,数据一直在TCP模块中缓存,最终受限于接收缓存的大小,window size会变为0,此时我们称呼这个接收窗口为零窗(zero window),对端也不能在发送更多的数据.如果随后本端应用层从TCP接收缓存中读取了足够数据,TCP模块有了足够的新的接收缓存的时候,就会发送一个TCP报文,并带有一个有效非零的Window size来指

一.概述 我们之前介绍过一种具有大的带宽时延乘积(band-delay product.BDP)的网络,这种网络称为长肥网络(LongFatNetwork,即LFN).我们想象一种简单的场景,假设发送端的发送窗口为5000bytes,网络的RTT为200ms,那么每秒的最大速率则为5000*(1000/200)=25000bytes/s,这大约为24kb/s,可以看到这个速率是非常低的,这就是TCP发送窗口对于发送速率的限制,实际的window size应该至少为带宽时延积才能高效的利用网络传输

一.Cork算法概述 Cork算法与Nagle算法类似,也有人把Cork算法称呼为super-Nagle.Nagle算法提出的背景是网络因为大量小包小包而导致利用率低下产生网络拥塞,网络发生拥塞的时候性能还会进一步下降,因此Nagle算法通过ACK确认包来触发新数据包的发送(ACK确认包意味着对端已经接收到了一个数据包,即有一个数据包已经离开中间网络,此时可以在向中间网络注入一个数据包块,这称呼为self-clocking).Cork算法则更为激进,一旦打开Cork算法,TCP不关注是否有收到A

一.Nagle算法概述 之前我们介绍过,有一些交互式应用会传递大量的小包(称呼为tinygrams),这些小包的负载可能只有几个bytes,但是TCP和IP的基本头就有40bytes,如果大量传递这种小包,会严重降低网络利用率,还可能造成网络拥塞.福特公司就曾经遇到过这种问题,John Nagle提出了一种通过ACK报文控制TCP发包的方法解决了这种问题,这种方法也就以Nagle名字命名,称为Nagle算法.Nagle算法最开始的标准为RFC896,但是RFC896目前已经被RFC7805移动到

一.简介 之前的内容中我们多次提到延迟ACK(Delayed Ack),延迟ACK是在RFC1122协议中定义的,协议指出,一个TCP实现应该实现延迟ACK,但是ACK不能被过度延迟,协议给出延迟ACK的最大时间为0.5s.如果发送端连续发送最大的数据报文,那么没两个数据报文就需要回复一次ACK.延迟ACK主要目的是等待接收者应用层接收到数据处理后有可能会发送一个响应,这样ACK报文就可以和这个响应报文一起发送了,这样减少了网络中的数据包的同时,也降低了主机的负载处理压力. 二.linux实现概

一.TCP选项概述 在前面介绍TCP头的时候,我们说过tcp基本头下面可以带有tcp选项,其中有些选项只能在连接过程中随着SYN包发送,有些可以延后.下表汇总了一些tcp选项 其中我标记为红色的部分是常见的TCP选项,我们仅针对这些红色的TCP选项进行介绍(主要是非红色的我也不太了解~~~),另外RFC1323已经被RFC7323取代,这里给出的是TCP选项原始定义的RFC 按照RFC793规定,一个TCP选项只需要单字节对齐,但是在实现上一般是两字节对齐或者会通过NOP选项实现四字节对齐,例如

TCP流量控制机制通过动态调整窗口大小来控制发送端的操作,确保路由器/接收端消息不会溢出. 交互式TCP连接 交互式TCP连接指该连接需要在客户端和服务器之间传输用户输入信息,如按键操作.短消息.操作杆或鼠标操作.对于这些操作,如果用较小的报文段来承载信息,则传输协议需要耗费很高的代价:反之采用较大的报文段则会引入更大的延时,对延迟敏感类应用造成负面影响.因此需要权衡相关因素来找到适合的方法. 以ssh(安全外壳)应用为例,对一个ssh连接,每个交互按键通常都会生成一个单独的数据报(每个按键独立

一.TCP连接的ISN         之前我们说过初始建立TCP连接的时候的系列号(ISN)是随机选择的,那么这个系列号为什么不采用一个固定的值呢?主要有两方面的原因 防止同一个连接的不同实例(different instantiations/incarnations of the same connection)的数据包混淆. 同一个连接的不同实例是怎么回事呢?之前我们说过(源IP.源端口号.目的地址.目的端口号)这个四元组唯一标识一个TCP连接,当一个TCP连接在经历四次挥手关闭时,假如有

我们在介绍TCP头的时候,提到过其中有个RST标志位.当一个TCP报文中这个标志位打开的时候,我们叫做reset包(严格的说应该叫做reset段,但是很多时候段包帧并不加以区分)或者简单称呼为reset.RST.通常reset的产生是由于一个异常包导致,reset一般会导致TCP连接的快速断开.产生reset的几种常见的情形如下 向一个未打开的端口发送连接请求 应用程序主动终止一个连接 应用程序还没有接收缓存中的数据,连接被提前关闭 TWA(TIME-WAIT Assassination) 半开

        经过前面对TCP连接管理的介绍,我们本小节通过TCP连接管理的状态机来总结一下看看TCP连接的状态变化 一.TCP状态机整体状态转换图(截取自第二版TCPIP详解) 二.TCP连接建立和终止过程中状态迁移总结 下面我们总结一下前面介绍过的连接建立方式和终止过程中client端和server端的状态切换 1.三次握手 client:CLOSED -> SYN_SENT -> ESTABLISHED server:CLOSED -> LISTEN -> SYN_RCVD

一.TCP连接管理概述 正如我们在之前所说TCP是一个面向连接的通信协议,因此在进行数据传输前一般需要先建立连接(TFO除外),因此我们首先来介绍TCP的连接管理. 通常一次完整的TCP数据传输一般包含三个阶段,分别是连接建立(setup).数据传输(established)和连接释放(teardown 也称为cleared 或 terminated).连接管理部分的主要内容则是TCP连接建立与连接释放的方式以及TCP连接状态(connection state)的管理,另外在建立TCP连接的过程

一.TFO背景 当前web和web-like应用中一般都是在三次握手后开始数据传输,相比于UDP,多了一个RTT的时延,即使当前很多应用使用长连接来处理这种情况,但是仍然由一定比例的短连接,这额外多出的一个RTT仍然对应用的时延有非常大的影响.TFO就是在这种背景下面提出来的. TFO(TCP fast open)是TCP协议的experimental update,它允许服务器和客户端在连接建立握手阶段交换数据,从而使应用节省了一个RTT的时延.但是TFO会引起一些问题,因此协议要求TCP实现

在前面的内容中我们介绍了TCP连接管理中最常见的三次握手方式和四次挥手的方式.但是有可能A和B两端同时执行主动打开并连接对方或者同时执行主动关闭连接(尽管发生这种情况的可能性比较低低),这个时候的流程就略有不同了.下面我们分别对同时打开(simultaneous open)连接和同时关闭(simultaneous)连接这两种情况分别进行介绍. 一.同时打开连接 同时打开连接是指通信的双方在接收到对方的SYN包之前,都进行了主动打开的操作并发出了自己的SYN包.如之前所说一个四元组标识一个TCP连

在前面部分我们我们分别介绍了三次握手.四次挥手.同时打开和同时关闭,TCP连接还有两种场景分别是半打开(Half-Open)连接和半关闭(Half-Close)连接.TCP是一个全双工(Full-Duplex)协议,因此这里的半连接"半"字就是相对于全双工的"全"来说的. 一.半开连接 从协议定义的角度来说,TCP的半开连接是指TCP连接的一端异常崩溃,或者在未通知对端的情况下关闭连接,这种情况下不可以正常收发数据,否则会产生RST(后面内容我们在介绍RST).比如

这部分内容涉及较多linux实现,可以跳过. 一.listen系统调用对backlog的处理 当socket处于LISTEN或者CLOSED状态时,fastopen队列的长度可以通过TCP_FASTOPEN选项进行设置. 对于listen的入参backlog,内核会限制backlog=min(backlog,/proc/sys/net/core/somaxconn) 如果当前打开了TFO的server端开关(tcp_fastopen的0x2有效),并且fastopen队列的最大长度还没通过选项设