计算机网络：TCP与UDP（一）

TCP与UDP同属传输层的协议。

运输层协议概述

网络层与运输层之间的区别：

• 传输对象
  
  • 网络层是为主机之间提供逻辑通信
  • 运输层为应用进程之间提供端到端的逻辑通信
• 有无差错检测
  
  • 运输层要对收到的报文进行差错检测
  • 网络层的IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分

传输层向高层用户屏蔽了下面网络核心的细节。当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的，但这种逻辑通信信道就相当于一条全双工的可靠信道。但运输层使用无连接的UDP时，这种逻辑通信信道仍然是一条不可靠信道。

---

• UDP在传送数据之前不需要先建立连接，远地主机在收到UDP报文后不需要给出任何确认。使用UDP的应用：

  • DNS
  • RIP
  • DHCP
  • SNMP

• TCP则提供面向连接的服务，在传输数据之前要先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠地、面向连接的运输服务，因此要增加许多开销。使用TCP的应用：

  • SMTP
  • TELNET
  • HTTP
  • FTP

---

运输层具有复用和分用功能，应用层的所有应用进程都通过运输层再传递到IP，这就是复用。运输层从IP收到数据后需要交付给指明的应用进程，这是分用。

为了完成分用功能，需要一个识别各个应用进程的地址方便运输层进行分发，最终使用的就是端口。这里的端口指的是应用层的各种协议进程与与运输实体进行层间交互的一种地址。

TCP与UDP的首部中都有源端口和目的端口这两个重要字段。当运输层收到IP交上来的报文时就可以根据端口来将数据交付给应用层的目的应用进程。

运输层采用一个16位端口号来标识一个端口。端口号只具有本地意义，只用于标志本计算机应用层中的各个进程在交互时的层间接口，在因特网中，相同的端口号是没有关联的。

由此可见，两个计算机中的进程要互相通信，不仅要知道对方的IP地址（找到对方的计算机），而且还要知道对方的端口号（找到对方计算机中的应用进程）。

下面是一些应用程序的端口号：

• FTP：21
• TELNET：23
• SMTP：25
• DNS：53
• HTTP：80
• SNMP：161

UDP

• UDP是无连接的。因此减少了开销和发送数据之前的时延
• UDP使用尽最大努力交付，即不保证可靠交互。
• UDP是面向报文的。
  
  • 发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。
  • 接收方的UDP将IP层交上来的UDP数据报去除首部后就原封不动地交给上层的应用进程。
• UDP 没有拥塞控制。因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用来说很重要，因为他们要求源主机以恒定的速率发送数据，允许在网络拥塞时丢失一些数据，但却不允许数据有太大的时延。
• UDP支持一对一、一对多、多对一和多对多的交互通信。
• UDP的首部开销小，只有8个字节。比TCP的20个字节要短。

TCP

• TCP是面向连接的。
• TCP只能是点对点的通信。
• TCP提供可靠交付服务。通过TCP传输的数据，无差错、不丢失、不重复、按序到达。
• TCP提供全双工通信。TCP允许双方在任何时候都可以发送数据。
• 面向字节流。

TCP连接的端点为套接字socket或插口。套接字为IP地址：端口号。每一条TCP连接唯一地被通信两端的两个套接字所确定。
同一个IP连接可以有多个不同的TCP连接。

可靠传输的原理

TCP发送的数据是交给IP层传输的，但是IP层只能提供尽最大努力交付，也就是说TCP下面的网络提供的是不可靠的传输，因此TCP必须采取一些措施使传输层之间的通信变得可靠。

我们可以使用一些可靠传输协议，当出现差错时让发送方重新传输出现差错的数据；同时在接收方来不及处理收到的数据时及时告诉发送方适当降低发送数据的速度。

停止等待协议

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

无差错情况

下面图a的情形。A发送之后等待，B收到之后就发送确认，A收到确认后再发送下一个分组。

出现差错

上图中b情况就是出现差错的情况。B接受M1时出现差错就丢弃它，其他什么也不做。也可能是M1在传输过程中丢失了。在这两种情况下B都不会发送任何消息。
可靠传输协议规定：A只要超过一段时间仍没有收到确认，就认为刚才发送的分组丢失了，从而重传前面发送的分组，这就是超时重传。

要实现超时重传，需要在每发完一个分组时就设置一个超时计时器，如果再超时计时器到期之前收到了对方的确认就撤销已设置的超时计时器。

这里有几个注意点：
1. A在发送完一个分组后必须暂时保留已发送的分组的副本（为发生超时重传时使用）。只有在收到相应的确认后才能清除暂时保留的分组副本。
2. 分组和确认分组都必须进行编号，这样才能明确是哪一个发出去的分组收到了确认，而哪一个分组还没有收到确认。
3. 超时计时器设置的重传时间应该比数据在分组中传输的平均往返时间更长一些。（从图b中也能看出来）
显然如果重传时间设定的很长那么通信的效率就会很低，但是设定的太短的话可能会产生不必要的重传。

确认丢失和确认迟到

图a中B发送的确认丢失了，A在超时重传时间内没有收到确认，但无法知道是自己发送的分组丢失、出错还是B发送的确认丢失了，因此A在超时计时器到期后就要重传M1。而此时B又收到了重传的M1，会采取两个行动：
1. 丢弃这个重复的分组M1，不向上层交付
2. 向A发送确认。不能认为已经发送过确认就不再发送，因为A重传了M1就表示没有收到确认。

图b也是一种可能的情况。即传输过程中没有出现差错，但是B对M1的确认迟到了。A会收到重复的确认，此时就会简单地丢弃。B同样会收到重复的M1，同样是丢弃重复的M1并重新发送确认。

使用上面的确认和重传机制，就可以在不可靠的传输网络上实现可靠传输。

上面的这种可靠传输协议常称为自动重传请求ARQ。

---

停止等待协议的优点是简单，缺点是信道利用率太低。

A发送分组的时间为TD。B发送确认分组的时间为TA，RTT为往返时间。
此时的信道利用率为：U = TD/(TD+RTT+TA)
当往返时间RTT远大于发送时间TD时，信道利用率就会非常低。

为了提高传输效率，发送方可以使用流水线传输，即发送方可连续发送多个分组，不必每发完一个分组就停止等待确认。这样可以使信道上一直有数据传输，可以获得很高的信道利用率。
这样的传输方式就是连续ARQ协议和滑动窗口协议

连续ARQ协议

发送方维持一个发送窗口，位于发送窗口内的几个分组都可以连续发送出去，而不需要等待对方的确认。

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

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

累计确认的缺点是不能向发送方反映出接收方已经收到了所有分组的信息。
例如当发送方发送了前5个分组，但是中间的3个分组丢失了，这时接收方只能对前两个分组发出确认。发送方只能把后面的三个分组都重传一次，这就是Go-Back-N，表示需要退回来重传已发送过的N个分组。因此当通信质量不好的时候连续ARQ协议会带来负面的影响。