个人主页 ： 个人主页
个人专栏 ： 《数据布局》 《C语言》《C++》《Linux》《网络》
前言
本文是我对于TCP协议-报头字段的知识总结
一、TCP协议格式
16位源端口号 和 16位目的端口号
16位源端口号：标识发送方应用步伐的端口号，是一个16位的字段。通过源端口和目的端口，可以唯一确定一个TCP毗连。
16位目的端口号：标识接收方应用步伐的端口号，同样是一个16位的字段。与源端口一起，用于确定数据应被哪个应用步伐接收。
4位首部长度
TCP协议怎样解决 报头和有用载荷分离的问题？ 其中 报头 为 TCP标准报头长度(20字节) + 选项。
TCP标准报头长度是固定长度好分离，但选项的长度不确定，该怎么办？
4位首部长度表示 TCP标准报头 + 选项 的大小。
4位首部长度的取值范围为[ 0000, 1111 ]转化为10进制也就是[ 0, 15 ]，那这不还没有TCP标准报头长度大吗？我们还规定首部长度的基本单元是4字节，也就说4位首部长度的取值范围是[ 0, 60 ]，选项最多40个字节。
如今我们算一下TCP标准报头的4位首部长度，TCP标准报头是20字节，那4位首部长度是5，转化为2进制就是0101 。
注意：TCP的报头长度必须是4的整数倍，因为基本单元是4字节。
16位窗口大小
- 16位窗口大小：表示接收方愿意并能够接收多少数据。用于实现TCP的流量控制机制。
那我们怎样明白16位窗口大小？我们先看下图。
我们都知道，TCP具有发送和担当缓冲区，即TCP是全双工通讯。发送数据就是把数据拷贝到操纵体系内的发送缓冲区，再从发送缓冲区到接收方的担当缓冲区。
那如果发送方不停疯狂的向接收方发送数据，此时发送方不清晰接收方的担当本事(担当缓冲区的剩余空间大小为担当本事)，发送方发送数据太快，导致接收方来不及担当数据，接收方的担当缓冲区满了。发送方还是发送数据，那接收方担当到数据，就会直接抛弃。虽然TCP有重传机制，可以重新发送数据，包管可靠性。但这不合理且不高效，数据历尽艰苦从网络到接收方，接收方却直接抛弃了。
那要怎样使如许的情况合理？如果接收方来不及担当数据了，发送方就慢点发，甚至等会再发。我们把这种如果对方来不及担当，就要求发送方发送变慢，甚至停止发送的策略，叫做流量控制。
对于流量控制的前提是：发送方可以知道接收方的担当本事。那发送方有怎样知道接收方的担当本事呢？
这就要先简单的看看确认应答机制了。如 client给server发送一条消息，TCP为了包管可靠性，要求接收方对发送方发过来的消息举行确认，即只要client收到server发送简直认，client就会以为server收到 “hello” 这条消息，包管client 到 server 的可靠性。
要注意其中"hello"这条消息是TCP报文。
如今发送方每发送一条消息，都会收到接收方的应答消息。那么发送方就可以从应答消息中的16位窗口大小来判断，接收方的担当本事，从而制止发送方发送的数据因为接收方缓冲区满了，而直接抛弃的问题。
注意：16位窗口大小，是指自身的担当缓冲区中剩余空间的大小。
32位序号 和 32位确认序号
我们先来看两种TCP发送数据的方式：
先看串行发送，client每发送一条数据后，必须得到server发送的ACK，才能继续发送数据。如许client可以清晰的知道每个ACK对应的是那条数据。如许虽然包管了可靠性，但效率低。
再看并行发送，client可以一次发送多条数据，那么server也要发送对应数量的应答给client(原则上要求server对每一条消息做出应答)。如许client发送时间，举行了重叠，效率得到提拔。但这也引来了几个问题。
- client怎么知道那个ACK是哪个发送数据的应答？如果client担当到的ACK与发送数据数量相同，那至少表明client发送的数据，server都收到了。但如果client收到的ACK数量少于发送数据的数量呢？此时client就不清晰那个发送数据没有被server担当到。
- 因为网络环境复杂，server担当到数据的顺序不一定是按照client发送数据的顺序。此时，如果client把报文分两次发送，server就有大概先收到数据，再收到报头；这就不可靠了。
对于上面两个问题，我们可以对发送的数据 和 ACK 举行编号。
此时client就可以根据每个ACK的编号，来确定哪个发送数据被server担当到了。而server也可以根据发送数据的序号，举行排序，从而包管数据的按序到达。
上面的序号就是 32位序号 和 32位确认序号。
- 32位序号：用于对TCP报文段举行编号和排序。每个TCP报文段都有一个唯一的序列号，确保数据的唯一性和可识别性。
- 32位确认序号：用于标识接收端确认收到的数据段。它是乐成收到的数据序列号加1，表示接收端已经乐成接收了序列号小于该确认序号的所有数据。
注意：32位确认序号还表示，确认序号之前的所有的报文已经被对方全部收到了。为什么要如许规定？允许少量报文的丢失，提高了效率。
如上图，如果server发送的3个ACK，只有序号为301的ACK被client担当到了，那client就会以为发送的3条数据都被server担当到了，效率提拔了。
那这里，我们大概会有一个问题？32位序号 和 32位确认序号 可以同一个字段吗？答案是不能。
向上图，client 和 server互相发送信息。在情况1 server对client的回应是发送两条信息，那server可不可以将这两条信息作为一条信息发送？要知道发送的消息都是完整的TCP报文，而ACK只是一个ACK标记位置1的报头，那将报头和 “hello” 数据合并不也是一个完整报文吗？如许不仅对client发送的"hello"举行了应答，而且还对client的信息举行了复兴。这些效率举行了提拔。像如许报文多数既是数据(必要32位序号，包管按序到达)，又是对汗青报文简直认(必要32位确认序号)，32位序号 和 32位确认序号 同事利用，不能是同一个字段。
6种标记位 和 16位紧急指针
我们知道一个server会被多个client毗连，这么多毗连，总会有不同的链接哀求。
即server一定会同时收到各种各样不同范例的TCP报文，也就表示报文要有范例，怎样表示报文的范例？TCP中是6种标记位来表示报文范例。
- URG：紧急指针是否有用
- ACK：确认序号是否有用
- PSH：提示接收端应用步伐立即从TCP缓冲区把数据读走
- RST：对方要求重新建立毗连，我们把携带RST标识的称为复位报文段
- SYN：哀求建立毗连；我们把携带SYN标识的称为同步报文段
- FIN：关照对方，本端要关闭了，我们称携带FIN标识的为结束报文段
这里我们先容URG，PSH，RST。
URG 和 16位紧急指针
在client 和 server 双方通讯时，TCP报文要按照32位序号排序，按序处置惩罚，也就是排队。如果此时 服务器通讯双方有一些紧急数据时，因为TCP报文是有序号的，那该紧急数据也要按序处置惩罚吗？这就不好了，我们应该尽快处置惩罚紧急数据，即该报文要提前处置惩罚，也就是要插队。
此时，我们就必要 URG 和 16位紧急指针。
- URG标记位被置 1 ，表示该报文是紧急报文
- 16位紧急指针表示，在当前报文中，紧急数据在有用载荷中的偏移量
注意：只有URG无效，16位紧急指针也就无效；只有URG被置1,16位紧急指针也要被查看
这就有一个问题。紧急数据的大小是多少？毕竟16位紧急指针只是给了一个地址，并没有给紧急数据有多少个字节。答案是 1个字节。
紧急使命都有哪些？
PSH
当client 给 server 发送 “hello” 时，server要给 client 发送 ACK；但不仅仅只发送 ACK 还会同步 窗口大小。比较发送的是一个完整报文。
如果server因为上层http 处置惩罚一个比较耗时的使命，导致历程卡主了。client 给 server 发送 “hello”， server 给 client 发送 ACK ，同时更新窗口大小为 0；
此时表示，server的担当缓冲区满了，client知道不能发送消息了，只能等待。那以后client 怎样知道 server 缓冲区的情况，这会不会出现双方互相当待的情况？
并不会，此时client会定期向server发送询问报文(只有报头)，根据TCP简直认应答机制，server要给client发送ACK(携带了server的窗口大小)。同时 当上层将担当缓冲区的数据取走，也就是server担当缓冲区的剩余空间 从 0 变为 非0。server 会主动给client发送窗口大小更新报文。
上面两种策略同时利用，那种方式先被client收到，client就会继续发送信息。
其中，client发送的询问报文，就是一个PSH标记位被置1的报头。
注意：PSH不仅仅利用在上述场景中，在所有数据必要尽快交付的场景下，都可以利用。如Linux的指令输入
RST
我们知道TCP通讯的前提，必须举行三次握手。这里有个问题，TCP是包管可靠性的，那是不是三次握手必须乐成？不是，三次握手大概失败。那TCP包管可考性是怎么回事，该可靠性不是包管数据100%发送到，而是数据被接收方收到，发送方要知道；数据发送出现问题，发送方也要知道。
如今我们以三次握手出现问题为例，先容RST出现场景。
我们先要知道对于client 和 server 来说， 什么时候，毗连建立好了。
- 对于client，是发出ACK就以为毗连建立好了
- 对于server，是要收到client发送的ACK，才以为毗连建立好了
注意：这里client 和 server 以为建立好链接有一定的时间差
相识上面这点，我们再往下看。其中SYN 和 SYN + ACK 如果丢包，我们不担心。因为SYN 和 SYN + ACK都有对应的应答，但 ACK 如果丢失，就不好办了。如果client发送的ACK丢包了，但client以为TCP毗连已经建立好了，而server因为还没有收到client的ACK，以为还没有建立TCP链接。这就存在了 毗连建立认知不一致 。此时client给server发送数据，server会给client发送一个重新建立链接的报文(RST标记位被置1 的报文)，此时client会知道发送的ACK丢包了，会重新建立链接。
另有许多别的例子。
下图就是linux-2.6.11.10中tcp的报头字段
总结
TCP包管可靠性，但又不仅仅包管可靠性，还会举行各种提高效率的设定。
以上就是我对于TCP协议的知识总结
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
