TCP深度了解

发表于 2021/03/25

作者 裘俊云 47 分钟阅读

TCP介绍

开放式系统互联模型（英语：Open System Interconnection Model，缩写：OSI；简称为OSI模型）

第七层：应用层 HTTP、HTTPS、FTP、Telnet、SSH、SMTP、POP3
第六层：表示层把数据转换为能与接收者的系统格式兼容并适合传输的格式
第五层：会话层 Socket：实现了下面两层的封装
第四层：传输层实现了TCP协议
第三层：网络层实现了IP协议
第二层：数据链路层以太网协议、无线局域网
第一层：物理层

socket

socket其实并不是一个协议，它工作在OSI模型会话层（第5层），是为了方便大家直接使用更底层协议（一般是TCP或UDP）而存在的一个抽象层。Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是调用接口（API）。

以太网协议

最底层的以太网协议（Ethernet）规定了电子信号如何组成数据包（packet），解决了子网内部的点对点通信。但是，以太网协议不能解决多个局域网如何互通，这由 IP 协议解决。

IP协议

IP协议定义了一套自己的地址规则，称为IP地址。它实现了路由功能，允许某个局域网的 A 主机，向另一个局域网的 B 主机发送消息。（路由器就是基于 IP 协议。局域网之间要靠路由器连接。)

IP 协议只是一个地址协议，并不保证数据包的完整。如果路由器丢包（比如缓存满了，新进来的数据包就会丢失），就需要发现丢了哪一个包，以及如何重新发送这个包。这就要依靠 TCP 协议。

简单说，TCP 协议的作用是，保证数据通信的完整性和可靠性，防止丢包。

TCP协议

wireshark TCP抓包工具

将不同电脑上的数据，必须通过一个共同的协议进行包装，才能实现数据传递和解读。

（图片说明：以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右。IP 数据包在以太网数据包里面，TCP 数据包在 IP 数据包里面。）

TCP协议介绍

SEQ、SYN、ACK、ISN

SEQ：sequence number，TCP 协议为每个包编号。一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。
ISN：Initial Sequence Number，第一个包的编号是一个随机数，动态生成的
SYN：Synchronize Sequence Numbers
ACK：acknowledgement

TCP socket states

状态	端点	描述
LISTEN	Server	服务的监听态，等待客户端的链接
SYN-SENT	Client	客户端发送`connect()`,发送第一次握手等待服务的响应
SYN-RECEIVED	Server	服务的发送第二次握手，回应客户端的第一次握手，等待客户端的第三次握手
ESTABLISHED	Server and client	两端建立链接
FIN-WAIT-1	Server and client	两端发送断开链接信号`close()`，等待应答
FIN-WAIT-2	Server and client	收到应答，等待确认可以关闭信号
CLOSE-WAIT	Server and client	收到`close()`信号，处理事物等待关闭
CLOSING	Server and client	Waiting for a connection termination request acknowledgment from the remote TCP.
LAST-ACK	Server and client	已经发送最后确认关闭的ack
TIME-WAIT	Server or client	发送我收到你的确认关闭了，等待足够的时候以确保他收到这个ack
CLOSED	Server and client	关闭

三次握手

第一次握手：客户端发送网络包，服务端收到了。

这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。

这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。

这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

半连接队列

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN-ACK 重传次数的问题：

服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

ISN(Initial Sequence Number)

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

三次握手过程中可以携带数据吗

第一次第二次不行，第三次可以。

为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

SYN攻击

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

  
netstat -n -p TCP | grep SYN_RECV

常见的防御 SYN 攻击的方法有如下几种：

缩短超时（SYN Timeout）时间
增加最大半连接数
过滤网关防护
SYN cookies技术

四次挥手

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，客户端或服务器均可主动发起挥手动作。

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。

即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。

即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的，服务端通常执行被动关闭，不会进入TIME_WAIT状态。

在socket编程中，任何一方执行close()操作即可产生挥手操作。

为什么需要四次挥手

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手

2MSL等待状态

TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。

对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。

这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

存在的两个理由：

保证客户端发送的最后一个ACK报文段能够到达服务端。

这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。

防止“已失效的连接请求报文段”出现在本连接中。

客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

拥塞控制

TCP流量控制、拥塞控制

流量控制

什么是流量控制？流量控制的目的？

如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。

如何实现流量控制？

由滑动窗口协议（连续ARQ协议）实现。滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

流量控制引发的死锁？怎么避免死锁的发生？

当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。

拥塞控制和流量控制的区别

拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；常用的方法就是：（ 1 ）慢开始、拥塞避免（ 2 ）快重传、快恢复。

流量控制：流量控制是作用于接收者的，它是控制发送者的发送速度从而使接收者来得及接收，防止分组丢失的。

拥塞控制的算法

我们在开始假定：1、数据是单方向传递，另一个窗口只发送确认；2、接收方的缓存足够大，因此发送方的大小的大小由网络的拥塞程度来决定。

慢开始算法：
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。
慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。
这里用报文段的个数作为拥塞窗口的大小举例说明慢开始算法，实际的拥塞窗口大小是以字节为单位的。如下图：
从上图可以看到，一个传输轮次所经历的时间其实就是往返时间RTT，而且没经过一个传输轮次（transmission round），拥塞窗口cwnd就加倍。
为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：当cwnd<ssthresh时，使用慢开始算法。
当cwnd>ssthresh时，改用拥塞避免算法。
当cwnd=ssthresh时，慢开始与拥塞避免算法任意
注意，这里的“慢”并不是指cwnd的增长速率慢，而是指在TCP开始发送报文段时先设置cwnd=1，然后逐渐增大，这当然比按照大的cwnd一下子把许多报文段突然注入到网络中要“慢得多”。
拥塞避免算法
拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。
无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有按时收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
整个流程图如下：
（1）拥塞窗口cwnd初始化为1个报文段，慢开始门限初始值为16
（2）执行慢开始算法，指数规律增长到第4轮，即cwnd=16=ssthresh，改为执行拥塞避免算法，拥塞窗口按线性规律增长
（3）假定cwnd=24时，网络出现超时（拥塞），则更新后的ssthresh=12，cwnd重新设置为1，并执行慢开始算法。当cwnd=12=ssthresh时，改为执行拥塞避免算法
关于乘法减小（Multiplicative Decrease）和加法增大（Additive Increase）：
“乘法减小”指的是无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半，并执行慢开始算法，所以当网络频繁出现拥塞时，ssthresh下降的很快，以大大减少注入到网络中的分组数。“加法增大”是指执行拥塞避免算法后，使拥塞窗口缓慢增大，以防止过早出现拥塞。常合起来成为AIMD算法。
注意：“拥塞避免”并非完全能够避免了阻塞，而是使网络比较不容易出现拥塞。
快重传算法
快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方，可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。如下图：
快恢复算法
快重传配合使用的还有快恢复算法，有以下两个要点：
当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半（为了预防网络发生拥塞）。但是接下去并不执行慢开始算法
考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh减半后的值，然后执行拥塞避免算法，使cwnd缓慢增大。如下图：TCP Reno版本是目前使用最广泛的版本。
注意：在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用

滑动窗口

滑动窗口协议

用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输，提高网络吞吐量。

主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。

Wireshark抓包，了解TCP序列号Seq和确认号Ack

1. 下载安装wireshark TCP抓包工具

2. 编写python，功能是建立链接之后，客户端想服务的返送一个姓名，服务的确认收到，并返回打招呼

Sever.py

  
   import socket
   import time
   import threading
   
   def tcplink(sock, addr):
       print('Accept new connection from %s:%s...' % addr)
       sock.send('Welcome!')
       while True:
           data = sock.recv(1024)
           time.sleep(1)
           if data == 'exit' or not data:
               break
           print('Accept %s, send back: Hello, %s' % (data, data))
           sock.send('Hello, %s!' % data)
       sock.close()
       print('Connection from %s:%s closed.' % addr)
   
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   ad = (('localhost', 5000))
   s.bind(ad)
   s.listen(5)
   
   print('Waiting for connection...')
   while True:
       sock, addr = s.accept()
       t = threading.Thread(target=tcplink, args=(sock, addr))
       t.start()

Client.py

  
   import socket
   
   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
   addr = (('localhost', 5000))
   s.connect(addr)
   print(s.recv(1024))
   while True:
       data = raw_input('please enter a name:')
       if data == 'exit' or not data:
           break
       s.send(data)
       print(s.recv(1024))
   s.send('exit')
   s.close()

3. 调用python，打开WireShark

如果不想写python，可以直接在这里下载WireShark的抓包文件。原文的WireShark文件

想要抓取localhost本地的客户端链接本地的服务端，选中Loopback这个端口进行监控，如图

监控过滤条件使用：ip.src == 127.0.0.1 or ip.dst == 127.0.0.1

启动服务端开始监听

socket|⇒ python server.py
Waiting for connection...

通过netstat查看链接状态，可以看到服务的处于三种状态（LISTEN、SYN_RCVD、ESTABLISHED）的第一种状态中

  
~|⇒ netstat -ant  | grep 5000
tcp4       0      0  127.0.0.1.5000         *.*                    LISTEN

启动客户端，向服务的发起TCP链接

socket|⇒ python client.py
Welcome!
please enter a name:

再次通过netstat查看链接状态，现在就是TCP三次握手成功之后的双向链接状态了

  
~|⇒ netstat -ant  | grep 5000
tcp4       0      0  127.0.0.1.5000         127.0.0.1.54544        ESTABLISHED			// 服务的链接客户端
tcp4       0      0  127.0.0.1.54544        127.0.0.1.5000         ESTABLISHED			// 客户端链接服务端
tcp4       0      0  127.0.0.1.5000         *.*                    LISTEN						// 服务端的监听

这个时候，我们来通过WireShark分析下

其中每一次握手的TCP报文和wareshark对应的介绍（我就使用网图，不再自己画了），如下

网络七层协议对应关系如下

第五个packet中就是服务器向客户端发送sock.send('Welcome!')，可以很清晰的看到TCP报文的data段有Welcome!。

第六个packet，客户端向服务器发送确认收到Packet #5，其中Ack变成了9，表示我总共收到了9字节的数据，客户端的seq保持为1

4. Done，你已经会用了

建立链接的三次握手

使用Wireshark内置的绘制流功能，选择菜单栏中的 Statistics ->Flow Graph->TCP flow

每行代表一个单独的TCP包，左边列显示时间，中间列显示包的方向、TCP端口、段长度和设置的标志位，右边列以10进制的方式显示相关序列号/确认号，在这里选中任意行会高亮主窗口中该行所关联的包

我们可以利用这个流图更好的理解序列号和确认号是如何工作的

Packet #1：TCP会话的每一端的序列号都从0开始，同样的，确认号也从0开始，因为此时通话还未开始，没有通话的另一端需要确认

Packet #2：服务端响应客户端的请求，响应中附带序列号0（由于这是服务端在该次TCP会话中发送的第一个包，所以序列号为0）和相对确认号1（表明服务端收到了客户端发送的包1中的SYN）。需要注意的是，尽管客户端没有发送任何有效数据，确认号还是被加1，这是因为接收的包中包含SYN或FIN标志位（并不会对有效数据的计数产生影响，因为含有SYN或FIN标志位的包并不携带有效数据）。

Packet #3：和包2中一样，客户端使用确认号1响应服务端的序列号0，同时响应中也包含了客户端自己的序列号（由于服务端发送的包中确认收到了客户端发送的SYN，故客户端的序列号由0变为1）。此时，通信的两端的序列号都为1，通信两端的序列号增1发生在所有TCP会话的建立过程中

Packet #4：这是流中第一个携带有效数据的包（确切的说，是客户端发送的HTTP请求），序列号依然为1，因为到上个包为止，还没有发送任何数据，确认号也保持1不变，因为客户端没有从服务端接收到任何数据。需要注意的是，包中有效数据的长度为725字节

Packet #5：当上层处理HTTP请求时，服务端发送该包来确认客户端在包4中发来的数据，需要注意的是，确认号的值增加了725（725是包4中有效数据长度），变为726，简单来说，服务端以此来告知客户端端，目前为止，我总共收到了726字节的数据，服务端的序列号保持为1不变

Packet #6：这个包标志着服务端返回HTTP响应的开始，序列号依然为1，因为服务端在该包之前返回的包中都不带有有效数据，该包带有1448字节的有效数据

Packet #7：由于上个数据包的发送，TCP客户端的序列号增长至726，从服务端接收了1448字节的数据，客户端的确认号由1增长至1449。在抓包文件的主体部分，我们可以看到上述过程的不断的重复，客户端的序列号一直是726，因为客户端除了最初的725字节数据没有再向服务端发送数据，服务端的序列号则与此相反，由于服务端不断的发送HTTP响应，故其序列号一直在增长

断开链接的四次挥手

Packet #38：在确认了服务端发送过来的最后一个数据段之后，客户端将处理整个HTTP响应并决定不需要进一步通信了。此时客户端发送设置了FIN标志位的包38，其确认号和之前的包37一样

Packet #39：服务端通过将确认号加1的方式回应客户端期望关闭连接的请求（这里和包2中确认SYN标志位时所作的操作是一样的），同时设置当前包的FIN标志位

Packet #40：客户端发送最终序列号727，通过将确认号加1的方式确认服务端的FIN包。此时，通信双方都终结了会话并且可以释放用于维持会话所占用的资源

TCP：WireShark分析，序列号Seq和确认号Ack

Understanding TCP Sequence and Acknowledgment Numbers

wireshark抓包新手使用教程

知乎讲解三次握手四次挥手

WIKI Transmission Control Protocol

Tech, other

gitlab TCP 滑动窗口拥塞控制

本文由作者按照 CC BY 4.0 进行授权