黑龙江做网站公司,广州网站建设设计哪家好,企业站系统,国外文创产品设计目录
一. 认识TCP协议的报头
1.TCP头部格式
2. TCP协议的特点
二. TCP如何封装与分用
TCP 报文封装与解包
如何封装解包#xff0c;如何分用
分离有效载荷
隐含问题#xff1a;TCP 与 UDP 报头的区别
封装和解包的逆向过程
如何分用 TCP 报文 如何通过端口号找到绑…
目录
一. 认识TCP协议的报头
1.TCP头部格式
2. TCP协议的特点
二. TCP如何封装与分用
TCP 报文封装与解包
如何封装解包如何分用
分离有效载荷
隐含问题TCP 与 UDP 报头的区别
封装和解包的逆向过程
如何分用 TCP 报文 如何通过端口号找到绑定的进程
数据交付给进程的过程
总结
三. TCP 的可靠性
学习 TCP 可靠性 (确认应答) 提高传送效率
1. 网络传输中的不可靠问题
2. 网络传输中的不可靠性场景
3. TCP 可靠性的保证机制
4. TCP 收发消息的工作模式
5. 捎带应答机制
6. 批量确认的工作模式
四. 理解TCP的报头
1. 4位首位长度
2. 序号和确认序号TCP 全双工通信与确认应答机制
2.1. TCP 真实工作模式
2.2. 问题分析
2.3. TCP 报文序号机制
2.4. 确认应答的机制
2.5. 丢包场景下的应答机制
2.6. 两组序号的必要性
2.7. 数据到达顺序与序号
3. 窗口大小TCP缓冲区与流量控制
缓冲区的作用
数据传输过程
流量控制的必要性
流量控制机制
全双工通信
交换接收能力 TCP报头细节很多我们打算这样开始
认识TCP协议的报头 — 字段如何理解TCP的报头如何封装解包如何分用学习TCP可靠性(确认应答) 提高传送效率
一. 认识TCP协议的报头
1.TCP头部格式
TCP全称“传输控制协议”(Transmission Control Protocol)它对数据传输进行了详细的控制。TCP头部包含多个字段每个字段都有特定的功能以确保数据能够可靠地从一个端点传输到另一个端点。
理解TCP的报头
Linux内核是C语言写的在UDP说过报头是协议的表现而协议本质就是结构体数据。所有tcp报头就是一个结构化或位段。 struct tcp_hdr这是一个类型可以定义出一个对象。 把应用层的数据拷贝到缓冲区里然后把报头拷贝到前面不就是添加报头吗~
TCP协议报文也有自己的报头有效载荷这个有效载荷是应用层的报文当然包含应用层报头和有效载荷。
源/目的端口号: 表示数据是从哪个远端进程来, 到服务器哪个进程去序列号用于解决网络包乱序问题每次发送数据时累加数据字节数。确认应答号指下一次期望收到的序列号帮助解决丢包问题。4位TCP报头长度表示该TCP头部有多少个32位比特最大长度为60字节。 6位标志位 SYN: 希望建立连接。ACK: 确认应答字段有效。FIN: 断开连接。PSH: 提示接收端应用程序立刻读取数据。RST: 要求重新建立连接。URG: 表示紧急指针字段有效。 16位窗口大小表明接收缓冲区还能容纳多少数据。16位校验和验证整个TCP段的完整性。16位紧急指针标识紧急数据的位置。40字节头部选项提供额外的信息或功能。
2. TCP协议的特点
面向连接TCP必须先建立连接才能进行数据传输。可靠无论网络状况如何变化TCP都能保证数据的正确传递。字节流消息无边界可以传输任意大小的数据并且保持顺序。
二. TCP如何封装与分用 4位首部长度表示TCP头部的总长度。如何封装将应用层的数据加上TCP头部后交付给IP层。如何分用根据头部长度计算出有效载荷的位置并提取数据。 TCP 报文封装与解包
报文宽度0-31 bit 是这个报文的宽度。每行4个字节总共5行因此标准 TCP 报文的长度是20字节选项部分暂不考虑。TCP 报文标准长度标准 TCP 报文长度是20字节。
如何封装解包如何分用
作为接收方如何保证把一个 TCP 报文全部读完呢其实很简单具体步骤如下
读取 TCP 标准报头 TCP 协议有标准长度20字节。因此先读取前 20 字节。这 20 字节转换为结构化数据后立刻提取报头中的 4 位首部长度字段。
计算 TCP 报头总长度 4 位首部长度字段表示的 TCP 报头总长度。其值范围为 0000-1111即 [0,15]。4 位首部长度字段单位为 4 字节因此 TCP 报头总长度 4 位首部长度 * 4 字节。报头长度范围为 [0,60] 字节。由于标准报头长度是 20 字节因此最终 TCP 报头长度范围为 [20,60] 字节。
确定报头长度的计算 若报头长度是 20 字节则 4 位首部长度应填写为x * 4 20因此 x 5即 0101。
计算选项长度 如果 TCP 报头长度为 x * 4则减去 20 字节的标准长度后剩下的即是选项的长度字节数。若无选项则 x * 4 - 20 0若有选项则继续读取选项部分长度。
分离有效载荷
一旦读取完 TCP 报头剩下的数据即为有效载荷将其放入 TCP 接收缓冲区供上层继续读取。
隐含问题TCP 与 UDP 报头的区别
UDP 报头包含了 UDP 报文的长度因此很容易确定 UDP 有效载荷的长度。TCP 报头仅包含 TCP 报头长度但并未明确有效载荷长度。这是因为 TCP 是面向字节流的协议。
封装和解包的逆向过程
解包完成后封装的过程也可以反向推导出来。只要能解包就可以逆向封装报文。
如何分用 TCP 报文
在 TCP 报头中有 目的端口号通过该端口号可以定位应用层的进程将数据交付给相应进程。
如何通过端口号找到绑定的进程
当接收到一个报文如何找到绑定了特定端口的进程呢以下是过程解析
网络协议栈与文件的关系 虽然 PCB协议控制块通过双链表进行组织和管理但为了快速定位进程系统将每个 PCB 添加到一个数据结构中——哈希表。系统中bind 绑定一个端口时会在 OS 中以端口号作为 key 维护一张哈希表。
通过哈希表定位进程 当收到一个目的端口号 8080 的报头时OS 会使用端口号查找哈希表迅速找到与该端口绑定的进程 PCB。 数据交付给进程的过程
找到进程后如何交付数据 每个进程的 PCB 都维护有一个文件描述符表。文件描述符表的 0、1、2 是默认占用的假设进程打开的文件描述符是 3此时 socket 对应的就是 3。
Linux 文件系统与网络协议栈的关系 在 Linux 下一切皆文件。OS 为了维护文件创建了一个 struct file 结构内含许多读写方法的函数指针。Linux 下文件的读写方法通过函数指针实现对应文件的读写方法实际是传输层的读写方法。文件还有自己的缓冲区用于存放数据。
读写过程 当传输层收到 TCP 报文后会将报头和有效载荷分离。有效载荷被放入文件的缓冲区中上层应用通过文件描述符读取缓冲区即可获取数据。
总结 数据报文经过 OS 各层处理最终将有效载荷存放到文件的缓冲区中。上层应用可以通过文件的方式统一读取网络数据实现了网络数据的封装与解包。
三. TCP 的可靠性 32位序列号对每个字节的数据编号确保按序到达。32位确认应答号响应历史数据确保数据被正确接收。确认机制通过序列号和确认应答号来保证数据的可靠性。 学习 TCP 可靠性 (确认应答) 提高传送效率
1. 网络传输中的不可靠问题 ❓ 谈 TCP 必谈可靠性但在讨论可靠性之前先考虑几个问题 为什么网络传输时会存在不可靠的问题不可靠问题常见的场景有哪些TCP 的可靠性如何保证 以前我们学过冯诺依曼体系结构里面包括 CPU、内存、外设如显示器、键盘、鼠标、磁盘等这些设备都是独立的。但我们可以将键盘的数据放入内存也可以将内存中的数据传送到 CPU这说明各个硬件并非孤立的它们之间是有联系的。这些设备通过计算机中的“线”连接。
内存和外设之间通信通过 I/O 总线。内存和 CPU 之间通信通过 系统总线。
内存和外设之间的通信也有自己的协议。因为有协议所以可以控制外设。而这类协议的开发者通常属于“嵌入式”领域。
虽然内存和外设之间有通信协议但我们并未讨论它们之间的可靠性问题。原因在于它们之间的距离很近不存在网络传输中的可靠性问题。 2. 网络传输中的不可靠性场景
为什么网络传输时会存在不可靠的问题
原因传输距离变长了。
常见的不可靠场景有哪些
丢包乱序重复校验错误
3. TCP 可靠性的保证机制
如何理解 TCP 的可靠性 假设两个人 A 和 B 之间相隔 500 米A 问 B“你吃饭了吗” A 不能确定 B 听到了除非 A 收到 B 的应答。所以只有在收到应答的情况下A 才能确认 B 听到了这句话。
但当 B 给 A 回复“我吃了”时B 也无法确定 A 是否收到了这条信息。同样只有当 A 回应后B 才能确定 A 收到了“我吃了”这条信息。
这个例子说明了以下两点
只有收到了应答才能100%确认对方收到了之前的信息。 —— 确认应答后消息才算可靠。通信中总会存在最新消息没有得到应答的情况。 —— 最新消息一般无法保证可靠性。 因此传输距离变长后不可能存在绝对可靠性只能保证相对可靠性。只要收到应答就能保证该报文的可靠性。这就是 TCP 可靠性的基础确认应答机制。
4. TCP 收发消息的工作模式
在学习 TCP 时需要理解两种工作模式
理论上的便捷理解方式。实际工作中的 TCP 工作模式。
实际通信过程
Client 发起请求Server 必须给确认。 由于应答的存在Client 可以确认 Server 100% 收到了请求因此可以保证 Client-Server 的可靠性。Server 回应 ClientClient 也必须给确认。 同理这也保证了 Server-Client 的可靠性。
因此通过确认应答机制双方的数据传输都能保证可靠性。这些请求和应答是通过封装成 TCP 报文进行发送的。在实际通信中除了正常的数据段通信时也包含确认数据段。
5. 捎带应答机制
在实际工作模式中确认应答可以与对请求的响应一起打包发送。以 A 和 B 的例子为例A 问 B “你吃饭了吗” B 本来应先确认收到消息再回复“我吃了”。但 B 可以直接回复“我吃了”这一条消息既是对 A 的确认应答也是 B 给 A 的新消息。这就是所谓的 捎带应答。
6. 批量确认的工作模式
另一种工作模式是 批量确认。Client 可以一次性给 Server 发出多个请求Server 则可以批量确认这些请求而非逐条应答。这种模式下请求和应答是并发的。 不管是串行确认还是批量确认原则上无论是 C-S 还是 S-C每个正常的数据段都需要应答来保证可靠性。但最新的一条消息是没有的
明确了上面的理论知识可以帮助接下来我们谈tcp报头里序号和确认序号 四. 理解TCP的报头
16位校验和选项我们不考虑接下来学习tcp报头剩余字段以及背后的知识。
1. 4位首位长度
序号和确认序号等会谈先谈4位首位长度
上面其实已经提到了概述如下
4位TCP报头长度表示该TCP头部有多少个32位bit(有多少个4字节)所以TCP头部最大长度是15 * 4 60
2. 序号和确认序号TCP 全双工通信与确认应答机制
今天客户端 (c) 可能向服务器 (s) 发送信息也可能是服务器向客户端发送信息。由于双方都使用 TCP 协议所以 TCP 的双方地位是对等的。要了解 TCP只需要搞清楚一个方向的通信过程反过来另一个方向的通信也是一样的。
2.1. TCP 真实工作模式
Client 可能一次给 Server 发送多个请求报文而 Server 也可以一次给 Client 发送多个确认应答。
2.2. 问题分析
数据的顺序问题 如果客户端一次给服务器发送多个请求数据到达对方的顺序是否和发送顺序一样 答案是不一定数据在网络传输中可能乱序到达。确认与请求的对应关系 当 Server 连续收到多个请求后要对请求进行确认。那么Client 如何知道这些确认是对应哪个请求的呢 假设客户端发了4个请求服务器只回了3个确认那客户端必须知道自己发了4个请求且只收到了3个确认这样才能判断哪个报文丢失了。
2.3. TCP 报文序号机制
为了保证每个请求和应答可以对应上TCP 请求报文数据段需要有方式标识数据段本身因此每个数据段都有自己的 32位序号。
每一个请求和确认应答都是一个 TCP 报文有数据的包含有效载荷没数据的只包含 TCP 报头。每个 TCP 报文都会填充一个序号确保报文有序。
2.4. 确认应答的机制
Server 给 Client 的应答报文中需要和请求报文一一对应。因此应答报文的报头中会包含确认序号这样 Client 可以知道应答是对哪个请求的。
序号与确认序号的对应规则 假设 Client 发送了序号为 1000 的报文Server 的确认序号将是 1001。如果 Client 发送了序号为 2000 的报文Server 的确认序号则为 2001。也就是说你发过来的报文序号是多少确认序号就是发过来的序号 1。 确认序号的含义 确认序号表示接收方已经收到了该序号之前的所有报文连续且无遗漏并告知对方下次发送从该确认序号开始。
2.5. 丢包场景下的应答机制
如果某个报文丢失了比如
Client 发送了序号为 2000 的报文丢失了Server 只收到了序号为 1000 和 3000 的报文。Server 对序号为 1000 的报文返回确认序号 1001但由于 2000 丢失了即使收到了 3000 号报文确认序号依然是 1001因为 2000 之前的报文不是连续的。为什么这样设计 这是为了支持 TCP 的滑动窗口机制使得确认序号可以线性右移从而保持可靠的数据传输。
2.6. 两组序号的必要性 ❓ TCP 报文为什么要有两组序号 请求和应答的序号不能共享吗 不能。因为 TCP 是全双工通信双方可以同时发送和接收数据。 当 Client 给 Server 发信息时Client 使用自己的序号Server 给出确认序号。同时Server 也可能给 Client 发送信息这时 Server 需要自己的序号Client 也需要给出对应的确认序号。 因此TCP 报头必须有两组独立的序号一组用于发送方的数据序号另一组用于接收方的确认序号。
捎带应答 当发送应答时可能同时捎带发送给对方的数据因此需要同时包含序号和确认序号。这是 TCP 通信中的常见模式。
2.7. 数据到达顺序与序号
如果客户端一次给服务器发送多个请求数据的到达顺序可能与发送顺序不同。但是由于报文中携带了序号可以通过序号对乱序报文进行排序保证数据的完整性和可靠性。
3. 窗口大小TCP缓冲区与流量控制
缓冲区的作用
发送缓冲区用于暂时保存应用层通过IO接口拷贝过来的数据等待通过网络发送。接收缓冲区用于暂时保存从网络接收到的数据直到被应用层读取。 数据传输过程 客户端Client将数据从应用层拷贝到其发送缓冲区。数据通过网络传输到服务器Server的接收缓冲区。服务器同样将响应数据从其应用层拷贝到发送缓冲区并通过网络发送回客户端的接收缓冲区。 流量控制的必要性 地理位置远近客户端与服务器可能相隔很远。发送速度不匹配 如果客户端发送数据过快而服务器来不及处理会导致服务器接收缓冲区溢出后续到达的数据包将被丢弃。反之如果发送速度过慢则会影响对方上层业务的正常处理速度。
合适的速度为了确保数据传输既不过快也不过慢需要一种机制来调节发送速率。 流量控制机制 反馈机制发送方需要知道接收方的接收缓冲区剩余空间大小以调整自己的发送速率。16位窗口大小TCP头部中的16位窗口大小字段表示的是接收方当前接收缓冲区的剩余空间大小。 发送方根据这个窗口大小调整其发送速率。这个字段填入的是接收方的接收缓冲区剩余空间大小而不是发送方的。 全双工通信
双向控制在全双工通信中双方都需要知道对方的接收缓冲区剩余空间大小。 客户端和服务器都需要保证对方能够以适当的速度接收数据。因此每个方向上的TCP报文都包含一个16位窗口大小字段表示自己的接收缓冲区剩余空间大小。
交换接收能力
双向流量控制这套规则对客户端和服务器同样适用实现了双方在两个方向上的流量控制。目的确保双方都能以合适的速度进行数据交换避免缓冲区溢出或处理速度跟不上。
通过这种方式TCP协议不仅确保了数据的可靠传输还有效地管理了网络带宽的使用提高了整体的通信效率。
下篇文章讲继续讲解 6 个标记位结合应用层和传输层的角度解释三次握手四次挥手~
