目录
一. 认识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 协议有标准长度：20字节。因此，先读取前 20 字节。
- 这 20 字节转换为结构化数据后，立刻提取报头中的 4 位首部长度字段。
- 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 下，统统皆文件。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 回应 Client，Client 也必须给确认。
同理，这也保证了 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 个标记位，结合应用层和传输层的角度，解释三次握手四次挥手~
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
