j网站开发的相关知识,企业网站html模板免费下载,成都微信网站建设公司,广西网站推广优化目录 1 TCP
1.1 TCP 最主要的特点
1.2 TCP 的连接
TCP 连接#xff0c;IP 地址#xff0c;套接字
1.3 可靠传输的工作原理
1.3.1 停止等待协议
#xff08;1#xff09;无差错情况
#xff08;2#xff09;出现差错
#xff08;3#xff09;确认丢失和确认迟到…目录 1 TCP
1.1 TCP 最主要的特点
1.2 TCP 的连接
TCP 连接IP 地址套接字
1.3 可靠传输的工作原理
1.3.1 停止等待协议
1无差错情况
2出现差错
3确认丢失和确认迟到
4信道利用率
停止等待协议要点
1.3.2 连续 ARQ 协议
1.4 TCP 报文段的首部格式
1.5 TCP 可靠传输的实现
1.5.1 以字节为单位的滑动窗口
1.5.2 超时重传时间的选择
1.5.3 选择确认 SACK
1.6 TCP 的流量控制
1.6.1 利用滑动窗口实现流量控制
1.7 TCP 的拥塞控制
1.7.1 TCP 的拥塞控制方法
1.8 TCP 的运输连接管理
1.8.1 TCP 的连接建立——三次握手
1.8.2 TCP 的连接释放——四次挥手
1.9 TCP 的有限状态机 1 TCP
1.1 TCP 最主要的特点
1.TCP 是面向连接的运输层协议。
2.每一条 TCP 连接只能有两个端点 (endpoint)每一条 TCP 连接只能是点对点的一对一。
3.TCP 提供可靠交付的服务。
4.TCP 提供全双工通信。
5.面向字节流 ·TCP 中的“流”(stream) 指的是流入或流出进程的字节序列。 ·面向字节流虽然应用程序和 TCP 的交互是一次一个数据块但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。 TCP 面向流的概念 ·TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。 ·但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。 1.2 TCP 的连接
·TCP 把连接作为最基本的抽象。 套接字 (socket) TCP 连接IP 地址套接字
·TCP 连接就是由协议软件所提供的一种抽象。
·TCP 连接的端点是抽象的套接字即IP 地址端口号。
·同一个 IP 地址可以有多个不同的 TCP 连接。
·同一个端口号也可以出现在多个不同的 TCP 连接中。 Socket 有多种不同的意思 ·应用编程接口 API 称为 socket API, 简称为 socket。 ·socket API 中使用的一个函数名也叫作 socket。 ·调用 socket 函数的端点称为 socket。 ·调用 socket 函数时其返回值称为 socket 描述符可简称为 socket。 ·在操作系统内核中连网协议的 Berkeley 实现称为 socket 实现。 1.3 可靠传输的工作原理 IP 网络提供的是不可靠的传输。 ·在理想传输条件下不需要采取任何措施就能够实现可靠传输。 ·但实际网络都不具备理想传输条件。必须使用一些可靠传输协议在不可靠的传输信道实现可靠传输。-停止等待协议、连续 ARQ 协议 1.3.1 停止等待协议
·每发送完一个分组就停止发送等待对方的确认。在收到确认后再发送下一个分组。
·全双工通信的双方既是发送方也是接收方。
·假设仅考虑 A 发送数据而 B 接收数据并发送确认。因此 A 叫做发送方而 B 叫做接收方。
发送方 1.发送数据 2.计时 3.确认发送下一包 未超时 4.重传数据超时 5.丢弃重复的确认信息
接收方 1.接收数据 2.检错 3.发送确认信息无错 4.丢弃数据数据位错误重复数据
1无差错情况 2出现差错
两种情况 ·B 接收 M1 时检测出了差错就丢弃 M1其他什么也不做不通知 A 收到有差错的分组。 ·M1 在传输过程中丢失了这时 B 当然什么都不知道也什么都不做。
·在这两种情况下B 都不会发送任何信息。 问题A 如何知道 B 是否正确收到了 M1 呢 解决方法超时重传 1.A 为每一个已发送的分组设置一个超时计时器。 2.A 只要在超时计时器到期之前收到了相应的确认就撤销该超时计时器继续发送下一个分组 M2 。 3.若 A 在超时计时器规定时间内没有收到 B 的确认就认为分组错误或丢失就重发该分组。 3确认丢失和确认迟到
确认丢失 1.若 B 所发送的对 M1 的确认丢失了那么 A 在设定的超时重传时间内将不会收到确认因此 A 在超时计时器到期后重传 M1。 2.假定 B 正确收到了 A 重传的分组 M1。这时 B 应采取两个行动 (1) 丢弃这个重复的分组 M1不向上层交付。 (2) 向 A 发送确认。
确认迟到 1.B 对分组 M1 的确认迟到了因此 A 在超时计时器到期后重传 M1。 2.B 会收到重复的 M1丢弃重复的 M1并重传确认分组。 3.A 会收到重复的确认。对重复的确认的处理丢弃。 4信道利用率 优点简单。缺点信道利用率太低。 停止等待协议要点
·停止等待。发送方每次只发送一个分组。在收到确认后再发送下一个分组。
·暂存在发送完一个分组后发送方必须暂存已发送的分组的副本以备重发。
·编号。对发送的每个分组和确认都进行编号。
·超时重传。发送方为发送的每个分组设置一个超时计时器。若超时计时器超时位收到确认发送方会自动超时重传分组。
·超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一些防止不必要的重传。
·简单但信道利用率太低。
1.3.2 连续 ARQ 协议 ·通常 A 最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认就说明通信线路太差不能进行通信。 ·使用上述的确认和重传机制我们就可以在不可靠的传输网络上实现可靠的通信。 ·像上述的这种可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的接收方不需要请求发送方重传某个出错的分组。 发送窗口发送方维持一个发送窗口位于发送窗口内的分组都可被连续发送出去而不需要等待对方的确认。 发送窗口滑动发送方每收到一个确认就把发送窗口向前滑动一个分组的位置。
累积确认接收方对按序到达的最后一个分组发送确认表示到这个分组为止的所有分组都已正确收到了。 -优点容易实现即使确认丢失也不必重传。 -缺点不能向发送方反映出接收方已经正确收到的所有分组的信息。(例如不按序到达的 连续 ARQ 协议采用 Go-back-N回退N。 Go-back-N回退N表示需要再退回来重传已发送过的 N 个分组。 当通信线路质量不好时连续 ARQ 协议会带来负面的影响。 1.4 TCP 报文段的首部格式
·TCP 虽然是面向字节流的但 TCP 传送的数据单元却是报文段。
·一个 TCP 报文段分为首部和数据两部分而 TCP 的全部功能都体现在它首部中各字段的作用。
·TCP 报文段首部的前 20 个字节是固定的后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。 ·源端口和目的端口各占 2 字节。端口是运输层与应用层的服务接口。 运输层的复用和分用功能通过端口实现。
·序号占 4 字节。TCP 连接中传送的数据流中的每一个字节都有一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。 ·确认号占 4 字节是期望收到对方的下一个报文段的数据的第一个字节的序号。 -若确认号 N则表明到序号 N – 1 为止的所有数据都已正确收到。
·数据偏移即首部长度占 4 位指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远。单位是 32 位字以 4 字节为计算单位。
·保留占 6 位保留为今后使用但目前应置为 0。
·紧急 URG控制位。当 URG 1 时表明紧急指针字段有效告诉系统此报文段中有紧急数据应尽快传送 (相当于高优先级的数据)。
·确认 ACK控制位。只有当 ACK 1 时确认号字段才有效。当 ACK 0 时确认号无效。
·推送 PSH (PuSH) 控制位。接收 TCP 收到 PSH 1 的报文段后就尽快即“推送”向前交付接收应用进程而不再等到整个缓存都填满后再交付。
·复位 RST (ReSeT) 控制位。当 RST1 时表明 TCP 连接中出现严重差错如主机崩溃或其他原因必须释放连接然后再重新建立运输连接。
·同步 SYN (SYNchronization) 控制位。 同步 SYN 1 表示这是一个连接请求或连接接受报文。 当 SYN 1ACK 0 时表明这是一个连接请求报文段。 当 SYN 1ACK 1 时表明这是一个连接接受报文段。
·终止 FIN (FINish) 控制位。用来释放一个连接。 FIN1 表明此报文段的发送端的数据已发送完毕并要求释放运输连接。
·窗口占 2 字节。 窗口值告诉对方从本报文段首部中的确认号算起接收方目前允许对方发送的数据量以字节为单位。 -窗口字段明确指出了现在允许对方发送的数据量。窗口值经常在动态变化。
·检验和占 2 字节。检验和字段检验的范围包括首部和数据这两部分。 在计算检验和时要在 TCP 报文段的前面加上 12 字节的伪首部。 在计算检验和时临时把 12 字节的“伪首部”和 TCP 报文段连接在一起。伪首部仅仅是为了计算检验和。 ·紧急指针占 2 字节。在 URG 1时指出本报文段中的紧急数据的字节数紧急数据结束后就是普通数据指出了紧急数据的末尾在报文段中的位置。
·选项长度可变最长可达 40 字节。 —— 长度可变。TCP 最初只规定了一种选项即最大报文段长度 MSS。MSS 告诉对方 TCP“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
·填充使整个 TCP 首部长度是 4 字节的整数倍。 MSS (Maximum Segment Size) 是 TCP 报文段中的数据字段的最大长度。 数据字段加上 TCP 首部才等于整个的 TCP 报文段。 所以MSS是“TCP 报文段长度减去 TCP 首部长度”。 选项2最大报文段长度 MSS。最大报文段长度 MSS (Maximum Segment Size) 是每个 TCP 报文段中的数据字段的最大长度。 与接收窗口值没有关系。 选项3窗口扩大。TCP 窗口字段长度 16 位最大窗口大小 64 K 字节。 对于传播时延和带宽都很大的网络为获得高吞吐率较需要更大的窗口。 ·窗口扩大选项占 3 字节其中一个字节表示移位值 S。 ·新的窗口值位数从 16 增大到 (16 S)相当于把窗口值向左移动 S 位。 ·移位值允许使用的最大值是 14窗口最大值增大到 – 1 – 1。 窗口扩大选项可以在双方初始建立 TCP 连接时进行协商。 选项8时间戳。 ·占 10 字节。最主要的 2 个字段 时间戳值字段4字节和时间戳回送回答字段4字节。 ·2 个主要功能 1.计算往返时间 RTT 2.防止序号绕回 PAWS (Protect Against Wrapped Sequence numbers)。 -序号重复时为了使接收方能够把新报文段和迟到很久的旧报文段区分开可以在报文段中加上时间戳。 1.5 TCP 可靠传输的实现
1.5.1 以字节为单位的滑动窗口
·TCP 使用流水线传输和滑动窗口协议实现高效、可靠的传输。
·TCP 的滑动窗口是以字节为单位的。
·发送方 A 和接收方 B 分别维持一个发送窗口和一个接收窗口。
·发送窗口在没有收到确认的情况下发送方可以连续把窗口内的数据全部发送出去。凡是已经发送过的数据在未收到确认之前都必须暂时保留以便在超时重传时使用。 ·接收窗口只允许接收落入窗口内的数据。 第一发送窗口是根据接收窗口设置的但在同一时刻发送窗口并不总是和接收窗口一样大因为有一定的时间滞后。 第二TCP 标准没有规定对不按序到达的数据应如何处理。通常是先临时存放在接收窗口中等到字节流中所缺少的字节收到后再按序交付上层的应用进程。 第三TCP 要求接收方必须有累积确认的功能以减小传输开销。接收方可以在合适的时候发送确认也可以在自己有数据要发送时把确认信息顺便捎带上。但接收方不应过分推迟发送确认否则会导致发送方不必要的重传捎带确认实际上并不经常发生。 1.5.2 超时重传时间的选择
·TCP 发送方在规定的时间内没有收到确认就要重传已发送的报文段。
·但重传时间的选择是 TCP 最复杂的问题之一。
·互联网环境复杂IP 数据报所选择的路由变化很大导致运输层的往返时间 (RTT) 的变化也很大。 TCP 超时重传时间设置
·不能太短否则会引起很多报文段的不必要的重传使网络负荷增大。
·不能过长会使网络的空闲时间增大降低了传输效率。 TCP 采用了一种自适应算法它记录一个报文段发出的时间以及收到相应确认的时间。 这两个时间之差就是报文段的往返时间 RTT。 1.5.3 选择确认 SACK
问题若收到的报文段无差错只是未按序号中间还缺少一些序号的数据那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据
解决选择确认 SACK (Selective ACK)。 RFC 2018 对 SACK 的规定 ·如果要使用选择确认在建立 TCP 连接时要在 TCP 首部的选项中加上允许 SACK 选项且双方必须事先商定好。 ·如果使用选择确认原来首部中的确认号的用法仍然不变累积确认。只是在 TCP 首部中都增加了 SACK 选项以便报告收到的不连续的字节块的边界。 1.6 TCP 的流量控制
1.6.1 利用滑动窗口实现流量控制
·流量控制 (flow control) 让发送方的发送速率不要太快使接收方来得及接收。
·利用滑动窗口机制可以很方便地在 TCP 连接上实现对发送方的流量控制。 利用可变窗口进行流量控制举例 死锁的解决办法——持续计时器
·持续计时器 (persistence timer)只要 TCP 连接的一方收到对方的零窗口通知就启动该持续计时器。 ·若持续计时器设置的时间到期就发送一个零窗口探测报文段仅携带 1 字节的数据对方在确认这个探测报文段时给出当前窗口值。 ·若窗口仍然是零收到这个报文段的一方就重新设置持续计时器。 ·若窗口不是零则死锁的僵局就可以打破了。
1.7 TCP 的拥塞控制
拥塞产生的原因
由许多因素引起。例如 节点缓存容量太小 链路容量不足 处理机处理速率太慢 拥塞本身会进一步加剧拥塞
出现网络拥塞的条件∑ 对资源需求 可用资源。
增加资源能解决拥塞吗 不能而且还可能使网络的性能更坏。 例如 增大缓存但未提高输出链路的容量和处理机的速度排队等待时间将会大大增加引起大量超时重传解决不了网络拥塞 提高处理机处理的速率会将瓶颈转移到其他地方 拥塞引起的重传并不会缓解网络的拥塞反而会加剧网络的拥塞。 拥塞控制与流量控制的区别 拥塞控制的一般原理 拥塞控制的前提网络能够承受现有的网络负荷。 实践证明拥塞控制是很难设计的因为它是一个动态问题。 分组的丢失是网络发生拥塞的征兆而不是原因。 在许多情况下甚至正是拥塞控制本身成为引起网络性能恶化、甚至发生死锁的原因。 1.7.1 TCP 的拥塞控制方法
·TCP 采用基于滑动窗口的方法进行拥塞控制属于闭环控制方法。
·TCP 发送方维持一个拥塞窗口 cwnd (Congestion Window)。
·拥塞窗口的大小取决于网络的拥塞程度并且是动态变化的。
·发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量。
·发送窗口大小不仅取决于接收方窗口还取决于网络的拥塞状况。
·真正的发送窗口值 Min (接收方通知的窗口值拥塞窗口值)。 控制拥塞窗口变化的原则 ·只要网络没有出现拥塞拥塞窗口就可以再增大一些以便把更多的分组发送出去提高网络的利用率。 ·但只要网络出现拥塞或有可能出现拥塞就必须把拥塞窗口减小一些以减少注入到网络中的分组数缓解网络出现的拥塞。 TCP 拥塞控制算法
四种拥塞控制算法 RFC 5681 ·慢开始 (slow-start) ·拥塞避免 (congestion avoidance) ·快重传 (fast retransmit) ·快恢复 (fast recovery)
慢开始和拥塞避免算法的实现举例 ·当 TCP 连接进行初始化时将拥塞窗口置为 1窗口单位不使用字节而使用报文段。
·将慢开始门限的初始值设置为 16 个报文段即 ssthresh 16。
·开始执行慢开始算法时拥塞窗口 cwnd1发送第一个报文段。
·发送方每收到一个对新报文段的确认 ACK就把拥塞窗口值加 1因此拥塞窗口 cwnd 随着往返时延 RTT 按指数规律增长。
·当拥塞窗口 cwnd 增长到慢开始门限值 ssthresh 时改为执行拥塞避免算法拥塞窗口按线性规律增长。
·当拥塞窗口 cwnd 24 时网络出现了超时发送方判断为网络拥塞。调整门限值 ssthresh cwnd / 2 12同时设置拥塞窗口 cwnd 1进入慢开始阶段。
·按照慢开始算法发送方每收到一个对新报文段的确认 ACK就把拥塞窗口值加 1。当拥塞窗口 cwnd ssthresh 12 时改为执行拥塞避免算法拥塞窗口按线性规律增大。
·当拥塞窗口 cwnd 16 时发送方连续收到 3 个对同一个报文段的重复确认记为 3-ACK。发送方改为执行快重传和快恢复算法。
·执行快重传和快恢复算法发送方调整门限值 ssthresh cwnd / 2 8设置拥塞窗口 cwnd ssthresh 8开始执行拥塞避免算法。
TCP 拥塞控制流程图 发送窗口的上限值 Min [rwnd, cwnd] . 当 rwnd cwnd 时是接收方的接收能力限制发送窗口的最大值。 当 cwnd rwnd 时是网络拥塞限制发送窗口的最大值。 1.8 TCP 的运输连接管理
·TCP 是面向连接的协议。
·TCP 连接有三个阶段 连接建立 数据传送 连接释放
·TCP 的连接管理就是使 TCP 连接的建立和释放都能正常地进行。
TCP 连接建立过程中要解决的三个问题
1.要使每一方能够确知对方的存在。
2.要允许双方协商一些参数如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等。
3.能够对运输实体资源如缓存大小、连接表中的项目等进行分配。 TCP 连接的建立采用客户服务器方式。 主动发起连接建立的应用进程叫做客户 (client)。 被动等待连接建立的应用进程叫做服务器 (server)。 1.8.1 TCP 的连接建立——三次握手
·TCP 建立连接的过程叫做握手。
·采用三报文握手在客户和服务器之间交换三个 TCP 报文段以防止已失效的连接请求报文段突然又传送到了因而产生 TCP 连接建立错误。 ·B 的 TCP 服务器进程先创建传输控制块 TCB准备接受客户进程的连接请求。
·A 的 TCP 向 B 主动发出连接请求报文段其首部中的同步位 SYN 1并选择序号 seq x表明传送数据时的第一个数据字节的序号是 x。 TCP规定SYN 报文段即SYN 1的报文段不能携带数据但要消耗掉一个序号。 ·B 的 TCP 收到连接请求报文段后如同意则发回确认。 B 在确认报文段中应使 SYN 1使 ACK 1其确认号 ack x 1自己选择的序号 seq y。
·A 收到此报文段后向 B 给出确认其 ACK 1确认号 ack y 1。 A 的 TCP 通知上层应用进程连接已经建立。 TCP 标准规定ACK 报文段可以携带数据。 但如果不携带数据则不消耗序号。下一个数据报文段的序号仍是 seq x 1。 ·B 的 TCP 收到主机 A 的确认后也通知其上层应用进程TCP 连接已经建立。双方可以开始数据传送。
1.8.2 TCP 的连接释放——四次挥手
·TCP 连接释放过程比较复杂。
·数据传输结束后通信的双方都可释放连接。
·TCP 连接释放过程是四报文握手。 ·A 的应用进程先向其 TCP 发出连接释放报文段并停止再发送数据主动关闭 TCP 连接。 A 把连接释放报文段首部的 FIN 1其序号seq u等待 B 的确认。 TCP规定FIN 报文段即使不携带数据也消耗掉一个序号。 ·B 发出确认ACK1确认号 ack u1这个报文段的序号 seq v。 TCP 服务器进程通知高层应用进程。 从 A 到 B 这个方向的连接就释放了TCP 连接处于半关闭 (half-close) 状态。B 若发送数据A 仍要接收。
·若 B 已经没有要向 A 发送的数据其应用进程就通知 TCP 释放连接。 FIN1ACK1确认号 ack u1。
·A 收到连接释放报文段后必须发出确认。 ACK1确认号 ackw1自己的序号 seq u 1。
·请注意此时 TCP 连接还没有释放掉。必须经过时间等待计时器 (TIME-WAIT timer) 设置的时间 2MSL 后A 才释放 TCP 连接。 必须等待 2MSL 的时间 第一保证发送的最后一个 ACK 报文段能够到达 B。 第二防止“已失效的连接请求报文段”出现在本连接中。 保活计时器
·用来防止在 TCP 连接出现长时期空闲。
·通常设置为 2 小时 。
·若服务器过了 2 小时还没有收到客户的信息它就发送探测报文段。
·若发送了 10 个探测报文段每一个相隔 75 秒还没有响应就假定客户出了故障因而就终止该连接。
1.9 TCP 的有限状态机 欢迎一起学习~
