UDP&TCP协议

用户数据报协议UDP

UDP的特点

• UDP是面向无连接的：即发送数据之前不需要建立连接（当然，发送数据结束时也没有连接可释放），因此减少了开销和发送数据之前的时延。
• UDP使用尽最大努力交付：即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有很多参数）。
• UDP是面向报文的：发送方的UDP对应用程序交下来的报文，既不合并，也不拆分，而是在添加首部后就向下交付IP层，也就是说，UDP一次交付一个完整的报文。因此，UDP发送的报文长度是应用程序给出的。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率；反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部相对长度太大，这也降低了IP层的效率。
• UDP没有拥塞控制：因此网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用很重要，很多的实时应用要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延，UDP正好适合这种要求。
• UDP支持一对一、多对多、多对一和多对多的交互通信。
• UDP的首部开销小：只有8个字节，比TCP的20个字节的首部要短。

UDP报文段的首部格式

        用户数据报UDP有两个字段： 首部字段和数据字段。首部字段只有8个字节，由四个字段组成，每个字段的长度都是两个字节，各字段意义如下：

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

        

        当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交至最后的终点，即应用进程，下图是UDP基于端口分用的示意图：

        

        如果接收方发现收到的报文中的目的端口号不正确（即不存在对应于该端口号的应用进程），就丢弃该报文。并由忘记控制报文协议ICMP发送“端口不可达”差错报文给发送方。

传输控制协议TCP

TCP的主要特点

• TCP是面向连接的：这就是说，应用程序在使用TCP协议之前，必须先建立TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。
• TCP连接是点对点的：TCP连接只能有两个端点，每一条TCP连接只能是点对点的。
• TCP提供可靠交付的服务：通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达。
• TCP提供全双工通信：TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。在发送时，应用程序在把数据传送给TCP的缓存后，就可以做自己的事，而TCP在合适的时候就把数据发送出去。在接受时，TCP把收到的数据放入缓存，上层的应用程序在合适的时候读取缓存中的数据
• 面向字节流：TCP中的“流”指的是流入到程序或从程序流出的字节序列。

TCP的连接

        TCP连接的端点就做套接字（socket）或插口，根据RFC793的定义，端口号拼接到IP地址即构成了套接字。总之，我们有：套接字socket = （IP地址：端口号）。

        每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定，即：

        TCP连接：：={socket1，socket2} = {（IP1：port1），（IP2：port2）}。

TCP报文段的首部格式

        一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项（n是整数）。因此TCP首部的最小长度是20字节。下图展示了TCP报文段的首部格式：

        

        首部固定部分各字段的意义如下：

• 源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。
• 序号：占4字节，序号范围是[0，2^32 - 1]，序号增加到2^32 - 1后，下一个序号又回到0，也就是说，序号使用mod运算。在TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置，首部中的序号字段值指的是本报文段所发送的数据的第一个字节的序号。例如：一报文段的序号字段值是301，而携带的数据共有100字节，这就表明：本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400。显然，下一个报文段（如果还有的话）的数据序号应当从401开始。
• 确认号：占4字节，是期望收到对方下一个报文段的第一个数据字节的序号。例如：B正确收到了A发过来的一个报文段，其序号字段值是501，而数据长度是200字节（序号501~700），这表明B正确收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。注意，现在的确认号不是501，也不是700，而是701。总之，应当记住：

           若确认号 = N，则表明：到序号N - 1为止的所有数据都已正确收到。

• 数据偏移：占4位，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。这个字段实际上是指出TCP报文段的首部长度。由于首部中还有长度不确定的选项字段，因此数据偏移字段是必要的。
• 保留：占6位，保留为今后使用，但目前应置为0。
• 下面有6个控制位说明本报文段的性质：
  • 紧急URG：当URG = 1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送（相当于高优先级的数据），而不要按原来的排队顺序来传送。这时，发送方TCP就把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据，这要与首部中紧急指针字段配合使用。
  • 确认ACK：仅当ACK = 1时，确认号字段才有效。当ACK = 0时确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1。
  • 推送PSH：当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下，TCP就可以使用推送操作。这时，发送方TCP把PSH置为1，并立即创建一个报文段发送出去。接收方TCP收到PSH = 1的报文段，就尽快地推送至接收应用进程，而不再等到整个缓存都填满了后再向上交付。
  • 复位RST：当RST = 1时，表明TCP连接中出现严重差错（如由于主机崩溃或其它原因），必须释放连接，然后再重新建立运输连接。RST置1还用来拒绝一个非法的报文段或拒绝打开一个连接。RST也可称为重置位。
  • 同步SYN：在连接建立时用来同步序号。当SYN = 1而ACK = 0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN = 1和ACK = 1。故SYN置为1就表示这是一个连接请求或连接接受报文。
  • 终止FIN：用来释放一个连接。当FIN = 1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
• 窗口：占2字节，窗口值是[0，2^16 -1]之间的整数。窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。窗口值告诉对方：从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量。之所以要有这个限制，是应为接收方的数据缓存空间是有限的。总之，窗口值作为接收方让发送方设置其发送窗口的依据。例如：设确认号是701，窗口字段是1000。这就表明，从701号算起，发送此报文段的一方还有接受1000个字节数据的接收缓存空间。总之，应当记住：
  窗口字段明确指出了现在允许对方发送的数据量。窗口值是经常在动态变化着。

• 检验和：占2字节，检验和检验的范围包括首部和数据两部分。和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部，格式与UDP伪首部一样。接收方收到此报文段后，仍要加上这个伪首部来计算检验和。
• 紧急指针：占2字节，紧急指针仅在URG = 1时才有意义。它指出本报文段中的紧急数据的字节数（紧急数据结束后就是普通数据）。因此，紧急指针指出了紧急数据的末尾在报文段中的位置。
• 选项：长度可变，最长可达40字节。当没有使用“选项”时，TCP的首部长度是20字节。

可靠传输的工作原理

        我们知道，TCP发送的报文段是交给IP层传输的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。下面介绍两种简单的可靠传输协议：

• 停 - 等协议：停 - 等协议就是每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组。
  • 存在问题：信道利用率太低
• 连续ARQ协议：连续ARQ协议规定，维持一个发送窗口，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方一般都是采用累积确认的方式，这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认。这就表示：到这个分组为止的所有分组都已正确收到了。例如：发送方发送了123456，接收方接收到了12 456，2是按序到达的最后一个分组，所以接收方对2这个分组发送确认。
  • 存在问题：如上例，发送方发送了6个分组，而第3个分组丢失了，这时接收方只能对前两个分组发出确认。发送方无法知道后面4个分组的下落，只好把后面的4个分组都再重传一次。这就叫做回退N，表示需要再退回来重传已发送过的N个分组。可见当通信线路质量不好时，连续ARQ协议会带来负面影响。

TCP可靠传输的实现：滑动窗口协议

        为了讲述可靠传输原理的方便，我们假定数据传输只在一个方向上进行，即 A发送数据，B给出确认。我们先讨论发送窗口的基本构造，然后再讨论发送窗口&接收窗口根据具体需求的动态变化情况。

        （1）发送窗口基本构造：

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

         

        根据这幅图，我们来讲解一些基本概念：

• A的发送窗口：发送窗口表示，在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
• 发送窗口中的序号：发送窗口里的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据。
• 发送窗口后沿：发送窗口后沿的后面部分表示已发送且已收到了确认，这些数据不需要再保留。发送窗口后沿不可后移，因为不能撤销已收到的确认。它通常有两种变化情况：
  • 后沿不动：表示没有收到新的确认。
  • 后沿前移：表示收到了新的确认。
• 发送窗口前沿：发送窗口前沿的前面部分表示不允许发送，因为接受方没有为这部分数据保留临时存放的缓存空间。它通常有两种变化情况：
  • 前沿不动：表示收到了新的确认但对方的通知窗口变小了，这个时候最好不动。
  • 前沿前移：表示收到了新的确认但对方的通知窗口变大了，这个时候前沿前移。

          注意：当对方的通知窗口变小时，发送窗口也有可能向后收缩。但TCP标准强烈不赞成这样做，因为很可能发送            方在收到这个通知以前已经发送了窗口中的许多数据。现在又要收缩窗口，不让发这些数据，这样会产生一些错误。

        （2）发送窗口&接收窗口的动态变化情况：

        如图所示，要描述一个发送窗口的状态需要三个指针：P1，P2和P3。指针都指向字节的序号。这三个指针指向的几个部分意义如下：

• 小于P1的部分：表示已发送并已经收到确认的部分
• 大于P3的部分：表示不允许发送的部分
• P3 - P1部分：表示A的发送窗口（又称为通知窗口）
• P2 - P1部分：表示已发送但尚未收到确认的字节数
• P3 - P2部分：表示允许发送但尚未发送的字节数（又称为可用窗口或有效窗口）

        

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

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

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

        

        A在继续发送完序号42~53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。如下图，由于A的发送窗口已满，可用窗口已减小到零，因此必须停止发送。请注意，存在下面这种可能性，就是发送窗口内所有的数据都已正确到达B，B也早已发出了确认。但不幸的是，所有这些确认都滞留在网络中。在没有收到B的确认时，A不能猜测或许B收到了吧，只能认为B还没有收到这些数据。于是，A在经过一段时间后（由超市计时器控制）就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。如果A收到确认号落在发送窗口内，那么A就可以使发送窗口继续向前滑动，并发送新的数据。

        

        根据以上讨论，还要注意3个地方：

1. 虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间滞后。
2. TCP通常对不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
3. TCP要求接收方必须有累积确认的功能，这样可以减小传输开销。

发送缓存和接收缓存

        

• 发送缓存暂时用来存放：
  • 准备发送的数据
  • 已经发送但尚未收到确认的数据
• 接收缓存暂时用来存放：
  • 按序到达的、但尚未被接收应用程序读取的数据
  • 未按序到达的数据

TCP流量控制

        

TCP拥塞控制

        

TCP运输连接管理：三次握手与四次挥手

        

        下图画出了TCP的三次握手（建立连接）的过程，注意几个字段：

• SYN：在连接建立时用来同步序号。当SYN = 1而ACK = 0时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使SYN = 1和ACK = 1。故SYN置为1就表示这是一个连接请求或连接接受报文。
• seq：选择的初始序号。
• ACK：仅当ACK = 1时，确认号字段才有效。当ACK = 0时确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1。
• ack：对应于初始序号的确认号。

        

        假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP进程所处的状态。请注意，A主动打开连接，而B被动打开连接。

        下面阐述TCP连接建立的步骤：

1. 第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
2. 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

        为什么A还要发送一次确认呢？第三次握手主要是为了 防止已失效的连接请求报文段突然又传送到了B，因而产生错误。举个例子：

        假设采用两次握手，且A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段，但B收到此失效报文段后，就误认为A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的请求就确立了。

        由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来的数据。B的许多资源就这样白白浪费了。

        采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

         下图画出了TCP的四次挥手（释放连接）的过程，注意几个字段：

• FIN：用来释放一个连接。当FIN = 1时，表明此报文段的发送方的数据已发送完毕，并要求释放运输连接。
• seq：选择的初始序号。
• ACK：仅当ACK = 1时，确认号字段才有效。当ACK = 0时确认号无效。TCP规定，在连接建立后所有传送的报文段都必须把ACK置为1。
• ack：对应于初始序号的确认号。

        

        下面阐述TCP释放连接的步骤：

1. 当主机A的应用程序通知其TCP数据已经发送完毕时，TCP向主机B发送一个FIN包（FIN=u，它等于前面已传送过的数据的最后一个字节的序号+1）。
2. 主机B收到这个FIN包之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段），同时通知自己相应的应用程序：对方要求关闭连接。因而从A到B这个方向的连接就释放了。这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。
3. 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。主机B的应用程序告诉TCP：我要彻底的关闭连接，其TCP向主机A送一个FIN包（FIN=w），B还必须重复上次已发送过的确认号ack=u+1。这时B就进入LAST-ACK状态，等待A的确认。
4. 主机A收到这个FIN包后，必须对此发出确认，它向主机B发送一个ACK表示连接彻底释放。