关于TCP协议的讲座的一部分

关于TCP协议的讲座的一部分
tcp协议的部分解析
解释uff1a

1)。本文分析了tcp的发展很容易造成混乱和误解。

2)。本文将不坚持大量的源代码,大部分是以文本的形式编写的,我相信文本看起来比代码更轻松。

3)。目标:对TCP有全面了解的人,因为本文不解析TCP头中的每一个字段或3次握手的细节,所以不能解释慢启动和快速重传的定义。

4)。除了TCP/IP(第一卷,第二卷)和UNIX和Linux网络编程源代码,学习网络资源更好的是RFC

5)。本文给出了一个概要,如果您想了解详细信息,请直接参考RFC。
6)。备忘录是根据这份备忘录的修订最终找到的。
1。网络协议设计

ISO提出了OSI分层网络模型,该模型是基于理论的。TCP/IP最终实现了分层协议模型。每个级别对应于一组网络协议来执行一组特定的函数。网络协议在其层次上被重用和重用,这是分层模型的本质,最终所有的逻辑都被编码成电缆或电磁波。

层次模型是很好理解的,但对各层协议的设计不是那么容易的。TCP / IP的好处是更复杂的协议去上水平。我们的网络被定义为相互关联的网络设备、角色或端到端的;沟通,但是希望相互通信的设备不能直接连接在一起的,所以他们会需要一些中间设备负责转发数据,所以这些设备电缆运行协议定义的链路层协议之间的连接,和事实上的链接实际上是启动装置通过一根线,终止于另一个设备。我们称之为链接一跳;所以端-端N网络包含许多跳;

2.tcp和IP协议

为了终止IP协议,我们已经能够完成端到端的通信,为什么我们需要TCP协议呢这是个问题。如果我们理解这个问题,我们就可以理解为什么TCP协议已经成为现在的形式,为什么它是如此的复杂,为什么它这么简单。

正如它的名字所示,TCP的功能传输控制,即控制端到端的传输。为什么这个控制不在IP协议中实现答案很简单,这将增加IP协议的复杂性,而IP协议需要简单,原因何在

首先我们知道为什么IP协议是腰部。它是链路层协议较低的范围内,链接提供语义相互不同的远,为了连接这些异构的网络,我们需要一个网络层协议提供至少一些自适应功能,它不会提供太多的保证服务由于上。确保在较低的限制更多的依赖,你将永远不会在IP协议上面的链路吞吐量保证千兆吞吐量达到100…

分组转发协议IP协议的设计,每一跳都必须通过一个中间节点,路由设计的又一重大举措,TCP / IP网络,IP协议没有方向,和路由信息协议本身是不牢固的联盟,他们只是通过IP地址关联,因此,该IP协议更简单。路由器也不是作为一个中间节点太复杂,涉及到成本问题,所以路由器负责路由和转发数据包只。

因此,传输控制协议必须在终点实现。在我们讨论TCP协议,第一要看它能做什么,因为IP协议不提供担保的,TCP不能提供IP依赖较低的环节保证,如带宽、延迟等,这些都是数据链路层的决定,由于IP协议是不可修复的,TCP是不,但它可以在一些IP校正层;不能保证的特性;这些特性包括IP层,IP层是不可靠的,不按照顺序,没有方向/ IP无连接层。

本节将介绍TCP / IP模型,从底部增加到顶部的功能,需要执行的设备,减少设备的复杂度,然而,在上升,这保证了成本的最小化,或性能的因素,依靠软件来调整它,TCP协议软件,其实一开始,TCP不考虑性能、效率和公平,是要考虑这些,只有复杂的TCP协议。

3.tcp协议

这是一个纯软件协议。为什么我们要设计两个端点让我们看最后一节。本节详细描述TCP协议,中间有一些简短的讨论。

3.1.tcp协议

确切地说,TCP协议有两个身份。作为一种网络协议,它弥补了IP协议尽力而为服务的不足,并依次实现了连接、可靠传输和消息到达,作为主机软件,与主机服务和网络的UDP协议和传输层协议相分离。他们可以被视为一个多路复用器/解复用器、可复用和复用多个主机处理数据到IP层。可以看出,无论从哪个角度,TCP作为界面的存在,作为网络协议,并对端TCP接口,实现TCP的控制逻辑,为多路复用器/解复用器,和较低的IP协议的接口协议栈的功能,这是网络分层协议模型的基本概念(两类接口,和较低的接口,另一类与对等层接口)。

我们习惯了TCP协议栈的顶部,而不是部分的应用层协议的协议栈,这部分是因为在应用层的TCP / UDP复用,呈现出非常复杂的情况下,应用层协议以不同的方式,不同的解释,在使用类似的天冬酰胺习惯的应用层协议。1标准包装,体现了作为复用/解复用器的TCP协议的重要性,由于直接和应用程序接口,可以很容易地应用直接控制,实现不同的控制策略的传输,这就是为什么TCP不从应用程序的地方太远的原因之一。

总之,TCP的主要观点有四,一是连接,二是可靠的传输,三是到达一致的数据,四的端到端的流量控制。注意,TCP的设计不仅保证了四点这段时间,虽然它也存在一些问题,然而,很简单,但更大的问题很快就出现了,它不得不考虑和IP网络相关的东西,如公平、效率,从而增加了拥塞控制,TCP就变成了现在这个样子。

3.2。有一个连接,一个可靠的传输,并且数据按TCP的顺序到达。

IP协议不是数据报传输方向可达到结束所有的路由,因此它是一个跳到最后,只要没有达到跳路由端,然后数据传输会失败,事实上,是一个核心的互联网路由,基本有两种功能在IP核心层首先是地址管理,二是route.tcp利用IP路由功能简单,所以TCP没有考虑路由,这是另一个原因,它的目的是端到端的协议。

现在,IP已能作单独的数据报到达另一端,TCP可以实现其他更严格的控制功能的这一努力network.tcp添加连接无连接的IP网络通信,确认已发送数据的状态,并保证了数据的顺序。

3.2.1。已连接

这是基本的TCP,因为传输可靠性和数据序列依赖于连接,这是最简单的方法,因此TCP被设计成基于流的协议,因为TCP需要建立连接,那么传输数据的数量并不重要,只要相同的连接可以识别数据。

1:3握手难杂病4波

TCP使用3次握手建立一个连接,初始化握手传输的可靠性和数据序列是必要的,对这些信息的两个方向的初始序列号,由初始序列号生成的确认号码,使用3次握手是因为3次握手准备必要的传输的可靠性和数据序列第三次握手信息,不需要单独的传输和数据传输,可以在一起。

3.2.2。传输的可靠性

基本上,传输可靠性是通过确认数来实现的。也就是说,在发送一个段时,接收方必须发送一个确认。发送确认后,下一个字节可以发送。这一原则是最简单的,教材上的停止等待这是字节的协议版本的原则,只是一个TCP滑动窗口机制使得每次使用不需要发送一个字节,但这是什么部分只确认超时机制。

你怎么知道数据到达另一端那就是发送一个确认到最后,但是发送端要等多久才能收到对方的确认呢如果您等待很长时间,您将无法找到数据丢失。该协议将不可用。如果等待时间太短,可能仍在路上。所以等待时间是个问题。另外,如何管理加班时间也是一个问题。

4:超时计算疑难疑难杂症

它猜想的超时时间将是绝对不可能的,但一个精确的算法应该给予计算。毫无疑问,答复的时间到一个TCP段报文往返时间,所以标准定义了一个新的名词RTT,代表一种TCP报文段的往返时间。然而,我们知道IP网络是最好的,而路由是动态的,而路由器没有警告或缓存丢弃任何数据,所以这是RTT动态测量,也就是说至少在固定的时间间隔来测量时间,如果每次都是一样的,但世界是不是一切都会好的。如果你想要一个,所以我们需要找到它;平均值,而不是一个精确的值。

平均值如果仅通过计算多个测量值直接取算术平均值,则是不合适的,因为数据传输延迟、瞬时抖动延迟路径我们必须考虑,或者如果两个测量值分别为2和98,那么超时值将为50,这个值太大,为2。因此,数据的延迟太大(重传在等待重发之前的长时间等待),但是,太小,导致过度的重传(距离,这是非常慢的,大量重传的结果已经被正确确认,但是是一个延迟的TCP段)。

因此,除了考虑每种测量偏差的变化率也应该考虑到,如果变化的幅度过大,通过独立的函数计算RTT的变化率(如果突然增加,则值是正的,比较大,如果突然降低,价值相对小的负。然后平均加权和)如果变化率很小,然后进行平均测量,这是不言而喻的,这种算法仍然工作得很好。

5:疑难杂病管理-连接超时定时器每定时器

显然,这是为每个TCP段生成计时器的最直接的方法。每一个定时器RTT时间到期后。如果没有收到确认,它将重发。然而,这是唯一合理的理论。对于大多数操作系统来说,它会带来巨大的内存开销和调度成本。因此,为每个TCP连接设计一个单独的计时器是一个默认的选择,但是单个定时器如何管理发送这么多TCP段呢以及如何设计一个计时器。

设计单个计时器有两条原则。1,每个消息都必须能够超过时间限制时,它是无法长期公认的;2,它不能从长期的RTT分离。因此RFC2988定义了一组非常简单的原则:

当A.发送TCP段时,如果未打开重传计时器,则打开它。

当B.发送TCP段时,如果重发计时器已打开,则不再打开。

当C.收到一个冗余ACK,如果有数据在传输,重开重传定时器。

当D.接收到一个非冗余ACK时,如果传输中没有数据,则重传定时器被关闭

让我们看看这4条规则是如何实现以上两点的。根据A和C(在C中,我们注意到ACK不是冗余的),只要没有被识别,任何TCP段都会过时。但是为什么需要C只有一个存在的规则实现规则1可以。事实上,这是它,而不是过早的重传,添加规则,如果没有规则,所以如果在发送数据的重传计时器到期,所以当定时器到期时,除了将数据发送到接收ACK很早后来,其他数据传输的ACK不来,所以这些数据将被重传。后一个规则,只要有一个分段ACK的到达,然后复位重传定时器,它是合理的,因此大多数正常的情况下,从数据到这个时间的到来和ACK计算RTT重发定时器的超时时间和三者之间的区别不是复位的ACK计时器可在预保护数据到来后成熟的重传。

9:TCP序列疑难疑难杂症

TCP序列号包会导致很多问题,如序号为一段M秒后,序列号,S小于J段发出,但此时J上的一圈,这是解决问题的,所以如果这一段接收端,这将导致完全无序的原始J后面,但结果抵达前,这种疾病是查不出来的TCP协议。我们认为这不会发生,分割的数据不是一个字节一个字节的发送出去,如果有一个速率1Gbps网络,TCP发送端发送一个二125mb数据,32位序列号空间可以传输2方的话的32倍,即32秒会发生,我们知道这个值远小于MSL值,它会发生。

一个细节可能会引起误解,也就是说,TCP窗口的大小是序列号空间的一半。所以,正是在满负荷,数据可以填补发送窗口和接收窗口,和序列号空间是足够的。但事实上,TCP的初始序列号是不是从0开始,但随机生成的(当然,一些更复杂的算法),所以如果初始序列号接近32的2倍,然后迅速完成。

当然,现在可以使用时间戳选项帮助作为识别序列号的一部分,接收机附近遇到的情况,需要比较时间戳,我们知道时间是单调递增的,虽然也会包,不过时间要长得多。这只是一种策略,有没有它的细节。这是一个很现实的问题,序列号的理论总结,但事实上,有许多TCP端点主机直接安装在两侧的电缆网络1G和接收方和发送方的窗口也会同时填充。此外,即使有一个包,是不是一个特殊的东西,包装内的电脑太常见,只需要能够识别可解决,TCP序列号,在高速网络(点对点网络和以太网)在数据两端,这种疾病的可能性很小,所以当收到一个序列号突然改变了序号为0的小于的情况序号的开始或终止,容易识别,和只需要在一个分段的比较可以确定,如果在两终端网络路由器,重新排列顺序将导致IP,TCP,虽然包装也会出现,慢得多,并且考虑到拥塞窗口(尚未推出)一般不会太大,很难被填充到窗口65536。

3.2.4。端到端流量控制

采用滑动窗口实现端到端的流量控制,滑动窗口的原理非常简单,基本上是生产者/消费者模型。

10难杂病:流量控制的真谛

很多人认为交通管制协调会非常有效的流程结束,这是真的,但如果你考虑到网络的利用率,TCP的流量控制机制不完善,是造成这种局面的原因,滑动窗口就限制了最大的数据传输,在最小传输数据没有限制,导致一些很小的数据被封装在TCP段,分组头的比例过大,网络利用率下降,导致下面的内容,这是端到端的TCP协议效率的意义。

~~~~~~~~~~~~~~~~~~~~

形成承上启下的纽带

最后,是时候解释这个问题了。上述tcp协议的实现非常简单,也是tcp的标准实现。然而,我们会发现各种各样的问题,很快,这些问题导致了TCP协议的标准化协会修复,这些修复都混合在一起,让一些人用来不知所措。本文档的目的是将这些混乱的情况,而事实上,根据RFC,这些混乱的情况找到自己的发展轨迹。

~~~~~~~~~~~~~~~~~~~~
4意义上的tcp协议效率。端到端

4.1要解决的三个问题与对策。

问题1描述:接收端处理缓慢,导致接收窗口被填充。

Linux的TCP实现这个问题上更加灵活,它可以发出这样的判断(在打开Nagle的情况):

如果(拥塞窗口的大小不超过数据段翅片包含无法识别的| |数据段)

数据分割不超过窗口边界

然后

The IF section in the middle (in the case of section 1 and 2) ||

这部分是| |急救模式

通过上述Nagle算法(改进的Nagle算法)

然后发送段

endif

endif

我已经改变了Nagle算法,而不是修改Nagle算法,但修改了在结束时,它可以发送数据到过去的策略是发送者确定是否发送数据,但是如果有一个延迟等待交付和要发送的数据并没有因的积累或其他原因无法发送,所以双方,在某些情况下,这是很不好的。我做的改善时,发送的数据被添加到的情况是,香格里拉;确认;确认,一旦等到法官的传输没有等待发送,如果任何数据,看是否在这在一定程度上,数据,我选择了MSS的一半:

如果(拥塞窗口的大小不超过数据段翅片包含无法识别的| |数据段)

数据分割不超过窗口边界

然后

如果在中间部分(在第1和2的情况下)| |

这部分是| |急救模式

通过上述Nagle算法(改进的Nagle算法)

然后发送段

endif

否则如果有延迟ACK等待传输

要在发送队列中发送的TCP段。

发送队列的头部大小是MSS的一半以上。

然后发送队列头分段和捎带延迟ACK

endif

此外,在发送队列头可以在统计意义上的动态计算的大小,而不是一半的MSS大小。我们发现,该算法是自适应的交互式网络应用,你打字越快,具体时间积累段更长,更迅速地结束回复(可搭载ACK),发件人是非常快的(回波例如将更好地理解)。

14:疑难杂症TCP / IP的详细实例解释(卷1)算法在Nagle

这个问题在互联网上有很多答案,有人说RFC的建议,有人说,但实际上,这是一个典型的种族问题;

首先,服务器发送两段:

数据段12:ACK 14

13:14的ACK数据段,54:56

然后客户端发送两段:

数据段14:确认54、17

15:56的ACK数据段,17:18

你可以看到,14的数据段应已确认56,但确认是54。也就是说,数据已经从队列中被发送但尚未发送的数据段13,软中断处理程序抓住数据段14的发送过程,知道这只是14个数据段从队列中移除,但更新任何状态信息,如但分段的数字还没有确定;此时,软中断处理成功接收13部分程序,然后更新窗口信息,看看有没有数据被发送,因为14节已从队列中删除,发送和接收的检查是15节,因为使用状态信息尚未更新,所以顺利通过15段发送测试,发送完成。

最后,数据包丢失的延迟也加剧了拥塞,假设TCP连接通过N路由器,第一n-1路由器可以平滑地传输TCP段,但最后一个路由器丢失一段,导致这些丢失的部分浪费了先前路由器的大部分带宽。

5.2。拥塞控制策略

在拥塞控制的介绍,介绍了拥塞窗口,它实际上说的是有多少数据可以发送到然而,通知和接收端的接收窗的意义是不一样的,流量控制的窗口,而前者是拥塞控制窗口,反映了网络拥塞程度。

拥塞控制大体上分为两类:一类是探索性拥塞检测,另一类是拥塞避免(注意,而不是传统意义上的拥塞避免)。

5.2.1。探索性拥塞检测分为两类,一类是慢启动,另一类是拥塞窗口加性扩展(称为拥塞避免),但这种方式无法避免拥塞。

第5.2.2。拥塞控制,拥塞控制也没有发生拥塞的第一警报发送端,网络拥塞,使发送者可以进入快速重传、快速恢复或明显减少拥塞窗口,以网络拥塞混乱出现后避免加班,进入慢启动阶段。

5.2.3。快速重传和快速恢复,快速恢复所谓的快速重传/是缓慢的开始,我们知道从1 MSS增加拥塞窗口的慢启动、快速重传、快速恢复是一次收到3冗余ACK,不必进入慢启动,但会降低一半的当前拥塞窗口阈值加3,然后如果你继续收到ACK冗余,拥塞窗口将增加1个MSS,直到它接收到一个新的数据集,ACK窗口开始正常值,加增阶段。

当进入快速重传时,为什么应该将拥塞窗口减少到当前阈值的一半加上33是基于包的保护,因为它已收到3个重复ACK,有三个数据段到达接收端,由于三段已经离开网络,所以可以在3段发送,刚刚收到一个重复ACK,这也表明1的一部分已经离开网络,所以拥塞窗口加1 MSS。直到新收到ACK,表明发送的ACK周期第三端的TCP报文段到达另一端直至正常阶段开始增加拥塞窗口。

17:疑难杂传重发,应答后接收3冗余重传。

两重发的意义是不同的,重传超时通常是由于严重的网络拥塞(不分段的到来,如果有,肯定会有确认,如果确认,则重传定时器的复位,如果冗余ACK可以重新排序或单个丢包。如果连续3个重复ACK,很可能是个人部分损失),需要减少拥塞窗口比较严格,所以在这个时候进入慢启动阶段。收到3个冗余ACK表明有丢失的中间段,但后面的分段确实在接收端,这是因为这将发送冗余ACK,这通常是由路由器故障或轻度充血或其他不太严重的原因引起的,所以,范围较窄的拥塞窗口不太大,此时进入快速重传和快速恢复阶段。

18:为什么冗杂疾病在冗余重发后接收到3个ACK

这是一个结构之间的权衡,接受两个或两个ACK也可以冗余重传,但这些话可能或造成不必要的重传,因为数据段障碍两种可能性不超过三段紊乱发生的可能性,换句话说,如果只收到了一个障碍,可能是分段的,的中间路由器重排,然后另一段可能马上就到了,然而,如果连续收到3段未能弥补,它很可能会丢失,需要重传的缺陷。因此,3个重复ACK是不必要的重传的减少和单段损失实际检测之间的权衡。

注意,ACK不仅仅是冗余。

19:疑难杂病减少,加性增加深层意义。

乘法和加法为什么会增加拥塞窗口的增加只是自我利益的增加,拥塞窗口降低了每个人的利益,但这本身就是一种伤害,更重要的是什么呢我们知道TCP的拥塞控制是公平的,确切地说,这种乘法减少是公平的,拥塞窗口的1个MSS变化影响了TCP发送方。为了减少拥塞窗口对TCP发送者的影响,使发送者获得更多的好处,采用了一种减少乘法的策略。

当然,BIC算法提高了添加剂提高效率。MSS算法不是一次增加一个MSS,而是一次增加更多的MSS,通过增加两点查找逐步发现该点而不会丢失数据包。

什么是传输稳态疑难杂波20:TCP连接

首先,让我们来讨论如何确定发射机的发送窗口。它以拥塞窗口和接收端通知窗口的最小值为基础,给出了三个传输窗口的稳定状态:

对a.ip网络接收大窗户的经典锯齿

对b.ip网络小窗口的接收机的线性状态

直接连接网络端点之间满负荷状态的线性状态

一是大多数人的状态,因为在一般情况下,TCP连接的建立在互联网上,其中也有很多,如网页浏览、电子邮件、网络游戏、FTP下载等on.tcp发射机采用慢启动拥塞或避免增加拥塞窗口,直到发生损失,然后输入慢启动和拥塞避免阶段(见是由于超时包丢失或由于数据包丢失,重复ACK)发送窗口会下降至下降1或一半,在这种情况下,一般的接待窗口是比较大的,毕竟,IP网络不快机网络是什么,一般的处理速度快。

但如果接收器坏了,处理速度慢,这会使它宣布一个小窗口,这样即使拥塞窗口较大,发送端将使用通知窗口的发送窗口,所以不会发生拥塞。最后,如果TCP连接在直两机运行,那么它将独家网络带宽,所以在最好的情况下,TCP数据流将填补管道网络(我们的管道网络的定义是带宽和延迟的产品),事实上,在这种情况下,没有拥挤你,喜欢一个人独自徘徊在喜欢下雨黄昏的街道…

5.2.4。主动拥塞避免

我们描述了拥塞控制方法的初步检测,然后拥塞窗口的被动的乘降,所以在接收窗口的下一个大的(一般是这样,网络拥塞,段不会轻易到达接收端的大量空置的窗口接收端)会出现锯齿时间窗地图,类似北京X环上了车,拥挤的车,发射开始,停止,等待,发动机,汽车的声音可以听出来…

虽然TCP不能看到下面的IP网络,它仍然可以通过检测RTT的变化和拥塞窗口的变化计算IP网络拥塞。例如,北京东第四环的快递公司要送快递到西第四环路不断。当发货人发现货物到达时间越来越慢时,他就会意识到,高峰时刻即将到来。

拥塞窗口的大小可以通过RTT连续观测的积极调整,而不是一味的加增。但还有一个更强大的算法,是计算两差值的产品:

(当前拥塞窗口-最后的拥塞窗口)x(当前RTT当前RTT)

如果结果是正的,拥塞窗口减少了1 8,如果结果为负数或0,那么将一个MSS添加到窗口。可以看出,约化比乘法约化小。这是因为拥塞控制是主动而非被动的方式探索之前,在测试模式下,在惩罚的方式实现公平乘降,与活动方式,当意识到拥塞,发送端的TCP主动减小拥塞窗口,为了鼓励的略有减少拥塞窗口的方式自首。需要注意的是,在减少拥塞窗口的过程中,在产品差异性是负的,如果不同的是否定的,那么结果是减少或缓解拥塞窗口,直到窗口减小到一定程度,要数做差是0,在这种情况下,在事实上,在差异只能改为0。

21:路由器与TCP之间的交互疑难疑难杂症。

尽管在5.2.4节主动拥塞检测,可以帮助检测拥塞的路由器吗你知道这个扩展的路由器是必要的,,有无数的TCP通过每天去一个路由器,但路由器的TCP协议无论什么(当然,排除连接跟踪等,这里是IP路由器的标准),但它可以在一个非常简单的方式告诉IP TCP网络拥塞发生的两端,这种方式是当路由器检测到你的轻微拥塞随机丢包,而TCP连续丢包随机丢包是显著的,随机丢包会使TCP发现丢弃的分割和随后的其他部分仍然会在接收端,发件人将收到此TCP 3冗余ACK,然后进入快速重传和快速恢复RA慢启动比慢启动。

这就是路由器可以为TCP做的事情。

6。其他

22:如何学习TCP疑难疑难杂症

很多人发帖TCP相关的内容要求,其次要让碎片看到TCP / IP。和UNIX网络编程一个特定的区域内,我认为这个答案是非常不负责任的。因为我不认为这两本书有很大帮助,写的很好,但我们可以看到,Richard Stevens是一个实用主义者,他喜欢用实例来解释一切,解释是充满了游戏的tcpdump,这种方式适用于TCP的人的理解,但大多数人不理解。

如果你想从设计的观点来看,这两本书都很好。我认为我们应该先看一些介绍性的,如维基等等,然后看RFC文档,7938961122,等等,这样你可以看到为什么TCP的设计是这样的,你永远不会得到它Richard Stevens的书。最后,如果你想的话,那么看Richard Stevens的书,最重要的是写代码或敲点命令,然后分析自己捕捉。

23:linux windows网络编程疑难疑难杂症。

我想在Linux上写一点TCP代码很好,如果有BSD,这样更好。不建议用Winsock学习TCP。尽管微软声称它的API是使事情变得更容易,它实际上是更复杂。如果您从Winsock学习,您将花很多时间掌握与网络编程无关的东西,但在Windows平台上不可或缺的东西。

6.1。总结

TCP协议是端到端协议。虽然它是与流量控制和拥塞控制协议,正是因为这些所谓的控制,TCP变得复杂。同时,这些特性是相互混合,流量控制带来了很多问题,解决这些问题最终带来了新的问题的解决方案,及时解决这些问题只考虑端到端的意义,但事实上,TCP需要IP提供最好的网络拥塞,从而成为改进拥塞控制算法的根本原因已成为一个独立的领域。

在学习tcp的过程中,避免一种象棋方式,我们必须了解每一个算法到底是为了解决什么问题,每一个问题和其他问题到底是什么关系,这些问题的解决之间的关系是什么,除了TCP历史的发展,最好是看看这些。大家都明白,TCP协议完全掌握在你手中,然后你就可以学习socket API,然后高效的TCP程序就从你手中得到!
免责声明:本网信息来自于互联网,目的在于传递更多信息,并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益,请及时联系我们,本站将会在24小时内处理完毕。
相关文章
返回顶部