运输层（TCP运输协议相关）

1. 运输层概述

• 网络层、数据链路层、物理层解决了网络中主机和主机之间的通信；
• 运输层解决网络中不同主机上的进程之间的通信，这种服务是端到端的；
• 进程通过唯一的端口号进行标识；
• 根据应用需求不同，运输层主要向应用层提供两种不同的运输协议：1）面向连接的TCP；2）无连接的UDP；

2. 端口号

• 网络中不同主机使用的操作系统可能不一致，因此在这些主机上的进程会使用不同格式的pid进行标识；
• 为了使得不同主机上进程之间的相互通信，运输层使用端口号标识进程；
• 端口号取值范围为 [0,65535]，占用两个字节大小，可分为以下三类：
  1）熟知端口号：[0,1023]，IANA（Internet号码分配机构）将此范围内端口号分配给一些重要的应用协议，比如HTTP使用80、DNS使用53、FTP使用21/20;
  2）登记端口号：[1024,49151]，为一些不熟知的应用程序使用，这类端口号必须在IANA按照规定登记，放置端口号重复；
  3）短暂端口号：[49152,65535]，供用户进程短暂使用，通信结束后，端口号释放；

3. 运输层复用和分用

复用

• 发送方上不同进程向运输层发送应用报文，运输层根据应用需求选择不同的协议；
• 网络层IP协议将运输层发送的数据（报文段或用户数据报）放入数据载荷，使用协议字段表示传输层数据使用何种协议：TCP使用6标识，UDP使用17标识；

分用

• 发送方发送的IP数据报到达接收方以后，接收方开始对数据报进行分析；
• 网络层IP协议通过协议字段解析出数据载荷中的数据使用了何种运输层协议，然后将数据解析为对应类型数据（报文段或用户数据报）；
• 运输层将对应数据通过不同的端口将数据传送给不同的应用进程；
  

4. 应用层常见协议使用的运输层熟知端口号

5. TCP协议对比UDP协议

TCP(Transmission Control Protocol)传输控制协议	UDP(User Datagram Protocol) 用户数据报协议
面向连接：1）三次握手建立连接；2）四次挥手释放连接；	无连接
仅支持单播，即一对一通信	支持单播、多播、广播，即支持一对一、一对多、一对全通信
面向字节流	面向应用报文
向上层提供面向连接可靠传输，使用流量控制、拥塞控制机以及确认应答机制、超时重传机制、累计确认机制、捎带应答机制	向上层提供无连接不可靠传输，尽最大努力交付
报文段首部最小长度20字节，最大60字节	数据报首部仅占据8字节

6. TCP的流量控制

• 目的：控制发送方的发送速率，使接收方来得及接收数据；
• 解决方案：使用滑动窗口机制可实现流量控制（TCP连接接收方通过自己的接收窗口大小限制发送方的发送窗口大小）；
  1）TCP连接双方均有缓存，即发送缓存和接收缓存。建立TCP连接时，接收方告诉发送方自己的接收窗口大小，发送方随即将发送窗口设置为对应大小；
  2）发送方只能发送滑动窗口内部的数据，滑动窗口内数据发送后收到接收方的累计确认后，移动窗口，调整窗口大小，将已发送的数据从缓存中删除；
  
  3）如果发送方收到接收方的零窗口通知，则开启持续计时器，计时器超时时发送方发送零窗口探测报文（仅携带一字节数据），接收方对该报文进行确认，告知自己当前的接收窗口大小：
  （1）如果接收窗口大小仍然为0，则重启计时器，重复操作；
  （2）如果接收窗口大小不为0，则打破TCP连接双方的死锁局面，发送方调整发送窗口，继续进行发送；
  

7. TCP的拥塞控制

• 网络拥塞：对网络资源的需求量超过当前所能提供的可用量，网络性能下降，此时称为网络拥塞；
• 网络拥塞会导致网络吞吐量随输入负荷的增大而下降；
  理想情况下，网络吞吐量未达到饱和之前，输入负荷与吞吐量相等；
  
• TCP的4种拥塞控制算法：慢开始、拥塞避免、快重传、快恢复；

7.1 慢开始算法、拥塞避免算法

• 慢开始算法：在开始阶段向网络输入的报文段数量较少，逐渐增大；
• 拥塞避免：降低拥塞窗口的扩大速率，改为线性增长（每次加1），使网络发生拥塞的可能性降低；
• 发送方判断网络是否发生拥塞的标准：发生超时重传（即发送方发送的部分报文段未按时收到确认报文）；
• 拥塞窗口的维护原则：未发生拥塞则扩大，发生拥塞就缩小；
• 拥塞窗口的大小是动态变化的，取决于网络拥塞程度；
• 发送方发送窗口swnd=拥塞窗口cwnd；
• 拥塞控制流程：
  1）一开始先执行慢开始算法（维护慢开始阈值ssthresh），初始化cwnd=1，以指数形式扩大cwnd；
  2）当cwnd<ssthresh时一直进行慢开始算法，直到cwnd=ssthresh时，转为执行拥塞避免算法，以线性规律扩大cwnd；
  3）在执行上述算法过程中，如果发生网络拥塞，则进行如下工作：
  （1）将慢开始阈值ssthresh变为当前拥塞窗口大小的一半，即ssthresh=cwnd/2；
  （2）令拥塞窗口大小为cwnd=1，重新开始执行慢开始算法；
  

7.2 快重传算法

• 发送方通过是否发生超时重传判断是否发生网络拥塞，此方式进行判断存在一个问题：有时报文段丢失发生超时重传时，网络并未发生拥塞，如果此时重启慢开始算法则会降低网络性能；
• 快重传算法就是通过提前重传丢失的报文段，而避免发生不必要的超时重传，以此避免错误的慢开始算法；
• 快重传算法流程：尽早告知发送方存在报文段丢失的情况，尽快重传
  1）发送方按序发送拥塞窗口内的报文段，如果接收方发现收到了失序的报文段，说明发生了报文段丢失；
  2）接收方收到失序报文段后立马向发送方发送重复确认报文；
  3）发送方一旦收到3个连续的重复确认报文，就立即重传对应报文段；
  

7.3 快恢复算法

• 发送方收到3个重复确认时，可知有部分报文段丢失，所以立即重传对应报文。与此同时，执行快恢复算法；
• 快恢复算法执行流程：
  （1）将慢开始阈值ssthresh变为当前拥塞窗口大小的一半，即ssthresh=cwnd/2；
  （2）令拥塞窗口大小为cwnd=ssthresh（或者cwnd=ssthresh+3），开始执行拥塞避免算法；
  

8. TCP超时重传时间的选择

TCP超时重传时间（RTO）的选择是一个比较复杂的问题，已知报文段实际往返时间（RTT）：
1）如果RTO的选择小于RTT，则会发生不必要的重传，增大网络负荷；
2）如果RTO的选择远大于RTT，则会使网络空闲时间增大，降低网络传输效率；
有上述分析，可知RTO的选择是比较复杂的，通常RTO要略大于RTT。

8.1 超时重传时间计算

• RTT不是一个固定值，因此简单测量的RTT不能直接用于计算超时重传时间；
• 标准建议通过下列方式计算RTO：
  
• 在通信过程中，如果发生超时重传现象，则每发生一次便将RTO增大一些，典型做法是将RTO设置为RTO_旧的2倍；

9. TCP可靠传输的实现-滑动窗口

• TCP使用滑动窗口机制实现可靠传输；
  
  
  

9.1 注意事项

• TCP规定接受方只能对按序到达的最高序号进行确认；
  

10. TCP连接的建立与释放

• 需要明确TCP连接双方有各自的角色：1）客户端：主动请求建立连接的一方；2）服务器：被动同意建立连接的一方；
• 通信双方建立TCP连接的目的是互相确认对方的发送能力和接收能力正常，可以进行可靠传输；

10.1 三次握手建立连接

• 连接建立工作流程（客户端、服务器一开始均处于CLOSED关闭状态），下列步骤中2~4步即为“三次握手”过程：

• 1）服务器进程创建传输控制块TCB（包括TCP连接表、指向发送和接收缓存的指针、当前发送和接收的序号等信息），进入LISTEN监听状态，等待客户端发送TCP连接请求；
• 2）客户端进程创建传输控制块TCB，发送TCP连接请求（报文段头部SYN=1，序列号seq赋随机值x），进入SYN-SENT同步已发送状态；
• 3）服务器接收2）发送的报文段，同意建立TCP连接，发送对应确认报文段（报文段头部SYN=1，ACK=1，序列号seq赋随机值y，确认号ack=x+1），服务器进入SYN-RCVD同步已接收状态；
• 4）客户端收到服务器对其TCP请求报文的确认报文段，发送对该确认报文段的确认报文段（报文段头部ACK=1，序列号seq=x+1，确认号ack=y+1），发送端进入ESTABLISHED连接已建立状态；
• 5）服务器收到3）中确认报文段后进入ESTABLISHED连接已建立状态，至此双方成功建立TCP连接，可进行可靠的数据传输了！！

• 注意：1）TCP规定SYN=1的报文段不能携带数据，但会消耗一个序号；2）TCP规定普通确认报文段如果不携带数据，则不会消耗序号！！
• 两次握手建立连接会导致，客户端失效的TCP连接请求报文段到达服务器，使得服务器误进入连接已建立状态，造成资源的浪费！！
  
• 四次握手是将三次握手过程的第二个步骤拆分为两步进行，即：1）服务器发送对TCP连接请求报文段的确认（ACK=1，ack=x+1）；2）服务器发送TCP连接请求报文段（SYN=1,seq=y）。这两步完全可以合并，一起发送，所以三次握手刚好满足连接建立的要求！！！

10.2 四次挥手释放连接

• TCP连接具有半关闭特性，A->B的连接释放了，但B仍可以向A发送数据，而TCP连接的释放指连接双方均释放连接；
• 连接释放工作流程（客户端、服务器一开始均处于ESTABLISHED连接已建立状态），下列步骤中2~4步即为“四次挥手”过程：

1）客户端主动发送TCP连接释放请求报文（FIN=1,ACK=1,seq=u,ack=v），进入FIN-WAIT1中止等待1状态；
2）服务器收到连接释放请求后，发送普通确认报文（ACK=1,seq=v,ack=u+1），并通知应用进程客户端想释放连接，进入CLOSE-WAIT关闭等待状态。客户端收到确认报文进入FIN-WAIT2中止等待2状态。此时，客户端->服务器的单向连接已关闭，TCP连接处于半关闭状态，服务器仍可以给客户端发送数据。此后，服务器向客户端发送连接释放请求报文（FIN=1,ACK=1,seq=w,ack=u+1），进入LAST-ACK最后确认状态。
3）客户端收到服务器发来的释放请求报文后，发送普通确认报文（ACK=1,seq=u+1,ack=w+1），进入TIME-WAIT时间等待状态。
4）服务器收到确认报文后，进入CLOSED关闭状态。与此同时，客户端经历2MSL后进入CLOSED关闭状态。至此，TCP连接完整释放！！

• TIME-WAIT状态等待2MSL（最大报文段存活时间）的作用：

• 1）确保服务器可以收到TCP连接释放请求的确认报文，避免持续重发释放请求报文，服务器一直处于LAST-ACK最后确认状态而无法关闭连接，浪费资源；
• 2）客户端TCP进程在时间等待状态持续2MSL可使网络中关于该TCP连接的所有报文段消失，避免影响后续新的TCP连接。

• 保活计时器的作用：

• 存在的问题：客户端发生故障，服务器无法及时得知，一直处于等待状态，浪费计算机资源。
• 解决方案：保活计时器；
• 工作原理：1）服务器每收到客户端的一次数据，就重启保活计时器（2小时定时）；2）如果保活计时器超时，则说明固定时间内客户端未发送数据。此时，服务器向客户端发送探测报文，此后每75秒发送一次，如果连续10次探测报文均为收到客户端的确认报文，则认为客户端出现故障，服务器关闭此TCP连接。

• 三次挥手不能实现TCP连接释放，因为：TCP连接具有半关闭特性，两次挥手释放客户端->服务器的连接之后，服务器仍可以向客户端发送数据，如果第三次挥手和第二次挥手合并，则无法实现半关闭状态下服务器->客户端的单向数据传输了。因此两次挥手只能释放单向连接，要想释放双向连接则需要四次挥手。

10.3 TCP连接状态转移图

• TCP连接的建立与释放过程中，双方状态转移图：
  粗实线表示客户端，粗虚线表示服务端
  

11. TCP报文段首部格式

• TCP报文段采用面向字节流的方式，以实现可靠传输；
• TCP报文段由首部和数据载荷两部分构成；
• 发送缓存中的部分或全部字节作为TCP报文段数据载荷，添加首部信息后即可作为报文段进行传输；
• 首部大小最小20字节（固定大小），最大60字节；

11.1 首部中字段解析

字段名	作用
源端口	占据16位，标识客户端TCP应用进程
目的端口	占据16位，标识客户端TCP应用进程
数据偏移	占据4位，以4字节为单位，表示首部大小，最小为5，最大为15
保留	保留字段，用于后序功能扩展，占据6位，暂设置为0
窗口	占据16位，以字节为单位。表示该主机作为接收方时对应的接收窗口大小，窗口值结合发送方的拥塞窗口大小共同决定发送方发送窗口的大小
校验和	占据16位，发送端填充，使接收方检查报文段的首部和数据是否有差错
SYN标志位	占据1位，用于标识TCP连接请求报文
FIN标志位	占据1位，用于标识TCP连接释放请求报文
ACK标志位	占据1位，标识该报文段为确认报文段，TCP规定连接建立后所有报文段必须设置ACK=1
序号seq	占据32位，表示该报文段第一个字节序号
确认号ack	占据32位，当ACK=1时有效，表示对接收到的报文段序号进行确认，同时期望后续接收的报文段的第一个字节的序号
PSH标志位	占据1位，表示推送操作，该报文段应尽快交付
RST标志位	占据1位，表示连接复位操作，说明TCP连接存在异常，需要重新建立连接
URG标志位	占据1位，表示紧急操作
紧急指针	占据16位，标记紧急数据的大小，仅当URG=1有效
选项	扩充TCP功能，目前有如下选项：
填充	用于填充首部，保证首部大小是4字节的整数倍，因为数据偏移以4字节为单位

参考：《计算机网络微课堂》