计算机网络——TCP/UDP协议

作者: Q南南南Q | 来源:发表于2017-08-03 18:43 被阅读0次

计算机网络七层模型中，传输层有两个重要的协议：
（1）用户数据报协议UDP (User Datagram Protocol)
（2）传输控制协议TCP (Transmission Control Protocol)

UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。

TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。

使用UDP 和TCP 协议的各种应用和应用层协议

用户数据报协议UDP

1 UDP 概述

UDP 的主要特点是：

UDP 是无连接的
即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延。
UDP 使用尽最大努力交付
即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数）。
UDP 是面向报文的
UDP 对应用层交下来的报文，既不合井，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP 多长的报文， UDP 就照样发送，即一次发送一个报文。因此应用程序必须选择合适大小的报文。若报文太长， UDP 把它交给IP 层后， IP 层在传送时可能要进行分片，这会降低IP 层的效率。反之，若报文太短， UDP 把它交给IP 层后，会使IP 数据报的首部的相对长度太太，这也降低了IP 层的效率。

2 UDP 的首都格式

首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。

源端口
在需要对方回信时选用。不需要时可用全0 。
目的端口
这在终点交付报文时必须要使用到。
长度
UDP 用户数据报的长度，其最小值是8 （仅有首部）。
检验和
检测UDP 用户数据报在传输中是否有错。有错就去弃。

UDP 的首都格式

传输控制协议TCP

1 TCP 最主要的特点

TCP 是面向连接的运输层协议
这就是说，应用程序在使用TCP 协议之前，必须先建立TCP 连接。在传送数据完毕后，必须释放已经建立的TCP 连接。
每一条TCP 连接只能是点对点的
TCP 提供可靠交付的服务
也就是说，通过TCP 连接传送的数据，无差错、不丢失、不重复、并且按序到达。
TCP 提供全双工通信
TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP 的缓存后，就可以做自己的事，而TCP 在合适的时候把数据发送出去。在接收时， TCP 把收到的数据放入缓存，上层的应用进程在合适的时候读取缓存中的数据。
面向字节流
“面向字节流”的含义是：虽然应用程序和TCP 的交互是一次一个数据块（大小不等），但TCP 把应用程序交下来的数据看成仅仅是一连串的无结构的字节流。TCP 并不知道所传送的字节流的含义。

TCP 面向流的概念

2 TCP 的连接

前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：

套接宁socket= (IP 地址：端口号’）

每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：
TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}

3次握手链接

第一次握手
当客户端向服务器发起连接请求时，客户端会发送同步序列标号SYN到服务器，在这里我们设SYN为m，等待服务器确认，这时客户端的状态为SYN_SENT。
第二次握手
当服务器收到客户端发送的SYN后，发送确认包ACK，这里的ACK为m+1，意思是说“我收到了你发送的SYN了”，同时，服务器也会向客户端发送一个SYN包，这里我们设SYN为n。这时服务器的状态为SYN_RECV。
第三次握手
客户端收到服务器发送的SYN和ACK包后，需向服务器发送确认包ACK，这里的ACK为n+1，发送完毕后，客户端和服务器的状态为ESTABLISH，即TCP连接成功。

TCP三次握手

4次握手释放链接

断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。

第一次挥手
A端向B端请求断开连接时会向B端发送一个带有FIN标记的报文段
第二次挥手
B端收到A发送的FIN后，B段现在可能现在还有数据没有传完，所以B端并不会马上向A端发送FIN，而是先发送一个确认序号ACK，意思是说“你发的断开连接请求我收到了，但是我现在还有数据没有发完，请稍等一下呗”。
第三次挥手
当B端的事情忙完了，那么此时B端就可以断开连接了，此时B端向A端发送FIN序号，意思是这次可以断开连接了。
第四次挥手
A端收到B端发送的FIN后，会向B端发送确认ACK，然后经过两个MSL时长后断开连接。

TCP四次挥手

各个状态节点解释如下：

FIN_WAIT_1:
FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
CLOSE_WAIT
这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）
FIN_WAIT_2
上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
LAST_ACK
这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
TIME_WAIT
表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
CLOSED
表示连接中断。

TCP可靠传输的工作原理

1 停止等待协议

下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。

“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。

无差错情况
A 发送分组M1，发完就暂停发送，等待B 的确认。B 收到了M1 就向A 发送确认。A 在收到了对M1的确认后，就再发送下一个分组M2。同样，在收到B 对M2的确认后，再发送M3

无差错情况

超时重传
B 接收M1时检测出了差错就丢弃M1，其他什么也不做（不通知A 收到有差错的分组户。也可能是M1 在传输过程中丢失了，这时B 当然什么都不知道。在这两种情况下， B都不会发送任何信息。可靠传输协议是只要超过了一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就叫做超时重传。要实现超时重传，就要在每发送完一个分组设置一个超时计时器。如果在超时计时器到期之前收到了对方的确认，就撤销己设置的超时计时器。

超时重传

确认丢失
B所发送的对M1的确认丢失了。A在设定的超时重传时间内没有收到确认，因此A 在超时计时器到期后就要重传M1。现在应注意B的动作。假定B又收到了重传的分组M1。这时应采取两个行动：
（1）丢弃重复的M1
（2）重新发送确认

确认丢失

确认超时
传输过程中没有出现差错，但B 对分组M1 的确认迟到了。A 会收到重复的确认。对重复的确认的处理很简单：收下后就丢弃。B 仍然会收到重复的M1 ，并且同样要丢弃重复的M1 ，并重传确认分组。

确认超时

使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。

2 连续ARQ协议

滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。

下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。

连续ARQ协议工作原理

连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。

接收方一般都是采用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。

累积确认的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。

例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。

TCP报文格式

源端口和目的端口各占2 个宇节，分别写入源端口号和目的端口号。
序号
占4 宇节，TCP 是面向字节流的。在一个TCP 连接中传送的宇节流中的每一个字节都按顺序编号。首部中的序号字段值则指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号字段值是301 ，而携带的数据共有100字节。这就表明：本报文段的数据的第一个字节的序号是301 ，最后一个字节的序号是400。
确认号
占4 字节，是期望收到对方下一个报文段的第一个数据字节的序号。例如， B 正确收到了A 发送过来的一个报文段，其序号字段值是501 ，而数据长度是200 宇节（序号501 ～ 700 ），这表明B 正确收到了A 发送的到序号700 为止的数据。因此， B 期望收到A 的下一个数据序号是701 ，于是B 在发送给A 的确认报文段中把确认号置为701 。
窗口
占2 字节，窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。例如，设确认号是701 ，窗口字段是1000。这就表明，从701 号算起，发送此报文段的一方还有接收1000 个字节数据（字节序号是701 - 1700 ）的接收缓存空间。
总之，窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着。

TCP 可靠传输的实现——以字节为单位的滑动窗口

1 以字节为单位的滑动窗口

TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。

根据B 给出的窗口值， A 构造出自己的发送窗口

发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。

发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。

现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】

A 的发送窗门

再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。

B的接收窗口

现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：

A 收到新的确认号，发送窗口向前滑动

A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。

发送窗口内的序号都属于己发送但未被确认

2 超时重传时间的选择

上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。

TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:

新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）

α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。

显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:

RTO = RTTs + 4 × RTTd

RTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：

新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|

发现问题：如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重
传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？

收到的确认是对哪一个报文段的确认？

若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。

若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。

Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。

新问题：设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。

解决方案：对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。

TCP 的流量控制

1 利用滑动窗口实现流量控制

流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。

利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。

利用可变窗口进行流量控制举例

接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。

发生死锁：现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。

解决方案：TCP 为每一个连接设有一个持续计时器（persistence timer）。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个零窗口探测报文段（仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。

常见问题解析

1 TCP连接时是三次握手，那么两次握手可行吗？

在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。

2 为什么TCP连接是三次，挥手确是四次？

在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。

3 为什么在第四次挥手后会有2个MSL的延时？

MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。

TCP、UDP应用层的使用

1 文件传送协议

文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。

盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。

FTP工作过程

在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。

2 简单文件传送协议TFTP

TCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。

TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。

3 TELNET

TELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。

4 邮件传输协议

一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。

电子邮件的最主要的组成构件

SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。