文章目录
- 基于UDP应用场景
- TCP协议
- TCP 协议段格式
- 确认应答机制
- 16位窗口大小 下定义
- 32位序号和32位确认序号
- 序号是什么？
- 确认序号
基于UDP应用场景
UDP，tcp这样的协议根本不是直接谈UDP。tcp的应用场景，一定是上层写了应用层协议，所以才有UDP协议的应用场景。
比如http
TCP协议
传输层最重要的协议，几乎没有之一
因为TCP基于通信时保证可靠性，对于高效传输也有一定策略。
TCP协议是目前应用层协议使用时常见的协议。
比如网络版本计算器，底层是TCP套接字。
http底层就是TCP协议，用的也是TCP套接字。
TCP叫传输控制协议
为什么叫传输控制，从何而来
TCP在OS内部存在自己的发送和接受缓冲区。
每建立一个链接的的时候，此时OS内部就要为该链接创建发送缓冲区和接受缓冲区
应用层也要定义缓冲区来接受用户输入，和输出结果给用户–用户级缓冲区
计算器为了能接受请求定义string in_buffer
通过read把数据读上来。
当上层调用write,read接口时，本质不是把数据发送到网络中！
那是什么呢？
比如发送，发送的数据拷贝到TCP的发送缓冲区，应用层就认为数据已经交给了系统。
至于数据什么时候发送，发 送多少，出错了怎么办？
完全由OS，TCP协议自主决定
所以write,read,recv ,send与网络相关的发送接口，本质不是发送函数而叫做拷贝函数
好像在哪里听过啊？
以前讲文件的时候不就是这样吗？
往文件里写也用的wirte接口，所以当时说C语言提供缓冲区，也是用户级缓冲区，我们把数据写到文件里，写到OS内部，要通过fd写入的，每个文件都有自己的文件缓冲区,所以应用层读写文件时把数据写到文件里，本质就是把数据拷贝到内核的文件缓冲区里，至于数据什么时候刷，刷多少，整个刷新细节你不用关心，是由OS和磁盘交互的，今天看来磁盘和网络有区别吗？
把磁盘设备换成网卡，不就完成数据发送，IO吗，冯诺依曼体系结构里文件是IO，往网络里写本质不就是在硬件层面上把内存里的数据写到网卡上，也是IO，大家在理念上是一致的，更何况Linux一切接文件。
从今天开始对于网络的理解，就可以这么认为了
我的应用层只负责对收上来的数据进行协议处理，把报文和报文分开，诸如反序列化，变成结构化数据，根据协议对数据做处理，把数据写好的响应发给TCP缓冲区应用层的工作就完了，至于数据什么时候发由TCP决定。
通信双方都支持TCP协议，所以CS的地位是对等的。所以一方学懂了另一方一样。
应用层把数据本质拷贝到发送缓冲区。
至于数据怎么发，其实把传输层发送缓冲区
的数据导到对方的接受缓冲区里，本质也是拷贝！
只不过这个拷贝工作需要通过网络而已，通过网络可能会出错，所以需要很多策略。
接收方通过read调用时会阻塞，由于接受缓冲区没有数据，有数据则资源就绪了。
后面网络和文件揉在一起说说
解释为什么UDP或Tcp 只有同样一个FD既可以读也可以写，因为一个fd配套两个缓冲区，所以可以即读又写了。-- 全双工
这就是TCP缓冲区的理解。
TCP下层还有协议，我们把数据交给下层，并不是直接发送给对方。
1。传输层的接受缓冲其实就是内存空间
2。OS为了管理对应的内存其实是把整个内存想成一个个4KB空间，所以OS有这么多内存块，OS怎么知道哪些已经被占用了那些没有，那些被锁定了，那些过期了？
OS就要对内存块管理。
为了管理内存所以每个内存块都要有strcut page这样的结构
所以接受发送缓冲区，无非就是多个内存块即strcut page构成的。
OS中用数组把100多万个page管理起来，对内存管理转为对数组的增删查改。
打开一个网络相当于得到一个文件描述符，底层一定有Strcut file对象，Strcut file对象以前指向磁盘，今天网络Strcut file对象指向网络设备，每个Strcut file后面跟上两个缓冲区，由多个4kb构成的，此时上层不变下层直接切换成网络这样的效果。
为什么突然扯到这里呢?
问题
所以为什么叫传输（能理解）控制协议（能理解）？
控制是什么意思？
应用层把数据经过write拷贝到发送缓冲区里，至于发送缓冲区里的数据什么时候发，发多少，本质就是在控制如何发送的问题。
这些工作由TCP协议自主决定，所以把他叫做传输控制协议。
为什么提供发送缓冲区呢？
当前对端来不及接受了，发送端怎么知道呢？用户一直把数据往缓冲区写，因为有缓冲区的存在，即便来不及接受了，但对于应用层来讲，可能并不影响应用层继续向OS拷贝，数据拷贝多了，发送缓冲快满了，OS就让对方接受缓冲区快点拿数据了。
TCP是具有接受发送缓冲区，进行全双工通信的，进行数据发送控制的一种协议。
TCP 协议段格式
应用层 请求和响应
传输层 数据段
网络层 数据报
链路层 数据帧
问题
1、报头和有效载荷如何分离，如何交付给上层？
TCP协议基本结构分三部分
TCP报头前20字节就是TCP标准报头
TCP支持对应的选项–我们忽略但存在
第三部分，TCP协议的有效载荷
如何交付给上层？
前两个字段，端口交付给上层目标进程
对TCP报文向上交付给进程
一行是4字节，0-31
标准报头一共五行，所以标准报头是4x5=20字节
报头和有效载荷如何分离?
当读取TCP数据时，在缓冲区里把前20字节拿出来，报头信息全拿到了，标准报头全拿到了他也是约定长度。
TCP报文里有一个字段，4位首部长度
凡是报文里介绍首部长度，他就真的是。
表示报头总长度，你不是说了标准报头是20字节吗，因为还包含了选项，选项也可以不带。
4位首部长度 【0000，1111】【0-15】
全写成1表示数字也就是15，怎么可能是20 呢？
是不是有问题呢？
不是，因为4位首部长度计算的时候，有基本的大小单位：4字节
则表示长度范围【0，60字节】
所以选项最多是40字节。
如果不带选项，则四位首部长度设为X
x * 4 = 20 => x = 5 = 0101
4位首部长度准确的把报头从整个报文里去掉
报头和有效载荷如何分离我们怎么做呢
实际上先读取前20字节，固定长度，之后根据4位首部长度计算出实际总大小再减去20剩下的就是选项的大小，没有的就不读了，剩下的就是数据
所以如何分离？
固定长度（前20字节）+ 自描述字段
你收到一个数据能不能按照指定字节数对数据做截取呢？
你直接把数据收上来，截取前20字节，整个报文也是结构体，地址强转成结构体指针直接从里面提取4位首部长度，这个4位长度描述是自身的报头大小，所以他叫自描述字段。（我们网络版本计算也带有有效载荷长度，也叫做自描述字段）
固定长度+自描述 的方式 能把标准报头和选项全部读上去，因为标准报头就是20字节，剩下的就是数据，所以能作分离。
1、报头和有效载荷如何分离，如何交付给上层？
搞定
整个报文也是结构体，他所谓的封装是把报头结构体变量形成的对象内容拷贝到数据前面。
能封装，也能拆开
下一个问题
16位窗口大小
左边客户端，有应用层和传输层/TCP
TCP有自己的接受缓冲区和发送缓冲区。
对于服务端也是这个结构
此时应用层构建Http请求
把数据通过write结构写到发送缓冲区里，传输层要发送这个数据给对方，此时要给发送的数据添加TCP报头
没来得及发送的就放到发送缓冲区里，可能有多个Http请求
封装报头经过底层交到对方的接受缓冲区里时，对方收到这个报文要进行报头有效载荷分离，套接字创建出来都要有自己的接收缓冲区，至此去掉报头的Http有效载荷请求放到接受缓冲区中。
问题
你心里要特别清楚，客户端和服务器基于tcp协议进行通信时，互发消息的时候，发送的可是完整的tcp报文哦，即一定携带完整的tcp报头
不管课件如何简写，双方通信时发数据发确认，当你看到数据时可不仅仅是数据他一定要涵盖tcp报头+数据，响应同理
看起来是发syn+ack,本质上是把报头特定的属性字段设置了，归根结底所有请求和响应都要基于tcp报头为载体
发起Http请求时一定要想到请求包含报头一大堆东西的。
tcp一样，报头必须完整
换句话说，C给S发消息时基于套接字，上层来看都是通过fd来读写的。
所以你打开多个套接字建立多个连接每个连接都要有一对收发缓冲区
双方通信时发送的报文携带完整报头
tcp协议要保证可靠性
不可靠的表现呢？
数据传输出现重复，乱序，丢包
发送的过程本质是把数据拷贝给对方，对方接受缓冲区是固定大小的，所以他的剩余空间就少了，如果应用层就不想读，此时发送方应用层给对方一直发消息，客户端和服务器双方进行通信时，客户端不清楚服务器接受能力的，所以客户端一直给服务器发消息时，服务器来不及接受，最终可能导致服务器接受缓冲区被写满，客户端又不知道就继续发，最后导致接受缓冲区没空间导致数据丢包。
所以CS通信时，服务器接受能力很少的时候我们要让客户端发慢点或者干脆不发了，
由发送方向服务端发消息，通过控制发送数据的速度让对方来得及接受从而规避大面积丢包的情况，我们称为流量控制。
tcp注定要解决这个问题
tcp可靠性里有一种叫做丢包重传
如果报文丢失了，发送发可以对服务器补发的。
如果对方来不及接受了出现大面积丢包，tcp害不害怕丢包，不害怕他有重传啊。
可以吗这样，可以。
但有更好的方案啊。
虽然你有重传，但是这样不合理，报文经过千里迢迢到了对端，我没有明显错误却要把我丢弃掉，所以他不合理。
我们不能让他启用重传策略，浪费曾经的发送，效率必定不高
既然来不及接受，那就要发送慢一点
tcp保证可靠性，凭什么说他保证可靠性？
最基本的一个特点：确认应答(最重要的机制）
比如我们两个相隔千里，老师说的话同学听到没听懂没老师不知道，所以老师经常说听懂没，听懂扣1，要求你给我响应的过程就叫做确认应答。
所以暂时认为客户端给服务器发送任何消息的时候，服务器都要对收到的消息进行响应
那你能保证你扣的6，老师一定能看到吗
确认应答机制
CS双方地位对等
如果C给S发消息，即便服务器没有任何话说，但服务器至少要对消息进行一次确认应答。
服务器想给客户端发消息，客户端OS也要立即给服务器确认应答。
这样就能保证对于C来讲，客户端刚刚发的消息服务器收到了。
基于确认应答保证了客户端到服务器方向的可靠性
同理服务器给客户端发消息，客户端做应答保证服务器到客户端方向数据的可靠性
重谈通信过程
客户端向发送消息交给服务器，服务器收到了这个消息，TCP协议要立即给对方应答
问题
无论发送消息，确认应答最后都是tcp报文，无论发的是什么消息什么应答，一定携带完整的tcp报文或者是报头
发送方 发送的量非常大，也很快
导致对方来不及接受，所以需要流量控制，无非就是让客户端发送数据慢一点，要发慢一点依据是什么？慢多少啊？
靠谁来决定呢？
由对方接受缓冲区当中剩余空间的大小决定
对于发送方来讲，发送速度由对方的接受缓冲区中剩余空间的大小决定！！！
剩多少空间让我知道了，我就可以根据你剩余空间最多发送把你缓冲区打满的数据，发满了我就不发了。
关键在于，客户端是给你发送数据，客户端怎么知道你服务器端剩余空间的大小呢？
我们tcp基于确认应答机制的，你发了一个报文我要给你响应，别忘了请求和响应都要是完整的报文，所以发一个消息对方会给我响应的，我收到响应才发 第二个目前认为。
收响应的时候，我就收到来自服务器给客户端发来的响应，响应中16位窗口大小填充就是我服务端接受缓冲区剩余空间大小。
得知对方接受能力是多少，客户端就知道应该最多发多少数据了。
这就叫16位窗口大小。
16位窗口大小填的应该是谁的接受缓冲区剩余空间大小呢？
客户端给服务器发，要进行流量控制，服务器有没有可能给客户端发消息呢？
tcp是全双工的。
所以从客户端到服务器端要进行流量控制，那么从服务器到客户端发送要不要也进行流量控制呢？
要
所以双方互发消息，互相确认应答，双方会出现很多tcp报头往来，双方根据报头里16位窗口大小，互相得知对方的接受缓冲区剩余空间大小，双方就可以进行互相流量控制。
16位窗口大小 下定义
我要填充的报头一定是我要给对方发的。
所以16位窗口填写的是自己的接受缓冲区中剩余空间的大小！！
这么多报头传输效率会不会很低？
后面有滑动窗口
（应用层比如Http有主从关系，你是客户端你只能向服务器发起请求
tcp双方地位对等，即你能向我发送报文我给你确认应答，左侧右侧都要互相有流量控制。
）
32位序号和32位确认序号
tcp说自己有确认应答机制，我们该如何理解确认应答呢？
为什么确认应答是保证可靠性最重要的一个核心点呢？
思考一个问题
这个世界，存不存在100%可靠的网络协议？
例子，我跟你不是面对面，相隔100米
我给你发了个消息，我们去吃饭吧
你回了个好的，这样能保证我给你的消息你是收到了的，但是你怎么知道刚刚说的好的被我收到了呢？
那我要保证你刚刚给我发来的好的消息，我也想让你知道我已经收到了，怎么办呢？我再给你回收到了你的好的了
可是当我给对方发了收到了你的好的了，确实能保证上一次的好的消息被我收到了，可是最新的消息怎么保证对方也收到了呢？那对方再给你个应答吧， 最新的消息怎么保证对方一定收到了呢？
1。站在我个人角度只要我收到应答，我就能保证我最近一次发送的消息对方收到了。
同理对对方也一样
2。没有应答的数据，我们无法保证可靠性，所以最新的一条消息，不管是我给对方说，还是对方给我说永远存在最新的一条消息，是没有应答的，所以在人类世界里几乎无法保证发出的消息时100%可靠的！
所以世界上不存在100%可靠的协议的
虽然整体不存在，但是局部上呢？
我刚给你发的消息，我给你应答，对你来讲，你并不确定这个应答我是否收到，对我来讲我只要收到对应的应答，我能保证从左向右方向上数据的可靠性。
对右边来讲，右边给左边发的消息只要右边也收到应答，他无法保证 最新的消息被自己收到，但只要右边收到了应答，就能保证从右向左的可靠性
虽然最新的一条消息没有应答，无法保证最新的一条消息可靠，但是局部上最新消息之前的消息我们其实是可以保证双方在两个方向上的可靠性。
这样说有点抽象，直接说tcp真实的方案
左C，右S
tcp最基本，最原始的通信过程
所以刚刚场景中，除了最新的消息，上面之前每一个报文的都有应答
所以之前的消息能保证各个方向上的可靠性
正常情况不会存在这样的场景的
我给你发个消息，你给我应答了，收到了，站在我的角度呢我就不再给你发消息了。
我们没必要对应答再作应答，实际上是鸡生蛋，蛋生鸡的问题，无穷尽了。
CS通信最终要的是保证两个方向上的可靠性
所以C给S发一条消息，tcp数据
S要合适的时候对消息进行应答，因为是客户端给服务器发消息，我要保证消息被对方收到了，我是主动的对方被动，我只要保证我发的消息被对方收到了，这不就达到了宏观层面上我们两个通信的目的吗。
所以我给对方发消息，对方只要给我应答，我收到应答时能保证我发的消息被对方收到了，这就叫保证客户端到服务器方向上的可靠性。
我们不需要再对应答再给S进行响应。
如果服务器要给客户端发消息tcp数据本质也是完整的tcp报文。
服务器是主动的一方，他要给客户端发消息，本质的目的就是想确认把这个数据发送给C，包括C给我做应答，你也是告诉对方你刚给我发的消息我已经收到了。
所以C也给S发了个应答
虽然C不能确定应答有没有被S收到，暂时我们不管，但假设S收到了应答，服务器立马就意识到我刚刚发的消息对方也收到了，所以只要收到应答，我们从右向左的可靠性也能保证。
所以要发送的一个数据，对应配套的收到应答，就能保证两个朝向上的可靠性。
所以第一阶段总结论
CS基于tcp通信时，我发的消息你给我应答，服务器给应答就行了，假如客户端收到这个应答，我就能保证从左向右的可靠性
最终所以工作都是围绕着发送的tcp数据是否被对方收到
1。S收没收到他自己清楚
2。只要C知道发送成功了，C就不管了，发送失败还有其他策略。
所以确认应答机制本质是使用了对应的局部上只要收到了我们收到了应答就能保证历史消息被对方收到这样的结论
有人就想到了，那要是应答丢了呢？
我作为C给S发消息，S给我进行应答，万一应答丢了呢？
站在C角度不就是他发出去的消息没有应答吗，此时已经是对应的答案了。没有应答客户端就认为对方没收到，所以进一步重发就可以了。这里其实有个问题，C给S发消息，S给C发应答，C怎么知道自己没有收到应答呢？
因为我们应答是由S响应回来的，没有收到应答前客户端连自己发出去的数据是不是丢失客户端都不确定，所以C确认自己有没有收到应答呢，C不是一直要等，万一数据丢了永远不会有应答，所以对C来讲怎么保证有没有收到应答？
C会进行一段时间，如果没有收到应答，C认为数据丢失了，此时重传就可以了。
作为C来讲，C要给S发消息，所以最重要的事情是保证C给S的消息被S收到了，S有没有收到消息他自己最清楚，最重大的问题是C不知道自己有没有被S收到，所以原则上只有C给S发过去的消息，S给了应答就认为我给对方发的消息对方收到了，所以保证从左向右的可靠性，从右向左一样。
所以我在把消息发出去的时候，在我没有收到应答之前，实际上对应的发送方要把数据暂时的维持一段时间，当我收到应答才把这个数据去掉。
这里有涉及滑动窗口后面说。
所以tcp保证可靠性，只要我收到了应答我能保证我刚发的消息对方一定收到了。
同样的对方给我发消息，我也会给对方做应答
通信不就是这样吗，我要可靠的把我的消息发给你，你要可靠的把消息发给我，现在目的达到了吗？
达到了，只有我收到应答就行了，没有应答就丢了。
细节
1我们一起去吃饭吧
2好的
2吃什么呢？
1饺子吧
1可不可以呢？
2 好的
我们会不会这样沟通呢？
很少
我们应该是
1我们吃饭吧
2吃什么啊
3饺子
2吃什么啊
这句话本身是既带确认，又挟带了对方想给我发的消息
所以我给对方发消息，对方给我应答，对方可能也想给我发消息，我给对方应答。
这种通信方案比如下图
让S响应 应答 S后面还发了报文，此时是发了两个报文的
不要忘记了，每一个报文都是一个完整的tcp报头，虽然标记位一个都没学，但是图中发两次这种方式比较低效率。
所以C给S发消息，S说好的，S可能也要给客户端发消息，所以此时可以把两个消息应答+我要给对方发的消息二合一，形成一个对应的响应，既是对客户端的响应，又是服务器想给C发消息，这种策略叫做 捎带应答
C也可以采用同样的策略，我们两个实际通信时纯粹的应答可能会比较少，双方通信时还是你来我往的。
这就叫做可靠性这是第一个。
虽然应答可能丢失，经过是否收到应答，就能评判刚刚发的消息对方是否收到，这是最重要的。
这其实是tcp最原始的通信过程
这样是可以的
但是如果客户端要给S发很多消息，如果S还没有给我应答的时候，我的C能不能发第二条消息，我发第二条消息客户端还没应答时，能不能发第三条消息？
从最原始的通信过程来看，我们收到应答才发第二条消息。
对于发送方来讲，发送数据的过程全部都是串行的，发一个消息得到应答才能发下一个，这样tcp通信效率非常低下。
C给S发消息的本质最终我只是要把一批消息被服务器全收到，只要客户端能收到各个数据应答就行了。
所以主流tcp并不是这种发一个应答一个，这样效率太低。
客户端可能会向服务器一次发一批消息，之后呢，服务器原则上针对每一条消息进行应答，只要客户端收到了历史上发过去每一个报文的应答，虽然我们是并行一次发了大量数据，但只要每一个都有应答，我们照样可以保证客户端向服务器方向上的可靠性，只要我收到应答就行了。
这是tcp比较常规的工作方式
那我一次发多少呢？万一中间出现丢包怎么办？
先暂时不管，后面说。
现在的问题就是C存在给S发送很多报文，每一个报文都是挟带报头和数据的信息发过去了。
客户端发过去的消息按顺序发出，S是否一定按顺序接受呢？
不一定！
就像你们班全去旅游，出发顺序和到达顺序不一定一样，今天同样受网络影响。
所以S收到的本质是把数据放到接受缓冲区里，收到的消息可能并不是我们曾经发送的顺序，这种情况叫做数据包乱序问题。
如果我们不管这个问题，直接把数据（图里黑色乱序上边一堆圈圈）交到接受缓冲区里，最后直接按乱序交给应用层会带来什么后果呢?
应用层解析请求全都是乱的。
所以乱序本身就是不可靠的一种。
所以怎么保证对应的可靠性呢？不乱序呢？
首先数据包按顺序到达对于S来讲是不保证的，因为网络路由网络路径可能有差别，可能刚发出去第一个路由器就坏了。
所以每一个tcp报头里会包含序号的东西。
给第一个报文带1，第二个带2，但事实不是这样的。
只要序号给对方发过去了，到了服务端收到乱序也没关系，我们可以根据序号对收到的报文进行排序就可以保证可靠性。
序号的核心作用之一叫做 保证数据的按序到达
可是你说的序号是什么意思呢？
确认序号又是什么鬼呢？
序号是什么？
不着急，同学们，慢慢的它把答案揭晓出来
只有慢慢的把前因后果交代清楚，很多东西才有逻辑，凡是被理解的东西才可能记忆深刻。
横向上 用户层
下层 tcp发送缓冲区
我们对于tcp发送缓冲区的理解，我们可以把它想象成chat outbuffer[N]
tcp面向字节流，所以tcp把缓冲区看出char类型的大数组，所以用户层拷贝下来的任何数据说白了不就是一堆二进制或者叫做char类型数据，我按八个bit位为单位。
所以你自己拷贝下来的数据其实在缓冲区里是按顺序存在的。
我们上层拷贝下来的数据在缓冲区里按照一个字节一个字节存在的。
不要说你上层是Http，Http在我看来就是一个大字符串，只不是按\r\n区分行的，都是字符，哪怕是二进制的在我看来都是按字节为单位陈列的。
你不是面向字节流吗缓冲区，比如Http请求就有可能如此陈列
意思就是上层拷贝下来的所有内容就按字节方式全部读走了，然后我们对应的，假设今天第一个tcp报文给对方发送若干字节，
当我把上层数据拷贝到发送缓冲区里，其实我把他当成char类型数组时，其中接受缓冲区里每一个字节都有天然的编号（本质就是数组下标）
假设我今天要发送的数据块，因为我可能发送不是一个字节一个字节发的，我一次发一批。当我把这批想发出去的时候，整个这个报文将来被封装的时候，他所填充的序号就是最后一个报文所对应的下标数字，就称为它的序号
所以发送数据的本质就是把缓冲区里的数据从左向右依次发送到网络里，从左向右的过程每次发送对应的一堆数据，每个数据块对应的序号我们都是以最后一个字符为准的话，他就叫对应的序号了。
课件上第一个报文序号应该是1000后面说
数组本身下标是连续的，当我收到报文之后就能根据序号进行排序就可以了。
这样就能保证按序到达了。
那万一丢包了呢？
我怎么知道是哪些报文被对方收到了呢？
以及确认序号是什么意思呢?
问题是我怎么知道响应是对哪个报文的响应？
确认序号
填充的是，收到报文的序号+1
这是他的约定
为啥要这么规定啊？
确认序号的意义：表示确认序号之前的数据，我已经全部收到了！
也就是1001之前的数据我全都收到了
下次发送，请从确认序号指定的数字开始发送！
发一个1000，给你响应1001，对于客户端来讲，读到应答
1。他能确认自己刚刚发的1000序号的报文对方收到了。他能保证这个应答就是给他的
2。1001表明1001之前的所有数据服务器全收到了。
3。客户端在发送就应该从1001开始继续发下一个报文。
为什么规定序号值1000还要+1呢？
因为假设应答丢了，1001，2001丢了，但是3001却收到了。
你发送了大量数据，我给你响应3001，此时我们不管1001，2001了我们认为3001服务器已经报3001之前的数据全部收到了，通过这样的规定，我们允许应答有少量的丢失
教材写的是1001-2000 实际上就是2000
问题
不管请求还是应答本质都是tcp报文，只不过应答不需要带数据，请求带数据
我给对方发了一个数据请求，我用序号，服务端给对方应答的时候它直接复用序号位就行了，我用一个序号，比如你给我序号1000，我还用这个序号加1，在写回去，然后把这个报文返回给你，此时我用一个序号就可以了，就完成了请求和应答的过程
我为什么要搞两个一个序号，一个确认序号呢？
应答的时候又没有数据，那你直接把序号复用就行了啊，我们约定用一个序号就行了啊
为什么非得在报头里看到两个序号呢
原因在于
两个场景理解他的
1。客户端给服务器发消息，服务器给我应答同时也可能想给我发消息，所以他也可能挟带数据，对于服务器来讲基于捎带应答既是应答也是数据，对于S给C响应应答此时使用确认序号，它本身也携带数据需要由客户端对它做响应，所以他就使用序号。
任何报文可能有双重身份，所以序号和确认序号可能同事存在，所以协议里必须把两个序号分开，不能复用。
2。通信时，CS地位是对等的，所以互发消息的情况很常见，CS互发消息，所以序号的问题还是分开。
所以就有两个序号。
问题
应答的确认序号，为什么要填充收到的报文+1？
这是一个规定
发个序号1000，你应答1001
我能确定应答是对1000的应答，因为1001-1就是1000
所以1000报文被对方收到了
另外1001之前的数据对方全收到了。
此时允许应答有部分丢失
理由不充分
快重传再聊
保留6位，16位检验和 不谈
选项不谈
tcp协议中携带了6个标记位
实际上S会收到来自多个C的请求
因为S和C 比重 1：n
tcp 通信时，建立连接
正常的数据通信
tcp通信完了，断开连接
建立连接要三次握手，断开连接要四次挥手
tcp建立连接的时候，我虽然不懂C和S怎么建立连接的，但我知道你一定要发送tcp的报文，包括接下来正常的数据通信时，和断开连接时。
所谓的三次握手不就是C和S来回三次通信，只要进行通信，你一定要互相发送完整的TCP报文。至少要有报头可以没有数据。
不管你建立连接还是正常通信还是断开连接，你们都是要发送tcp报文的。
所以呢？
所以通信之前呢我们有些tcp请求是用来建立连接的，有的是把数据交给服务器的，有的功能性是用来断开连接的，这就注定了服务器收到了tcp的报文本身是有类型的。
不同的类型，决定了S要做不同的动作！
例如
如果你发了建立连接的请求，S应该要和你进行三次握手的动作，而不是正常的发送数据，如果你发的是断开连接的请求，我就要
四次挥手，并且断开连接的过程，如果是正常的数据通信，我才把收到的报文进行报头和有效载荷分离，然后把收到的报文放到tcp的接受缓冲区里然后交付上层。
所以不同的报文类型决定了服务器要做不同的动作。
问题是我们的C和S双方通信时，一定是互相发送的是完整的tcp报文
建立连接和断开连接可能只含有tcp的标准报头，正常通信时可能有数据
所以问题是
接收方，如何得知，报头的类型各自是什么呢？
所以我们需要tcp里存在6个标记位
标志位存在的意义：区分tcp报文的类型！！！
下一篇
我们进入六个标记位
和tcp的具体可靠性和效率的策略如何保证。
UDP报文。
报头是定长的，UDP报头里有个UDP长度能算出有效载荷长度
可是tcp协议里只有报头长度，他没有有效载荷长度，不知道你发现没？
因为它是面向字节流的后面说。
那接收方咋知道有效载荷多长？
对方为什么要知道啊，对方不需要知道，tcp保证可靠性你一直发我就一直收，字节流，不像udp，字节流我不需要知道长度，你不发你就关了，关了读到0我就认为你完了，我tcp协议不对报文做任何解释，你带了长度报文和报文之间不就有间隔了吗，对我来讲不是，你给我发的数据，你发了多少我放多少，原封不动放到缓冲区里。
这就叫做字节流。
所以网络版本计算器为什么读取时，要先读取len\r然后再读取有效载荷，因为它是面向字节流的，他的报文之间没有边界，后面我们会谈数据包粘包问题，到时候就知道字节流是何意了。
发送缓冲区有没有可能缓冲区不够了，发送缓冲区和接受缓冲区实际上是环状的。
序号是循环的吗，还是一直增大？
序号是一直增大的，达到一定程度会回绕的，回绕数字非常大，一般出现不会冲突。