1000字范文 > 运输层（TCP运输协议相关）

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

时间：2024-06-25 08:28:12

相关推荐

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

运输层

1. 运输层概述2. 端口号3. 运输层复用和分用4. 应用层常见协议使用的运输层熟知端口号5. TCP协议对比UDP协议6. TCP的流量控制7. TCP的拥塞控制7.1 慢开始算法、拥塞避免算法7.2 快重传算法7.3 快恢复算法 8. TCP超时重传时间的选择8.1 超时重传时间计算 9. TCP可靠传输的实现-滑动窗口9.1 注意事项 10. TCP连接的建立与释放10.1 三次握手建立连接10.2 四次挥手释放连接10.3 TCP连接状态转移图 11. TCP报文段首部格式11.1 首部中字段解析

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协议

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