互联网是由许多独立发展的网络通信技术融合而成。能够使它们之间不断融合并实现统一的正是TCP/IP技术。
如上图的 OSI参考模型所示,IP协议是网络层协议,TCP、UDP协议是传输层协议
TCP/IP是通信协议的统称。
简单来说,协议就是计算机与计算机之间通过网络实现通信时事先达成的一种“约定”。
这种“约定”使那些由不同厂商的设备、不同的CPU以及不同的操作系统组成的计算机之间,只要遵循相同的协议就能够实现通信。反之,如果所使用的协议不同,就无法实现通信。
TCP(Transmission Control Protocol)和 IP(Internet Protocol)是互联网的众多通信协议中最为著名的。
IP
IP(Internet Protocol,网际协议)。IP作为整个TCP/IP中至关重要的协议,主要负责将数据包发送给最终的目标计算机。因此,IP能够让世界上任何两台计算机之间进行通信。
TCP
TCP是一种面向有连接的传输层协议。它可以保证两端通信主机之间的通信可达。TCP能够正确处理在传输过程中丢包、传输顺序乱掉等异常情况。此外,TCP还能够有效利用带宽,缓解网络拥堵。然而,为了建立与断开连接,有时它需要至少7次的发包收包,导致网络流量的浪费。此外,为了提高网络的利用率,TCP协议中定义了各种各样复杂的规范,因此不利于视频会议(音频、视频的数据量既定)等场合使用。
UDP
UDP有别于TCP,它是一种面向无连接的传输层协议。UDP 不会关注对端是否真的收到了传送过去的数据,如果需要检查对端是否收到分组数据包,或者对端是否连接到网络,则需要在应用程序中实现。
UDP常用于分组数据较少或多播、广播通信以及视频通信等多媒体领域。
IP(Internet Protocol)相当于OSI参考模型中的第3层——网络层。网络层的主要作用是“实现终端节点之间的通信”,即“点对点通信”。
网络层的下一层 —— 数据链路层的主要作用是在互连同一种数据链路的节点之间进行包传递。而一旦跨越多种数据链路,就需要借助网络层。网络层可以跨越不同的数据链路,即使是在不同的数据链路上也能实现两端节点之间的数据包传输。
数据链路层提供直连两个设备之间的通信功能,网络层的IP则负责在没有直连的两个网络之间进行通信传输。
那么为什么需要两个层次?它们的区别是什么?
在此,以外出旅行为例说明这个问题。
有个人要去一个很远的地方旅行,并且计划先后乘坐飞机、火车、公交车到达目的地。为此,他制定了一个详细行程表,先购买了机票和火车票。
机票和火车票只有特定区间内有效,当换乘不同公司的飞机或火车时,还需要重新购票。
那么IP与数据链路的作用如下图所示:
这里每张票只能够在某一限定区间内移动。此处的“区间内”就如同通信网络上的数据链路。而这个区间内的出发地点和目的地点就如同某一个数据链路的源地址和目标地址等首部信息(即源MAC地址与目的MAC地址)。
整个全程的行程表的作用就相当于网络层。如果我们只有行程表而没有车票,就无法搭乘交通工具到达目的地。反之如果除了车票其他什么都没有,也很难到达目的地。因为你不知道该坐什么车,也不知道该在哪里换乘。因此,只有两者兼备,既有某个区间的车票又有整个旅行的行程表,才能保证到达目的地。
与之类似,计算机网络中也需要数据链路层和网络层这个分层才能实现向最终目标地址的通信。
IP大致分为三大作用模块,它们是IP寻址、路由(最终节点为止的转发)以及IP分包与组包。
IP地址用于在“连接到网络中的所有主机中识别出进行通信的目标地址”。因此,在TCP/IP通信中所有主机或路由器必须设定自己的IP地址。
路由控制(Routing)是指将分组数据发送到最终目标地址的功能。即使网络非常复杂,也可以通过路由控制确定到达目标地址的通路。因此,一个数据包之所以能够成功地到达最终的目标地址,全靠路由控制。
发送数据至最终目标地址
Hop 译为中文叫“跳”。它是指网络中的一个区间。IP包正是在网络中一个个跳间被转发。因此IP路由也叫做多跳路由。在每一个区间内决定着包在下一跳被转发的路径。
多跳路由是指路由器或主机在转发IP数据包时只指定下一个路由器或主机,而不是将到最终目标地址为止的所有通路全都指定出来。因为每一个区间(跳)在转发IP数据包时会分别指定下一跳的操作,直至包达到最终的目标地址。
当IP包到达一个路由器以后,会再次经历查找下一目标地址的过程,并由该路由器转发给下一个被找到的路由器。这个过程可能会反复多次,直到找到最终的目标地址将数据包发送给这个节点。
路由控制表
为了将数据包发给目标主机,所有主机都维护着一张路由控制表(RoutingTable)。该表记录IP数据在下一步应该发给哪个路由器。IP包将根据这个路由表在各个数据链路上传输。
IP是实现多个数据链路之间通信的协议。数据链路根据种类的不同各有特点。对这些不同数据链路的相异特性进行抽象化也是IP的重要作用之一。
数据链路的地址可以被抽象化为IP地址。因此,对IP的上一层来说,不论底层数据链路使用以太网还是无线LAN亦或是PPP,都将被一视同仁。
不同数据链路有个最大的区别,就是它们各自的最大传输单位(MTU:Maxi-mum Transmission Unit)不同。就好像人们在邮寄包裹或行李时有各自的大小限制一样。
下图以运送包裹为例来说明。
MTU的值在以太网中是1500字节,在FDDI中是4352字节,而ATM则为9180字节。IP的上一层可能会要求传送比这些MTU更多字节的数据,因此必须在线路上传送比包长还要小的MTU。
为了解决这个问题,IP进行分片处理(IP Fragmentation)。也就是将较大的IP包分成多个较小的IP包。分片的包到了对端目标地址以后会再被组合起来传给上一层。即从IP的上次层看,它完全可以忽略数据包在途中的各个数据链路上的MTU,而只需要按照源地址发送的长度接收数据包。IP就是以这种方式抽象化了数据链路层,使得从上层更不容易看到底层网络构造的细节。
IP面向无连接。即在发包之前,不需要建立与对端目标地址之间的连接。上层如果遇到需要发送给IP的数据,该数据会立即被压缩成IP包发送出去。
为什么IP要采用面向无连接?
提高通信的可靠性很重要。TCP就提供这种功能。如果说IP只负责将数据发给目标主机,那么TCP则负责保证对端主机确实接收到数据。
为什么不让IP具有可靠传输的功能,从而把这两种协议合并到一起呢?
这其中的缘由就在于,如果要一种协议规定所有的功能和作用,那么该协议的具体实施和编程就会变得非常复杂,无法轻易实现。相比之下,按照网络分层,明确定义每层协议的作用和责任以后,针对每层具体的协议进行编程会更加有利于该协议的实现。
网络通信中如果能进行有效分层,就可以明确 TCP 与 IP 各自协议的最终目的,也有利于后续对这些协议进行扩展和性能上的优化。分层也简化了每个协议的具体实现。
任何一台主机都有必要对 IP 分片(IPFragmentation)进行相应的处理。分片往往在网络上遇到比较大的报文无法一下子发送出去时才会进行处理。
下图展示了网络传输过程中进行分片处理的一个例子。
分片报文只在目标主机端进行重组
经过分片之后的 IP 数据报在被重组的时候,只能由目标主机进行。路由器虽然做分片但不会进行重组。
为什么只在终端重组?
这样的处理是由诸多方面的因素造成的。例如,现实当中无法保证 IP 数据报文是否经由同一个路径传送。因此,途中即使等待片刻,数据包也有可能无法到达目的地。此外,拆分之后的每个分片也有可能会在途中丢失。即使在途中某一处被重新组装,但如果下一站再经过其他路由时还会面临被分片的可能。这会给路由器带来多余的负担,也会降低网络传送效率。出于这些原因,在终结点(目标主机)端重组分片了的 IP 数据报文成为现行的规范。
IP(Internet Protocol)旨在让最终目标主机收到数据包,但是在这一过程中仅仅有IP是无法实现通信的。必须还有能够解析主机名称和 MAC 地址的功能,以及数据包在发送过程中异常情况处理的功能。此外,还会涉及 IP 必不可少的其他功能。
然而,人们在上网的时候其实很少直接输入某个具体的 IP 地址。
在访问Web站点和发送、接收电子邮件时,我们通常会直接输入Web网站的地址或电子邮件地址等那些由应用层提供的地址,而不会使用IP地址。因此,为了能让主机根据实际的IP包进行通信,就有必要实现一种功能 —— 将应用中使用的地址映射为IP地址。这就使用到了DNS域名解析系统(参考其它资料)。
不同数据链路的MTU也是不同的,那么就需要以路径上所有数据链路中的最小MTU来进行分片,传输数据,这样避免了在不同数据链路中切换时的再次分片问题(路由器中分片),也能保持较高的网络利用率。
这种发现链路中最小MTU的技术就是“路径MTU发现”(Path MTU Discovery),现在很多操作系统都已经实现了路径MTU发现的功能。
**路径MTU发现的机制(UDP的情况下)**如下图:
**路径MTU发现的机制(TCP的情况下)**如下图:
TCP/IP 中有两个具有代表性的传输层协议,它们分别是 TCP 和 UDP。TCP 提供可靠的通信传输,而 UDP 则常被用于让广播和细节控制交给应用的通信传输。总之,根据通信的具体特征,选择合适的传输层协议是非常重要的。
TCP是面向连接的、可靠的流协议。流就是指不间断的数据结构,你可以把它想象成排水管道中的水流。当应用程序采用TCP发送消息时,虽然可以保证发
在 TCP 中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK,Positive Acknowledgement,意指已经接收)。
TCP 通过肯定的确认应答(ACK)实现可靠的数据传输。当发送端将数据发出之后会等待对端的确认应答。如果有确认应答,说明数据已经成功到达对端。反之,则数据丢失的可能性很大。
未收到确认应答并不意味着数据一定丢失。也有可能是返回的确认应答在途中丢失。这种情况也会导致发送端因没有收到确认应答,而认为数据没有到达目的地,从而进行重新发送。
此外,也有可能因为一些其他原因导致确认应答延迟到达,在源主机重发数据以后才到达的情况也履见不鲜。此时,源发送主机只要按照机制重发数据即可。但是对于目标主机来说,这简直是一种“灾难”。它会反复收到相同的数据。而为了对上层应用提供可靠的传输,必须得放弃重复的数据包。为此,就必须引入一种机制,它能够识别是否已经接收数据,又能够判断是否需要接收。
上述这些确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现。
序列号是按顺序给发送数据的每一个字节(8位字节)都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据的长度,将自己下一步应该接收的序号作为确认应答返送回去。就这样,通过序列号和确认应答号,TCP可以实现可靠传输。
重发超时是指在重发数据之前,等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍未收到确认应答,发送端将进行数据重发。
由于网络环境的不同,重发超时的计算既要考虑往返时间又要考虑偏差
在BSD的Unix以及Windows系统中,超时都以0.5秒为单位进行控制,因此重发超时都是0.5秒的整数倍。不过,由于最初的数据包还不知道往返时间,所以其重发超时一般设置为6秒左右。
数据被重发之后若还是收不到确认应答,则进行再次发送。此时,等待确认应答的时间将会以2倍、4倍的指数函数延长。
此外,数据也不会被无限、反复地重发。达到一定重发次数之后,如果仍没有任何确认应答返回,就会判断为网络或对端主机发生了异常,强制关闭连接。并且通知应用通信异常强行终止。
TCP提供面向有连接的通信传输。在传输信息之前需要先建立连接。
TCP会在数据通信之前,通过TCP首部发送一个SYN包作为建立连接的请求等待确认应答。如果对端发来确认应答,则认为可以进行数据通信。如果对端的确认应答未能到达,就不会进行数据通信。此外,在通信结束时会进行断开连接的处理(FIN包)。
可以使用TCP首部用于控制的字段来管理TCP连接。一个连接的建立与断开,正常过程至少需要来回发送7个包才能完成(也就是常说的三次握手四次挥手)。
在建立TCP连接的同时,也可以确定发送数据包的单位,我们也可以称其为“最大消息长度”(MSS:Maximum Segment Size)。最理想的情况是,最大消息长度正好是IP中不会被分片处理的最大数据长度。
TCP在传送大量数据时,是以MSS的大小将数据进行分割发送。进行重发时也是以MSS为单位。
MSS是在三次握手的时候,在两端主机之间被计算得出。两端的主机在发出建立连接的请求时,会在TCP首部中写入MSS选项,告诉对方自己的接口能够适应的MSS的大小。然后会在两者之间选择一个较小的值投入使用。
TCP以1个段为单位,每发一个段进行一次确认应答的处理。这样的传输方式有一个缺点。那就是,包的往返时间越长通信性能就越低。
如何解决?
为解决这个问题,TCP引入了窗口这个概念。即使在往返时间较长的情况下,它也能控制网络性能的下降。
如图所示,确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度的缩短。也就是说,发送端主机,在发送了一个段以后不必要一直等待确认应答,而是继续发送。
下图窗口大小为4个段。这个机制的实现使用大量的缓冲区,对多个段同时进行确认应答。
窗口中的数据缓存必须等到收到对应数据段的确认应答后才能删除,因为可能需要重发。
窗口滑动如下图所示:
上图窗口内的四个数据段依次发送,首先收到了第一个数据段的确认应答,那么就可以将该数据段从缓存中清除,将窗口向前滑动。
注:上图描述数据段未丢失,以及正常收到确认应答的情况。
在使用窗口控制中,如果出现段丢失该怎么办?
在这种情况下,数据已经到达对端,是不需要再进行重发的。然而,在没有使用窗口控制的时候,没有收到确认应答的数据都会被重发。而使用了窗口控制时,某些确认应答即便丢失也无需重发。
接收主机如果收到一个自己应该接收的序号以外的数据时,会针对当前为止收到的数据返回确认应答。(如下图中,收到2001~3000后,仍然返回 “下一个是1001”)这时即使收到的包序号不连续也不会丢弃,而是暂时保存至缓冲区中。
当 1001~2000 的报文丢失后,发送端会一直收到序号为1001的确认应答。
因此,在窗口比较大,又出现报文段丢失的情况下,同一个序号的确认应答将会被重复不断地返回。而发送端主机如果 **连续3次 **收到同一个确认应答,就会将其所对应的数据进行重发。这种机制比之前提到的超时管理更加高效,因此也被称作 高速重发控制。
如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。为了避免这种现象发生,TCP 提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量,这就是流量控制。
流量控制根本目的是防止分组丢失,它是构成TCP可靠性的一方面。
它的具体操作是,接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。在前面介绍的窗口大小的值就是由接收端主机决定的。
TCP首部中,专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端。这个字段的值越大,说明网络的吞吐量越高。不过,接收端的这个缓冲区一旦面临数据溢出时,窗口大小的值也会随之被设置为一个更小的值通知给发送端,从而控制数据发送量。
也就是说,发送端主机会根据接收端主机的指示,对发送数据的量进行控制。这也就形成了一个完整的TCP流控制(流量控制)。
流量控制过程示意图如下(注意文字描述部分):
有了TCP的窗口控制,收发主机之间可以连续发送大量的数据包。然而在网络出现拥堵时,突然发送一个较大量的数据,极有可能会导致整个网络的瘫痪。
TCP为了防止该问题的出现,在通信一开始时就会通过一个叫做慢启动的算法得出的数值,对发送数据量进行控制。
首先,为了在发送端调节所要发送数据的量,定义了一个叫做“拥塞窗口”的概念。于是在慢启动的时候,将这个拥塞窗口的大小设置为1个数据段(1 MSS,以太网可以从3 MSS开始)发送数据,之后每收到一次确认应答(ACK),拥塞窗口的值就加1。在发送数据包时,将拥塞窗口的大小与接收端主机通知的窗口大小做比较,然后按照它们当中较小那个值,发送比其还要小的数据量。
如果重发采用超时机制,那么拥塞窗口的初始值可以设置为1以后再进行慢启动修正。有了上述这些机制,就可以有效地减少通信开始时连续发包导致的网络拥堵,还可以避免网络拥塞情况的发生。
不过随着包的每次往返,拥塞窗口也会呈1、2、4等指数增长,使网络拥塞更加严重。为防止这些,引入了慢启动阈值的概念。只要拥塞窗口的值超出这个阈值,在每次收到一次确认应答时,不再以指数增长,只允许以下面这种比例放大拥塞窗口:
(1个数据段字节数)/(拥塞窗口字节数)* 1个数据段字节数
TCP的通信开始时,并没有设置相应的慢启动阀值(与窗口最大值相同)。而是在超时重发时,才会设置为当时拥塞窗口一半的大小。
拥塞窗口越大,确认应答的数目也会增加。不过随着每收到一个确认应答,其涨幅也会逐渐减少,甚至小过比一个数据段还要小的字节数。因此,拥塞窗口的大小会呈直线上升的趋势。
由重复确认应答而触发的高速重发与超时重发机制的处理有些不同。因为前者要求至少3次的确认应答数据段到达对方主机后才会触发,相比后者网络的拥堵要轻一些。
而由重复确认应答进行高速重发控制时,慢启动阀值的大小被设置为当时窗口大小的一半。然后将窗口的大小设置为该慢启动阀值+3个数据段的大小。
由于窗口的大小会直接影响数据被转发时的吞吐量,所以一般情况下,窗口越大,越会形成高吞吐量的通信。
《图解TCP/IP》