TCP/IP -- 2

五、TCP与UDP

1.传输层的作用

TCP/IP中有两个具有代表性的传输层协议,它们分别是TCP和UDP。TCP提供可靠的通信传输,而UDP则常被用于让广播和细节调控交给应用的通信传输。

传输层的定义

IP首部中有一个协议字段,用来标识网络层的上一层所采用的是哪一种传输层协议。根据这个字段的协议号,就可以识别IP传输的数据部分究竟是TCP的内容,还是UDP的内容。同样,传输层的TCP和UDP,为了识别自己所传输的数据部分究竟应该发给哪个应用,也设定了这样一个编号。

通信处理

TCP/IP的众多应用协议大多以客户端/服务端的形式运行。客户端类似于客户的意思,是请求的发起端。而服务端则表示提供服务的意思,是请求的处理端。另外,作为服务端的程序有必要提前启动,准备接收客户端的请求。否则即使有客户端的请求发过来,也无法做到响应的处理。这些服务端程序在UNIX系统中叫做守护进程。例如HTTP的服务端程序是httpd(HTTP守护进程),而ssh的服务端程序是sshd(SSH守护进程)。在UNIX中并不需要将这些守护进程逐个启动,而是启动一个可以代表它们接收客户端请求的inetd(互联网守护进程)服务程序即可。它是一种超级守护进程,该超级守护进程收到客户端请求以后会创建新的进程并转换为sshd等各个守护进程。确认一个请求究竟发给的是哪个服务端(守护进程),可以通过所收到数据包的目标端口号轻松识别。

两种传输层协议TCP和UDP

TCP:
TCP是面向连接的、可靠的流协议。流就是指不间断的数据结构,你可以把它想象成排水管道中的水流。当应用程序采用TCP发送消息时,虽然可以保证发送的顺序,但还是犹如没有任何间隔的数据流发送给接收端。TCP为提供可靠性传输,实行"顺序控制"或"重发控制"机制。此外还具备"流控制(流量控制)"、"拥塞控制"、提高网络利用率等众多功能。

UDP:
UDP是不具有可靠性的数据报协议。细微的处理它会交给上层的应用去完成。在UDP的情况下,虽然可以确保发送消息的大小,却不能保证消息一定会到达。因此,应用有时会根据自己的需求进行重发处理。

TCP与UDP的区分:
TCP用于在传输层有必要实现可靠传输的情况。由于它是面向有连接并具备顺序控制、重发控制等机制的,所以它可以为应用提供可靠传输。
UDP主要用于那些对于高速传输和实时性有较高要求的通信或广播通信。

2.端口号

端口号的定义

数据链路和IP中的地址,分别指的是MAC地址和IP地址。前者用来识别同一链路中不同的计算机,后者用来识别TCP/IP网络中互连的主机和路由器。在传输层中也有这种类似于地址的概念,那就是端口号。端口号用来识别同一台计算机中进行通信的不同应用程序。因此,它也被称为程序地址。

通过IP地址、端口号、协议号进行通信识别

TCP/IP或UDP/IP通信中通常采用5个信息来识别一个通信。它们是"源IP地址"、"目标IP地址"、"协议号"、"源端口号"、"目标端口号"。只要其中某一项不同,则被认为是其他通信。

端口号如何确定

标准既定的端口号:
这种方法也叫静态方法。它是指每个应用程序都有其指定的端口号。但并不是说可以随意使用任何一个端口号。每个端口号都有其对应的使用目的。

时序分配法:
服务器有必要确定监听端口号,但是接收服务的客户端没必要确定端口号。在这种方法下,客户端应用程序可以完全不用自己设置端口号,而全权交给操作系统进行分配。操作系统可以为每个应用程序分配互不冲突的端口号。根据这种动态分配端口号的机制,即使是同一客户端程序发起多个TCP连接,识别这些通信连接的5部分数字也不会全部相同。

端口号与协议

端口号由其使用的传输层协议决定。因此,不同的传输协议可以使用相同的端口号。数据到达IP层后,会先检查IP首部中的协议号,再传给相应协议的模块。如果是TCP则传给TCP模块,如果是UDP则传给UDP模块去做端口号的处理。即使是同一端口号,由于传输协议是各自独立地进行处理,因此相互之间不会受到影响。

3.UDP

UDP的特点及其目的

UDP不提供复杂的控制机制,利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻,立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况,UDP也无法进行流量控制等避免网络拥塞的行为。此外,传输途中即使出现丢包,UDP也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正功能。如果需要这些细节控制,那么不得不交由采用UDP的应用程序去处理。

由于UDP面向无连接,它可以随时发送数据。再加上UDP本身的处理既简单又高效,因此经常用于以下几个方面:

  • 包总量较少的通信(DNS、SNMP等)
  • 视频、音频等多媒体通信(即时通信)
  • 限定于LAN等待定网络中的应用通信
  • 广播通信(广播、多播)

4.TCP

TCP的特点及其目的

TCP是对"传输、发送、通信"进行"控制"的"协议"。它充分地实现了数据传输时各种控制功能,可以进行丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。TCP作为一种面向有连接的协议,只有在确认通信对端存在时才会发送数据,从而可以控制通信流量的浪费。为了通过IP数据报实现可靠性传输,需要考虑很多事情。例如数据的破坏、丢包、重复以及分片顺序混乱等问题。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

通过序列号与确认应答提高可靠性

在TCP中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答。

序列号是按照顺序给发送数据的每一个字节都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据的长度,将自己下一步应该接受的序号作为应答返送回去。就这样,通过序列号和确认应答号,TCP可以实现可靠传输。


序列号与确认应答号

重发超时如何判断

重发超时是指在重发数据之前,等待确认应答到来的那个特定时间间隔。如果超过了这个时间仍未收到确认应答,发送端将进行数据重发。重发超时的计算既要考虑往返时间又要考虑偏差是有其原因的。根据网络环境的不同往返时间可能会产生大幅度的摇摆,之所以发生这种情况是因为数据包的分段是经过不同路线到达的。TCP/IP的目的是即使在这种环境下也要进行控制,尽量不要浪费网络流量。

数据被重发之后若还是收不到确认应答,则进行再次发送。此时,等待确认应答的时间将会以2倍、4倍的指数函数延长。此外,数据也不会被无限、反复地重发。达到一定重发次数之后,如果仍没有任何确认应答返回,就会判断为网络或对端主机发生了异常,强制关闭连接。并且通知应用通信异常强行终止。

连接管理

TCP提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好通信两端之间的准备工作。在数据通信之前,通过TCP首部发送一个SYN包作为建立连接的请求等待确认应答。如果对端发来确认应答,则认为可以进行数据通信。如果对端的确认应答未能到达,就不会进行数据通信。此外,在通信结束时会进行断开连接的处理。

可以使用TCP首部用于控制的字段来管理TCP连接。一个连接的建立与断开,正常过程至少需要来回发送7个包才能完成。


连接管理

TCP以段为单位发送数据

在建立TCP连接的同时,也可以确定发送数据包的单位,我们也可以称其为"最大消息长度"(MSS)。最理想的情况是,最大消息长度正好是IP中不会被分片处理的最大数据长度。

MSS是在三次握手的时候,在两端主机之间被计算得出。两端的主机在发出建立连接请求时,会在TCP首部中写入MSS选项,告诉对方自己的接口能够适应的MSS的大小。然后会在两者之间选择一个较小的投入使用。

利用窗口控制提高速度

TCP以1个段为单位,每发一个段进行一次确认应答的处理。这样的传输方式有一个缺点。那就是,包的往返时间越长通信性能就越低。为了解决这个问题,TCP引入了窗口这个概念。即使在往返时间较长的情况下,它也能控制网络性能的下降。窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。


用滑动窗口方式并行处理
滑动窗口控制

窗口控制与重发控制

在未使用窗口控制时,没有收到确认应答的数据都会被重发。而使用了窗口控制,某些确认应答即使丢失也无需重发。


没有确认应答也不受影响

其次,我们来考虑一下某个报文段丢失的情况。接收主机如果收到一个自己应该接收的序号以外的数据时,会针对当前位置收到的数据返回确认应答。


高速重复控制

当某一报文段丢失后,发送端会一直收到序号为1001的确认应答,这个确认应答提醒发送端,"我想接收的是从1001开始的数据"。

流控制

TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量。这就是所谓的流控制。它的具体操作是,接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端会发送不超过这个限度的数据。这大小限度被称作窗口大小。窗口大小的值就是由接收端主机决定的。


流控制

当接收端从3001号开始的数据段后其缓冲区即满,不得不暂时停止接收数据。之后,在收到发送窗口更新通知后通信才得以继续进行。

拥塞控制

有了窗口控制,收发主机之间可以不再以一个数据段为单位发送确认应答,也能够连续发送大量数据包。但是如果在通信刚开始时就发送大量数据,也有可能会引发其他问题。TCP为了防止该问题的出现,在通信一开始时就会通过一个叫做慢启动的算法得出的数值,对发送数据量进行控制。


慢启动

首先,为了在发送端调节所要发送数据的量,定义了一个叫做"拥堵窗口"的概念。于是在慢启动的时候,将这个拥堵窗口的大小设置为1个数据段(1 MSS)发送数据,之后每收到一次确认应答(ACK),拥堵窗口的值就加1。在发送数据包时,将拥堵窗口的大小与接收端主机通知的窗口大小做比较,然后按照它们当中较小那个值,发送比其还要小的数据量。

如果重发采用超时机制,那么拥塞窗口的初始值可以设置为1以后再进行慢启动修正。有了上述这些机制,就可以有限的减少通信开始时连续发包导致的网络拥堵,还可以避免网络拥塞情况的发生。不过,随着包的每次往返,拥塞窗口也会以1、2、4等指数函数的增长,拥堵状况激增甚至导致网络拥塞的发生。为了防止这些,引入了慢启动阀值的概念。只要拥塞窗口的值超出这个阀值,在每收到一次确认应答时,只允许以下面这种比例放大拥塞窗口:


拥塞窗口放大比例
TCP的窗口变化

TCP的通信开始时,并没有设置相应的慢启动阈值。而是在超时重传时,才会设置为当前拥塞窗口一半的大小。由于重复确认应答而触发的高速重发与超时重发机制的处理多少有些不同。因为前者要求至少3次的确认应答数据段到达对方主机后才触发,相比后者网络的拥堵要轻一些。而由重复确认应答进行高速重发控制时,慢启动阈值的大小被设置为当时窗口大小的一半,然后将窗口的大小设置为该慢启动阈值+3个数据段的大小。当TCP通信开始以后,网络吞吐量会逐渐上升,但是随着网络拥堵的发生吞吐量也会急剧下降。于是会再次进入吞吐量慢慢上升的过程。因此所谓TCP的吞吐量的特点就好像是在逐步占领网络带宽的感觉。

提高网络利用率的规范

  • Nagle算法
  • 延迟确认应答:每收到两个数据段发送一次的确认应答。
  • 捎带应答:TCP的确认应答和回执数据可以通过一个包发送,必须得等到应用处理完数据并将作为回执的数据返回为止,才能进行捎带应答。

5.其他传输层协议

UDP-Lite

UDP-Lite(Lightweight User Datagram Protocol,轻量级用户数据报协议)是扩展UDP机能的一种传输层协议。在基于UDP的通信当中如果校验和出现错误,所收到的包将被全部丢弃。然而,现实操作中,有些应用在面对这种情况时并不希望把已经收到的所有包丢弃。如果将UDP中校验和设置为无效,那么即使数据的一部分发生错误也不会将整个包废弃。不过,这不是一个很好的方法。因为如果发生的错误有可能是UDP首部中的端口号被破坏或是IP首部中的IP地址被破坏,就会产生严重后果。因此,不建议将校验和关闭。为了解决这些问题,UDP的修正版UDP-Lite协议就出现了。

UDP-Lite提供与UDP几乎相同的功能,不过计算校验和的范围可以由应用自行决定。这个范围可以是包加上伪首部的校验和计算,可以是首部与伪首部的校验和计算,也可以是首部、伪首部与数据从起始到中间某个位置的校验和计算。有了这样的机制,就可以只针对不允许发生错误的部分进行校验和的检查。 对于其他部分,即使发生了错误,也会被忽略不计。而这个包也不会被丢弃,而是直接传给应用继续处理。

SCTP

SCTP(Stream Control Transmission Protocol,流控制传输协议)与TCP一样,都是对一种提供数据到达与否相关可靠性检查的传输层协议。
其主要特点如下:

  • 以消息为单位收发
    TCP中接收端并不知道发送端应用所决定的消息大小。在SCTP中却可以。

  • 支持多重宿主
    在有多个NIC的主机中,即使其中能够使用的NIC发生变化,也仍然可以继续通信。

  • 支持多数据流通信
    TCP中建立多个连接以后才能进行通信的效果,在SCTP中一个连接就可以。

  • 可以定义消息的生存期限
    超过生存期限的消息,不会被重发。

SCTP主要用于进行通信的应用之间发送众多较小消息的情况。这些较小的应用消息被称作数据块(Chunk),多个数据块组成一个数据包。此外,SCTP具有支持多重宿主以及设定多个IP地址的特点。多重宿主是指同一台主机具备多种网络的接口。例如,笔记本电脑既可以连接以太网又可以连接无线LAN。同时使用以太网和无线LAN时,各自的NIC会获取到不同的IP地址。进行TCP通信,如果开始时使用的是以太网,而后又切换为无线LAN,那么连接将会被断开。因为从SYN到FIN包必须使用同一个IP地址。然而在SCTP的情况下,由于可以管理多个IP地址使其同时进行通信,因此即使出现通信过程当中以太网与无线LAN之间的切换,也能够保持通信不中断。所以SCTP可以为具备多个NIC的主机提供更可靠的传输。

DCCP

DCCP(Datagram Congestion Control Protocol,数据报拥塞控制协议)是一个辅助UDP的崭新的传输层协议。UDP没有拥塞控制机制。为此,当应用使用UDP发送大量数据包时极容易出现问题。互联网中的通信,即使使用UDP也应该控制拥塞。而这个机制开发人员很难将其融合至协议中,于是便出现了DCCP这样的规范。
DCCP具有如下几个特点:

  • 与UDP—样,不能提供发送数据的可靠性传输。
  • 它面向连接,具备建立连接与断开连接的处理。在建立和断开连接上是具有可靠性。
  • 能够根据网络拥堵情况进行拥塞控制。使用DCCP(RFC4340)应用可以根据自身特点选择两种方法进行拥塞控制。它们分别是"类似TCP(TCP-like)拥塞控制"和"TCP友好升级控制"(TCP-Friendly Rate Control)(RFC4341)。
  • 为了进行拥塞控制,接收端收到包以后返回确认应答(ACK)。该确认应答将被用于重发与否的判断。

6.UDP首部格式

UDP首部格式
  • 源端口号
    表示发送端端口号,字段长16位。该字段是可选项,有时可能不会设置源端口号。没有源端口号的时候该字段的值设置为0。可用于不需要返回的通信中。

  • 目标端口号
    表示接收端端口,字段长度16位。

  • 包长度
    该字段保存了UDP首部的长度跟数据的长度之和。单位为字节。

  • 校验和
    校验和是为了提供可靠的UDP首部和数据而设计。

7.TCP首部格式

TCP首部格式

TCP首部比UDP首部要复杂得多。TCP中没有表示包长度和数据长度的字段。可由IP层获知TCP的包长,由TCP的包长可知数据的长度。

  • 源端口号
    表示发送端端口号,字段长16位。

  • 目标端口号
    表示接收端端口号,字段长度16位

  • 序列号
    字段长32位。序列号是指发送数据的位置。每发送一次数据,就累加一次该数据字节数的大小。

  • 确认应答号
    确认应答号字段长度32位。是指下一次应该收到的数据的序列号。实际上,它是指已收到确认应答号减一为止的数据。发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。

  • 数据偏移
    该字段表示TCP所传输的数据部分应该从TCP包的哪个位开始计算,当然也可以把它看作TCP首部的长度。该字段长4位,单位为4字节。

  • 保留
    该字段主要是为了以后扩展时使用,其长度为4位。

  • 控制位
    字段长位8位,每一位从左至右分别为CWR、ECE、URG、ACK、PSH、RST、SYN、FIN。这些控制标志也叫做控制位。
    1.CWR标志与后面的ECE标志都用于IP首部的ECN字段。ECE标志为1时,则通知对方已将拥塞窗口缩小。
    2.ECE标志表示ECN-Echo.置为1会通知通信对方,从对方到这边的网络有拥塞。在收到数据包的IP首部中ECN为1时将TCP首部中的ECE置为1。
    3.URG该位为1时,表示包中有需要紧急处理的数据。对于需要紧急处理的数据,会在后面的紧急指针中再进行解释。
    4.ACK该位为1时,确认应答的字段变为有效。TCP规定处理最初建立连接时的SYN包之外该位必须设置为1。
    5.PSH该位为1时,表示需要将收到的数据立即传给上层应用协议。PSH为0时,则不需要立即传而是先进行缓存。
    6.RST该位为1时表示TCP连接中出现异常必须强制断开连接。
    7.SYN用于建立连接。SYN为1表示希望建立连接,并在其序列号的字段进行序列号初始值的设定。
    8.FIN该位为1时,表示今后不会再有数据发送,希望断开连接。当通信结束希望断开连接时,通信双方的主机之间就可以相互交换FIN位置为1的TCP段。

  • 窗口大小
    该字段长为16位。用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小。

  • 校验和
    TCP的校验和与UDP相似,区别在于TCP的校验和无法关闭。

  • 紧急指针
    该字段长为16位。只有在URG控制位为1时有效。该字段的数值表示本报文段中紧急数据的指针。

  • 选项
    选项字段用于提高TCP的传输性能。可以根据数据偏移进行控制,所以其长度最大为40字节。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,776评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,527评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,361评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,430评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,511评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,544评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,561评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,315评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,763评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,070评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,235评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,911评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,554评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,173评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,424评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,106评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,103评论 2 352