创建一个网站的条件有哪些,如何做游戏渠道网站,郑州高端定制网站,微信网页版登录手机版下载未出现的一般考点较少#xff0c;这里的复习笔记一般可以满足考试需求 o.O 全部章节都有哦#xff0c;具体看此博客
计算机网络-自顶向下期末复习一篇就够了——重点复习笔记整理-CSDN博客 3.1传输层服务
TCP#xff1a;可靠、有序传输 拥塞控制流量控制建立连接
UDP这里的复习笔记一般可以满足考试需求 o.O 全部章节都有哦具体看此博客
计算机网络-自顶向下期末复习一篇就够了——重点复习笔记整理-CSDN博客 3.1传输层服务
TCP可靠、有序传输 拥塞控制流量控制建立连接
UDP不可靠、无序传输 是“尽力而为”的 IP 服务的简单扩展
不提供的服务 延迟保证带宽保证
3.2多路复用和解复用
概念定义
复用Multiplexing在发送端将来自多个应用层的消息合并并通过单个传输层通道发送。解复用Demultiplexing在接收端将接收到的数据段分配给正确的套接字socket。
复用是对通信信道的复用而不是对传输数据报的分解。 接收端的解复用过程
主机接收 IP 数据报。 每个数据报包含源 IP 地址和目标 IP 地址。每个数据报封装一个传输层段。✨数据报datagram属于网络层段segment属于传输层数据报头含有IP地址段头含有端口地址。每个段还包含源端口号和目标端口号。
主机根据 IP 地址和端口号将段转发给正确的套接字。TCP/UDP segment format 传输层协议的段格式TCP/UDP
每个传输层段头部会包含
源端口号目标端口号
这两个信息构成了解复用所需的关键字段。 P.S.TCP的面向连接 vs UDP的无连接
TCP传输控制协议是面向连接的这意味着在数据传输之前通信双方必须先建立一个逻辑上的连接并在传输过程中维护状态信息。整个过程可以类比为打电话
三次握手四次挥手可靠有序状态维护
UDP用户数据报协议是无连接的这意味着通信前不需要建立连接数据直接发送不管对方是否准备好接收。这个过程可以类比为寄信
无握手无状态维护直接释放不可靠低延迟 无连接解复用Connectionless Demultiplexing——适用于 UDP
创建带有端口号的套接字。UDP 套接字的唯一标识为一个二元组 目标 IP 地址目标端口号
当主机收到一个 UDP 段时 检查段中的目标端口号将该段交给该端口号对应的套接字
即使来自不同源 IP 和源端口的多个数据报其目标端口相同也会被送到同一个套接字。 示例场景 多个客户端可能向这个端口发送数据但都由同一个套接字接收。 面向连接的解复用Connection-oriented Demux——适用于 TCP
TCP 套接字由一个四元组标识 源 IP 地址源端口号目标 IP 地址目标端口号
接收主机使用这四个字段来将段分配给正确的 TCP 套接字。一个服务器可以同时支持多个 TCP 连接每个连接由一个不同的四元组标识。对于不持久连接的 HTTP 请求每次请求都建立一个新的套接字连接。
3.3无连接传输UDP
UDP: 用户数据报协议 [RFC 768]
UDP 是一种“无修饰”、“骨架式”的互联网传输协议。提供“尽力而为best effort”服务即 UDP 段可能会丢失。UDP 段可能无序地交付给应用程序。
UDP 是无连接的 发送方和接收方之间无需握手。每个 UDP 段都是独立处理的与其他段无关。 为什么需要 UDP
无需连接建立避免了握手带来的延迟。结构简单 发送端与接收端不需维护连接状态。段头开销小。
无拥塞控制UDP 可以按需快速传输数据适用于实时性要求高的应用。 UDP segment结构头部就是出去Application那四个 “长度”表示包括头部和数据在内的整个 UDP 段的字节长度。“校验和”用于差错检测。checksum
UDP 的常见用途
多媒体流式应用如视频、语音 容错能力强对丢包不敏感对发送速率敏感。
其他应用 DNS域名系统SNMP简单网络管理协议 如何在应用层实现可靠性
虽然 UDP 本身不提供可靠性但应用可以在其之上实现 添加应用特定的错误恢复机制例如 校验和校验重传机制序号追踪等。 3.4可靠性数据传输
概述
可靠数据传输RDTreliable data transfer对于应用层、传输层和链路层都非常重要。是网络中最核心的十大问题之一。不可靠信道的特性决定了可靠数据传输协议的复杂程度。 可靠数据传输起步
基本组件
发送方Send side rdt_send()由上层应用调用将数据交由发送方RDT协议发送。udt_send()由发送方RDT协议调用将数据段通过不可靠信道传输到接收方。
接收方Receive side rdt_rcv()当数据段到达接收方时由接收方RDT协议调用。deliver_data()接收方RDT协议调用此函数将数据交给接收方上层应用。 方框中的内容可理解为TCP缓冲区 开发思路
我们将逐步开发可靠数据传输协议rdt的发送方与接收方。本节仅考虑单向数据传输但控制信息将在双向流动。使用有限状态机FSM来描述协议的状态与行为 每个状态由事件触发转换每次状态转换可以触发具体动作。 Rdt1.0可靠信道上的可靠传输
假设底层信道完全可靠 无比特错误无丢包。
发送方 FSM 将数据打包成段调用 udt_send() 发送。
接收方 FSM 通过 rdt_rcv() 接收段并调用 deliver_data() 向上层交付数据。
简单的数据流
发送方 接收方
rdt_send(data) ─────► udt_send(packet)rdt_rcv(packet)extract(data)deliver_data(data) Rdt2.0考虑比特错误的信道
新增问题
信道可能导致比特翻转利用校验和检测错误。
如何处理错误
acknowledgements ACK确认接收方确认段无误negative acknowledgements NAK否认接收方通知段存在错误发送方收到 NAK 后重传该段。
新机制相较于 rdt1.0
错误检测如使用校验和接收方向发送方发送控制消息ACK/NAK。 rdt2.0状态机描述简化
发送方 FSM
等待来自上层应用的数据构建段含校验和发送等待 ACK 或 NAK 若收到 ACK继续若收到 NAK 或错误段重发。
接收方 FSM
检查接收到的段是否损坏若无误提取数据交付上层并发送 ACK若出错发送 NAK。 rdt2.0 的局限性
问题
如果 ACK 或 NAK 本身被破坏发送方将无法得知接收方状态。
错误恢复难点
若重传可能导致重复数据需要解决重复数据问题。 解决重复数据的方法
给每个段添加序列号接收方收到重复数据段时丢弃不交付协议变为“停等协议Stop-and-Wait”发送一个段后必须等待其确认。 Rdt2.1处理错误确认的增强版
改进
为每个段添加序列号0 或 1接收方和发送方分别追踪当前预期的序列号能够识别 ACK 或 NAK 是否损坏或是重复。
状态数目增加
每种状态必须记住当前段的序列号0 或 1更复杂但能更好容错。 Rdt2.2无 NAK 协议
功能与 rdt2.1 相同但只使用 ACK 接收方对每个正确接收的段发送 ACK包括其序列号发送方收到重复 ACK 时视为 NAK重传当前段。 RDT2.1和2.2正在等待的发送方只要收到与上一个ACK序号相反的ACK信号就继续发送下一个。 Rdt3.0考虑丢包的信道
新假设
不仅存在比特错误段也可能丢失包括 ACK即使使用校验和、ACK、序列号有时仍无法保证可靠性。
解决方法
发送方设置计时器 若超时仍未收到 ACK则重传。若 ACK 实际只是延迟而非丢失重传段会被接收方识别为重复并丢弃序列号机制仍有效。 Rdt3.0 的操作与性能分析
工作流程
发送方 每发送一段就启动计时器若计时器到期未收到 ACK可能因为丢包也可能因为ACK丢失则重发若收到 ACK停止计时器。
性能问题
示例1 Gbps 链路15 ms RTT1KB 分组 吞吐率约 33 KB/s仅占链路带宽的一小部分Stop-and-Wait 协议利用率极低。 流水线协议Pipelined ProtocolsC3P50
相较于stop-and-wait
概念
发送方可以同时发送多个“飞行中”的未确认分组增大了序列号范围需要在发送方和接收方缓存未确认分组。
两种基本类型
回退 NGo-Back-NGBN选择重传Selective RepeatSR 3.5面向链接的传输TCP
TCP
全双工数据传输Full duplex data 数据可以在一个连接中双向同时传输。MSS最大报文段长度每个 TCP 报文段中允许的数据最大字节数。
面向连接Connection-oriented 发送方与接收方在发送数据前必须进行握手即交换控制信息以初始化连接状态。
流量控制Flow controlled 发送方不会发送超出接收方处理能力的数据。
点对点通信Point-to-point 每个 TCP 连接仅连接两个端点。
可靠、有序的字节流Reliable, in-order byte stream 数据流中没有明确的“报文边界”。字节顺序交付给应用层。
流水线传输Pipelined 结合拥塞控制和流量控制设置窗口大小以进行高效数据传输。
发送与接收缓冲区 TCP 在两端都设置缓冲区用于临时保存数据。 TCP 报文段结构 字段 说明 源端口号、目标端口号 用于标识通信的进程 序列号Sequence Number 表示该段数据的第一个字节编号 确认号Acknowledgment Number 表示期望收到的下一个字节编号 头部长度、保留位、控制位如URG, ACK, PSH, RST, SYN, FIN 控制连接建立、断开、数据推送等 接收窗口大小Receive Window 表示接收方可接受的字节数 校验和 检测段在传输过程中是否出错 紧急指针、选项字段可变 特殊数据控制
TCP segment 结构 TCP 序列号与确认机制
序列号sequence number每个报文段携带的数据第一个字节的编号。确认号acknowledgement number期望接收的下一个字节编号。 累计确认Cumulative ACK确认号表示之前所有字节都已成功接收。
例如一个 500,000 字节的文件用 1000 字节作为 MSSTCP 会创建 500 个段。
第一段的序列号为 0第二段为 1000第三段为 2000以此类推。 在A发送给B的TCP segment中
Seq. #’s n表示这次A发送给B的数据是从第n字节开始的。
ACKs m表示A收到的B发送给A的数据中前m-1个字节都已确认无误收到累计确认期望收到B发给A的从m字节开始的数据。
体现了全双工特性。 TCP 往返时间Round Trip TimeRTT与超时Timeout
设置超时的挑战
RTT 会变化因此 过短 → 会导致不必要重传过长 → 会导致响应变慢。
解决方法
测量 SampleRTT从发送段到收到 ACK 的时间。使用 加权移动平均计算 EstimatedRTT
EstimatedRTT (1 - α) × EstimatedRTT α × SampleRTT
α 通常为 0.125参考 RFC 2988设置 超时间隔TimeoutIntervalDevRTTRound Trip Time Deviation用于估计往返时间变化幅度DevRTT 是 RTT 偏离平均值的“平均偏差”越大说明网络越不稳定。
Deviation离差
DevRTT (1 - β) × DevRTT β × |SampleRTT - EstimatedRTT|
TimeoutInterval EstimatedRTT 4 × DevRTT
β 通常为 0.25 TCP 实现可靠数据传输
TCP 在不可靠的 IP 之上实现可靠服务。支持流水线传输和累计确认。触发重传的条件包括 超时事件收到重复的 ACK。 TCP 发送端事件处理简化版
应用数据到达时 创建报文段并设置序列号若计时器未运行启动计时器用于追踪最早未被确认的段更新下一个序列号指针。设置超时间隔为TimeOutInterval超时重传时间。
计时器超时时 重传最早的未确认段重新启动计时器。
接收到 ACK 时 若 ACK 覆盖了新的未确认数据更新确认边界若仍有未确认数据则保持计时器运行。 TCP 重传场景分析
场景 1提前超时
数据实际上已送达但 ACK 未及时到达 → 触发不必要的重传。
场景 2ACK 丢失
发送方未收到 ACK → 触发重传接收方忽略重复数据通过序列号识别。
场景 3快速重传Fast Retransmit
如果发送方连续收到 3 个相同的 ACK即重复 ACK则假定丢包提前重传无需等待超时。 快速重传Fast Retransmit
前提
只有当接收方收到一个合法的数据段时哪怕乱序才会发送ACK。如果接收方什么都没有收到则不会回复ACK。即没有ACK的定时重传延迟 ACKDelayed ACK机制
RFC1122 规定如果接收方收到按序数据段可以延迟 ACK 最多 500ms看是否还能马上收到下一个段为了合并 ACK但如果没有后续数据到达接收方仍会在500ms 内发送 ACK
快速重传机制
实质发送方在收到三次重复的ACK信号时则认为最后一次ACK后的段丢失于是在计时器结束之前重发段。
event: ACK received, with ACK field value of yif (y SendBase) {// 收到新的 ACK说明有新段被确认SendBase yif (有未被确认的段)启动定时器
}
else {// 收到重复 ACKy SendBase增加该 ACK 的重复次数计数器if (该 ACK 重复次数 3)立即重传该序号的数据段快速重传
} TCP 发送方发送多个段segments时可能是连续的如
1000-10491050-10991100-1149...
如果其中某一个段丢失比如 1050-1099 段丢了接收方收到 1000-1049 后再收到 1100-1149接收方无法按序交付于是就不断重复发送
ACK1050ACK1050ACK1050...
因为接收方“仍然等待字节 1050”。
TCP 利用这种现象连续收到三个相同 ACK比如 ACK1050发送方就假设字节 1050 的段丢失了立刻重传而不等超时。 TCP ACK 生成策略RFC 1122, 2581 接收事件 响应策略 收到预期序列的段 延迟 ACK等待最多 500ms 看是否有下一个段为了合并 ACK 收到连续两个段 立即发送 ACK 收到高于期望序列的段乱序 立即发送重复 ACK指出期望字节编号 收到填补乱序空缺的段 立即发送 ACK
发送方通过流水线协议Pipelined Protocols更细致的利用了滑动窗口机制Sliding Window可能会连续发送很多连续的段并不是Stop-And-Wait在收到ACK之后才发送下一个段。
PSTCP 是滑动窗口协议带重传机制的典型流水线协议实现高吞吐。
接收方只有在收到有效的段不管是否乱序后才会发送ACK且此ACK为“期望的下一字节”即last ACKed数据的下一个seq.#告诉发送方“你应该给我发送的是这一段。”
PSTCP 使用“累计确认”cumulative ACK始终 ACK 最小的、尚未收到的字节编号。ACK 的作用不是“告诉发送方我收到了什么”而是“告诉你我还需要哪个字节”。 TCP 流量控制TCP Flow control 接收方设置接收缓冲区接收方会告知发送方其缓冲区剩余空间RcvWindow发送方限制未确认的数据量不超过接收方 RcvWindow保证不会导致缓冲区溢出提供速率匹配机制发送速率与接收进程读取速率相匹配。 三、公式含义左下角
RcvWindow RcvBuffer - (LastByteRcvd - LastByteRead)
各变量含义如下 名称 含义 LastByteRcvd TCP 接收方已经收到的最后一个字节序号 LastByteRead 应用程序已经从缓冲区读取的最后一个字节序号 LastByteRcvd - LastByteRead 表示缓冲区中“未被应用消费的字节数” RcvBuffer 接收缓冲区总容量 RcvWindow 当前剩余空间spare room
✅ 本质上就是接收窗口 总容量 - 当前正在占用的空间 四、工作机制逻辑
接收方接收到数据 → 放入缓冲区每次发送 ACK 时把 RcvWindow 值带上发送方根据 RcvWindow 控制发送节奏限制未确认数据的量若 RcvWindow 0 → 发送方停止发送当接收方的应用程序读取数据后 → 空间释放 → RcvWindow 增大 → 发送方继续发送。 TCP连接管理TCP Connection Management
TCP连接建立
请记住TCP 的发送方与接收方在传输任何数据段之前必须先“建立连接”。
连接建立过程包括
初始化 TCP 状态变量 序列号Sequence numbers缓冲区、流量控制信息如 RcvWindow 客户端连接发起方
Socket clientSocket new Socket(hostname, port number);
️ 服务器端等待被连接
Socket connectionSocket welcomeSocket.accept(); 三次握手Three-way handshake
详见图 3.39第290页流程如下
重要信息SYN段Synchronize同步段
✅ 第一步
客户端向服务器发送 TCPSYNSynchronize同步段
声明客户端的初始序列号initial sequence number此时无数据只有控制信息。
✅ 第二步
服务器收到 SYN 后回复一个 SYNACK 段
分配接收缓冲区包含服务器自己的初始序列号ISN(Initial Sequence Number)作为对 SYN 的确认。
✅ 第三步
客户端收到 SYNACK 后回复一个 ACK 段
可包含实际应用数据至此连接正式建立双方可以开始传输数据。 ✅ 第一步客户端发送 SYN连接请求
SYN 1, seq client_isn
SYN1表示这是一个连接请求段seqclient_isn客户端选择的初始序列号Initial Sequence Number此时段中没有实际数据但携带了控制信息目的告诉服务器我想建立连接而且我从哪个字节号开始计数。 ✅ 第二步服务器回应 SYNACK连接同意 确认
SYN 1, seq server_isn, ack client_isn 1
SYN1服务器也声明它自己的初始序列号seqserver_isn服务器的初始序列号ackclient_isn1表示确认客户端的初始序列号SYNACK这是一个组合段表示“我同意建立连接并确认你的请求”。 ✅ 第三步客户端发出 ACK确认服务器回应
SYN 0, seq client_isn 1, ack server_isn 1
SYN0说明这是一个普通的数据确认段seqclient_isn1客户端此时的数据序列号已经准备好ackserver_isn1确认服务器的初始序列号至此三次握手完成连接建立。 段字段 含义 SYN1 表示是连接请求或响应 ACKx 表示确认收到了编号为 x-1 的数据 seqy 表示我从编号 y 开始发我的数据 client_isn / server_isn 各自初始化时随机生成的序列号 连接关闭 - 四次挥手
TCP连接的关闭
例如客户端关闭连接
clientSocket.close();
✅ 第一步
客户端的终端系统发送一个 TCP FIN 控制段 给服务器表示“我没有数据可发了”。
✅ 第二步
服务器收到 FIN 后回复 ACK并开始关闭连接
此时服务器可能还有数据未发完或也准备关闭它会随后发送一个 自己的 FIN 段。
✅ 第三步
客户端收到服务器的 FIN 后回复 ACK进入“时间等待”状态TIME_WAIT
TIME_WAIT 会持续一段时间以便 如果服务器没有收到 ACK会重发 FIN客户端仍在监听并确认。
✅ 第四步
服务器收到 ACK 后连接关闭CLOSED。 注意如果两边同时发送 FIN也可以通过轻微修改该过程处理。 3.6TCP 拥塞控制
概览
拥塞窗口cwnd的含义
发送窗口 Min {拥塞窗口cwnd接收窗口}
TCP 发送方感知拥塞的两个事件
TCP 慢启动
相关概念慢启动、拥塞避免、快速恢复、阈值、带宽探测、加法增加拥塞避免状态、乘性减三个重复 ACK
CongWin 即 拥塞窗口Congestion Window 的缩写通常用 cwnd 表示。 作用动态调整发送方的发送速率避免网络过载。
Threshold 即 阈值ssthresh全称为 慢启动阈值Slow Start Threshold 什么是拥塞
非正式定义过多的数据源以过快的速度发送数据导致网络无法处理。拥塞 ≠ 流量控制Congestion ≠ flow control 流量控制是端到端的速率匹配拥塞控制是全网络层面的资源协调问题。
拥塞的表现形式包括 丢包由于路由器缓存溢出高延迟由于路由器排队缓慢
拥塞控制是网络设计中的十大核心问题之一
注意TCP提供的是端到端的拥塞控制发送端根据自身观察判断网络是否拥塞
TCP 拥塞控制
拥塞控制的基本策略
Congestion Window
控制方为发送方发送方动态调整属于流量控制 Flow Control
Receive Window
控制方为接收方接收方Receive Buffer的一部分RcvWindow RcvBuffer - (LastByteRcvd - LastByteRead)属于拥塞控制 Congestion Control TCP 发送方通过控制拥塞窗口Congestion Window, 简称 CongWin的大小限制其发送速率
已发送未确认的数据量 ≈ LastByteSent - LastByteAcked ≤ CongWin
拥塞窗口的性质
是一个动态调整的变量表示发送方当前估计的“可用带宽”随网络拥塞状况而变化。
拥塞的感知方式
TCP 通过以下两种事件判断可能的拥塞 超时Timeout三次重复确认Triple Duplicate ACKs。 TCP 拥塞控制的三大机制
AIMD加性增大乘性减小慢启动Slow Start超时后的保守处理Conservative after Timeout。 AIMD加性增大乘性减小
additive increase, multiplicative decrease
加性增大Additive Increase 每个往返时延 RTT 内将拥塞窗口增加一个 MSS最大报文段大小。就是再Conwinthreshold的时候一个RTT增加一个Conwin的意思差不多
乘性减小Multiplicative Decrease 一旦检测到拥塞例如丢包将 CongWin 减半或者直接设置为1。
整体效果是“锯齿形”增长探测带宽直到丢包发生。 慢启动Slow Start
目的
防止新连接一开始就占用过多网络资源。
原理
初始化时设置 CongWin 1 MSS每收到一个 ACKCongWin 增加 1 MSS即每个 RTT 使窗口 指数增长。
举例若 MSS 500 字节RTT 200ms则初始速率为 20kbps但指数增长很快提升。 区分不同的丢包类型
三次重复 ACK3 dup ACKs 说明网络仍能传送部分段响应较“温和” → 将 CongWin 减半并线性增长。
超时事件Timeout 说明网络可能严重拥塞更“激进” → 将 CongWin 设置为 1 MSS重新进入慢启动。 拥塞控制中阈值的引入Threshold
当丢包发生 Threshold CongWin / 2不同事件触发不同策略 事件 动作 三次重复 ACK CongWin ← Threshold进入线性增长阶段 超时 CongWin ← 1 MSSThreshold ← CongWin / 2 当拥塞窗口 CongWin 达到“阈值 Threshold”时就从“指数增长”切换为“线性增长”。
慢启动Slow Start指数增长到达Threshold 切换点。拥塞避免Congestion Avoidance线性增长。
当发生丢包loss event时
将 Threshold 设置为当前 CongWin 的一半CongWin 回退为 1 MSS或新的起始值重新开始慢启动。 TCP Tahoe检测到拥塞
Threshold 设为一半 CongWin 重置为1再次慢启动从1开始重新指数增长。
没有快速恢复每次丢包都归零非常保守。
TCP Reno检测到拥塞
Threshold 设为一半 CongWin不是重置为1而是快速恢复Fast Recovery到新的Threshold。
直接从 Threshold 开始线性增长更加高效。 TCP 拥塞控制总结
CongWin Threshold处于慢启动阶段 → 指数增长CongWin ≥ Threshold进入拥塞避免阶段 → 线性增长发生三次重复 ACK设置 Threshold CongWin / 2将 CongWin 重置为 Threshold发生超时设置 Threshold CongWin / 2CongWin 重置为 1 MSS。
