（注：本文部分摘自《计算机网络 谢希仁》）

目录

1.传输控制协议TCP

1.1TCP的主要特点：

1.1.1面向连接的运输层协议

1.1.2每一条TCP连接只能有两个端点，每一条TCP链接只能是点对点的（一对一）

1.1.3TCP提供可靠交付的服务

1.1.4TCP提供全双工通信

1.1.5面向字节流

1.2与TCP有关的面试问题

2.用户数据报协议UDP

2.1UDP协议的主要特点：

1.传输控制协议TCP

1.1TCP的主要特点：

1.1.1面向连接的运输层协议

（1）TCP的连接

TCP的许多特性都与TCP是面向连接的这个基本特性有关，因此要对TCP的连接有更清楚的了解。

每一条TCP连接唯一地被通信两端的两个端点所确定，所谓的端点就是套接字（或插口）。

套接字的表示方法：在点分十进制的IP地址后面写上端口号，例如IP地址是192.3.4.5，端口号是80，那么套接字就是（192.3.4.5：80） 。

（2）TCP的连接建立

三次握手：TCP建立连接的过程叫做握手，握手需要在客户端和服务器之间交换三个TCP报文段。此过程如下：

（3）tcp的连接释放

 四次挥手过程如下：

（4）tcp的有限状态机

可以看我之前的这篇文章，这里不再赘述。

TCP连接的状态——TIME_WAIT的存在意义https://blog.csdn.net/m0_54355780/article/details/121190546

1.1.2每一条TCP连接只能有两个端点，每一条TCP链接只能是点对点的（一对一）

1.1.3TCP提供可靠交付的服务

（1）可靠传输的工作原理

①停止等待协议：

“停止等待”就是每发送完一个分组就停止发送，等待对方确认。在收到确认后再发送下一个分组。

• 无差错的情况下：一端发送，另一端等待并接收
• 出现差错的情况：一端在一段时间（会设置有超时计时器）一直没有收到确认，认为自己刚发送的内容丢失，于是重新发送，这就叫超时重传。这里需要注意三点：第一，发送完自己的分组需暂时保留自己的副本，以防超时重传；第二，分组和确认分组要编号，从而确认哪些分组收到确认，哪些分组没有收到确认；第三，超时计时器设置的重传时间应当比数据在分组传输的平均往返时间长一些。
• 确认丢失和确认迟到：  
• 信道利用率 

等值等待协议的信道利用情况如下图：

为了提高效率，发送方可以不使用低效率的停止等待协议，使用流水线传输，流水线传输就是发送方可以连续发送多个分组，不必每发完一个分组就停下来等待对方的确认。

②连续的ARQ协议

连续ARQ协议规定：发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。接收方采用累计确认的方式，也就是说：接收方不必对收到分组逐个发送确认，而是在收到几个分组之后，对按序到达的最后一个分组发送确认。

（2）可靠传输的实现

①超时重传时间的选择

报文段的往返时间RTT：采用自适应算法，记录一个报文段发出的时间，以及收到相应确认的时间。这两个时间之差就是RTT。

平滑的往返事件RTTs：RTT的一个加权平均往返时间

上式的α值在RFC 6298推荐为0.125 。

超时重传时间RTO：报文每重传一次，就把超时重传时间RTO增大一些，取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时，才根据下面的式子计算超时重传时间。

②选择确认SACK

如果收到的报文没有差错，但是未按序号，中间还缺少一些数据，使用选择确认可以只传送缺少的数据而不重传已经确认到达接收方的数据。

要使用选择确认，需在TCP首部的选项中加上“允许SACK”的选项，并且双方必须事先商定好。

但是首部最长40字节，如果要报告5个字节块的边界信息，那么5个边界需要2*5*4=40个字节来表述，再加上一个字节指明SACK选项命令一个字节指明SACK占用多少字节，这就一共需要42字节，超出首部长度。因此大多数的实现还是需要重传全部的数据块。

③流量控制

流量控制的目的：让发送方的发送速率不要太快，从而让接收方来的及接收

• 滑动窗口：在 TCP 的报头中有一个字段叫做接收通告窗口，这个字段由接收端填充，是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。所以发送端就会有一个发送窗口，这个发送窗 口的大小是由接收端填充的接收通告窗口的大小决定的，并且窗口的位置会随着发送端数据 的发送和接收到接收端对数据的确认而不断的向右滑动，将之称为滑动窗口。（TCP的滑动窗口以字节为单位）p3-p1=A的发送窗口；p2-p1=已发送但尚未收到确认的字节数；p3-p2=允许发送但尚未发送的字节数。此外，需要注意的是，并不是发送方将数据直接发给接收方，而是发送方的应用进程把字节流写入TCP的发送缓存，发送缓存用来暂时存放发送应用程序传送给发送方TCP准备发送的数据以及TCP已发送出但尚未收到确认的数据。接收方的应用进程从TCP的接收缓存中读取字节流，接收缓存用来暂时存放按序到达但尚未被接收应用程序读取的数据以及为按序到达的数据。最后在滑动窗口的部分知识中需要注意三点：第一，同一时刻，发送方的发送端口并不总是和接收方的接收窗口一样大，其会根据网络拥塞情况适当减少自己的窗口值；第二，不按序到达的数据，先临时存放在接收缓存中，等到缺少的字节收到后，再按序交付给上层的应用进程；第三，TCP接收方要有累计确认的功能。
• TCP的传输效率：TCP报文段的发送时机有三个控制机制：第一种，缓存中存放数据达到MSS（最大报文段长度）字节时，就组装成一个TCP报文段发送；第二种，发送方应用进程指明要求发送报文段；第三种，发送方的一个计时期限到了，就把当前已有 缓存数据并且<=MSS装入报文段发送出去。

④拥塞控制

• 满开始：由小到大逐渐增大拥塞窗口数值。
• 拥塞避免：为了防止拥塞窗口增长过大引起网络拥塞，设置慢开始门限。然后拥塞避免的算法思路就是让拥塞窗口缓慢增大，即每经过一个往返时间RTT就把发送方的拥塞窗口加一。
• 快速重传：接收方不要等待中积极发送数据的时候再进行对之前数据的捎带确认，而是收到数据立即发送确认。快重传算法规定：发送方一连收到三个重复的确认，就应当进行快重传。
• 快速恢复：当出现超时的时候，不启动慢开始，而是执行快恢复算法。发送方调整门限值=出现超时的cwnd(拥塞窗口)/2。

1.1.4TCP提供全双工通信

1.1.5面向字节流

流式服务的特点：TCP 字节流的特点，发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系，应用程序对数据的发送和接收是没有边界限制的。

1.2与TCP有关的面试问题

（1）为什么时三次握手，可不可以是两次握手，为什么？

如果是两次握手，那么如果出现这种情况：发送端发送请求连接报文，但是由于在网络中出现了滞留并没有按时到达接收端，等到一段时间发送端再次发送连接请求报文，接收端接收之后并发送确认连接。这样两次握手建立连接1。但是之前在网络中滞留的连接请求报文并没有丢失，于是发送给接收端，接收端误以为建立连接，于是就回复确认建立连接，所以此时又建立了连接2，但是发送端并不会给连接2发送数据，所以接收端一直处于等待，就会浪费接受端许多资源。

三次握手也可以是四次握手：接收端在回复确认建立连接报文的时候，将其分成两个报文段，一个是回复对发送端的连接确认，一个是发送自己的同步报文段。

（2）三次握手时可能出现什么攻击？

可以参考下面这篇文章：

TCP三次握手有哪些漏洞？https://www.cnblogs.com/HuiH/p/12599048.html可能出现的攻击有三种：SYN flood的攻击，TCP全连接攻击，Land攻击。

（3）四次挥手的过程可以用三次完成吗？

关闭连接时，服务器端收到FIN报文，并不会立刻关闭SOCKET,先回复ACK报文，等到服务器端的所有报文都发送完了，才发送FIN报文。所以不能三次完成，将ACK和FIN不能放在一起发送。

（4）对于三次握手四次挥手的面试题，可以看看这个文章

面试官，不要再问我三次握手和四次挥手https://zhuanlan.zhihu.com/p/86426969

（5）同一个端口可不可以被一个 TCP 和一个 UDP 的应用程序同时使用？

可以。原因是端口的唯一性标识是：端口号+协议名称。所以TCP和UDP的端口完全没有任何关系，协议内部端口号唯一。

追问：程序在连接到端口时，怎么知道此时从该端口进来的数据是tcp的还是udp的呢？

操作系统根据接收的IP数据包的首部内的8位协议来判断这是什么报文，从而直接交给相关的内核进程或者协议栈处理。

追问：一个端口是否可以绑定多个端口号？

可以。一个进程可以打开多个文件描述符，每个文件描述符对应一个端口号，所以一个进程可以绑定多个端口号。Linux会给每个socket分配一个唯一的文件描述符，通过这个文件描述符来区分对应的套接字。

追问：一个端口号是否可以被多个进程绑定？

不可以。但是在父子进程中可以实现多进程绑定一个端口号，因为子进程具有父进程的文件描述符副本，可以处理绑定到同样的端口上的连接

追问：一个端口可以同时连接多个TCP和多个UDP吗？

一个端口可以建立多个TCP连接，所谓的同一个端口是指服务器端的ip和port不变，但是只要客户端的ip和port不同就可以。一个端口同一时间只能绑定一个socket。UDP是面向无连接的，所以不存在多个UDP连接，只是服务端接收UDP数据需要绑定一个端口，一个socket只能绑定一个端口而已。

（如果还不是很清楚这方面的问题，可以参考下面几篇文章）

TCP和UDP使用同一端口通信https://blog.csdn.net/szm1234/article/details/116994450一个端口号可以同时被两个进程绑定吗？https://zhuanlan.zhihu.com/p/280672302#:~:text= 由上述结果可知：TCP、UDP可以同时绑定一个端口8888，但是一个端口在同一时刻不可以被TCP或者UDP绑定2次。,原因如下： TCP和UDP传输协议监听同一个端口后，接收数据互不影响，不冲突。快狗二面 一个端口可以 同时TCP 又UDP 吗？https://cloud.tencent.com/developer/article/1813256

（6）同一个应用程序可以创建多个套接字吗？

端口是唯一的，系统中任一个端口只能被一个程序占用。一个程序可以创建多个Socket，但多个Socket是不能共用端口的。

（7）什么是 TCP 粘包，如何解决？

定义：指的是多个报文数据内容融合在一起被接受

解决方案：

①循环接收、发送；即就是一次send,一次recv……

②设置分割标志。

③在头部加上长度控制，然后读取的时候只读取头部信息中指定的长度。

（8）为什么UDP数据包不发生粘包，而TCP会出现粘包？

TCP协议是面向链接的，收发两端都必须要有成对的socket,因此发送端为了将多个发往接收端的包更有效的发送，使用了优化的方法nagle算法。

面向流的服务是没有消息保护边界的。

UDP协议是无连接，面向消息的，支持一对多的模式，所以接收端的套接字缓冲区采用链式结构记录每一个到达的UDP包。

面向消息的通信是由消息保护边界的。

（9）如果接收端填充的接收通告窗口为 0，发送端接下来怎么处理？

接收端通告的窗口大小变成0，发送端会发一个1字节的段，这一个字节段可以是下一字节的数据，如果没有新的数据段发送的时候，就发一个ack，强制接收端重新宣告下一个期望的字节和窗口大小。如果接收方回复窗口大小仍然为零，则发送方的探测定时器加倍。没有收到ACK时，发送探测包的最大次数之后连接超时。

（10）什么叫糊涂窗口综合征？

糊涂窗口综合症是指当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小； 极端情况下，有效载荷可能只有1个字节；传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象。

要解决这个问题，发送方要把数据累计成足够大的报文段，等到其到达接收方缓存区的一半大小，再发送报文。接收方等待一段时间，使得自己的接收缓存区中能够容纳一个最长的报文段或缓存区有一半空闲，然后再去发送确认报文。

（11）在 TCP 的实现中广泛使用的 Nagle 算法是什么？

若发送应用进程，把要发送的数据逐个字节的送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个发送报文段发送出去。

（12）TIME_WAIT 状态存在的原因？

①保证发送端发送的最后一个ACK报文段能够到达接收端，从而避免接收端因为收不到ACK报文段而不按照正常步骤进入CLOSED状态。

②使本链接持续的时间内所产生的所有报文都从网络中消失，避免下一个新连接中出现旧的连接请求报文段。

2.用户数据报协议UDP

2.1UDP协议的主要特点：

（1）UDP是无连接的，可以减少开销和发送数据之前的时延。

（2）UDP使用尽最大努力交付，不保证可靠交付，主机不需要维持复杂的连接状态表。

（3）UDP是面向报文的，一次交付一个完整的报文。

（4）UDP没有拥塞控制，因此网络出现的拥塞不会使得源主机的发送速率降低。

（5）UDP支持一对一、一对多、多对一、多对多的交互通信。

（6）UDP的首部开销小，只有八字节。

TCP协议

• TCP报文段
• TCP建立连接的过程（三次握手）
• TCP拆除连接的过程（四次挥手）
• TCP发送数据的过程(超时和重传)

什么是TCP协议

传输控制协议（TCP，Transmission ControlProtocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793 定义。TCP协议建立的是一种点到点的，一对一的可靠连接，与UDP相比以牺牲效率为代价换取高可靠性的服务。

TCP报文段

TCP报文段也叫TCP分组，是TCP协议传输和接收数据的一种封装格式，只有按照该格式发送的数据才可以被TCP协议通信的双方正确的接收与解析。

TCP报文的组成部分描述如下：

• 源端口：标识源端应用进程，即发送TCP分组的进程端口号。
• 目的端口：标识目的端应用进程，即需要接收分组数据的进程端口号。
• 序号（seq）：在SYN标志未置1时，该字段指示了用户数据区中的第一个字节的序列号；在SYN标志置1时，该字段指示的是初始发送的序列号。
• 确认号（ACK）：用来确认本端TCP实体已经接收到的数据，其值表示期待对端发送的下一个字节的序号，实际上告诉对方，这个序号减1以前的字节已经正确接收。例如发送确认号为1001，则表示前1000个字节已经被确认接收了。
• 数据偏移：表示以 32bit为单位的TCP分组头的总长度，用于确定用户数据区的起始位置。
• RST：连接复位，重新连接
• SYN：同步序号，当SYN置1时，表示建立连接，分组将发送seq为初始序列号（其值一般随机）
• FIN：结束标志，表示关闭连接，当该字段置1时，表示分组将要关闭连接
• ACK：确认号有效的标志，置1时表示确认号有效。
• URG：紧急指针有效的标志，置1时表示紧急指针有效
• PSH：Push操作。

TCP建立连接的过程（三次握手）

TCP连接的建立是通过三次握手的过程完成的，下面将具体讲解何为三次握手：

第一次握手

第一次握手由客户端向服务器 发出：客户端发送一个TCP数据报，其中，TCP分组的源端口为客户端发起通信建立的进程端口，而目的端口为服务器处理请求的进程端口号，比如80端口。在表示建立连接的TCP分组中，SYN标志位为被置1，则告知服务器发送该分组的目的是请求建立连接，并且当SYN置1时，该分组中的seq字段发送的是初始序列号cilent_isn，初始序列号的取值方案有多种，一般取随机值。

第二次握手

第二次握手由服务器向客户端发出：服务器在成功接收了客户端第一次握手发送的分组后，首先需要解析收到的TCP分组，发现SYN置1后，得知这个客户端发送分组的目的是为了建立连接，在确认完毕分组信息后，服务器也会向客户端发送一个TCP分组来代表第二次握手。

这个由服务器发送的TCP分组包含以下内容：

• 首先将代表建立连接目的的SYN标志位同样置1
• 然后随机地产生服务器端的初始序列号 server_isn在seq字段中发送
• 同时将代表累计确认接收字节位数的ACK确认号发送，该确认号ACK的值为客户端发送的TCP分组中的初始序列号+1,即cilent_isn+1。也就是发送服务器期望接收的下一个字节序号。

第三次握手

第三次握手由客户端向服务器发出：客户端在接收到服务器第二次握手的回复之后，同样会接收来自于服务器的TCP分组并进行解读：由SYN为1解读该TCP分组的目的是继续建立连接，由分组中的ACK确认号了解到服务器已经成功接收了前cilent_isn个字节的内容，并期望接收第cilent_isn+1个字节的字节序号，同时累计确认来自服务器的初始序列号。并发送最后一个TCP分组给服务器来完成第三次握手。

这个由客户端发送给服务器的最后一个TCP分组的内容有：

• 代表继续建立连接的SYN为1
• 发送服务器期望接收的值为cilent_isn+1的序列号字段seq
• 发送期望接收到的下一个字节的序列号，也就是确认号ACK，值为server_isn+1

为什么需要三次握手

为什么TCP的连接必须进行三次握手，而不是一次或两次？

为了防止建立重复的连接而损耗资源或造成其他问题

谢希仁版《计算机网络》中的例子：“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

也就是说，假如只采用两次握手，会让因网络错误延时到达的客户端连接请求被服务器接收时，服务器无从得知这是一个失效的请求而与客户端建立一个无效的连接。在三次握手机制的情形下，这样无效的请求分组会被返回给客户端来确认，而客户端不在等待该由该分组产生第三次握手的状态，服务器得不到客户端的回应，等待超时后会取消本次连接的建立。从而避免了错误连接的建立

TCP拆除连接的过程（四次挥手）

四次握手的连接关闭过程与三次握手相类似：
四次挥手的过程简述如下：

第一次挥手： 客户端因为不再有数据发送给服务器，所以向服务器发送FIN报文表示想要关闭连接，不会再发送数据了。同时包含客户端的报文序号M

第二次挥手： 服务器在接收了来自客户端的FIN报文后，得知客户端不再发送数据，将要关闭连接。但是，此时服务器端获取还有部分数据没有回传给客户端，服务器可能还要向客户端发送一部分数据才能关闭连接。所以服务器不会立马同意关闭连接，而是先发送表示确认信息的ACK报文，该ACK报文中包含了值为M+1的确认号。

第三次挥手： 在服务器端完成向客户端传送最后的数据后，此时不再有数据需要传输了。那么服务器也准备关闭连接，所以向客户端发送表示关闭连接的FIN报文，报文中包含了服务器端的序号N

第四次挥手： 在客户端也收到了服务器端发送的FIN报文之后，得知服务器端也可以关闭连接了，此时再向服务器发送最后一次确认报文ACK，使连接成功关闭，ACK报文中的确认号为N+1

为什么需要四次挥手？

为什么需要中间两次挥手？
为什么需要其中的第二次和第三次的原因其实已经提到，假如在服务器收到客户端的第一次挥手就准备关闭连接发送FIN报文，不再发送数据。那么只是客户端单方面提出了中断通信的请求而导致连接关闭，使服务器中要发往客户端的最后数据不能正常传送，会导致通信不完整。
为什么需要第四次挥手？
第四次挥手同样是用来解决一个因网络时延滞后到达的失效请求的问题。
请分析这样一个情形：即假如客户端一次发送了两个关闭请求，其中一个滞后了很久才到达，此时它们当时建立的连接已经被第一个请求关闭。而服务器又再次和客户端建立了新的连接，并且此时不需要关闭，但是这个失效的关闭请求滞后到达了。

• 假如没有最后一次挥手，那么服务器以为客户端要关闭连接，一次发送ACK和FIN报文后连接就被错误关闭了，这样显然是存在问题的。

• 假如有最后一次握手，服务器在收到失效报文后仍然会发送ACK和FIN报文给客户端来确认客户端是否真的要关闭连接。而客户端此时的状态并不是等待关闭连接的状态，所以不会给服务器发送ACK报文进行关闭连接的确认回复，服务器在等待一段时间超时后会取消连接的关闭，从而不会因为失效的报文让连接错误地关闭。

TCP发送数据的过程(超时和重传)

TCP数据的发送过程也与建立连接的过程相类似：
发送数据的过程采用了累计确认的机制，其中ACK表示的是累积确认的字节序号。
如上图，发送的TCP分组中可以包含数据，也可以不包含数据，但是一定需要包含seq序号和确认号。seq序号表示数据区中第一个字节的序号，而回传的ack确认号的值为seq的值加上发送的数据字节数。表示这些字节的数据已经被确认接受了，并表达了期望接收的下一个字节序号位置。

发送TCP分组的一方会在发送分组时设置超时时间并开启计时器，当在超时时间内未收到该分组的ACK回复时，会认为该分组丢失，并重发该分组。假如之前的分组被连续发送，而该分组及之后的分组已经被接收端确认，那么本次重复分组收到的ACK是累计确认的字节序号值，而非该分组的seq+数据字节数，如上图右侧所示。

感谢阅读，求关注收藏，等期末考试结束后会再出关于TCP流量控制和拥塞控制等方面更加详细的内容。超链接写好后会附在下面。
本文参考了哈工大mooc计算机网络的内容

TCP 协议头全解

写在前面

好久没有写在前面了，这次写下。很久没有更新，csdn 估计要忘了我了，排名一直在掉，提笔写这篇文章，说实话，从题目定了，到下笔，中间大概有 3 天之久，到完成可能还更晚。一来是最近可能有点忙，二来有点不知道该如何提笔了，有时候在想 ”意义“ 二字。有时会颓然觉得，所思所想所做，都无甚大意义，大抵如此。

说回技术文章，我看技术文章有个毛病，看长篇大论，很容易就不想看了，密密麻麻写了一堆，我靠，我根本不想看好嘛。

然鹅，到我写的时候，也不可避免的会堆一些学术文档来说明。确实很恶心，但又有啥办法呢，为了能够明确主题和主旨，所以加个模块 《本文将带你学会》总结一下我这篇文章将为你带来什么，你能从这里 get 到什么。避免大家浪费时间是不。

文章我尽量写的简洁一点，把我在学习过程中疑惑的点整理出来。

害，干货啊干货，前有干货，所以，三连很有用。

本文将带你学会

1. 从 wireshark 中来看面试中常问的 tcp 三次握手 四次挥手 真正的数据面目到底是什么？

2. 看到 TCP/IP 五层模型的具象化真实表达

3. 网络传输中 TCP 头全解析

我用 wireshark 抓了我的接口

从 wireshark 看 ”三次握手“ 和 ”四次挥手“

首先带你们看看，一次接口请求，在网络中都经历了什么

上图，三次握手 建立连接，请求接口传输数据。这个时候请求结束，TCP 进行了一波 Keep-Alive

最后服务端向我请求端发起了断链，进行了四次挥手 断开连接。

三次握手建立连接，四次挥手断开连接。这个我们在后面讲为什么要这么做。重点看数据包中都发了写什么

首先拿第一个 SYN 请求连接包来举例看

这里可以具象化地看到，我们所谓的分层都是些什么东西，他们的实际表现形式

TCP/IP 五层最终的表达是什么？

物理层： Frame 11561: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface en0, id 0

数据链路层： Ethernet II, Src: Apple_cb:e5 (90::cb:ec:c5), Dst: Huaa:04 (ac:7:40:ea:04)

网络层： Internet Protocol Version 4, Src: 172.16.25.144, Dst: 192.168.26.144

传输层： Transmission Control Protocol, Src Port: 58173, Dst Port: 18080, Seq: 0, Len: 0

应用层： 这里没有，下面 HTTP 协议就有了

看一眼，HTTP 的

应用层： Hypertext Transfer Protocol

看到这里有些蒙的同学可以看看我之前的文章，补补课复习一下

网络编程之 Socket 编程 一文看懂

网络分层流转—从浏览器请求到服务端响应究竟经历了什么？

本篇重点是 传输层协议 TCP ，篇幅问题，就不节外生枝，直接走主线

Transmission Control Protocol 中都存了什么

在这里我要放一下，网络上都放烂了的图，当然我会抄一遍，用自己的形式展示出来 [狗头]

给了图，不解释下什么意思，就是耍流氓了，这里大概给个解释，让大家对这个设计有个理解

源端口号 Source Port： 一般来说就是客户端发起请求时使用的端口号，这个在浏览其发起请求时会自动分配一个。比如这里我被分配的端口号就是 58173。这个作用是服务端给你返回数据的时候能找到你客户端的端口

目的端口号 Destintion Port： 这个就是你要访问的服务的端口号，比较常用的如 8080 ，我这里是 18080。同理，你请求到了服务端总要知道服务是由哪个端口提供的吧。

序号 Sequence Number： TCP 为了保证包的顺序到达，就需要给每个包一个需要来标识它的顺序，它解决了乱序的问题，当然这个逻辑也是在两端程序逻辑控制的，真正的包到了网络中是怎么样的，那对你来说可就是鞭长莫及干瞪眼了。（祈祷他能平安到达吧）

关于序号的生成规则

TCP 是面向字节流的，这意味着 TCP 在传输数据的过程中会为每个字节按照顺序进行编号。例如对于传输 10 kb 的 HTML 文档

10 kb = 10 * 1024 byte = 10240 byte 一共 10240 个字节。

序号是 32 位 是 2^32 是 4 294 967 296 = 4G 所以 TCP 可以对 4G 的数据进行编号，超过之后回 0 重新计数

那对于上面的 10 kb 其编号范围就是 [0,10239]

这里的序号标识的是此报文段中，数据的第一个字节的序号，如上述 10 kb 数据我们分成两等分传输

第一段： 5 kb Sequence Number = 0 ； 其范围是 [0,5119]

第二段： 5 kb Sequence Number = 5120 ； 其范围是 [5120,10239]

相信大家可能注意到了一点，超出 4G 重复使用编号的问题，这种情况其实基本不用担心，一般情况，旧的序号早就到达终点，或者丢失了。

确认序号 Acknowledgement Number： 为了保证可靠性，发出去的包需要确认到达，就有了确认序号，这个解决了丢包的问题，一定时间没确认收到就重发嘛。我们 TCP 能做啥呢，就是不断的重传，寄希望于能得到对端的收到确认，卑微也就至此了。

同样的 32 位确认序号，表示的是 期望收到对方下一个报文的序号值。

TCP 的可靠就是基于此，我们要确认每个发送出的报文都被确认收到了。

通讯双方在接到对方的报文后，都需要发送一个对应的确认报文，要告知已经收到，有确认报文就需要确认好

如第一段： 5 kb Sequence Number = 0 ； 其范围是 [0,5119] 发送过来，此时回 ACK 确认报文 Acknowledgement Number = 5120

标志位 Flags： 标志位共 16 位，首部占 4 位，保留 6 位，剩余 6 位每没一位标志不同的意思

1. 首部 Header Length 4 位，表示 TCP 报文段首部长度，看了下有的地方也叫它数据偏移，可以理解为 TCP 报文起始位置 到 数据部分 payload 的起始位置 也就是上图中 [源端口号 , 选项, 填充 ] 这部分数据的大小，4 位 0000 最大为 1111 = 15 ，这里每个数代表 4 byte，所以首部最大是 15 * 4 byte = 60 byte
2. 保留 6 位 保留 6 位默认给 0，用于之后的拓展
3. 标志位 目前 6 位下图，0 表示没有，1 表示标识，每位代表不同含义
   1. 紧急 Urgent URG 该位为 1 表示后面要说到的 紧急指针 有效，用于告诉系统，此报文段中包含紧急数据，应该尽快传送，而不是按原有顺序排队传，紧急吗，就是要加急传输。
   2. 确认 Acknowledgment ACK 该位为 1 表示确认序号 Acknowledgement Number 有效，一般称携带 ACK 标志的 TCP 报文段称为确认报文段，TCP 规定在建立连接后所有的传输报文都必须报 ACK 设置为 1
   3. 推送 Push PUS 该位为 1 表示该报文高优先级，接收方 TCP 应该尽快将其推送给应用服务，而不用等到 TCP 缓存填满后再一起发送
   4. 复位 Reset RST 该位为 1 表示在 TCP 连接中出现了严重的错误，需要释放并重新建立连接，一般携带 RST 标志的报文段称之为 复位报文段
   5. 同步 Syn SYN 该位用于标识此报文为同步报文，SYN = 1 ACK = 0 表示此次是 请求建立连接报文段，如果对方同意建立连接，则会返回一个 SYN = 1 ACK = 1 的响应报文。
   6. 终止 Fin FIN 用于标识断开连接，为 1 是表示此报文的数据发送方数据已发送完毕，请求断开释放连接，这个在 ”四次挥手“ 时会用到。

窗口大小 Window ： 16 位，该字段指定此时允许对方发送的最大数据量，也就是说此数据是我方缓冲区剩余大小，用于控制发送数据的速度

窗口大小是指，从本端报文的 确认序号 Acknowledgment Number 开始，还允许对方发送的数据量。

比如 Acknowledgment Number = 100 Window = 60 ，那么标识报文发送方还有 60 字节的接收空间，即序号范围是 [100,159] 的数据。

校验和 CheckSum： 16 位 用于检测 TCP 报文段在传输过程中有没有损坏，如果损耗则丢弃，采用 CRC 算法，这个是保证 TCP 可靠传输的重要一环。 具体生成校验规则，感兴趣同学可以自行搜索算法。

紧急指针 Urgent Pointer： 16 位 ，当标志位 URG 为 1 时有意义，用于指出报文段中紧急数据的字节数。发送方会将紧急数据插入到本次报文段的最前面，而后面的仍然是普通数据，紧急指针指示的是紧急数据的末尾在本段报文数据的位置。

给你们看看 16 进制表示，而老说的位 ”01010101“ 而进制传输本质是 01 嘛，为啥不给你看 01 ？ 因为不好看哈哈

不想写了，本文到这，下期再见