tcp文件服务器展示ppt,tcp课件

最新推荐文章于 2024-05-13 02:38:12 发布

ztx kepler

最新推荐文章于 2024-05-13 02:38:12 发布

阅读量252

点赞数

文章标签： tcp文件服务器展示ppt

PPT内容

这是tcp课件，包括了运输层协议概述，TCP/IP 体系中的运输层，用户数据报协议 UDP，运输控制协议 TCP等内容，欢迎点击下载。

第 7 章运输层

7.1 运输层协议概述

7.2 TCP/IP 体系中的运输层

7.2.1 运输层中的两个协议

7.2.2 端口的概念

7.3 用户数据报协议 UDP

7.3.1 UDP 概述

7.3.2 UDP 用户数据报的首部格式

第 7 章运输层(续)

7.4 运输控制协议 TCP

7.4.1 TCP 概述

7.4.2 TCP 报文段的首部

7.4.3 TCP 的数据编号与确认

7.4.4 TCP 的流量控制与拥塞控制

7.4.5 TCP 的重传机制

7.4.6 采用随机早期丢弃 RED 进行拥塞控制

7.4.7 TCP 的运输连接管理

7.1 运输层协议概述

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。

运输层为相互通信的应用进程提供了逻辑通信

运输层的主要功能

运输层为应用进程之间提供端到端的逻辑通信(但网络层是为主机之间提供逻辑通信)。

运输层还要对收到的报文进行差错检测。

运输层需要有两种不同的运输协议，即面向连接的 TCP 和无连接的 UDP。

7.2 TCP/IP 体系中的运输层7.2.1 运输层中的两个协议

TCP/IP的运输层有两个不同的协议：

(1) 用户数据报协议 UDP (User Datagram Protocol)

(2) 传输控制协议 TCP (Transmission Control Protocol)

TCP 与 UDP

两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元 TPDU (Transport Protocol Data Unit)。

TCP 传送的数据单位协议是 TCP 报文段(segment)

UDP 传送的数据单位协议是 UDP 报文或用户数据报。

TCP/IP 体系中的运输层协议

TCP 与 UDP

UDP 在传送数据之前不需要先建立连接。对方的运输层在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最有效的工作方式。

TCP 则提供面向连接的服务。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

7.2.2 端口的概念

端口就是运输层服务访问点 TSAP。

端口的作用就是让应用层的各种应用进程都能将其数据通过端口向下交付给运输层，以及让运输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。

从这个意义上讲，端口是用来标志应用层的进程。

端口

端口用一个 16 bit 端口号进行标志。

插口(socket)

一个TCP连接由它的两个端点来标志,而每一个端点又是由IP地址和端口号决定的.TCP 使用“连接”(而不仅仅是“端口”)作为最基本的抽象，同时将 TCP 连接的端点称为插口(socket)，或套接字、套接口。插口和端口、IP 地址的关系是：

7.3 用户数据报协议 UDP 7.3.1 UDP 概述

UDP 只在 IP 的数据报服务之上增加了很少一点的功能，即端口的功能和差错检测的功能。

虽然 UDP 用户数据报只能提供不可靠的交付，但 UDP 在某些方面有其特殊的优点。

发送数据之前不需要建立连接

UDP 的主机不需要维持复杂的连接状态表。

UDP 用户数据报只有8个字节的首部开销。

网络出现的拥塞不会使源主机的发送速率降低。这对某些实时应用是很重要的。

7.3.2 UDP 用户数据报的首部格式

7.4 传输控制协议 TCP 7.4.1 TCP 概述

窗口字段 —— 占 2 字节。窗口字段用来控制对方发送的数据量，单位为字节。TCP 连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。

7.4.3 TCP 的数据编号与确认

TCP 协议是面向字节的。TCP 将所要传送的报文看成是字节组成的数据流，并使每一个字节对应于一个序号。

在连接建立时，双方要商定初始序号。TCP 每次发送的报文段的首部中的序号字段数值表示该报文段中的数据部分的第一个字节的序号。

TCP 的确认是对接收到的数据的最高序号表示确认。接收端返回的确认号是已收到的数据的最高序号加 1。因此确认号表示接收端期望下次收到的数据中的第一个数据字节的序号。

7.4.4 TCP 的流量控制与拥塞控制1. 滑动窗口的概念

TCP 采用大小可变的滑动窗口进行流量控制。窗口大小的单位是字节。

在 TCP 报文段首部的窗口字段写入的数值就是当前给对方设置的发送窗口数值的上限。

发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整对方的发送窗口上限值(可增大或减小)。

发送端要发送 900 字节长的数据，划分为 9 个 100 字节长的报文段，而发送窗口确定为 500 字节。

发送端只要收到了对方的确认，发送窗口就可前移。

发送 TCP 要维护一个指针。每发送一个报文段，指针就向前移动一个报文段的距离。

发送端已发送了 400 字节的数据，但只收到对前 200 字节数据的确认，同时窗口大小不变。

现在发送端还可发送 300 字节。

利用可变窗口大小进行流量控制双方确定的窗口值是 400

2. 慢开始和拥塞避免

发送端的主机在确定发送报文段的速率时，既要根据接收端的接收能力，又要从全局考虑不要使网络发生拥塞。

因此，每一个 TCP 连接需要有以下两个状态变量：

接收端窗口 rwnd (receiver window) 又称为通知窗口(advertised window)。

拥塞窗口 cwnd (congestion window)。

接收端窗口 rwnd 和拥塞窗口 cwnd

(1) 接收端窗口 rwnd 这是接收端根据其目前的接收缓存大小所许诺的最新的窗口值，是来自接收端的流量控制。接收端将此窗口值放在 TCP 报文的首部中的窗口字段，传送给发送端。

(2) 拥塞窗口 cwnd (congestion window) 是发送端根据自己估计的网络拥塞程度而设置的窗口值，是来自发送端的流量控制。

发送窗口的上限值

发送端的发送窗口的上限值应当取为接收端窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，即应按以下公式确定：

发送窗口的上限值  Min [rwnd, cwnd]

当 rwnd < cwnd 时，是接收端的接收能力限制发送窗口的最大值。

当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值。

慢开始算法的原理

在主机刚刚开始发送报文段时可先将拥塞窗口 cwnd 设置为一个最大报文段 MSS 的数值。

在每收到一个对新的报文段的确认后，将拥塞窗口增加至多一个 MSS 的数值。

用这样的方法逐步增大发送端的拥塞窗口 cwnd，可以使分组注入到网络的速率更加合理。

慢开始和拥塞避免算法的实现举例

乘法减小(multiplicative decrease)

“乘法减小“是指不论在慢开始阶段还是拥塞避免阶段，只要出现一次超时(即出现一次网络拥塞)，就把慢开始门限值 ssthresh 设置为当前的拥塞窗口值乘以 0.5。

当网络频繁出现拥塞时，ssthresh 值就下降得很快，以大大减少注入到网络中的分组数。

加法增大(additive increase)

“加法增大”是指执行拥塞避免算法后，当收到对所有报文段的确认就将拥塞窗口 cwnd增加一个 MSS 大小，使拥塞窗口缓慢增大，以防止网络过早出现拥塞。

必须强调指出

“拥塞避免”并非指完全能够避免了拥塞。利用以上的措施要完全避免网络拥塞还是不可能的。

“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞。

用三次握手建立 TCP 连接

建立 TCP 连接

A 的 TCP 向 B 发出连接请求报文段，其首部中的同步比特 SYN 应置为 1，并选择序号 x，表明传送数据时的第一个数据字节的序号是 x。

B 的 TCP 收到连接请求报文段后，如同意，则发回确认。

B 在确认报文段中应将 SYN 置为 1，其确认号应为 x  1，同时也为自己选择序号 y。

A 收到此报文段后，向 B 给出确认，其确认号应为 y  1。

A 的 TCP 通知上层应用进程，连接已经建立。

当运行服务器进程的主机 B 的 TCP 收到主机 A 的确认后，也通知其上层应用进程，连接已经建立。

采用三次握手法，主要是为了防止已失效的连接请求报文段突然又重传送到了主机B,因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的。考虑这样一种情况。主机A发出连接请求，但因连接请求报文丢失而未收到确认。主机A于是再重发一次。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。主机A共发送了两个连接请求报文段，其中的第二个到达了主机B。

现假设出现另一种情况，即主机A发出的第一个连接请求报文段并没有丢失，而是在某些网络节点滞留的时间太长，以至延误到在这次的连接释放以后才传送到主机B。本来这是一个已经失效的报文段。但主机B收到此失效的连接请求报文段后，就误认为是主机A又发出一次新的连接请求。于是就向主机A发出确认报文段，同意建立连接。

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

采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，主机A不会向主机B的确认发出确认。主机B收不到确认，连接就建立不起来。

TCP 的正常的连接建立和关闭