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 首部中字段解析
文章来源：https://www.toymoban.com/news/detail-566900.html
| 字段名 | 作用 |
|---|---|
| 源端口 | 占据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字节为单位 |
参考：《计算机网络微课堂》文章来源地址https://www.toymoban.com/news/detail-566900.html
到了这里，关于运输层（TCP运输协议相关）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
